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.

Change Management Principles

1. Start With What You Do Now - A Kanban implementation is sensitive to avoid changing too much too quickly, but to optimise what is currently being done
2. Agree to Pursue Improvement Through Evolutionary Change - Small and continuous optimisations of the process are encouraged
3. Encourage Acts of Leadership at Every Level - Real change is expected to be supported by leadership at all levels

In addition, Kanban focusses on managing the work and encourages teams to self organise around it taking into consideration their expertise and opinion.

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.

Limiting Work In Progress

Work In Progress (WIP) Limits provide a mechanism to reduce the amount of work done at once and applies the Theory of Constraints to smooth out the flow of the work in the Value Stream.

The WIP Limits form a constraint which prompts active evaluation and prioritisation of the work enabling a team to decide which items are more valuable and hence, higher priority than others.

Optimising The Flow

WIP Limits are best agreed in the team as an honest representation of how much work can be done at once for a particular point, (or state,) in the Value Stream. Continually measuring the Value Stream, (how much value over the waiting time,) along with Cycle Time can then be used as an indicator of how the work traverses the Value Stream and where it can be optimised.

WIP Limits are expected to be optimised on a regular basis during the initial adoption of the technique and periodically adjusted to gain the optimum flow, as the Value Stream may be dynamic and ever changing in nature.

Service Level Agreements

Not all work items are the same and some may have a natural higher urgency or importance, and so should take priority over other work items. In Kanban teams decide with stakeholders the Classifications of Service to represent the different categories and implied importance of work items, and may be represented as different colour tickets to assist teams determine the appropriate priorities of the work.

Classifications

Example classifications of service include:

• Urgency Class - these work items do not happen often but when they make an appearance they may live in the Expedite swim lane and are prioritised over all other work
• Fixed Delivery Date Class - if a team is working towards a fixed date it may be useful to represent these work items in a prominent colour so that the team appreciate the criticality of the work and prioritise them effectively
• Standard Class - most of the work may well be in a standard classification and so the normal prioritisation rules apply
• Indeterminate Class - for those items that are not urgent but may be background or preparatory work items and so form a lower class of priority

Establishing SLAs

The best approach to establish an SLA is to use historical data, for example: Cycle Time, (measuring the time it takes for a work item to traverse the Value Stream from entry to exit,) to indicate the demonstrated average response times for classifications of work items. This historical data and subsequently the rolling average response times may change over time as the Value Stream is optimised, but provides an evidential approach to SLAs rather than just guessing.

Metrics

Common metrics used in Kanban include:

• Cumulative Flow Diagram which indicates the queue sizes over time providing historical information about how the work traverses through the Value Stream.
• Lead Time, sometimes referred to as Cycle Time which indicates the actual time taken for work items to traverse the Value Stream and can be useful when compared to the agreed SLA times
• Throughput which indicates the number of work items completed at regular sampling intervals, weekly for example, and can be used to indicate long term trends or in a Control Chart to indicate flow performance

Scaling

Scaling is predominantly about how multiple Kanban teams can work together in cohesive harmony towards a common goal. A practical implementation of this is to allow each Kanban team to be independent and autonomous so that they are able to define their own destiny and run at their own pace and with their own Card Walls. The challenge is then how to enable them to also coordinate their efforts towards a common goal and manage any cross dependencies.

To help with improving the visibility across the portfolio, a combined Card Wall at a higher level of abstraction representing the teams' Value Streams can be created.

Abstraction

Aggregating several Kanbans together in a portfolio view for example, involves abstracting or Laddering Up the work items to a higher level. Using a tiered Card Wall can help to provide traceability between the higher level objectives and the lower level work items. Here the Card Wall representing the Value Stream has another level of abstraction around it with coarse grained work items representing objectives, initiatives or intentions aligned to the corresponding lower level work items. As all of the related child work items are completed, then the higher level parent work objectives are also completed.

To help with visibility, swim lanes are often used to segregate related work items and higher level objectives.

Dependencies

Cross team dependencies can often be managed as they happen especially if the teams are located close to each other. Here teams that have discovered a dependency simply walk over to the team that they are dependent upon and resolve how they are going to resolve the issues as they happen, often updating their respective Card Walls to reflect the current state of the work.

Coordination

There may be additional forums to help teams coordinate their efforts if needed, although a natural and ad-hoc approach is favoured.

Operations Review

The Operations Review is a feedback and adaptation meeting across the enterprise or organisation to review each department's performance and decide on process improvements often supported with metrics and with a view to developing a Kaizen or continuous improvement culture in the organisation.

A monthly cadence is suggested as being appropriate for several departments to get together and provide feedback.

The management team are usually expected to implement the process improvements as a means to act on the feedback in order to support the teams, often with senior management support.

See Also

• Lean Software Development
• Scrum Framework

References

1. Kanban: Successful Evolutionary Change For Your Technology Business, Anderson D. J., 2010
2. https://www.agilealliance.org/glossary/kanban/, accessed 14 Jan 2019