I’ve received an email from my friend Stan looking for an outline of ideas on how to spread his Kanban implementation from one unit/team to the rest of his company. I get asked this question often and there are patterns with what Stan is trying to do. So, I’m copying and pasting from my email response to him here, with all private information deleted, obviously, and the rest of the message adapted somewhat for the broader audience.

Remember service orientation. We create Kanban systems largely so that we can understand and improve some service that we’re delivering. Therefore, organizational Kanban systems should reflect some services that we’re delivering as a whole organization. They should not merely radiate or “roll up” information on tasks everyone is doing.

Keep eyes on the prize. What challenge are you answering: to increase throughput, decrease delivery time, improve quality, predictability, due-date performance, relieve some sources of unhappiness? When you know your challenge, it informs the design of each kanban system. It also helps find the next evolutionary steps.

Scaling up with two-tier Kanbans. There is an example of this pattern in the Chapter 13 of the blue book. It is also covered in the Foundation-level class. (Stan and several his colleagues took the class and saw this pattern emerge during the kanban system design exercise.) The workflow is hierarchical. At the upper tier, work items are coarsely grained (e.g. feature sets). For some part of the upper-tier workflow, those large work items break down into more finely grained items (e.g. features, user stories), which flow through the lower-tier workflow.

Scaling up with Portfolio Kanban. Pawel Brodzinski’s blog is a good starting point. Pawel also made a good presentation on Portfolio Kanban at a recent conference.

Scaling out by joining Kanban systems. This means gradually joining two or more kanban systems separated by infinite (no WIP limit) buffers into a single kanban system. At the early stages of using Kanban, you may find yourself in a situation, where WIP is limited for each (most, some) workflow stages, but these stages are separated from each other by unlimited buffers. Stringing together multiple WIP-limited workflow stages into a single kanban system may be culturally difficult early on in Stan’s company or may create an unsafe-to-fail experiment.

Scaling out in the service-oriented fashion. Various departments and teams have their kanban systems, delivering services to external customers as well as to each other. One system’s external dependency or output could be another system’s source of demand/input. Each system seeks its own balance of demand and capability, but they’re interdependent. Interdependence helps unlock improvements. Russell Healy’s Obeya project is the cutting edge in visualizing this interdependence (link to a video of Russell’s recent conference talk explaining it).

Scaling by learning. Designing kanban systems in various departments, sustaining them on the daily basis, evolving them cannot be taken for granted. It takes people real effort and the people need training, community support and coaching.

Which of these patterns do you find most helpful in your company? What other pragmatic advice can you give to Stan?