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 framework for managing work. Teams that develop new code also apply Extreme Programming (XP) practices to bring focus to Agile software engineering (see the Technical Agility section of Team and Technical Agility) and code quality (see the Code Quality section of Built-In Quality). Some teams, however—particularly System Teams, operations, maintenance and support 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, and Essential 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 work pushed on them. This article describes team Kanban, a method that helps facilitate the flow of value by visualizing workflow and applying WIP limits, measuring throughput, and continuously improving the process.
A Kanban system is made up of workflow states and most of these will have WIP limits. A work item can be pulled into a state only when the number of items currently in that state is lower than the WIP limit. A few states (typically beginning and end states) 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 in turn 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 of states that define the workflow.
- The progress of items is tracked 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 states: Analyze, Review, Build, and Integrate and test.
In Figure 1, the team has also decided to create two buffers (labelled ‘Ready,’ above) to better manage flow variability. One is in front of the ‘Review’ state, 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 this 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 states are treated as a single state. Also, to justify the transaction cost, the team allows reasonably higher WIP limits for the Review and Integrate and test states.
A team’s Kanban board evolves iteratively. After defining the initial process and WIP limits and executing for a while, 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 overloaded. Other changes might include merging, splitting, or redefining workflow states. This helps the team continually adjust the process to optimize flow.
Kanban teams use objective measures, including average lead time, WIP, and throughput to understand their process and improve flow. 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 slope of 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.
The CFD 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 flow. The CFD is an excellent example of an objective measure that facilitates relentless improvement for Kanban teams.
Throughput—the number of Stories completed per period of time—represents another critical metric. Since Kanban teams in SAFe operate on an Iteration cadence, they measure throughput as the number of stories delivered per iteration.
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 highlight an 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.
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 Cost of Delay (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 nor 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 specific date by which the work must be completed.
- 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 may need to be reclassified as expedite if the team falls behind.
- Expedite – An expedite work item has an unacceptable CoD and therefore requires immediate attention. It can be pulled into development, even if it is 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 Spikes, and maintenance. This adds clarity to the work being performed, which is further described in the Program Increment (PI) Planning article.
The SAFe Kanban Team Is on the Train
SAFe Kanban teams operate in a broader context, building a solution that requires multiple Agile teams and possibly the collaboration of multiple ARTs 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, 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 as ScrumXP teams do. Instead, they take a look at the work needed, split the bigger items where necessary, and pull the resulting stories through the Kanban system to completion, mostly without much concern for their size. However, during PI Planning, SAFe teams must be able to estimate the demand for work against their capacity, and also help contribute to estimates for larger cross-team backlog items (Features). 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 overall 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 historic performance. To get started, they need a way to estimate work, often beginning with the first PI planning event. In a manner consistent with ScrumXP teams, estimation of initial capacity begins with normalizing story point estimating (as described in Iteration Planning). Kanban teams then add their estimated stories into iterations, just as the ScrumXP 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 calculate their actual throughput in stories per iteration by simply counting the number of stories delivered in previous iterations and averaging 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 stories, just as ScrumXP teams do, to improve understanding, increase the accuracy of estimation and make it easier for the Product Owner to prioritize the work. Stories are then estimated in normalized story points. This provides the ability for the Enterprise to combine 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: 31 December 2019