A first experiment of STATIK

By reading the excellent Kanban from the Inside by Mike Burrows, I discovered a method to introduce Kanban called STATIK (Systems Thinking Approach To Introducing Kanban) which is mainly based on the systemic approach. So I got down to experimenting with it to launch a new team by following the different stages of the process as well as possible and relying on the examples in the book. Here's what happened! 😉

STATIK, in a nutshell

STATIK literally means "Introduction to Kanban through a systemic thinking approach", here are the main steps as defined in Kanban from the Inside:

1. Understand the sources of dissatisfaction
2. Analyze demand and capacity
3. Modeling the flow – the “learning process”
4. Learn about classes of service
5. Design kanban systems
6. Deploy

In my case, I only decided to tackle steps 1, 2 and 3 during my experimentation. Indeed, the kanban systems were subsequently designed during complementary workshops.

Note: The number of STATIK steps within the framework of official Lean Kanban University training is 8 in number but does not fundamentally differ from those presented above.

1. Understand the sources of dissatisfaction

Objective

The purpose of this step is to share the same understanding and to agree on the dissatisfactions so that we can make a change that makes sense to everyone.

The author adds that any deliberate change requires 2 fundamental elements of context:

• its scope: the boundaries around “what we do now” within which the change will be focused. THE WHAT change.
• its goals: an expression of what we hope to achieve with this change, relative to how things are currently. THE FOR WHAT change.

NB: some might remember a certain "Golden Circle"! 😉

Further information

This step requires keeping in mind 2 prospects :

• People working in the system: to get their impression of how the system is perceived from the outside and of course to understand the system itself.
• People working outside the system: to get their impression of how their immediate needs are being met and to understand how the system helps meet broader needs.

In my case, there were mainly people working in the system, which already halved the prospects for understanding the system.

THE 2 questions offered are as follows:

• From your personal perspective, and what you perceive of others inside and outside (of the system), what are the main sources of dissatisfaction with the system? What needs (whose?) are not being met?
• What sources of variability and unpredictability would you highlight? What frustrates you and the system more broadly in your attempt to produce valuable items with quality and on time?

Implementation

Given the time I had and to keep it as simple as possible, I decided to carry out a Workshop consensus answering the only question:

What are your main sources of dissatisfaction and frustration?

Here is the result following Dot Voting:

At the same time, I challenged the participants to express the needs hiding behind these sources of dissatisfaction, which was a particularly difficult but revealing exercise! It is important to stay in the language of dissatisfaction and frustration (or need) but to do not describe solutions !

The author gave some interesting indications according to the results obtained:

• If the dissatisfaction concerns the punctuality, then it could be relevant to address the issues of communication, of coordination and of quality.
• If the dissatisfaction concerns the staffing level, then it could be relevant to address the issues of workload, prioritization and system efficiency.

In my case, the 2 subjects seemed to be sources of dissatisfaction which allowed me to already have a strategy to put in place.

2. Analyze demand and capacity

Objective

The objective of this step is to gather qualitative and quantitative facts about the current process, which will allow the design of kanban systems later.

Instructions

After defining the sources of dissatisfaction together, it was time to focus on understanding the current system: after all, let's not forget that Kanban is defined as the evolutionary “start where you are” method ! 🙂

At first, I decided to separate the participants according to their specialties; 4 groups were then formed:

• Business,
• AMO,
• IT (development of new features)
• and IT (maintenance and support).

I then explain to the groups the process of this step:

The objective of this step is to understand how each of you works to ensure a shared understanding of your current system. To do this, we will go through distinct phases to better structure the restitution. Indeed, the expected result is a summary on A4 sheet for each phase. I am going to distribute a document in which you will find a series of questions and examples of expected results to help you.

I will then describe each of the parts by sharing with you the questions and examples of results given to the participants.

A) Study of the What

In this phase, we try to understand what each group produces, how its work is organized, what is the business language used… So a simple way is to ask everyone to display the tasks on which he or she is currently working. (one idea per Post-it as usual). This makes it easier to have a view of the different types of elements transiting within their activity.

Questions – Quantitative Analysis

• How big are our work items? (days, weeks…)
• How often do we deliver?
• How many items per delivery?
• How long do our deliveries take, end-to-end?
• With what variability? With what predictability?
• How many items are currently in progress, and what is their age profile?
• How many items are ready to start, and what is their age profile?
• Do you see them as your backlog (waiting to be taken care of) or as something more flexible (ideas, options…to choose from)?

Example given

We maintain a number of recently developed apps and are currently working on two more.

