When you’re coaching a new team, it’s a good idea to begin with a comprehensive understanding of their work.
But where — exactly — do you start?
In this blog, I’ll go through how to apply STATIK to design a Kanban system, step-by-step.
I’ll use a real story of a 5-member operations team responsible for supporting delivery teams with configuration management, deployment, automation, environmental issues and related topics as a practical example on how to improve team dynamics, self-organisation and predictability – among other things.
But, first things first…
What is STATIK?
STATIK is an iterative approach that can help you understand the processes already in place within a team.
It stands for Systems Thinking Approach to Introduce Kanban. You can use it even if you’re using another approach (e.g. Scrum). It’s also a good tool for discovering all the services a team provides, their workflows and their alignment with purpose and customer expectations.
STATIK is a repeatable (and human) way to get started with Kanban or to improve an existing Kanban implementation.
STATIK steps
As an iterative approach, STATIK suggests you go through the following steps (although you don’t need to follow them in a specific order):
- Understand what makes the business fit for purpose
- Understand sources of dissatisfaction regarding current delivery
- Analyse source and nature of demand
- Analyse current delivery capability
- Model the service delivery workflow
- Identify and define classes of service
- Design the Kanban system
- Socialise design & negotiate implementation.
A practical workshop application
As a guide, you can download our STATIK1 Canvas.
0. Before the workshop
- Set aside approx. 2 hours for the workshop.
- It’s important that all team members attend the session.
- You’ll need post-its, pens and a whiteboard or flipcharts.
1. How to get a general understanding of purpose
- Start with an open conversation.
- Explain to the team their purpose is to gain a shared understanding of their process that will later be transferred to a Kanban board.
- Without getting in too much detail, I generally ask:
- Why does the team exist (from their point of view)?
- What is their routine?
- Who is their customer (or who is consuming their services)?
2. Understanding the source of dissatisfaction
Once you understand the system’s purpose, begin discussing any current dissatisfactions with the service(s) provided. This is one of the most important steps, as identifying pain points will result in a call to action and the motivation to tackle recognised problems.
It’s often useful to split sources of dissatisfaction into two categories:
| Internal | External |
|---|---|
| Classical examples of internal dissatisfaction might be: | Consider the immediate customer of the service, whether another team, a product owner or end user. In general, external dissatisfaction can be associated with: |
Proper identification of problems within the current system will guide your Kanban design and help engage those involved in the transition. For our operations team, the main sources of dissatisfaction were:
- A large amount of work in progress
- Lack of prioritisation
- Long provision times for the software development teams
- Lack of predictability
3. Analysing the source and nature of demand by identifying Work Item Types
Next, explain the concept of Work Item Types — essentially a service a team provides that is requested by another party. Then, ask the team to remember all the services that they provide to other parties.
Our operations team was asked to remember all the services they provide to the Delivery teams (who we identified as the consumer in step 1).
3.1. Grouping and identifying specialised work
This optional step can be useful in understanding the level of specialisation inside a team, so you can model a system that reflects the current reality.
After identifying the items above, I ask the team to (one item at a time):
- Group similar items into no more than seven groups
- Give each group a name that summarises the service provided (preferably a short one)
- Ask each team member to write their name on post-its and attach them to the groups with which they’re involved.
For this last point, team members can write their names several times according to the services they execute in the team. This helps assess the level of specialisation inside a team – e.g. If a name appears only in one type of service, it’s a specialised role.
Below is an example result of the grouping and identifying tasks activity. The pink post-its carry the names of team members involved with an identified service.
4. Analysing demand and delivery capability
Now it’s time to look at each work item type and identify its patterns of arrival and delivery, as well as other useful information.
Use the following table as a guideline:
Work Item Type = the type of request a service receives (e.g. user story, defect, support, etc.t…). For example:
- Different sources of demand, delivery platform or channel
- Different business or technical risk resulting in different workflows, dependencies, required skills
- Different granularity, scale or complexity.
Source = where requests for a Work Item Type come from? (e.g. product owner)
Destination = where work results are delivered? (e.g. product owner, DevOps team)
Arrival Rate = number of requests per unit of time.
- If available, use graphs to analyse historical data.
Delivery Rate = number of requests delivered per unit of time
- If available, use graphs to analyse historical data (e.g. lead time, flow efficiency, etc.)
Nature of Demand = random, burst, seasonal, batches, chaotic, planned or unplanned, anticipated or not? Refutable/discretionary or not?
Customer expectations = Met? Unmet? Consider also lead time, delivery rate, service level agreements, service level expectations, etc.
Here are the results from our team:
5. Modelling the service delivery workflow
With the items that flow through your knowledge discovery process identified, it’s time to get a better understanding of each workflow/value stream.
- Ask the team to draw a sequence of steps for each work item type and ask the following questions:
- Are they all the same?
Do they have a workflow or it is just a simple ‘to-do,’ ‘doing,’ ‘done’ workflow?
Using this process, our team discovered they had a very simple to-do,’ ‘doing,’ ‘done’ workflow and a high level of specialisation. We also discovered work was carried out by only one team member – the specialist – who initiated tasks and completed them himself.
Further conversations determined this process could be improved with swarming and encouraging more generalists-specialists.
However, Kanban is all about starting with what you do now, so no changes were implemented until we completely understood how things had been working up until that point in time.
6. Identifying classes of service
It’s time to identify the set of policies that describes how and when work must be delivered.
They’re usually one of the four following types:
- Standard
- Expedite
- Fixed date
Read more about the different classes of service1.
Our team identified the following classes of service:
- Expedite: for critical incidents into production.
- Fixed date: for monthly scheduled deploys.
- Standard: for all other items requested by the delivery team. They had associated service level agreements (SLAs).
- Intangible: long term initiatives to improve work (automation, use of new tools, platform migrations, etc.).
7. Designing the Kanban system
At this point, it’s useful to have a checklist of the elements likely to be included, for example:
- Board design
- Workflow states
- Types of work
- Swimlanes
- Dependencies
- Classes of service
- WIP limits
- Explicit policies
- Ticket design
- Buffers
- Commitment and delivery points
- Pool of options
- Legends
- Replenishment policies
- Metrics
- Feedback loops.
The design of our first board is attached below.
Notice that a To-Do, Doing, Done board doesn’t need to be boring. There’s plenty of information that can be radiated so you can have a meaningful and actionable visual system.
The team was already doing daily stand-ups but in a poorly structured way that didn’t help them self-organise. This new board helped them maintain daily stand-ups and replenished free slots during those meetings.
8. Socialising design & negotiating implementation
STATIK encourages collaborative workshops for Kanban system design, creating a sense of ownership in the process. It also serves as a good team building activity.
Depending on the nature of the teams I’m working with, the time that I have to explain the concepts and the nature of the activities, I can co-create the board design with them or ask if I can work on it for a day and present a proposal.
It’s paramount the team recognises itself in the picture. After seeing a board, it’s common teams propose alterations or new insights that haven’t been noticed before.
Even if I do the design, a team should be responsible for building the physical board. This helps preserve the IKEA effect3.
Final remarks and results
After beginning the stand-ups and coaching the leadership to use the new system, our team began exhibiting self-organising behaviour.
The board helped to implement very simple metrics so team members could feel empowered by the improvements.
When a work item type/service was finished inside the targeted SLA, the team placed it inside the IN area. All other work item type/ services that didn’t reach the SLA were placed in the OUT area.
After each month, we counted the percentage of IN items to give the percentage of Due Date performance. We began with a Due Date Performance of 43%. After 4 months, it had increased to an amazing 93%!
In addition, there were significant qualitative benefits, including:
- Improved team dynamics
- A self-organising attitude
- Leadership acting to improve the new process
- An increase in predictability
- No complaints from software delivery teams.
Like this approach? Want to explore how to run a STATIK session in your own context?
Learn how to design your own Kanban System with Elabor8’s Kanban System Design training.
Reference:
