Published on Tue, 09/03/2019 - 10:15

What is Kanban Software Development?

Chronology of Iterative and Incremental Development

- 1995 First 'Agile' methodologies introducted DSDM & Scrum

- 1999 Extreme Programming book published

- 2001 Agile Manifesto

- 2004 Kanban being introduced to Software Development

Kanban is 'Lean'

Lean was used to describe Toyota's production management techniques during the 1980s that was producing with fewer labour hours, better quality and faster turn around times. [1] This was achieved using a just-in-time (JIT) production system by:

1. Visualising the value stream map (Kanban board)

2. Reversing the flow of information (Pull system)

3. Multi-skilled workers

4. Continual improvement

How does it work?

"Kanban systems are different because they focus
on a continuous flow of work, and disregard fixed
iterations. When needed, the team chooses a subset
of features from the backlog and moves them to the
Kanban board. Then, it develops these features one
after the other. Work is delivered as soon as it's
ready, and the team only works on one – or very few
– feature at a time. " [2]

This is based on its axioms

1. It is possible to divide the work into small value adding increments that can be independently scheduled.
2. It is possible to develop any value-adding increment in a continuous flow from requirement to development.
[3]

"Continuous flow" aka Continuous Develivery

If you deliver daily, waste is exposed almost immediately; you have no choice but to build quality in; you learn quickly what customers value; .... problems are exposed quickly and so constant improvement is mandatory [1]

Pull system

Through 'pulling' only the highest value task from the backlog work is focused on high value work, eliminating waste of work on unnecwssary features and enabling the team to be reactive.

Work in progress limit

Limiting WIP reduces context switching, aids the visualisation of the value stream map and highlights blocked work.

When not to use Kanban

When the Axioms aren't possible e.g Work can't be independelty scheduled or add value incrementally. This could be the case when tasks need to be done in a particular order such as a large refactoring, tasks by themselves won't add value as they may even break the system and it is necessary to see a bundle of tasks completed simultaneiouysly. At that point you are doing an iteration and lose the advantage of focusing on a continous flow.

What do you lose out on Kanban over Scrum?

1. Lose out on wins from the end of a sprint.

2. No artifical time pressure

Citations:

[1: Lean Software Development: A tutorial Mary Poppendick, Michael Cusumano]

[2: A Review of Lean-Kanban Approaches in the Software Development ]

[3: Scrumban, Corey Ladas]

[4: Kanban pull and flow, Raju and Krishnegowda]

Blogs of things