Kanban Development

From Youmanage
Jump to: navigation, search
Appropriate Process @ Youmanage HR
Risk Map Risk Map
Getting Started in Agile Getting Started

Software development run as a “Pull” system throughout.


The Kanban Development approach runs the entire software development process as a Kanban system (see Kanban Card), pulling work into each phase of development when capacity is available and balancing the phases to attempt smooth and continuous flow through the entire process.


David Anderson and the kanbandev group on Yahoo


The Pull Signal from delivering finished features is propagated up the supply chain. Each link in the supply chain has just enough Work in Progress (WIP) to have work ready to pass on just in time as the Pull Signal arrives. Iterative Development is eliminated, all necessary work is folded into the continuous flow of work. In reality, few existing Kanban Development systems manage to achieve this ideal; retrospectives (see Retrospective Of Work) usually fall outside the normal flow of work. Most aspects are similar to other Agile Approaches; delivery is measured in terms of Running Tested Features and the push is to reduce Cycle Time. A desire to increase Work in Progress in any phase of development is reason to investigate causes, as is excessive slack time in any phase. These things often point to opportunities for process improvement.

Kanban Development is a cutting edge approach to Agile and Lean development that emerged c. 2006, part of a trend to integrate these approaches that is now common across the entire range of Agile and Lean Software Development.

One interesting common policy from Kanban Development is that work is not estimated up front. In reality there will always be some tacit expectation of ‘size’ and often an attempt will be made to chunk the input work into jobs of roughly similar sizes. Yet this is all that needs to be done by way of estimation and it is done to ease the flow through the system; in general estimation is regarded as waste to be eliminated. The underlying thinking is that it is always easy enough to find work that is undeniably worth doing, so if we’re going to do the work anyway it gains us nothing to estimate the cost up front, bearing in mind the necessary inaccuracy in such an estimate.

Kanban Development is particularly useful in areas where there is need to service tight Service Level Agreements (SLA) such as in maintenance of Live systems or support for systems where there are exceptionally good opportunities to be had for short ‘time to market’ responses – any cases where Iterative Development’s standard average time to market of one and a half iterations would be too slow a response.

Problems and Contra-Indications

Though David Anderson claims this is an easy way to transition a team to Agile development this is only true if the team is already working with many "small batch" pieces of work; it is not going to be an easy transition if they are starting from "big batch" Waterfall. There is also some criticism that it isn't good to break the flow up into stages controlled by Kanban cards or the like; One Piece Flow is better. In reality, Kanban Development does not preclude One Piece Flow, it gives the team the option to break the flow but the limits to Work In Process and the drive to reduce Cycle Time drive the team toward One Piece Flow in any case.


How Kanban differs from Scrum - Here’s a useful comparison between Kanban and Scrum – not too one-sided.

Conversation Snippets

David Anderson – Core Properties of Kanban Development

(kanbandev group 4 Jan 2010)

This time I am separating the definition into 5 Core Properties (of a Kanban implementation) and 5 Emergent Properties.
The 5 core properties were all present in the original XIT implementation in 2004. The 5 Emergent Properties all appeared at Corbis during 2007. Together all 10 represent the content of the forthcoming book.
There are 5 core properties to a Kanban implementation
  1. Limit Work-in-Progress
  2. Visualize Workflow
  3. Measure & Optimize Flow
  4. Make Process Policies Explicit
  5. Manage Quantitatively
There at least 5 emergent properties we might expect in a Kanban implementation
  1. Prioritize Work by Cost of Delay
  2. Optimize Value with Classes of Service
  3. Spread Risk with Capacity Allocation
  4. Encourage Process Innovation
  5. Use Models* to Recognize Improvement Opportunities
*Common models in use with Kanban include the Theory of Constraints, Systems Thinking, an understanding of variability through the teachings of W. Edwards Deming and the concept of "muda" (waste) from the Toyota Production System. The models used with Kanban are continually evolving and ideas from other such as sociology, psychology, and risk management have been used already with some implementations.
This new definition is also word-for-word compatible with the 3 point definition that Henrik Kniberg & Mattias Skarin published in their "Scrum and Kanban" book.

Karl Scotland on “Isn’t Kanban just a Task Board?”

(kanbandev group May 2009)

While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?
A Kanban System visualises some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualising the current tasks.
A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.
A Kanban System deals with these units of value through the whole system, from when they enter a team’s control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.
By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.
A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status.