Kanban

What is Kanban? Why do we use Scrum and not this?

Kanban is neither a framework (like Scrum) nor a methodology (like PRINCE2). Instead it’s a simply a model for implementing change through incremental improvements.

States

With Kanban you organise your work on a Kanban board. The board has a series of columns, each one a work state that your stories pass through, left to right, as they’re developed. These columns, or states, can include development, review, QA, done. You can also have sub-states within a state. For example, the development state might have ready, in progress and don as its sub-states.

Kanban board in action

Work in Progress (WIP)

WIP is a Kanban control. For each state on the Kanban board you must specify a WIP limit. That is, the maximum number of items, or stories, that are allowed in that state at any one time. If a state reaches its limit then no new work can pass into that state until room is freed up.

Setting a maximum WIP for a state can be good news for many Agile teams. This control means that there can be no flexibility for a client to be continually pushing more and more into the queue. Before more work can be pushed into the required state it’s the team’s responsibility to complete the work in the maximum state, to free up the state and get things moving.

With Scrum it’s all too easy in a sprint to end up spinning too many plates. When you have multiple strands of work on the go then you can suffer from context-switching. This happens when you’re bouncing between multiple stories, not concentrating for long enough on a single task and not performing efficiently.

With a WIP limit the team needs to stop what it’s doing and concentrate on the bottleneck. They need to work together to complete whatever work is clogging up the workflow and get the work flowing properly again. This also serves to maintain a more constant stream of work and helps avoid those last minute sprint panics when EVERYTHING needs to be tested, reviewed or approved!

Kanban or Scrum?

As I mentioned earlier, Kanban is not a framework. We don’t need to choose between it and Scrum. Kanban is a model that can be applied to existing processes.

Kanban can compliment Scrum. With Scrum we accept stories into a sprint backlog and we work on those over the course of, say, two weeks. If you’re struggling to deal with the many spinning plates that introduces, particularly if you have a large delivery team or if you need to exert control over a demanding client, then integrating Kanban into the mix is a great way to control things.

So, it’s not a question of "Kanban or Scrum?” The question is "Scrum or Scrum with Kanban controls?"