Kanban — What It is and Using It with Agile or CMMI

Introduction

Kanban (“signboard” or “billboard” in Japanese) is an inventory-control system to control the supply chain. It was made popular by Toyota in 1953*. In Kanban, a signal is sent to produce and deliver a new shipment of material as it is consumed. These signals are tracked through the replenishment cycle and bring visibility to a workflow.

One of the main benefits of Kanban comes from establishing an upper limit to the work in progress (WIP) to avoid overloading the development or manufacturing system. Kanban aligns inventory levels and work in progress, with actual consumption.

Kanban consists of the following steps:

1. Visualize the workflow
2. Limit WIP
3. Manage flow

Since Kanban is an approach to monitor the state of work activities, it can be applied to any type of work. Kanban measures the flow of work so that bottlenecks can be identified and addressed. One example is software development. Work items that are tracked in software development can include requirements (user stories), tasks, defects, enhancements, or action items.

Figure 1 shows an example work flow for software development. Each column, or work flow state, is usually well-defined and the columns represent a summary view.

Figure 1

The diagram is the same as a typical Scrum Board or Task Board used in Agile. The difference here is that a Work in Progress (WIP) limit is set for each of the columns.

WIP (Work in Progress)

To maximize the items that reach the “done” state, a limit can be put on the previous columns to highlight where work is building up. A WIP limit of three would mean that three or fewer items should be active in that state at any time. If the WIP limit is exceeded, the team needs to address issues that prevent the flow of work, rather than ignore chronic issues and move to other work just to stay busy.

Common causes of exceeding WIP limits include:

• Test tools and resources not available or working.
• Requirements not defined or clear.
• Test cases not defined or updated.
• Task and story dependencies are not identified or satisfied.
• Distractions prevent work being done.
• Poorly performing vendors.

When a WIP limit is approaching, or has been reached, the team stops and addresses the issue. Corrective actions could include helping a team member finish his or her work, improving a process that is causing the delay, or changing the WIP limit.

WIP limits are usually based on capacity. For example, a WIP limit of one item per person means that a team of five people can handle five items in that column. One item has to be finished before one more can be added. Setting a WIP limit of 10 would imply that multitasking is being done. If each team member switches between two primary tasks, then exceeding a WIP of 10 will likely indicate there is an issue to address. The goal is to move work to the “done” state, not just stay busy. Try several different WIP limits and determine a good one for your team.

An example

The following diagrams illustrate a client using Kanban for software development.

Figure 2

The “Working” chart in Figure 2 shows development tasks that are in progress. The seven-person team set a WIP limit of 14 (based on two tasks per person). This means that up to 14 tasks can be active at any one time for the team. The chart shows that the team isn’t suffering from multitasking in the work column, so the WIP limit could be reduced, perhaps even by half.

This group focuses on achieving smooth velocity to maintain a predictable cycle time rather than a smooth WIP. WIP charts provide an instantaneous picture and serve as a leading indicator for future velocity problems.

The same team also set a WIP limit of three for “Verification.” The chart shows that they exceeded the WIP limit at the beginning of the time period and the problem continued to worsen. While the team should consider raising the WIP limit to something more reasonable for its workflow, the real problem highlighted by this graph is a bottleneck in the testing phase.

Test teams that commonly exceed their WIP limit can have underlying causes, such as poorly defined requirements, excessively buggy code, unstable software and hardware platforms, or an understaffed testing team. Exceeding WIP limits can be an indicator that a bottleneck exists or that large cycle time variance is pending. The key Kanban indicators are cycle time (the time spent working on an item) and the Cumulative Flow Diagram described below.

Cumulative Flow Diagram

The Cumulative Flow Diagram in Figure 3 shows the overall work flow. The average delay in work finished is shown by the horizontal distance between the two graphs. The average WIP is shown by the vertical distance.

Figure 3

Each line represents the counts of the Backlog and Done columns from the Kanban board. The other columns can be plotted to provide more visibility about where the WIP is building up. The lines should be mostly parallel for a team to predict when work can be released.

When the lines start to separate on either axis, corrective action should be investigated. Figure 4 shows one example of the organization described above. The graph shows a fairly consistent flow of work from “Ready for Work” to “Done.”

Figure 4

