As a Lean Coach working in IT I often hear development teams refer proudly to their scrumboards as an example of Kanban. To which I say, ‘that’s a great start… but it’s really only just the start’.

Let’s start with what a scrumboard is, and does. A scrumboard is a visual display of work, showing the progression of user stories in development. As you see some stories moving through the phases of development, and others getting stuck, you huddle to figure out how to get them unstuck. Now you’re using your visual display for visual management, which is a great Lean solution.

Change management boards, like the one used in The Pheonix Project, are another good example of visual management. The physical display of changes, shown by release date and system, is a great way to get a handle on the amount of change and risk you’re throwing into live production. When you start moving them around to limit the risk, again, you’re using visual management.

The word ‘kanban’ roughly translates as ‘signboard’, and a scrumboard really is a good start. But it’s only half the story. Until you limit the number of stickies on your change management plan, or the number of story cards on your scrumboard, you’re really only half way to kanban nirvana.

True kanban requires you to limit the amount of work in progress and to establish the pull of work. In a manufacturing plant, a kanban card is attached to each unit in production. When a completed unit is, say, taken off the shelf by a customer, the card is sent back into the production line to signal that there is now an empty slot on that shelf which needs replenishing. Limiting the kanban cards sets a constraint around the amount of work in progress – and this limit should reflect the capacity of the process. In the same way, you can limit the number of story cards, boxes on your scrumboard or spaces in your change management plan. When a scrumteam complete a story that frees up a slot for them to pull the next story into their workload: the visual display should reflect this by showing each team’s capacity. In addition to visual management, you can create rules around work in progress, requiring each scrumteam to limit their intake so they have no more than, say, two workpackages in progress at a time.

This is all well and good, but what do you do when demand from the business requires a greater capacity? Historically you’d have thrown that extra demand into the mix, asking your teams to do more with the the same amount of resource, maybe pushing back a release date to accommodate the extra work.

Kanban requires you to create additional capacity in the system to allow for the additional demand either by:

• rebalancing the load, for example switching some resources from a work package that is ahead of schedule
• removing or deprioritizing other work and putting work on hold
• increasing resources by bringing in new team members

All of these actions will generate some churn, so it’s going to be worth a tough conversation with your customer first. ‘Are you sure you want me to disrupt the current sprint, or the next release, to squeeze this in? How about we pick it up next week, when we’ll have some new capacity?’ By limiting your work in progress, you’ll be speeding up the flow of development into production, so you can make that ‘next week’ promise with increasing confidence.

So the next time you walk over to that scrumboard, why not take the next step, and limit the work in progress to truly establish kanban.