Kanban Adoption for Software Teams

Although the Kanban Method has its roots in manufacturing, and outside of that is usually associated with product support teams, it has become increasingly adopted by software development teams seeking an agile delivery method with less overhead than Scrum, or looking for additional techniques to improve the flow of their delivery processes. The Kanban Method and Scrum solve different problems, the former being focused on accelerating the flow of work through a workflow or business process, often in environments with significant demand variability, while Scrum is an empirical framework designed for development of new products in an environment of high uncertainty and rapid change. The heart of Kanban is workflow optimization. Scrum is designed for product innovation. Either framework can be applied to software development, where each brings a different emphasis depending on the nature of the specific challenges facing a development team. Further, when the Kanban Method is deployed for software development it is frequently supplemented with additional practices borrowed from Scrum, such as stand-ups, product demos and retrospectives. Scrum teams on the other hand can take advantage of Kanban concepts such as improved visualization and controlling WIP within their workflows as a way to improve transparency, boost throughput and velocity.

Beginning an initiative to adopt Kanban requires no major disruption to existing delivery processes or organizational structures. The transition can be evolutionary and self-directed. Here is a summary of the basic steps for setting up and operating a Kanban system for software development:

Step 1: Visualize your workflow.

Bringing clarity and transparency to the work is a prerequisite for problem-solving and meaningful change – you can’t fix problems that you can’t see. Transparency promotes a common understanding of the work between members of a delivery team, and establishes an objective basis for enacting change. The individual steps in workflow are represented by columns on a board or wall (either physical or electronic), the details of work items are captured on cards which are then placed in the column representing their current state. For software development cards typically represent User Stories, though other artifacts such as Features or entire initiatives (Epics) could be tracked.

For each state in the workflow (except the end states), create 2 sub-states: In Progress and Done. This step is important because it makes it possible to identify and react to emergent queues within the system. Effective visualization enables rapid diagnosis of flow-related problems.

Step 2: Apply WIP limits to each step of the workflow.

WIP-limited pull is the central flow-control mechanism in Kanban. WIP Limits are used to ensure that any processing step in a workflow is not being overwhelmed by consuming more work than it has the capacity to process. This prevents queues of work from building up between steps and keeps the cycle time for each step to a minimum. When WIP within each process step is minimized, end-to-end lead time is minimized. This relationship is enshrined in Little’s Law:

This may seem like common sense, viz. the time to get a work item through a process is the amount of work waiting to be processed divided by the processing rate per item. The amount of WIP between each step in a workflow is effectively a queue. The longer the queue the longer an item must wait to be processed, directly causing longer lead or cycle times per Little’s Law. The end-to-end Lead Time through the entire system is the sum of the individual process cycle times. To achieve our goal of minimizing Lead Time, we constrain the length of the queues between processing steps by applying WIP limits. In an ideal system, work items arriving in  the ‘done’ sub-state of each process step would be immediately consumed by the next processing step. This ideal is referred to as One Piece Flow. The result is that work flows smoothly through the system, improving end-to-end performance.

The optimum WIP level for any processing step is a reflection of that step’s capacity to process work. We neither want to overload it’s capacity or starve it of work either. WIP limits should be set to some initial values (say based on the number of team members within each processing step) and then refined or adjusted over time. Ultimately we want to achieve a balance in the flow between adjacent processes where the average rate of output from one process (arrival into it’s ‘done’ state) matches the average rate at which the adjacent downstream process can consume that work. In a manufacturing environment where the product being produced is highly repetitive, these limits can be calculated mathematically to achieve balance between processing steps. For software development where every new feature or user story is unique, this problem must be solved empirically. WIP constraints are the most effective way to achieve rate-matching between adjacent processes.

Step 3: Define ‘done’ for each step in the process.

Being clear and explicit about what ‘done’ means for each step of the workflow further enhances overall transparency about how the system operates, and provides a foundation for how to improve it. A transparent definition of done brings predictability and ensures quality. Making the exit criteria explicit means that the work for each step is done in a consistent and repeatable way, and that the work item is a known state when done.

