Kanban Distilled for Managers

This is a repost from kanbandistilled.com/ . Their website reports that they will be back soon… but until then, here is a great explaniation of how a kanban can work in software development. If you’re interested, click here for a Lean Glossary (adapted from Richard Durnall’s blog).
Bob Hubbard, Atlanta Georgia USA

Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota’s “just-in-time” (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end.

Software Pipeline

Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we’ll assume a simple phased process of: (1) analyse the requirements, (2) develop the code, and (3) test it works.

The Effect of Bottlenecks

A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the throughput of the bottleneck.

Using our development pipeline as an example: if the testers are only able to test 5 features per week whereas the developers and analysts have the capacity to produce 10 features per week, the throughput of the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck.

Effect of Bottlenecks

If the analysts and developers aren’t aware that the testers are the bottleneck, then a backlog of work will begin to pile up in front of the testers.

The effect is that lead times go up. And, like warehouse stock, work sitting in the pipeline ties up investment, creates distance from the market, and drops in value as time goes by.

Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting bugs released into production cause problems for the users and waste future pipeline capacity.

If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it. For example, the analysts could help with testing and the developers could work on test automation.

But how do we know where the bottleneck is in any given process? And what happens when it moves?

Kanban reveals bottlenecks dynamically

Kanban is incredibly simple, but at the same time incredibly powerful. In its simplest incarnation, a kanban system consists of a big board on the wall with cards or sticky notes placed in columns with numbers at the top.

Limiting work-in-progress reveals the bottlenecks so you can address them.

The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of each column are limits on the number of cards allowed in each column.

The limits are the critical difference between a kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get out of hand.

Worked Example

The board below shows a situation where the developers and analysts are being prevented from taking on any more work until the testers free up a slot and pull in the next work item. At this point the developers and analysts should be looking at ways they can help relieve the burden on the testers.

Notice that we’ve split some of the columns in two, to indicate items being worked on and those finished and ready to be pulled by the downsteam process. There are several different ways you can layout out the board. This is a fairly simple way. The limits at the top of the split columns cover both the “doing” and “done” columns.

Once the testers have finished testing a feature, they move the card and free up a slot in the “Test” column.

Now the empty slot in the “Test” column can be filled by one of the cards in the development “done” column. That frees up a slot under “Development” and the next card can be pulled from the “Analysis” column and so on.

Next steps

How to get started with Kanban…

  1. Map your value stream (your development process).
    Where do feature ideas come from? What are all the steps that the idea goes through until it’s sitting in the hands of the end-user?
  2. Define the start and end points for the Kanban system.
    These should preferably be where you have political control. Don’t worry too much about starting with a narrow focus, as people outside the span will soon ask to join in.
  3. Agree:
    • Initial WIP limits and policies for changing or temporarily breaking them
    • Process for prioritising and selecting features
    • Policies for different classes of service (e.g. “standard”, “expedite”, “fixed delivery date”). Are estimates needed? When choosing work, which will be selected first?
    • Frequency of reviews
  4. Draw up a Kanban board.
    All you need is a whiteboard and some Post-It™ notes. Don’t spend too much time making it look beautiful because it will almost certainly evolve.
  5. Start using it.
  6. Empirically adjust.

from kanbandistilled.com/


One thought on “Kanban Distilled for Managers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s