The only way you can create excess inventory is by having excess manpower.
Or perhaps overspecialization?
Team Kanban is a method that helps teams facilitate the flow of value by visualizing work flow, establishing work-in-process limits, measuring throughput, and continuously improving their process.
Kanban systems are used, albeit for somewhat different purposes, at the Portfolio, Value Stream, Program, and Team Levels of SAFe. This article describes Team Kanban.
SAFe teams have a choice of Agile methods. Most use ScrumXP, a lightweight, effective, and ubiquitous method for managing work. Some teams, however, particularly System Teams, and maintenance teams, choose to apply Kanban as their primary method. In these contexts, the response mandate, the rapid-fire nature of the work, fast-changing priorities, and the lower value of planning what exactly will be done in the next Iteration all lead them to this choice. This article will describe a Kanban system well suited to Agile Teams. However, these teams are “on the train,” and certain rules of the train must be applied.
Generally, Kanban is described as a pull system; teams “pull” work when they have known capacity for it, rather than scope being “pushed” on them. This article describes Team Kanban, a method that helps teams facilitate the flow of value by visualizing work flow, establishing work-in-process limits, measuring throughput, and continuously improving their process.
A Kanban system is built up of work flow steps. Most steps have work-in-process (WIP) limits, whereby a work item can be pulled into a step only when the number of items at that step is lower than the WIP limit. A few steps, typically beginning and end steps, are not WIP limited. WIP limits are defined and adjusted by the team itself, allowing for the quick adaptation to variations in flow that is characteristic of complex systems development. In SAFe, Team Kanban is applied in concert with the cadence and synchronization requirements of the Agile Release Train (ART). This provides for alignment; dependency management; and fast, integration-based learning cycles, which provide the objective evidence needed to advance the larger Solution.
At its core, Kanban (meaning “visual signal”) is a method for visualizing and managing work. While there are many interpretations of how to apply Kanban in development, most would agree that the primary aspects of a development Kanban system include the following:
- The system contains a series of defined steps that work moves through.
- All work is visualized, and the progress of individual items is tracked.
- Teams agree on specific WIP limits for each step and change them when necessary to improve flow.
- Teams adopt specific policies covering how work is managed.
- Flow is measured. Work items are tracked from the time they enter the system to the time they leave, providing continuous indicators of the amount of work in process and the current lead time (how long, on average, it takes an item to get through the system).
- Prioritization is done by assigning a class of service, which, in turn, is based on cost of delay.
Visualizing Flow and Limiting WIP
To get started, teams typically build an approximation of their current process flow and define some initial WIP limits. Figure 1 shows an example of one team’s initial Kanban board, which captures their current work flow steps of analyze – review – build – integrate – test.
In Figure 1, the team has also decided to create two buffers (“Ready”) to better manage variability of flow. One is in front of the “Review” step, which might require external subject matter experts (Product Management or others), whose availability may be limited and uneven. The other buffer is in front of “Integrate and Test,” which, in their case, requires the use of shared test fixtures and resources. Since integration and testing is performed by the same people on the same infrastructure, the two steps are treated as a single step. Also, to justify the transaction cost, the team allows reasonably higher WIP limits for the “Review” and “Integrate and Test” steps.
Many teams will track their progress beyond these steps and into deployment and release, as they are responsible for that part of the Continuous Delivery Pipeline as well.
A team’s Kanban board evolution is iterative. After defining the initial process steps and WIP limits and executing for a while, the team’s bottlenecks should surface. If not, the team refines the steps or further reduces the WIP until it becomes obvious which step is “starving” or is too full, helping the team adjust toward more optimum flow. As the assumptions are validated, WIP limits are adjusted and streps may be merged, split, or redefined.
In order to understand and improve their flow and process, Kanban teams use objective measures, including average lead time, WIP, and throughput. One common way is to use a Cumulative Flow Diagram (CFD), as illustrated in Figure 2.
Each backlog item is date stamped, both when it enters the work flow (pulled from the team backlog to begin implementation) and when it is completed. The arrival curve shows the rate at which backlog items are pulled into work. The departure curve shows when they have been accepted. The x-axis shows the average lead time—how long it takes, on average, for an item to get through the system. The y-axis shows the WIP—the average number of items in the system at any point in time. Throughput—the number of stories completed per a period of time—represents another critical metric. Since Kanban teams in SAFe operate on an Iteration cadence, they measure throughput in Stories per iteration.
The Cumulative Flow Diagram provides the data for the team to be able to calculate their current iteration throughput. To do this, the team divides the average WIP by the average lead time, to arrive at the average number of stories processed per day. They then multiply by 14 (which is the iteration duration in days). This provides the iteration average throughput in number of stories per iteration, which helps with planning. (This will also be important in calculating “derived velocity,” as described later in this article.)
The Cumulative Flow Diagram also provides a critical visualization of significant variation in flow, which may be a result of systemic internal impediments the team is not aware of or external forces that impede the flow. The CFD is an excellent example of an objective measure that facilitates relentless improvement for Kanban teams.
Improving Flow with Classes of Service
In addition, teams need to be able to manage dependencies as well as ensure alignment with Milestones. Kanban uses the mechanism of classes of service to help teams optimize the execution of their backlog items. Classes of service provide a way of differentiating backlog items based on their cost of delay. Each class of service has a specific execution policy that the team agrees to follow. For example:
- Standard. Most backlog items should fall in the normal case—new development, which is not specifically date dependent. The cost of delay is linear for standard items, in that value cannot be achieved until delivery occurs, but there is no fixed date requirement.
- Fixed date. Fixed-date items represent milestones and dependencies with a predetermined date. The cost of delay is nonlinear. These items are pulled into development when necessary so as to be finished on time. Some may require additional analysis to refine the expected lead time; some need to be changed to “expedite” if the team falls behind.
- Expedite. An “expedite” backlog item has an unacceptable cost of delay and therefore requires immediate attention; it can be pulled even in violation of current WIP constraints. Typically there can be only one “expedite” item in the system at a time, and teams may set a policy to swarm on that item to make sure it moves through the system expeditiously.
If teams find that many items require expediting, then the system may be overloaded. Either demand exceeds capacity, or the input process could be undisciplined. In any case, the process needs to be adjusted.
As illustrated in Figure 3, classes of service are typically visualized as “swim lanes.”
In addition, the teams may reserve specific colors for different types of backlog items (see PI Planning), such as “new functionality,” “research spike,” “modeling,” etc., which adds additional understanding to the work being performed.
Close attention to the structure of flow provides Kanban teams with improvement opportunities that otherwise would pass unnoticed. For example, changes in the Cumulative Flow Diagram may suggest increasing average WIP (which will cause an increase in lead time). While this can just be a symptom of a deeper problem, the team now has a way of spotting it. Regular reflection and adaptation of the process is a necessary measure to realize the benefit of high visibility of flow.
The SAFe Kanban Team Is on the Train
SAFe Kanban teams operate in a broader context of building a solution that requires multiple Agile Teams and may even span multiple Agile Release Trains (ARTs). In order to accomplish this, the team needs to adhere to specific SAFe rules in addition to the regular Kanban guidelines. These rules are that the teams plan together, integrate and demo together, and learn together, as is described in more detail in the Agile Teams article. Planning together is one element that warrants further discussion, as described below.
Generally, Kanban teams don’t invest as much time in estimating or tasking as Scrum teams do. Rather, they take a look at the needed work, split the bigger items where necessary, and drive the resulting stories to completion, mostly without much concern for their size. However, SAFe teams have to be able to estimate the demand against the capacity for PI planning, and they also participate in economic estimation of larger backlog items. Also, in order to be able to forecast, there must be an understanding of the teams’ velocity in a manner consistent with that of the other teams on the train, and of the total ART velocity.
Establish a Common Starting Point for Estimation
Initially, a new Kanban team has no knowledge of its throughput, as that is a trailing measure based on history. To get started, SAFe Kanban teams must have a means to estimate work, often beginning with the first PI planning session. In a manner consistent with Scrum teams, estimation of initial capacity begins with normalized estimating (as described in Iteration Planning). Kanban teams then add their estimated stories into iterations, just as the Scrum teams do. Their starting capacity is their assumed velocity, at least for the first Program Increment (PI).
Calculating Derived Velocity
After this starting point, Kanban teams can use their Cumulative Flow Diagrams to calculate their actual throughput in stories per iteration (or they can simply count and average them!). Kanban teams then calculate their “derived velocity” by multiplying the throughput by an average story size (typically 3 – 5 points). In this way, both SAFe Scrum and Kanban teams can participate in the larger Economic Framework, which, in turn, provides the primary economic context for the Portfolio.
Estimating Larger Work Items
At the Portfolio and Large Solution Levels, it is often necessary to estimate larger work items (Epics and Capabilities) to determine the potential economic viability of these initiatives. In addition, development of ARTs and Value Stream Roadmaps requires both a knowledge of estimating (how big is the item) and ART velocity (how much capacity does the ART have to do it). In order to do this, Kanban teams break larger initiatives into stories for estimating, just as the Scrum teams do. This provides the finer-grained resolution needed to estimate larger items. Stories are then estimated in normalized story points. This provides the ability for the Enterprise to aggregate estimates from various teams—and types of teams—without excessive debate.
Learn More Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.  Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Pragmatic Programmers, 2012.
Last update: 20 June, 2017