Scaling Kanban with Domain Storytelling
If you search what is the STATIK approach in Kanban on the web, most probably you will see David Anderson’s article on top of search results. In the article, David teaches about STATIK (Systems Thinking Approach to Introducing Kanban). STATIK approach consists of 8 steps and each step is based on the previous one. Let’s summarize the steps.
Step 0: Identify Services (← I will focus on here)
For each service…
- Step 1: Understand what makes the service fit for purpose for the customer
- Step 2: Understand sources of dissatisfaction with the current system
- Step 3: Analyze demand
- Step 4: Analyze capability
- Step 5: Model workflow
- Step 6: Discover classes of service
- Step 7: Design the kanban system
- Step 8: Socialize the design and negotiate the implementation
In this post, I will talk about STEP 0. STEP Zero is a very important part of introducing the Kanban method. Kanban Method is also is very effective at the non-IT business or we can name it upstream. Non-IT businesses for example banking or insurance domains are very complex. The question is how are we going to introduce Kanban into those complex domains. In that situation applying Kanban become an art. Most of the examples in Kanban are based on the IT Software process which doesn’t make very sense to non-IT people.
We know that if we want to introduce Kanban Method, we have to apply STATIK. And In order to apply the STATIK approach, we have to start from STEP-0 which is Identify Services. And while identifying the services I found a very effective way that I will share it with you.
STEP — 0 — Identifying the Services
How do you identify the services? It is not an easy job especially if you work with complex domains like bank or insurance. In that stage, I would like to introduce the Domain Storytelling concept.
Domain Storytelling
Domain Storytelling is a collaborative modeling technique that highlights how people work together. Its primary purpose is to transform domain knowledge into pictographic language[1].
Domain Stories are told from an actor’s perspective. Actors may be a person, a group, or a software system. Hence, we use different pictograms.
Actors create, work with, and exchange work objects and information about work objects such as documents and messages. The pictograms represent the work object’s medium.
The actor’s activities are depicted as arrows.
Identifying Value Stream Networks
Let’s start with an example: Leasing Company. It is a Non-IT business. How do we introduce the Kanban method in a Leasing Company? Assume that you are a consultant in a leasing company and you want to start that agility transformation. Step — 0 says: identify the services and in order to identify services first, we need to understand and see value networks. Here is the happy path story of the customer :
Story : The customer wants to lease a car so he contacted the sales person. The salesperson calculates the monthly installment for the contract and sends it to the customer for signature.
After that salesperson passes the contract to the risk manager, she starts to wait for the response from the risk department. At this point risk manager calculates and vote the risk for that contract. If everything goes well, the salesperson turns over the car to the customer.
After the leasing period customer returns the car to the salesperson, in case of a problem (if the car is worn out or damaged) the salesperson calculates the resale value and customer pays payback value. Last step is the salesperson sends the car to the repair service for prepared for resale.
Is it complicated? Can you see the value networks? You are right, it is not easy. Let’s begin with the end mind. We are trying to visualize the process into a Kanban board below like this :
This Kanban board is a coordination level Kanban board because there are 3 service providers are working on this value stream in order to satisfy the customer.
Some hard questions about this board may be like that :
1- How did we identify the activity steps?
2- Who will work on what?
3- Why there is a black hole in the middle of the board?
Now let’s start to work on STEP — 0 with Domain Storytelling. In that stage, we will visualize the story with domain Storytelling.
The customer wants to lease a car so he contacted the sales person. The salesperson calculates the monthly installment for the contract and sends it to the customer for signature.
After that salesperson passes the contract to the risk manager, she starts to wait for the response from the risk department. At this point risk manager calculates and vote the risk for that contract. If everything goes well, the salesperson turns over the car to the customer.
After the leasing period customer returns the car to the salesperson, in case of a problem (if the car is worn out or damaged) the salesperson calculates the resale value and customer pays payback value. Last step is the salesperson sends the car to the repair service for prepared for resale.
We have just converted the story above into a visual form with Domain Storytelling format. In Domain Storytelling, two questions are very important
1- What is next?
2- Where to go From Here?
Those questions lead to visualize value stream networks according to Domain Storytelling rules. The next step is we will map necessary activities into the Kanban board.
Can you see the value streams?
By the help of Domain Storytelling, we can see the value streams (painted in purple), service providers and customers very clearly
From DST to Kanban
In that stage, we know work-steps, actors, activities, and relations. Now it is time for mapping.
Short-lived activities might not be mapped into the Kanban board. In that use case, we mapped below activity points
Point (2): Sales team provides “Calculate monthly Installment” service at that point
Point (5): Risk Team provides “Calculate risk” services. This is a very abstract step in the Coordination level Kanban board. We will go to a deeper point for risk later.
Point(6): Risk Team provides “Validate risk” service. Also, this is a very abstract step. We will go to a deeper point for risk later.
Point(8): Sales team provides “Turn over the car” service. This point is very important for the customer so we have to show that point on the Kanban board.
Waiting for (∞): In that story, there is no limit for leased cars so we put a black hole. This is not a mature sign accırding to Kanban Maturity Level but we will go to a deep level step by step in evolutionary mode. So far so good.
Point(11): Sales team provides “Calculate resale value and backpay” service which is very important after the end of the leasing period.
Point(12): Pay backpay is must be tracked on the Kanban board.
Point(13): Repair & Clean Team provides “Prepare for resale” service at that point
Service Provider point of view
If you look from services providers, there are 3 types of Service providers
Let’s show clearly teams and coordination level board relation
Now we can clearly see which team works on what. If you look at the situation from the customer point of view, there is only one only service: Leasing Car. This Leasing Car service is provided by 3 service providers So I called this relation 1 to N. Multiple Teams gives One Service.
Risk Team’s Operation Level Kanban board
Let’s go to the Risk Team’s operation level. We will create an operational level Kanban board for Risk Team. First, we have to understand their story.
In the first step, the Risk Team fills out the credit rating form with information from the contract into the Rating Agency system.
After that Rating Agency System generates a credit rating report and sends it to the Risk Team. With the report, the Risk Team creates a customer profile into The risk management system.
In Step 4 the Risk Team creates a risk assessment documentation and saves it to the risk management system. After that and 5 is about calculating the risk. Step 6 and 7 is all about decision and making.
Now it is very easy to map Domain Storytelling steps into Kanban board. Short-lived activities might not be mapped to Kanban boards.
Here is the Kanban board which is an operational level Kanban board, show all necessary steps on the board.
Storytelling is a means to transport domain knowledge from the heads of domain experts into the heads of Kanban coaches, Agile managers, product owners, product managers, business analysts — anyone who is involved in the transformation process. I believe that the Kanban method with Domain Storytelling approach gives huge power to Kanban coaches in order to introduce the Kanban method into complex Business units more effectively.
Resources
1- Domain Storytelling — https://domainstorytelling.org/
2 — Domain Storytelling Book — Stefan Hofer and Henning Schwentner — https://leanpub.com/domainstorytelling
3 — STATIK — Systems Thinking Approach to Implementing Kanban https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/ — David Anderson
4 — Flight Levels: The Organizational Improvement Levels — https://www.leanability.com/en/blog-en/2017/04/flight-levels-the-organizational-improvement-levels/
5 — Agile Kanban Istanbul — https://agilekanban.istanbul/
