Although Scrum continues to be the predominant Agile methodology in the industry, Kanban can also be a great fit for teams or organizations. More organizations are not using Kanban because of some common misconceptions about it. This article explores those misconceptions so that you can better understand what role Kanban might play in your organization. From use as the primary methodology to targeted use for specific teams, most organizations would be well served by some use of Kanban.
#1. Kanban Is Only a Board
Many people think Kanban means using a simple board with To Do, Doing, and Done columns. However, Kanban is a sophisticated method with a thorough set of core principles and practices. Kanban includes Kanban boards, but it is much more than that.
The Kanban Method is a way to drive evolutionary change to teams, processes, and organizations. Kanban advocates starting with how the work is done today and then making incremental improvements—improvements based on objective data provided by Kanban’s metrics.
The Kanban Method consists of the following practices:
- Visualize. Understand the stakeholders and the work, and then make the workflow visible by using a Kanban board.
- Limit work in progress. Set explicit work in progress (WIP) limits to implement what’s known as a “pull” system—a work item is moved to the next stage only when there is capacity in that next stage for the work. WIP limits help unburden individuals and optimize flow by having the right amount of work in the system.
- Manage flow. Observe, manage, and continuously improve the flow of work through the system. The goal is a predictable system with smooth, fast flow.
- Make policies explicit. Ensure that everyone understands and agrees to the policies for the work that moves through the system. When are various activities and work items done? What work items are most important? How will blocked items be handled? These are just some of the policies that teams must discuss for effective Kanban adoption.
- Improve collaboratively, evolve experimentally. Continuously improve the system. Everyone can and should engage in seeking enhancements and evolving the system by using data.
Kanban boards are part of the Visualize practice. For a single person managing his or her work alone, a simple Kanban board similar to the one shown in Figure 1 is often all that is necessary.
Figure 1: A personal Kanban board.
When a team of people is working—either autonomously or as part of an even larger workgroup—visualizing the work will require a more nuanced board. For example, a team working on projects and infrastructure might have a board similar to that shown in Figure 2.
Figure 2: A team Kanban board.
A Scrum team using Kanban to visualize and manage its workflow might use a board similar to that in Figure 3.
Figure 3: A Scrum-oriented Kanban board.
Construx works with teams and organizations implementing Kanban around the world, and one of the biggest mistakes we see is an organization making use of another organization’s board as is. Teams need to think about what they in particular deliver, to whom they deliver it, and how they do that work (not how others do work). This analysis will give them the information necessary to build a Kanban board that best makes their work visible to themselves and others.
Work visualization is a very powerful practice, but a Kanban board is just one step in the creation of a rich, deep Kanban system that enables teams and organizations to improve continuously.
#2. Kanban Is Good Only for Support
Kanban is well suited to product-support work. Its flow-based approach tolerates rapidly changing priorities much better than a timeboxed approach like Scrum. But Kanban is not limited to support work—it can be used effectively for product development, infrastructure, or any other kind of work.
Kanban’s greatest strength is that it models anything and is very flexible. Unlike Scrum, Kanban is not at all prescriptive. There is no base recipe to start from, so the adopting organization makes every decision regarding how it implements Kanban.
To adopt Kanban, teams need to:
- Understand and model the current workflow
- Define exit criteria for each workflow stage
- Set WIP limits for each workflow stage
- Determine whether work has different levels of importance and, if so, address those levels with classes of service
- Determine initial feedback loops and metrics
Understanding these different aspects, modeling them in a Kanban board, and putting in place a system of continuous improvement allows Kanban to be used in many ways and places within an organization. Kanban can be used effectively at the team, program, and portfolio levels.
For more information on adopting Kanban, contact us for these resources:
- Kanban Implementation Guidance Paper
- Kanban Board Samples
#3. Kanban Is Good Only for Small Teams
Kanban’s great flexibility means that it can be used by a single person, by a single team doing any kind of work, and by large product development groups. When implementing Kanban for larger efforts, teams often use:
- Kanban at the portfolio and program level to visualize and manage the top-level workflow in the product, product, or organization
- A multitier Kanban board to visual the work with two or more levels of decomposition
- A multilevel Kanban system (also called a cascading Kanban system) in which multiple Kanban boards show different levels of abstraction to different audiences, based on the information they need
- Software tools in addition to physical boards, especially for multisite work
Figure 4 shows an example of a multitier board with two tiers: epics and stories. The paragraph following the figure describes the board, its flow, and how the team has defined the terms epics and stories for their unique situation.
Figure 4: A multitier Kanban board with two tiers.
In this example, epics populate the early and late stages in the board. The epics represent meaningful pieces of business value that are deliverable to the users. Once one or more teams pull the epic into development, they decompose the epic into stories. These stories represent smaller, meaningful pieces of work that cannot be released independently to the users. Once all user stories for an epic are in the “Closed” state, the epic is then end-to-end tested for the overall workflow to ensure that it works in a preproduction environment and that all nonfunctional requirements have been met. It is then released to the users.
In addition to multitier boards, it is common for larger product development efforts to use multilevel (cascading) Kanban systems to visualize the efforts across all of the teams. In such a multilevel Kanban system, one program-level Kanban board will show customer-focused deliverables (features, epics, capabilities, etc.). This top-level board (often, but not always, a multitier board) shows work across the entire project, program, or release. An example is shown in Figure 5.
Figure 5: A program-level Kanban board.
Each team then has its team-level board, which captures greater detail by showing the internal decomposition of the work (epics, stories, etc.). These boards enable the teams to complete their day-to-day work. Figure 6 shows the details of a board that a team might use.
Figure 6: A team-level cascaded Kanban board.
Beyond program boards, organizations can use a portfolio-level Kanban board to understand, model, prioritize, and guide the work across the entire organization.
As these examples show, Kanban’s use is not limited by team size.
#4. Kanban Can’t Support Long-Range Planning
Because many organizations use Kanban for work that doesn’t need long-range planning (such as first-line production support), many people mistakenly believe that Kanban can’t support project-level forecasting or long-range planning.
One of the goals for a Kanban system is to achieve smooth, even flow. A system in that state will have predictable cycle time.
Consistent cycle time allows teams to establish and meet service-level agreements (SLAs) with their stakeholders, which significantly helps with long-range planning.
One of the keys to achieving consistent cycle time is having work items that are about the same size. Size normalization is done in many ways, such as setting policies that keep the work within a boundary size range or segregating large work from small work by having each type run through different swim lanes.
When work item size and cycle time are consistent, it becomes relatively easy to forecast how long it will take to complete a known set of work.
Like any Agile approach, organizations must use care when deciding what to do when unforeseen or unplanned work is added to the queue.
#5. Kanban or Scrum Is an “Either-Or ” Decision
Scrum and Kanban are not mutually exclusive—many organizations find that a mix of Scrum and Kanban is the best fit for their needs. Some examples of mixed adoptions include:
- A large product development organization has 15 Scrum teams building the next release of a system. The infrastructure and test automation teams use Kanban because its flow-based approach allows those teams to be more responsive within the two-week Sprint boundary.
- Teams throughout the organization are empowered to choose either Kanban or Scrum based on their preferences. All teams are required to provide a standard set of metrics reported on a two-week cadence.
- Scrum teams Kanban their workflow to ensure that a sufficient number of stories are ready for the Sprint and to model the Sprint Backlog throughout the Sprint.
- Fifty teams use Scrum throughout the entire organization. Kanban is used at the program level to visualize and manage the work for the three product development efforts. It is used at the portfolio level to ensure alignment with the organization’s strategic goals.
Kanban or Scrum is not an either-or decision. Instead, the question to ask is this:
“Where in the organization will Scrum work best, and where will Kanban work best?”