Kanban Framework

This article refers to the Kanban agile framework first introduced by David Anderson[1] and his experiences when working on the Corbis project at Microsoft.

Kanban gets its name from the use of visualising the flow of work and the use of tickets or signposts to indicate the state of the work items in the process flow. As a framework it focusses on optimising a smooth efficient flow of the work as it arrives, is worked on by the team and leaves the team with visualisation techniques, establishing delivery and input cadences, limiting the amount of work in progress, establishing service level agreements, measurement and continuous improvement.

Mapping The Value Stream

Mapping the value stream considers the flow of work as it arrives at a team, is completed by the team and finally leaves the team. Understanding where value is added in the process flow and where waste, (or waiting time,) is present provides an understanding of the Value Stream and where it can be optimised for efficient flow of the work.

The Value Stream is often represented as a Card Wall providing visibility of the state of the work, where bottlenecks are appearing and how to optimise the flow.

Coordination

The coordination of the Kanban system is usually done with the use of:

• Daily Standup Meetings where the team meet on a daily basis to coordinate their efforts
• Queue Replenishment Meetings to consider the next high level and strategic priorities with respect to the Work In Progress (WIP) limits
• Release Planning meetings to consider the intent and composition of the releases

Delivery Cadence

The delivery cadence is the frequency or rhythm of delivery for the team. Separating the management of the work from the delivery cadence allows for regular delivery schedules to be set up and features are either in the next available release, (on the bus,) or not, (off the bus,) and waiting for the next available one. This approach helps to smooth out the flow of features to deployment and de-couples the hard definition and composition of a release to use a pull system instead that pulls in features that are ready for release.

Frequency

The frequency of releases in the delivery cadence will usually depend upon the time, (and cost,) it takes to make a delivery. If using a manual approach and it takes 5 people 2 days to make a release to production, then may be a 4 weekly cadence may be more appropriate. Calculating a delivery efficiency with respect to the cost involved in making a release and the Cost of Delay of delivering features may be a good approach to provide an object measure of delivery efficiency and so indicate an appropriate cadence to agree and implement.

If a team is using Continuous Delivery approaches, then the automation of releases and the subsequent high frequency of releases then provides a higher cadence and shorter feedback cycle. Using these techniques allows teams to consider a smoother flow of features from concept to production and the rapid incorporation of feedback and adaptation.

Input Cadence

The input cadence is a prioritisation meeting where new work items are decided upon, prioritised and input into the value stream.

Typically, the attendees to this forum tend to be stakeholders with a wider perspective than those that attend the Queue Replenishment meetings. Policies may be implemented to assist the prioritisation such as a valuation criteria to provide some guidance on which work items are deemed more valuable than others.

Continuous Improvement

• Theory of Constraints
• Elimination of Waste

Practices

• Showcase
• Kaizen & Continuous Improvement

See Also

• Lean Software Development
• Scrum Framework

References

1. Kanban: Successful Evolutionary Change For Your Technology Business, Anderson D. J., 2010