What it is and why it matters
Large organizational changes tend to fail for the same reason: they ask people to accept, all at once, new roles, new rules and a new professional identity, with a promised benefit that only shows up months later. The Kanban Method proposes another path. You start from what exists, make the problems visible and change one thing at a time, with a clear hypothesis about the expected effect.
This approach is slower on day one and faster in year one. Each step is small enough to be accepted and reversible enough to be tried. And because each step is measured, the organization learns from what worked and from what did not.
Key concepts
Evolutionary change
Evolving, here, has a precise meaning: vary, select and keep what works. Variation comes from experiments in the system, such as a new policy, a different WIP limit or a visible waiting column. Selection comes from flow data and from the customer’s perception. What improves the outcome becomes policy; what does not is undone.
A well-run evolutionary change causes a small, short dip in performance, if it causes any. Large, simultaneous changes tend to cause a deep, long dip, and many organizations abandon the initiative before the recovery.
STATIK
STATIK (Systems Thinking Approach to Introducing Kanban) is the systemic approach to introducing Kanban into a service. The steps are not a rigid sequence; you return to them as you learn:
- Understand the sources of dissatisfaction, both of those who do the work and of those who receive it. What bothers people is what gives energy to change.
- Analyze demand and capability: what types of requests arrive, in what volume and with what variation, and how much the service delivers today.
- Model the workflow as a knowledge discovery process, with the real steps and queues.
- Discover the classes of service that already exist implicitly, such as the requests that always jump the queue.
- Design the Kanban system: board, WIP limits, policies, metrics and cadences.
- Socialize the design and negotiate the rollout with the people involved, adjusting whatever is needed.
Some presentations add a step zero: identify the services before anything else. The rolling out Kanban with STATIK challenge puts these steps in a situation with real pressure.
Experiments with hypothesis and measurement
A useful experiment has five elements written down before it starts:
- the change, specific: “reduce the Development WIP limit from 6 to 4”;
- the hypothesis, with the expected effect: “the 85th percentile of cycle time drops from 14 to under 11 days”;
- the measure and the period: “within four weeks, keeping throughput above 8 items per week”;
- the criterion for rolling back, if the side effect is greater than the benefit;
- who follows up and in which cadence the result will be discussed.
Without a hypothesis, every change looks like a success to whoever championed it. Without a period and a rollback criterion, the change becomes permanent by inertia. Build yours in the experiment lab.
Resistance
Resistance is rarely stubbornness. It is usually a reasonable reaction to a perceived threat: loss of status, fear of being judged by the metrics, distrust after earlier changes that did not work. The method reduces this threat by design. It respects current roles, measures the system and not the people, and starts with the dissatisfactions that people themselves pointed out.
When resistance to a specific experiment arises, treat it as data. Perhaps the proposed change is too big, or the hypothesis is not convincing. A smaller experiment, with a short timeframe and a guaranteed rollback, usually gets the conversation moving.
Choosing the next step by the bottleneck
With many visible problems, the temptation is to tackle them all. The theory of constraints reminds us that only improvement at the bottleneck increases the system’s delivery; improvements elsewhere can even make flow worse, if they grow the queue in front of the constraint. Before choosing an experiment, ask: where does work wait the most? Which step sets the exit rate? The answer shows where the next step pays off most.
A common example: a team invests in automating the development step, which already had spare capacity, while items wait on average 6 days for approval from another area. Cycle time does not change. The right next step would be to make the wait visible and negotiate a policy with the approving area. Train this reading in the invisible bottleneck challenge.
Common mistakes
- Rolling out the final design all at once. The perfect design does not survive contact with real work.
- Experimenting without measuring first. Without a baseline, there is no way to know whether things improved.
- Changing several things at the same time. The result cannot be attributed to any of them.
- Ignoring customer dissatisfaction. Improvements that only the team notices rarely last.
- Optimizing steps that are not the bottleneck. It creates effort with no gain in delivery.
How this shows up on the exam
You will find rollout and continuous improvement situations. Examples of the kind of decision: what the first STATIK step is when faced with a request to “roll out Kanban across the whole department”; which experiment is best formulated among several options; what the best response is to a team that fears being judged by throughput; where to invest first, given a board with queues and times per step.
Frequently asked questions
What does STATIK stand for?
It is the acronym for Systems Thinking Approach to Introducing Kanban, a systemic approach to introducing Kanban. It organizes the rollout starting from real sources of dissatisfaction, the analysis of demand, capability and current flow, through to the design of the system and the negotiation with the people involved.
How long should an experiment last?
Long enough for the chosen metric to reflect the change. For effects on cycle time, that usually means a few multiples of the team’s typical cycle time. A team with an 85th percentile of 10 days generally needs three to six weeks to see the effect.
How do I deal with people who do not want to change?
Start with what bothers those people, not with what you want to change. Propose small, reversible, time-boxed experiments, and measure the system, never the people. Resistance usually drops when the change solves a problem they themselves recognize.
Why start with the bottleneck?
Because the bottleneck sets the delivery pace of the whole system. Improving other steps can grow the queue in front of it without increasing delivery. Focusing the next experiment on the bottleneck is what brings a visible effect fastest.
