Limiting WIP

A true kanban system incorporates some mechanism for limiting the amount of work in progress. Once again, there are numerous ways to achieve this:

• Numeric WIP limits, each controlling the amount of WIP in a single column, a span of columns, or a horizontal swim lane.
• Physical constraints, such as the number of horizontal swim lanes available.
• Limits on the number of tokens (e.g., personal avatars) in circulation, and attaching them to tickets. The control offered by this mechanism is lessened if tickets are allowed to be in progress without such a token; in this case, it is limiting not the overall WIP, only the amount considered “active.”
• Policies that control, for example, the amount of WIP per person or class of service.
• Some external mechanism that releases work into the system only when there is capacity. Scrum achieves this by limiting the amount of work committed to in a timeboxed sprint.

There is a lot to be said for using multiple techniques in combination, for example:

• Horizontal (e.g., class of service) and vertical (state) limits in combination
• Physical constraints (e.g., on epics) combined with vertical limits (e.g., on features in active development)
• Sprints combined with column-level limits, to curb multitasking and to encourage work to move from states of partial completion (e.g., “code complete”) and on toward deployment

When multiple crosscutting mechanisms have been properly calibrated, no limit needs to feel overly constraining on its own, and yet the combined effect is to reduce WIP to levels that might previously have seemed inconceivable. Each limit addresses a particular symptom or behavior, kicks in when needed, and helps to smooth flow overall.

Review

Given the wide range of design choices available, it’s a good idea to review the board design before deeming it to be your “initial” one (don’t ever think of it as “final”!).

Begin with some basic technical checks:

• How does the board look when populated with work items? Does it organize them effectively? Is there enough room?
• How much movement will we see between standups? Not enough? Too much?
• Is it understandable by its intended users? Too complicated? Too simplistic? Ask them, or better still, involve them.
• Does it make unreasonable demands or assume changes of process, organization, or role that aren’t yet agreed upon? (I don’t say “never” to introducing radical system changes at this stage, but I don’t usually recommend it.)

More reflectively, a good design addresses multiple needs of a broader nature:

• It brings transparency to what is happening and how it happens, helps better decisions to be made, and encourages self-organization and collaboration. Can you (collectively) picture those things with this design?
• It helps to bring balance—between demand and supply, across different categories of demand, and so on. Will it do that, even if only tentatively?
• It encourages both thought and action with respect to customer focus and flow. Refer to Chapters 4 and 5 and try using your board design as a thinking tool.

Lastly, and crucially:

• In what ways does this design begin to address the specific dissatisfactions and frustrations you captured at the very start of this process (Chapter 18)? Don’t expect to fix all of them right away—it may be better not even to try—but will it bring their symptoms or causes closer to the surface than they are now?

These review considerations—and most especially the last one—apply not only when designing a board for the first time, but when evolving it, too. Better an ugly board whose changes are deliberately targeted than a beautiful one whose refinements exist for their own sake. Learn to see through the board to the system it represents; act on one for the effect it has on the other.