Systems Thinking Approach to Introducing Kanban (STATIK)

STATIK, or Systems Thinking Approach to Introducing Kanban, is a complementary practice to the Kanban Method promoted by Kanban University and provides precise, repeatable, and human-friendly guidelines on how to get started with Kanban.

STATIK offers an iterative process made of eight steps, as illustrated below.
‍

The first and last steps are often considered more advanced and require higher organisational maturity, so the middle six steps are the most frequently used.

STATIK is an iterative process, so you should go through the steps multiple times since later steps may reveal new information requiring revisiting the results of earlier steps.  However, these steps may be carried out in different order, not always following the sequence suggested by the picture. Nevertheless, the order in which they have been presented is still essential since they illustrate how individual steps inform other steps.

STATIK is applied to a single service, so a service that will be “kanbanized” needs to be identified before starting the STATIK steps. If we wish to introduce Kanban to multiple services, STATIK is used for each separately.

Let’s proceed to short explanations of each step of STATIK.

Understand what makes the service fit for purpose

Firstly, we ensure that we understand the service we provide very well. In this step, we are answering questions like:

• How do you describe in a few words or sentences what we do / what our service is?
• Who is the customer/requestor? Who is consuming our service?
• Why are we providing the service, and what value is the customer getting?
• How do we know if our service meets customer needs?

We are not trying to introduce any changes to our service at this stage. We are starting with what we do now and dedicating effort and time to understanding our current service to inform the next steps better.

Identify sources of dissatisfaction

Once we understand what makes the service fit for purpose, we investigate why currently our service might not be quite there yet. We reach out to customers, stakeholders, and members of the delivery team(s) and ask what makes them unhappy. We gather the answers in one place and group them into two categories:

• External sources of dissatisfaction are the points raised by external people, i.e., those who are not delivering the service but are either dependent on or affected by the service. This typically includes customers/recipients or users of the service but may also include teams from your organisation that depend on you. By gathering the external sources of dissatisfaction, we gain an outside-in perspective on why their expectations might not always be met and what might be improved regarding service delivery.
• Internal sources of dissatisfaction are those raised by people and teams who directly contribute to service delivery. They concentrate on any issues that may prevent them from delivering on expectations.

Analyse demand

Service delivery means responding to the requests or orders from customers/requestors or users. But what exactly do they ask for? Are these always explicit requests? From where or whom do these requests come from? What are the different types or categories of these requests, and what expectations are associated with them? What is the arrival rate, and is there any observable pattern in how the demand is arriving?

As you can see, many meaningful questions can and should be asked to understand the demand better. We are not yet looking into our system built to respond to the demand; we look at the entire delivery organisation as a black box and analyse what is coming in as input. Once we have a solid understanding of the demand, we can investigate how well we cope with it, but that’s already the next step of STATIK.

Analyse system capabilities

Analysing system capability boils down to scrutinising how much we can deliver on the incoming demand. In the perfect case, the capability to deliver matches the demand – if there is a gap in either way, it is an undesired situation. Demand higher than capability means that we are overburdened, whilst capability consistently higher than demand over a longer period leads to starvation.

The demand and capabilities are usually analysed for each work item type identified in the previous STATIK step. This way, we gain useful insight into how well we deal with different kinds of demand, which helps produce a good Kanban system design in one of the subsequent steps.

Model the workflow

In this step, we continue to analyse work for each type/category separately. We identify the process of delivering value to the customers for each work item type. We need to remember that whilst modelling the workflow, we are not modelling the organisational chart but the flow of work, so the workflow that we create should consist of activities rather than teams, organisational units, or hand-over points. Another vital principle whilst modelling the workflow is that we are aiming to capture what is actually happening currently when the service is being delivered – it may be tempting to idealise the workflow by writing down the process that we believe should be happening, but that misses the important rule of Kanban of starting where we are now.

Identify classes of service

