Kanban in a Nutshell

The true power of Kanban isn't a board, stories, or pull. The real power is in Disneyland Time.

Lean Values

Let's go back. Way back to before Lean Software Development came out. We had Scrum or Extreme Programming as Agile processes. We also noticed Lean Manufacturing had values and principles that aligned with Agile Software Development.

Specifically Value, Value Stream, Pull and Flow.

Value is the V in INVEST. A story should have value either to the customer or to the developer in the form of risk management.

Value is important whether you're practising XP, Scrum or Kanban.

Value Stream is the process.

Lean Manufacturers optimize the value stream to deliver value as soon as possible.

In Kanban, the value stream is the board. The board represents all the stages the story passes through before it is delivered to the customer.

Pull is where the term Kanban came from. In Lean Manufacturing, the upstream station puts a kanban card in the middle of his or her product stack. When the downstream station gets to the card, he or she walks it up to the upstream station who then starts producing again.

In Kanban, pull is simulated with WIP limits. The goal is to pull stories across the board, not push more work into it.

Flow is how well the value moves through the value stream. Flow is pulling value through the value stream while not piling up inventory in front of any station.

Flow in Kanban is simulated with WIP limits and swarming. Developers swarm when a column has reached its WIP limit and no more work can be pulled in.

For example, say the development and test lanes are at their WIP limits, and thus no more stories can be pulled into either lane. Developers will swarm with the testers to help clear the test lane so development stories can be pulled into the test lane; making room in the development lane for stories to be pulled in.

Kanban is Pull

Simply stated, if your pushing stories into the board you're doing Kanban wrong. Stories should be pulled into the next lane by those responsible for that lane.

Kanban teams have different ways to indicate a story is ready to be pulled into the next lane. Some mark the card, others divide the lane somehow to differentiate done and in process stories. Done stories are candidates to be pulled into the downstream lane.

WIP Limits

Work in Process limits restrict the number of stories that can be in each lane.

Shops that pair base their WIP limits on how many stories can be actively worked on.

For example, a team with 6 developers and 4 testers would put a limit of 3 on development and 2 on testing.

There should not be a story on the board, other than in backlog, that is not being actively worked on. The exception is blocked stories which is another topic in and of itself.

Cycle and Lead Time or Disneyland Time

So where does this Disneyland Time come in? At Disneyland when you are waiting in line (before the digital era where you can reserve a time) there were signs that said "Your wait time from here is X minutes".

Kanban boards can provide the same information based on measurements instead of estimates. When the story is placed in the backlog, the placer (product owner) writes the date on the card.

When the card is pulled into development, the developer writes that data on the card. Now you can measure the time from backlog to development.

When the card is pulled into deploy, the devops engineer writes the date on the card. The time between the start of development and pulled into deploy is the cycle time.

In my opinion, cycle time is the only valuable measurement for a team.

When the story is deployed, the date it was deployed is written on the card. The time from backlog to deployed is lead time.

After a few stories have been deployed, you have a real world average of how long a story takes from backlog to deployed. You can calculate the Disneyland Time and write that at the bottom of the backlog.

From here your story will take X days to deploy.

No estimates required. You have real measurements for how long a story spends on the board.

When you can confidently write "From here your story will be deployed in X days" at the bottom of the backlog then, and only then, can you brag at the next conference that your team is doing Kanban.

Happy Lean Development.

References: