KSD: Design with STATIK

STATIK - the Systems Thinking Approach To Introducing Kanban - is the design method used in KSD to build a Kanban system that fits an existing workflow, rather than a template. The order is the point.

The steps and what they produce

1. Understand purpose and context - the aim of the system and its boundary.
2. Understand sources of dissatisfaction - pain points from customers and from the people doing the work.
3. Analyse demand - work item types, volumes, arrival patterns, effort, failure demand, candidate classes of service.
4. Analyse capability - throughput, capacity, scarce skills, current lead times.
5. Model the workflow - states, handoffs and the queues between them.
6. Discover classes of service - the policies that decide selection.
7. Design the Kanban system - board, WIP limits, explicit policies, cadences, metrics.
8. Socialise and evolve - agreements, experiments, a name for the system.

Why the order matters

Steps 1–6 are understanding, step 7 is design, step 8 is change management. Designing before understanding produces a board fitted to a template instead of to the context.

Worked example

A support team runs STATIK. Demand analysis shows 60% small requests, 25% incidents, 15% changes - and that 40% of requests were already answered in the knowledge base. Capability is 25 items per week with two specialists. Workflow model: triage → investigate → awaiting customer → resolved. Classes of service: incidents expedited (maximum two), changes fixed date, requests standard. Design: WIP limit of six in investigate, a visible blocked column with ageing, weekly replenishment. The failure-demand finding yields an experiment that reduces demand rather than adding capacity.

Traps that cost marks

• Jumping straight to step 7 and drawing a board.
• Skipping sources of dissatisfaction, so the design solves nothing anyone feels.
• Confusing work item types with classes of service.
• Treating STATIK as a one-off workshop instead of repeated evolution.