Classes of service are often misunderstood. The easiest way of learning about classes of service is by finding examples from everyday life that surround us. Airlines introduce different classes for passengers (such as business class, economy or first class), and so do train companies. Public transport companies in large cities introduce priority seats for certain groups of people, e.g., the elderly and pregnant. Many countries with state-founded health care introduce special privileges for recognised blood donors, such as priority treatment (skipping waiting in line) when the donors need to become patients. Emergency care at hospitals labels incoming patients differently depending on the urgency of treatment they require. NHS UK uses colours to differentiate the patients allocated following a medical triage.

Countless more examples of classes could be provided here, but it is probably already becoming clear why so many service organisations are introducing them. This is nothing else than just categorisation of work items to help the service provider easily recognise that the items of the same category (i.e. class of service) need to be treated in a certain way, especially in comparison with other items that might be in progress or waiting to be started. Typically, the classes of service are differentiated based on the priority or risk associated with different work item types. Hence, it may be said that the classes of service emerge from the inherent qualities of the demand. However, as we are designing the Kanban system, we have certain flexibility on what classes of service we want to have – after all, there are so many airlines, but even if they provide very similar service, we can find some variety in the ticket classes they offer. Moreover, we are the ones who define the policies attached to each class of service – we, the designers of the Kanban system, decide what treatment work items each class should receive.

A useful concept very much related to the topic is the archetypes of classes of service. Since none of the readers will be the first ones ever to design a Kanban system and identify the classes of service, there is no reason why we wouldn’t look at the wisdom of those who did that before us. The archetypes are nothing more than the most commonly observed classes of service across various Kanban systems. These archetypes include:

• Expedite
• Fixed Date
• Standard
• Intangible

The main differentiator between them is the different costs of delay. An Expedite would be an item that needs to be urgently worked on and delivered because every minute or second of delay comes with a massive penalty. Fixed Date items may not have any noticeable penalty for delaying the delivery for quite a while, but if we miss the due date, the penalty suddenly becomes significant. Standard class of service denotes a most common situation, where the sooner we deliver something, the better. However, an item of this category does not stand out from many other items regarding the speed at which the penalty due to delay arises (unlike Expedites). Finally, the Intangible is the case where we don’t even know whether there will be any penalty at all if we delay the execution. It often appears with any organisational or system improvement initiatives – a penalty might be marginal or huge, it might come early or late or never… Our inability to predict upfront what the cost of delay for these items will be makes them intangible.
‍

Design the Kanban system

We finally reach the step at which the Kanban board is being designed. Read our What is a Kanban Board article to learn more about this practice. During the STATIK process, we create a bespoke Kanban board that will be unique and optimised to help us deliver our service in our context. We do not copy-paste the board, which would reduce the benefits of using the Kanban method. Instead, based on all the information that previous STATIK steps allowed us to gather, we create a board that will be designed for our and only our service (as defined in step 1), helping with effectively addressing the paint points identified in step 2, designed to highlight most important information about our demand and risk, etc.

But it’s not only about the Kanban board. We should be concerned with other elements of the Kanban system. Such as:

• Design the ticket (card) that will be used to visualise work items on the board
• Define explicit policies, such as exit or pull criteria for the workflow states or a replenishment policy
• Decide on which feedback loops (cadences) shall be part of the Kanban system and how they should be carried out (e.g. participants, duration and frequency of meetings)

Socialise the design and negotiate implementation

Once we’ve finished designing our Kanban system, we must face the harsh reality that our service does not exist in a vacuum. There will be various stakeholders, some more interested and others less, some more keen to introduce Kanban and others more sceptical, some having strong opinions about how the service should be managed, and others happily listening to your ideas. Whoever they are and whatever their attitudes, it is important to socialise with all relevant internal or external players in the new Kanban system design. This step is more straightforward if you truly follow the three Change Management Principles through the STATIK process.

With the last step being completed, you are ready to go – just start using your new Kanban system. When creating the initial design, you’ve probably gone through several iterations of the STATIK steps, but this does not mean you should forget about STATIK. In the future, you might find it beneficial to go through the STATIK for your now-existing and maturing Kanban system to refine it, improve it and adapt it to the changing realities.