At the team level, we mainly work on features (sometimes bug fixes) approximately two days of development time, taking a few days in all.

We make releases in production as often as possible, typically several times a week, sometimes more than one per day.

At a higher level, we like to think in terms of business initiatives; we think less and less in terms of projects.

B) Study of “To Whom”

This part addresses the recipient of what is produced. This can be the downstream process simply receiving what is sent to it, but also the end customer, because let's not forget, all the work we provide is aimed at bringing value to the customer.

Issues

• To whom do you deliver what you do?
• What do they do with it?
• What is the downstream activity?
• Who is the end customer?
• Are there different customers?

Example given

We do our own production releases and manage our own support.

Our immediate business customers use our systems to perform risk analysis on energy markets, to generate trading alerts, and to produce reports to the company's paying clients on a daily basis.

C) Study of the “Why”

The study of WHAT and WHOSE naturally leads us to the study of FOR WHAT to give meaning to what is being done.

Issues

• WHY/IN WHAT is what you do necessary for the downstream activity?
• For end customers?

Looking at representative samples of individual deliverables:

• What is the impact of whether they are produced quickly or slowly?
• Does your strategy allow you to meet needs effectively enough?

Example given

Our paying customers consume energy (electricity, gas, and oil) in such large quantities that it is worth preventing their risks by buying some months in advance or by derivative contracts.

Our tools help them buy the right quantities at the right time, so timely information is vital information. We are working hard both to expand our market coverage (energy markets are highly fragmented) and to stay ahead of our competition in terms of sophistication and speed.

D) Study of incoming sources

Finally, for this last step, the study focuses on the sources of input to the process, which will make it easier to characterize the typology of elements feeding the flow.

Questions – for each item type

• How does it happen? Are you actively soliciting it, waiting for it to happen, or something in between – conversation, exploration, or negotiation?
• How often does it happen (as many per day, per week, or per month)?
• Does it arrive with regularity (ex: by a regular meeting) or randomly (ex: by calls to a helpdesk)?
• Does the work arrive in batches or in peaks? Are there predictable seasonal variations?
• What are your key measures of success? Are they well aligned with customer results?

Example

There is no regular pattern of arrival of work.

Our biggest projects started in agreement with the management; the smallest things happen through private conversations or through our team mailbox. We aim to resolve support issues within 24 hours (and we do very well by this metric); expectations on development work vary by size and need.

Restitution to the whole

The moment of restitution had to be the highlight of this part of the workshop. Indeed, each group having worked on its own, sharing it with the whole team was intended to awaken collective awareness of the current mode of operation of their system.

I therefore proposed to each group to come and present their results in turn. The limitation to one A4 per part made it possible to structure their speech and greatly simplified the restitution. 🙂

After each presentation, the rest of the participants had 5 minutes to "challenge" what they had heard: challenge in the sense ask questions to better understand and not question what has been said.

The exchanges were much more interesting than I had hoped: indeed, even if we can have the impression of knowing how our system or the other teams with which we interact work, we can always learn and be surprised. The participants' understanding of their system then seemed to begin to align.

Here is the end result:

NB: Yes, as always, respecting the rules is not always great, but we will say that some people write bigger than others! 😛

3. Model the workflow

This last step of my experimentation with STATIK aimed to model their complete workflow. To do this, I once again asked each group to work separately and sketch their process, paying particular attention to the interfaces in order to explain their vision of the Definition of Ready with the upstream process and Definition of Done with the process. downstream.

When this was done, the restitution stage could begin.

I then proposed to carry out a fictitious basic case to build their process chronologically. So we started from the idea (on the left) and then as we went along, I asked what came next. Very quickly, the participants gathered in front of the Sticky Wall and organized themselves to build their process together. It barely lasted 5 minutes.

This was a blatant example of the effectiveness of visualization and Post-its! 🙂

But also, the uselessness of my presence! 😛

Here is the final result obtained:

Note: The process looks a bit messy, I think I'll emphasize the visualization rules more next time to get a cleaner result with the steps, Definition of Ready and Definition of Done.

Conclusion

I found this first experiment of STATIK rather enriching for my part. Indeed, I find that it really allowed the participants to ask themselves to understand the way they work today instead of immediately taking action to change. I nevertheless keep a somewhat mixed view of the ratio of time spent to the result obtained: has the collective consciousness of the current system really increased? Will it make it easier to target improvement actions?

However, the exercise remains no less relevant in substance and I would not hesitate to reuse STATIK in my future accompaniments to get a better idea of it.

Note: The implementation described in this article was only the result of my interpretation of the book, I would be curious to see how others have been able to do it and the results they have obtained.