STATIK | Agile Scrum Master
STATIK (Systems Thinking Approach to Introducing Kanban) is an iterative method for designing a Kanban system tailored to a specific service rather than copying a generic board. It starts from understanding the service's purpose and sources of dissatisfaction, then works through demand, capability, and workflow before producing a board design that fits the actual context. Key steps: understand the service, identify dissatisfaction, analyze demand and capability, model the workflow, identify classes of service, design the system, and socialize it with stakeholders before implementation.
What STATIK is designed to do
STATIK exists to answer a specific problem: copying a Kanban board from another team rarely works, because a board that fits one service's demand, risk, and workflow will not fit a service with different characteristics. STATIK provides a repeatable sequence for understanding a service well enough to design a Kanban system that actually matches it, rather than adopting a generic template and hoping it holds up under real demand.
STATIK is applied to one service at a time. When an organization wants to introduce Kanban to more than one service, STATIK is worked through separately for each, since the demand pattern, customer, and workflow of one service will not transfer cleanly to another.
The approach is a systems-thinking application, meaning that a service is treated as a whole rather than assessed as a set of unconnected steps or activities. This matters because a Kanban system designed only around one part of the process tends to shift constraints elsewhere rather than actually improving flow for the customer.
How STATIK approaches introducing Kanban
STATIK moves through a sequence of steps, most often applied iteratively rather than strictly in order, since later steps regularly surface information that changes what an earlier step assumed:
- Understand what makes the service fit for purpose - clarify what the service actually is, who it serves, and what value the customer is getting from it, without trying to change anything yet.
- Identify sources of dissatisfaction - gather what customers, stakeholders, and the delivery team find frustrating about the current service, split into what comes from outside the team and what comes from within it.
- Analyze demand - look at what is actually being requested, in what categories, and at what rate, treating the delivery organization as a black box that receives this demand as input.
- Analyze system capabilities - assess how much the current system can actually deliver against that demand, since a persistent mismatch in either direction signals overburden or underused capacity.
- Model the workflow - map the actual activities used to deliver each type of work, based on what really happens today rather than an idealized process.
- Identify classes of service - separate types of work by the urgency and risk they carry, an idea covered in more depth under Class of Service, so that different kinds of demand can be handled with different policies rather than one uniform rule.
- Design the Kanban system - translate everything learned so far into a Kanban Board, a ticket design, explicit workflow policies, and a set of feedback loops suited to the service.
- Socialize the design and negotiate implementation - work with stakeholders who will use or be affected by the new system, since a design that has not been discussed with the people running the service rarely survives first contact with reality.
The first and last steps require more organizational maturity than the middle steps, so many early adoptions lean heavily on the middle six while treating the outer two more lightly.
Why grounding the design in evidence matters
STATIK's value comes from refusing to skip straight to a board. Sources of dissatisfaction, demand patterns, and actual workflow are all evidence that shapes design decisions, which is what separates a Kanban system built for a specific service from a generic template applied without understanding what problem it is solving. This lines up with the same evidence-based reasoning that runs through Kanban more broadly: policies and limits exist to solve an observed problem, not because a guide recommends them.
How STATIK relates to ongoing Kanban practice
STATIK is most visible at the start of introducing Kanban to a service, but it does not stop mattering once a Kanban Board is running. Because circumstances change, such as new sources of dissatisfaction or a shift in demand, teams often revisit STATIK steps later to refine an existing Kanban system rather than treating the initial design as final. In this sense, STATIK connects directly to Continuous Improvement and to Flow, since the questions it asks about demand, capability, and workflow are the same questions a team returns to whenever it inspects how well its system is actually performing.
Common misuse and fake-agile patterns
STATIK is frequently shortcut in ways that undermine the design it is meant to produce. Typical problems include:
- Board-first design - a team jumps straight to drawing columns on a board without doing the earlier steps, producing a board that reflects assumptions rather than the actual service.
- Idealized workflow modeling - the workflow step captures how the team believes work should flow instead of what actually happens today, hiding the real constraints STATIK is meant to surface.
- Skipped socialization - a design is finalized without input from the people who will run the service, leading to a system that gets quietly ignored or overridden once real work starts flowing through it.
- One-time exercise - STATIK is treated as a setup activity done once at launch and never revisited, even as demand and dissatisfaction change over time.
The fix in each case is the same: base each step on what is actually happening rather than what is assumed, and treat STATIK as a cycle the team can return to, not a one-off design exercise.
STATIK (Systems Thinking Approach to Introducing Kanban) is an iterative, systems-based method for designing a Kanban system around one specific service