How does Kanban relate to Scrum?

Scrum limits how much work you should commit to in a Sprint and expects sprints to be between one and four weeks. Kanban limits how much work you should have in any one process step (each column of the Kanban board).

Kanban does not have any fixed time boxes, project management or engineering practices. Therefore, the typical Scrum workflow (“Backlog Review,” “Sprint Planning,” “Development” and “Done”) can be used to define the initial Kanban states. Here are some suggestions for when to use Scrum and Kanban.

Use Scrum if:

• Your team prefers to group work into two-, three- or four- week chunks.
• Your team prefers daily and weekly team events to monitor progress, perform demos for feedback, and collect and act on lessons learned.
• Your team benefits from a periodic forcing function to look at what is actually built every sprint and take action.
• Your team members or managers tend to wander, change their mind a lot when they have goals longer than a month, or ignore real-time data regarding progress. Use the periodic scrum events to look at this information.

Use Kanban if:

• Your team has a continuous flow of work where any one item can be released when completed, and does not have to wait for other items. Examples could include bug fixes or help desk requests.
• Your team has an irregular release cycle.
• Your development work does not easily fit into standard duration sprints, or you prefer to set longer-term release goals and track progress to that goal.
• Your workflow processes are well defined and the team and management have a history of paying attention to project progress data and don’t need a forcing function every two weeks to stay focused.

Use Kanban and Scrum if:

• Your team wants the standard milestones of Scrum to chunk and manage work.
• Your team wants the additional visibility from Kanban on how well work is flowing through the process.

Kanban and CMMI (Capability Maturity Model Integration)

CMMI is a collection of project management, engineering and improvement practices organized into a roadmap to improve capability and performance. The practices can be put into a work flow and summarized on the Kanban board based on an Agile, Waterfall or hybrid project lifecycle. Kanban expects a work flow to be defined and CMMI provides one example of a complete set of practices that can be adopted incrementally into the workflow.

Two of the practices in CMMI refer to tracking work over time and establishing thresholds to trigger investigation and corrective action (PMC sp 1.1 and IPM sp 1.5***). The Kanban board is an example of how to track actual work complete. The WIP metric can be used as a threshold to trigger investigation regarding current performance. Therefore, Kanban can be used to implement these two practices.

The Risks of using Kanban

Here are some risks to be aware of if you adopt Kanban. (Don’t panic, they are all fixable.)

• If the work being tracked on a Kanban board is not clearly defined and monitored with “done” being crystal clear, then the charts won’t mean anything.
• If team members and senior managers typically shy away from discussing and correcting chronic problems because status quo is comfortable, then Kanban will provide little value and the team will be less willing to try the next approach.
• If team members are chided for exceeding WIP limits or not having predictable Cumulative Flow diagrams, then they will stop reporting accurate data.
• If your culture thrives on extreme multi-tasking then Kanban might fail because Kanban focuses on getting work done, not getting more work started.
• If your organization gave up on Scrum or CMMI because it didn’t like to plan based on capacity, commit and be accountable, then Kanban will just provide one more view of the world that you don’t like. It would be like throwing away a square mirror and hoping for better results from a round mirror.

Summary

Using Scrum to chunk and manage work, along with CMMI Maturity Level 3 engineering, project management and improvement practices, leads to a world-class performing organization. Adding Kanban provides visibility into the work flow. Organizations can go one step further by adding Lean principles to identify and reduce waste.

Questions and comments link.

[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link.

[Thanks to Jim Congdon of Logos Technologies, LLC for real data and input for the article. Jim is a PMI-certified manager of an Agile software development group that has been appraised at CMMI Maturity Level 3.]

References

*https://en.wikipedia.org/wiki/Kanban

**Kanban and Scrum – making the most of both, Henrik Kniberg & Mattias Skarin. Also see https://www.atlassian.com/agile/kanban

***CMMI Practices for tracking work:

• Project Monitoring and Control (PMC) Specific Practice (sp) 1.1: Monitor actual values of project planning parameters against the project plan. (This practice is partially implemented by tracking work in the Kanban board, and can be fully implemented by additionally tracking the actual work effort required.)
• Integrated Project Management (IPM) sp 1.5: Manage the project using the project plan, other plans that affect the project, and the project’s defined process.