One of the core concepts in Lean Manufacturing is Standard Work. The idea is that we get consistent results from a process that is applied consistently. This may seem anathema for knowledge workers who are motivated by autonomy. The idea isn’t to use the standards as a way to limit the team. Rather, the standard is to be used a baseline for continuous improvement.  It is only possible to evaluate improvements objectively when existing workflow procedures are ‘standardized’. As standards improve, the new standard becomes the basis for further improvements: improving standardized work is a never-ending process.

Now our pull system is constrained by 2 things: only pull an item when there is capacity to work on it (WIP constraint), and when the item meets the definition of done for the last step in the workflow (workflow policy constraint).

Step 4: Make it Flow.

Meet daily to identify bottlenecks, emergent queues and other impediments or delays to the flow of work. In particular, check if any step is overloaded or if any step is waiting for work, or if any items are stuck in a step well beyond their normal cycle times For the latter issue some tools will display the age of the age of the item in that state. Priority should always be given to finishing work versus starting work. If necessary make adjustments to improve the flow.

Maintaining the flow means actively managing all work items in progress between the Backlog and Done states. A Kanban development team should meet on a regular cadence (for example, conduct a Daily Stand-up) to review their board and agree what adjustments need to be made. In the above example what action should the team take? How about the one below?

A Daily Stand-Up for a Kanban team is focused on managing flow. The event takes place around the Kanban Board and seeks to identify steps in the workflow that are overloaded, starved of work or blocked, and on what actions the team can take to recover the flow.

Step 5: Measure and Improve.

While the Daily Standup event is focused on making tactical adjustments to maintain the flow on a day-to-day basis, more systemic improvements of the overall workflow need a broader perspective on how the system is performing. Continuous measurement and improvement of the development workflow is necessary to improve lead times and reduce costs.  Teams must continually improve their processes by eliminating non-value adding tasks and by investing in training, better tools, and automation.

In Kanban, a small number of process metrics is sufficient to evaluate the performance of core delivery processes, and to point at where improvement is needed. Since the focus of Kanban is the reduction of Lead Time by improving the flow of work through a system, the metrics used to measure flow performance are flow metrics, Specifically, Lead Time, Throughput and WIP.

The relationship between these metrics is described by Little’s Law, and the Continuous Flow Diagram (CFD) is a good way to visualize these relationships. The CFD Diagram is one of the primary artifacts of the Kanban Method, and is used to measure flow performance, identify bottlenecks in the process, and to help identify opportunities for improvement. The CFD shows the distribution of work in each of the workflow states and how that distribution is trending over time. Each band in the diagram shows the number of work items in each state of the workflow.

Reading a CFD can provide us with each of the fundamental measurements of flow, namely Lead Time, Throughput and WIP. One can see from the above example CFD chart that after day 7 the work arrival rate has increased while throughput has been unable to keep up. This has caused an increase in WIP, and a consequent increase in Lead Time. Anytime the arrival rate exceeds the departure rate (or throughput – the processing rate per item), WIP will accumulate and Lead Times will increase per Little’s Law. The CFD is a powerful tool for diagnosing problems in a system. This data provides the team with the data needed to decide what actions are needed to improve Lead Time. The relative priority of all proposed improvement initiatives should be directly proportional to their impact on reducing lead time.

Another useful tool in bringing focus to Lead Time improvement is the Lead Time Histogram. This is a chart showing the distribution of delivery lead times (for example for User Story lead time in days) by frequency.

This is useful (and actionable) data for a team that has a goals like:

• deliver majority (>50%) of user stories in 2 days or less, and,
• deliver 95% of all stories in under 10 days.

Summary

The Kanban Method can be an effective alternative to Scrum when applied in the right way:

• Visualize your workflow in a way that enables diagnosis of flow-related problems.
• Limit the amount of work pulled into each processing step to minimize queues and delays.
• Continuously measure and improve.

Like Scrum, the Kanban Method is intended to be a team sport, and improvement is best achieved through inspection and adaptation based on transparency and collaboration. Some Scrum teams may wish to relinquish their fixed time-boxes and try a continuous flow type development model. They should by all means give it a try.