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 workflow, establishing Work In Process (WIP) limits, measuring throughput, and continuously improving their process.
SAFe teams have a choice of Agile methods. Most use Scrum, a lightweight, and popular method for managing work. Teams that develop new code also apply Extreme Programming (XP) practices to bring focus to software engineering and code quality. Some teams, however—particularly System Teams, operations, and maintenance teams—choose to apply Kanban as their primary method. In these contexts, the rapid-fire nature of the work, the fast-changing priorities, and the lower value of planning activities for the next Iteration all lead them to this choice.
Kanban systems are used at the Portfolio, Large Solution, Program, and Team levels of SAFe, although for different reasons. This article will describe a Kanban system well suited to Agile Teams. However, these teams are on the train, and some additional rules must apply.
Generally, Kanban is described as a pull system. Teams pull work when they know they have the capacity for it, rather than having scope pushed on them. This article describes team Kanban, a method that helps facilitate the flow of value by visualizing workflow and WIP limits, measuring throughput, and continuously improving the process.
A Kanban system is made up of workflow steps. Most steps have WIP limits, which a work item can be pulled into only when the number of items at that step is lower than the WIP limit. A few steps (typically beginning and end steps) may not be limited. WIP limits are defined and adjusted by the team, allowing it to adapt quickly to the variations in the flow of complex system development. In SAFe, team Kanban is applied together with the cadence and synchronization requirements of the Agile Release Train (ART). This facilitates alignment, dependency management, and fast, integration-based learning cycles. These provide the objective evidence needed to advance the broader Solution.
Kanban, which means ‘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 include the following:
- The system contains a series states that define the workflow.
- The progress of items is track by visualizing all work.
- Teams agree on specific WIP limits for each state and change them when necessary to improve flow.
- Policies are adopted to specify the management of work.
- 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. In other words, how long, on average, it takes an item to get through the system.
- Classes of service are used to prioritize work based on the Cost of Delay (CoD)
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 workflow steps: analyze, review, build, and integrate and test.
In Figure 1, the team has also decided to create two buffers (see ‘Ready,’ above) to better manage flow variability. 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’ state, which, in their case, requires the use of shared test fixtures and resources. Since integration and testing are 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.
A team’s Kanban board evolves iteratively. After defining the initial process and WIP limits and executing for a while, the team’s bottlenecks should surface. If not, the team refines the process or further reduces some WIP limits until it becomes evident that a workflow state is ‘starving’ or is too full. This helps the team continually adjust the process to optimize their flow. For example, changing WIP limits and merging, splitting, or redefining workflow states.
Kanban teams use objective measures, including average lead time, WIP, and throughput to understand and improve their flow and process. The Cumulative Flow Diagram (CFD), illustrated in Figure 2, is an area graph that depicts the quantity of work in a given state, showing arrivals, time in a state, quantity in a state, and departure.
Each work item is date stamped, both when it enters the Kanban (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 a number of stories per iteration.
The CFD provides the data for the team to be able to calculate their current iteration throughput. To arrive at the average number of stories processed per day, the team divides the average WIP by the average lead time. Then they multiply it by 14, which is the number of days in a two-week iteration. This provides the average throughput of stories per iteration, which helps with planning. (This will also be important in calculating derived velocity, as described later in this article.)
The CFD also provides an important visualization of significant flow variations, 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 concept of classes of service to help teams optimize the execution of their backlog items. Classes of service help differentiate backlog items based on their CoD. Each class of service has a specific execution policy that the team agrees to follow. For example:
- Standard – Represents the baseline class of service, applicable to work items that are neither expedited or fixed date. Most backlog items should fall into this category. The CoD is linear for standard items, meaning that value cannot be achieved until delivery occurs, but there’s no fixed-date requirement.
- Fixed date – Describes work items that must be delivered on or before a specific date. Typically, the COD of these items is nonlinear and is highly sensitive to small changes in the delivery date; these must be actively managed to mitigate the schedule risk. Therefore, these items are pulled into development when necessary to be finished on time. Some items may require additional analysis to refine the expected lead time. Some need to be reclassified as expedite if the team falls behind.
- Expedite – An expedite backlog item has an unacceptable CoD and therefore requires immediate attention. It can be pulled into development, even in violation of current WIP limits. 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 rapidly.
If teams find that many items require expediting, then the system may be overloaded. Either demand exceeds capacity, or the input process may need more discipline. Whatever the case, the process needs to be adjusted.
As illustrated in Figure 3, classes of service are typically visualized as ‘swim lanes.’
Also, the teams may use specific colors for different types of backlog items, such as new functionality, research Spike, and modeling. This adds clarity to the work being performed, which is described in the Program Increment (PI) Planning article.
Close attention to the process of flow enables Kanban teams with improvement opportunities that otherwise would pass unnoticed. For example, changes in the CFD may suggest increasing average WIP (which will cause an increase in lead time). While this may just be a symptom of a deeper problem, the team now has a way of spotting it. Regular reflection and adaptation of the process are necessary to realize the benefit of high visibility of flow.
The SAFe Kanban Team Is on the Train
Kanban teams operate in a broader context, building a solution that requires multiple Agile teams and or the collaboration within a Solution Train. To accomplish this, the team needs to adhere to specific SAFe rules in addition to the regular Kanban guidelines. The rules are that the teams plan together, integrate and demo together, and learn together, as is described in the Agile Teams article. Planning together is one element that warrants further discussion, as described in the next sections.
Kanban teams don’t invest as much time in estimating or tasking as Scrum teams do. Instead, they take a look at the work needed, split the bigger items where necessary, and push the resulting stories to completion, mostly without much concern for their size. However, SAFe teams must be able to estimate the demand against their capacity for PI planning, and they also help estimate larger backlog items. Moreover, forecasting requires an understanding of the team’s velocity in a manner that’s consistent with the other teams on the train and the total ART velocity.
Establish a Common Starting Point for Estimation
Initially, a new Kanban team does not know its throughput, as that is a trailing measure based on history. To get started, they need a way 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 PI.
Calculating Derived Velocity
After this starting point, Kanban teams can use their CFD 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 three to five points). In this way, both SAFe ScrumXP 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 to determine their potential economic viability (Epics and Capabilities). Also, developing a program Roadmap requires:
- A knowledge of estimating (how big is the item)
- ART velocity (how much capacity does the ART have to do it)
Larger items tend to be harder to estimate, which increases risk. Therefore, they are split into user stories, just as ScrumXP teams do, to improve understanding, increase the accuracy of estimation and make it easier for the PO to prioritize the work. Stories are then estimated in normalized story points. This provides the ability for the Enterprise to combining estimates from various 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: 9 November 2017