People often ask, “Why should I use kanban?” or “Why switch from scrum to kanban?” These questions show that we need to communicate better what kanban is and why many people are starting to use it.
Kanban is a lean method that takes our current process and enhances it to provide better predictability and risk management. It can take an agile (or waterfall) method that has stalled and bring it back to life, creating a custom solution based on the unique needs of the organization. It creates a culture of continuous improvement so that we get better at scheduling and delivering our work while our workers are happier in their jobs.
Kanban is lean. A lean method is one that tries to optimize the flow of work through a system. Kanban tells us to first visualize the invisible knowledge work. We must visualize the current process so that we can see the flow. This visual model should enable us to identify bottlenecks and reduce the impact of variability. Kanban is designed to reveal issues and create the opportunity to address problems so that we can achieve smooth, predictable delivery of finished work.
Let’s consider a typical development scenario: A batch of work items, such as features, is planned for completion at the end of a 2-week iteration time box. Before the team commits to this schedule, they consider what they know about the requirements, the dependencies, and their own availability. They also consider the typical speed of their development pipeline (velocity).
Then the work begins and reality sets in. There is an essential vendor who is unavailable. A manager required for approval steps is also missing. The development process itself is far from efficient, with stops and starts throughout. Interruptions occur as new circumstances arise for the business, requiring meetings and unscheduled work as priorities shift. Tensions flare, schedules slip and commitments are missed.
What could help this situation? Ideally we would start with a realistic sense of demand we are receiving, an understanding of what our stakeholders need. We would also want to understand our capability to deliver. It is likely that our capability is not matched against the demand we are receiving, and this is a source of some dissatisfaction. To put it another way, we struggle to fulfill the work requests that come in. We might like to consider how to shape our demands to better match our capability to supply them, and at the same time consider how we might improve our capability over time to supply more of the demands we are seeing.
Shaping demand means that we put policies in place that help us focus and manage the work so that a reasonable mix of urgent and important work is undertaken and delivered, and that our risks are managed by balancing our workload across the demand from various stakeholders. Ideally, we would have the agility to better deal with disruptions. Our work would flow smoothly, and we would more consistently meet our commitments despite hiccups along the way. This is what kanban aims to deliver.
Kanban does not replace the current development process; it is overlaid on top of it. Think of kanban as a big magnifying glass that will reveal the kinks in the current process. It provides ways to either smooth out the kinks or stretch to accommodate them. Most importantly, kanban delivers a customized solution because every organization is different. Every team within an organization is different. The goal of kanban is to understand and evolve the way each team and organization deals with their work.
#!
Where did kanban come from?
The original concept of kanban came from the Toyota Production System. A kanban was a physical card that signaled when inventory was getting low and an action such as restocking needed to happen. The new material wasn’t prepared until the worker was ready to “pull it” into the assembly line.
In knowledge work such as IT, we don’t see any inventory. We can’t walk around the office pointing to it. Even if we could, our inventory would be a variety of size and shapes. We don’t have the steady sameness found in manufacturing. Knowledge work is creative and varies depending on the requirements of the organization. It has different challenges than a manufacturing environment.
The reason we still use the term kanban is because we use a visual model that both represents the work and signals when we need to take action. For example, we need to know when to pull in new work, but only as our capacity allows it. By watching the movement of the kanban cards, we can see the flow of work and when action is required to keep the work flowing.
People who turn to kanban are often people who are less than satisfied with their current process. Here are situations that are common among organizations that seek out kanban:
• Their work does not fit well with timeboxed delivery (e.g. media companies)
• Their work is high risk (e.g. defense, oil production)
• Their work requires specialists (e.g. game development)
• Their work is not new development work (e.g. DevOps)
• Their work comes in unpredictable bursts, with frequent re-prioritization (e.g. startups)
This is not to say that kanban cannot be used with timeboxed iterations or on new development work. Most commonly, organizations turn to kanban when they have more work than they can handle along with frequent interruptions. Organizations all over the world are using kanban to establish an order and method to getting the work done.
#!
How to implement the Kanban Method
Visualize: The Kanban Method takes an existing knowledge work process and brings it into sharper focus. It allows us to see it as a system. The approach to change is to start with the existing process rather than redefining it. Visualization reveals details about the current way of working, which provides understanding that allows the organization to see and communicate needed changes.
Map the workflow: For each type of work, we identify the sequence of dominant activities used to discover new knowledge until a piece of work is ready for delivery to a customer. This sequence represents the workflow for that given type of work. Different types of work may have a different sequence of activities.
Types of work are often identified by the source of the request, such as a customer department like marketing, customer care or sales; by the destination system or platform, such as with mobile applications, iPhone, Android, Windows Phone and Symbian; or by differences in the workflow or in orders of magnitude in size and complexity. In Extreme Programming, for example, Epic and Story are two different orders of magnitude in size.
The Kanban Method asks us to focus on the work and its flow, not the people and the tasks they perform. We also want to focus on the state changes in the work based on the activities performed to discover new knowledge. It’s important to focus on the changes in the work and not hand offs between individuals.
Often, several activities happen together and overlap in time. We will focus on the sequence of dominant activities through the life cycle of the work under development. This will prove sufficient to enable us to visualize work and workflow, and to manage that flow and enable significant improvements.
The card wall is designed to visualize this workflow. If workflows for several types of work are significantly different, then several card walls may be necessary.
For example, an existing software development process for small maintenance functionality changes to IT systems may have a type of work referred to as a change request. Change requests will have a workflow of states: Queued, In Analysis, Analysis Complete, Development Ready, In Development, Development Complete, Build Ready, In Test, Testing Complete (aka Release Ready), In Staging, In Production.
Create the card wall: Draw columns on the board that represent the activities performed, in the order first performed. Model in-progress and completed work by splitting the columns. Add the initial input queue and any downstream delivery steps that you wish to visualize. Finally, add any buffers or queues (Ready or Done states) between activities.
The cards themselves could be sticky notes or index cards. They may represent features, stories or tasks, or any other work item type. We might use different lanes on the card wall for different work types, or different-colored cards in order to better visualize the mixture of work being undertaken.
#!
Limit work-in-progress (WIP): Limiting the amount of work that is in progress will contribute to faster completion, better quality, and greater focus on only the highest-priority work. A WIP limit is a policy, an agreed-upon decision about how the work will be processed. Policies can similarly specify how the organization handles types of work items.
A WIP limit defines a stage in the kanban system. A stage in the kanban system may span across several workflow states. A limit on WIP constrains how many work items can be in each stage of the workflow at a given time. When a work item is pulled to the next stage of the process, a slot opens and a new work item can be pulled into that stage. A number of workflow states may be grouped together under a single WIP limit.
A significant consequence of a WIP limit is that blocked work “holds up the line.” A blocked work item still counts against the limit, so a situation may arise as more items become blocked, in which no new work can progress until the block is resolved. This drives collaboration, as the team (and any affected external stakeholders) are highly motivated to clear the blockage.
Positive tension: Respecting WIP limits will cause team members to report they are stuck (blocked and without an alternative) or idle (starving for something to do). It is variability, the unevenness caused by the nature of the work and the effects of the workplace environment that causes these problems. The WIP limit protects the team from the effects of too much variability, and exposes a positive tension as a result.
If a conflict with the limit arises, the team has a choice to break the WIP limit and ignore the issues, or face up to the issues and address them. The action taken to address an issue in flow may depend on how the team understands the problem at hand. They may choose to make no change to the kanban system design and simply swarm on the stalled work to get it flowing again, or they may decide that a change to the system design is appropriate.
Excessive time should not be wasted trying to determine the perfect initial WIP limits within the kanban system; simply pick a number that is close enough, and make progress. Empirical adjustment will happen naturally.
As with all aspects of the kanban system design, WIP limits are more likely to be respected when agreed upon through consensus with up- and downstream stakeholders and senior function managers, as well as the knowledge worker team.
It can be useful to make the completion criteria explicit. What does it mean to be complete? This policy can be printed and pinned to the card wall under each column. Sometimes such policies are referred to as “Exit Criteria” or “Definition of Done.”
#!
Manage flow: Flow is the visible progression of the work items through the system. Flow should proceed at a consistent pace. If a work item seems to languish, a conversation should happen to resolve how the team can get it “flowing” again. If all work items within a particular step of the workflow seem to stall, this may suggest a bottleneck in the system. A conversation and action toward resolution can happen between the team and managers based on visible evidence of an issue.
Kanban systems help to create the conditions for steady workflow by controlling unevenness and highlighting problems that occur periodically. When a kanban system is working properly, the flow of work will have some predictability to it. The system parameters that can be directly influenced are the team members, the typical work item size, the workflow, and the WIP limit. Flow of an individual item can be affected by issues such as ambiguity in information, dependencies on other items, or required approvals.
Explicit policies: Having agreed-upon policies regarding workflow, WIP limits, approvals, prioritization, classes of service, risk management, and other management topics, provides clarity and empowerment to the workforce. Making such policies explicit enables team members to make good decisions on their own regarding what to select next and how to treat WIP. The result is better governance, greater compliance, better economic results, and less contentious discussions when exceptions do occur.
If a suggestion to violate a policy is made, a discussion can happen to review the current policy and ask whether the group feels the policy should be changed, or if it is worthwhile to allow a one-time exception. Exceptions should happen in response to special-cause variation, and permanent changes in response to common-cause variation. Focusing on policies depersonalizes issues and exceptional circumstances. This leads to a healthier, more collaborative workplace. It is often best to post explicit process policies in a public team area such as next to the card wall.
Cadence policies: Kanban decouples input queue replenishment cadence from development lead time and delivery. This is unlike agile methods that couple prioritization activity to a timeboxed period of development activity, such as two-week increments.
Frequent queue replenishment meetings provide visibility for upstream stakeholders and help build trust. Other cadence policies may also be set to determine frequency of product demos, retrospectives, backlog grooming, scoping exercises, or whatever is appropriate and interesting to the organization.
Work-item type policies: Different work-item types can have different workflows. A “defect” and a “new feature” are two examples of work-item types. A defect may enter the development process at a different point and may be processed in a different way than a new feature. Relative priorities can be set for each work item type.
It is useful to set an allocation by work-item type to provide clarity about which kinds of work the team is spending time developing. It sets an agreement with the development team and management about how their resources are best spent.
The card wall can be divided into rows to clearly visualize work of different types.
Class-of-service policies: Class of service allows the development team and management to assign priority to work. Work items can be assigned to a class of service according to their business impact. Examples of class of service would be “fixed date,” “expedite,” or “standard.” It is typical to assign class of service based on impact and time-criticality. Items that incur high costs or lose value quickly will receive faster treatment via a higher class of service.
If classes of service are used properly and combined with a regular delivery cadence, very few complaints are likely to be received, even if a significant portion of items miss their target lead time. The most time-critical work items will be prioritized ahead and should be delivered on time.
Classes of service enable a team to self-organize around the flow of work, and can free up management time to focus on the process and its performance (or capability).
Classes of service should be visually displayed by using, for example, different colored cards to represent the class of service.
It is also useful to allocate capacity within the kanban system to classes of service. For example, maybe 20% of the team’s efforts could be set aside for “standard class” work items.
#!
Improve collaboratively: W. Edwards Deming suggested studying system and their capabilities. The Kanban Method embraces this idea. Gathering data on system performance (flow time, WIP, delivery rate) will provide scientific insight into opportunities for improvements. It is common (and encouraged) for teams using Kanban to frequently modify their processes and policies during their daily check-in meeting and at formal retrospectives and operations review meetings.
Useful models to learn and use may include work from Taiichi Ohno (Toyota Production System) on muda, muri and mura; Eliyahu M. Goldratt on “Theory of Constraints,” specifically The Five Focusing Steps; John Seddon and Peter Senge on Systems Thinking; and W. Edwards Deming’s System of Profound Knowledge, and specifically his work on variability.
Feedback mechanisms
Daily standup meetings should be used to discuss issues, impediments and flow. Such standup meetings do not typically follow the established pattern of other agile development methods. A kanban standup meeting focuses on the progress of the work on the kanban board.
Operation reviews and metrics: As part of continuous improvement, the teams using kanban should have regularly scheduled operations review meetings to analyze gathered data. Data in kanban is often in a Cumulative Flow Diagram (CFD). The CFD shows how much work is entering the system and how long it is taking to complete it. In kanban, lead time is measured to see how long it takes work to move through the system. The many kanban tools on the market today graph these metrics for easy reporting at an Operations Review meeting.
Introducing kanban: It is recommended that you introduce kanban into an organization using an evolutionary approach focused on changing management policies rather than through a planned transition initiative and prescribed training program. While training may be necessary to introduce the ideas and catalyze getting started, the goal should never be to adopt kanban. The goal should be to improve customer satisfaction and better outcomes for knowledge workers and business owners.
It is useful to start with a single team or workflow that can demonstrate the benefits of kanban for the rest of the organization. The most important thing is to gain consensus around the introduction of kanban and the pursuit of its core principles before using it. Initially, change as little of the existing culture and process as possible.
#!
The wide world of kanban
Kanban has gone tribal. People who are interested in kanban are connecting with a growing global community. There is the kanbandev discussion group, which has over 2,000 practitioners in discussions on how to meet the challenges in the workplace with kanban. There is the spinoff kanbanops group specifically for IT operations and IT services concerns.
The wider kanban community is gathered at the Limited WIP Society. There are many local Limited WIP Society chapters that meet regularly throughout the world. Some of those meetings have more than 100 attendees. The Lean Software and Systems Conference each May in the United States is the formal gathering where the community comes together to share the latest findings and case studies in the practice of the Kanban Method. Many vendors have started to offer software tools for designing and tracking work in kanban systems. These tools help make kanban implementation easier.
Training in the Kanban Method is now offered all over the world. Along with this, some people are jumping on the bandwagon and offering kanban training that is poor quality. That training is given by people who have never been involved in the kanban community and who may be offering substandard guidance. There is a need for quality standards so that people who pay for kanban training know they will walk away with useful information they can apply in their organization.
David J. Anderson is founder of a consulting, training and publishing business covering business and managerial approaches to knowledge workers. He has led software teams delivering superior productivity and quality using innovative agile methods at large companies such as Sprint and Motorola. He is also author of two books: “Agile Management for Software Engineering,” and “Kanban – Successful Evolutionary Change for Your Technology Business.” He is a founder of the Lean Kanban University, a business dedicated to assuring quality of training in lean and kanban throughout the world. He can be reached at dja@djaa.com or on Twitter at @agilemanager.
