Kanban, you build a map of your work. The landscape depicted is your value stream. A value stream visually represents the flow of your work from its beginning through to its completion.

― Jim Benson, Personal Kanban: Mapping Work Navigating Life

Applying Kanban in SAFe


Note: This article is part of Extended SAFe Guidance, and represents official SAFe content that cannot be accessed directly from the Big Pictures


Kanban is a Lean workflow management method that Agile teams use to define, manage, and continuously improve the products and services they build for customers.  This method helps teams visualize and understand their workflow, optimize efficiency, and improve relentlessly.

Kanban is a flow-based system. “As most workflows exist to optimize value, the strategy of Kanban is to optimize value by optimizing flow. Optimization does not necessarily imply maximization. Rather, value optimization means striving to find the right balance of effectiveness, efficiency, and predictability in how work gets done [1].

The unprecedented level of visibility that Kanban provides is causing it to spread to different parts of the organization. Today, many organizations adopt Kanban to help embrace Lean-Agile principles across all aspects of business, from marketing to finance, human resources to legal, security to compliance, operations to Agile Teams, and more.

Details

In SAFe, Kanban systems manage the backlog and flow of work at every level of the framework. Each reflects a team’s unique process for delivering value and its current workflow and capacity.

Kanban System

A Kanban system is generally characterized by a ‘Kanban board’ that includes or references the elements shown in Figure 1.

Figure 1. Elements of an example Kanban system
Figure 1. Elements of an example Kanban system
  • Work in Process (WIP) limits set the maximum number of items that can exist in an individual workflow state.
  • Columns represent a series of steps (states) representing an activity that collectively defines the team’s workflow. (The steps above are just illustrative).
  • Cards represent the individual work items, such as stories, features, capabilities, and Epics, including enablers.
  • Swim lanes group and highlight related work items to further define the team’s workflow. Typical use of swim lanes includes separating work for different classes of service and individual responsibilities, cross-team dependencies, and more.
  • Policies specify how work is managed, such as exit or entry criteria for moving a work item from one state to another or defining the rules for service classes.

Establishing a Kanban System

Implementing an effective Kanban system adapted to meet the needs of a specific Agile team is based on the type of work performed (e.g., software development, hardware design, marketing), the team members’ skills, and the team’s role in the enterprise.

Establishing a Kanban system is best done by involving the entire team with the guidance and facilitation of an experienced coach. The following tenets will help teams establish and adopt Kanban [1]:

  1. Start with what you do now
  2. Agree to pursue incremental, evolutionary change
  3. Respect the current process, roles, responsibilities, and titles
  4. Encourage acts of leadership at all levels in your organization

The first step is critical for establishing the Kanban system and deserves some additional clarification. The Kanban Method does not require changing the existing workflow. This approach makes implementation easier since the team’s existing processes need not be changed immediately. Kanban advocates gradual, evolutionary change based on empiricism. The team incrementally makes process improvements. With these tenets in mind, the initial design of the Kanban typically involves the six activities defined below.

1. Map the Team’s workflow

A facilitator guides the team to build an approximation of their current workflow to get started. It’s important to note where work is handed off to other teams, as they may be candidates for creating buffer states to smooth the workflow. Figure 2 depicts a typical flow for a software team. Technical and business teams may follow a similar process. However, their process steps will need to be adapted based on the type of work performed.

Figure 2. An example of a software team’s current workflow
Figure 2. An example of a software team’s current workflow

2. Arrange the Workflow Steps

The current workflow informs the steps that the team wants to track in the team Kanban. Once the team agrees on the existing workflow, they can arrange these steps on a Kanban board, but they may not be identical to the team’s current flow. For example, some steps may be merged or split, and buffers or review states can be added. After reviewing the initial Kanban board, the team may decide to simplify it or add more steps. A Kanban with too many steps can make it overly complex, while too few can hide bottlenecks and non-value-added steps.

3. Identify Buffer states

Introduce buffer states to help manage variability in the team’s workflow. Buffers show bottlenecks and delays in the system. Since each extra item of WIP carries a penalty in terms of lead time, start with a small number and adjust it up or down based on observation. Reducing the variability in the size of the work items may allow you to reduce the buffer size.

4. Create Policies

A Kanban board makes the team’s processes and policies explicit. For example, each state’s entry or exit policies clarify what the team needs to do before a story can be pulled into the next state.

Below are some examples of explicit policies:

  • The Definition of Done (DoD) for a work item
  • Who can add, change, and prioritize the backlog?
  • How to handle emergency requests
  • What to do when team members become blocked from doing their work
  • Who can move an item to the next state?

This list is not exhaustive. However, it provides example policies to help teams form their own. Have regular meetings with the team after specific milestones and revisit them so they can evolve.  By viewing the Kanban board, the team and their stakeholders can have a shared understanding of their workflow, policies, and the status of its WIP.

5. Assign Initial WIP limits

At this point, the basic structure of the board is ready, and it is time to define the initial WIP limits. These limits are based on the team’s experience with their current process, and this is often the first attempt to limit the WIP at each step to facilitate a faster flow. Some states (like ‘Funnel’ and ‘Done’) do not need WIP limits.

Figure 3 shows an example of a team’s workflow expressed as a Kanban board after mapping their workflow, arranging the steps, refining their workflow with buffers, and establishing WIP limits.

Figure 3. An example of one team’s Kanban board
Figure 3. An example of one team’s Kanban board

6. Identify Classes of Service

Kanban classes of service have two primary purposes: categorizing work items according to their priority and describing individual policies for a specific work item type. The team agrees to establish and follow a particular execution policy for each class to optimize flow and value. Often teams start with a simple group of service classes, as shown in Figure 4:

Figure 4. Classes of service on the Kanban board
Figure 4. Classes of service on the Kanban board
  • Standard. Represents the baseline class of service, applicable to work items that are neither expedited nor have a fixed date and should not violate WIP limits.
  • Expedite. This class is for unexpected but urgent work with a high cost of delay and therefore requires immediate attention. As a result, items in this swimlane can be pulled into development, even if it violates current WIP limits. Therefore, teams should have policies limiting the use of this class of service (e.g., only one expedite item can be in the system at a time). Moreover, teams may set a policy to ‘swarm’ on expedited items to make sure it moves through the system rapidly.
  • Fixed date. Describes work items that need to be delivered on or before a specific date. These items must be specifically identified and actively managed to mitigate schedule risk. Among other uses, this service class can ensure flow-based Kanban teams meet their dependency commitments with other teams.

A Kanban board should evolve iteratively and continuously adapt to fit the team’s needs. After defining the initial process and WIP limits and executing for a while, bottlenecks should become visible. If not, the team refines the process or further reduces some WIP limits until it becomes evident that a workflow state is overloaded or starving. Other changes to optimize flow might include merging or splitting steps, adding buffers, or redefining workflow states.

Connected Kanban Systems in SAFe

Kanban systems are used throughout SAFe, including the Portfolio, Large Solution, and Essential levels (ART and Team), as illustrated in Figure 5. Each Kanban system has several things in common to help improve the flow of value. For example, they:

  • help match demand to capacity based on Work in Process (WIP) limits
  • help identify opportunities for relentless improvement by visualizing bottlenecks in each process state
  • facilitate flow with policies governing the entry and exit of work items in each state
Figure 5. SAFe’s connected Kanban systems.
Figure 5. SAFe’s connected Kanban systems.

Figure 5 illustrates how new work goes through the various Kanban systems and backlogs that manage the workflow. Kanban systems help strategy changes move quickly across value streams to the teams who do the implementation. This way, execution is aligned—and constantly realigned—to the evolving business strategy.

SAFe is not a top-down system. Not all work originates from the portfolio. Smaller, local changes are often needed, which may only require only new stories, features, or capabilities. These local concerns will go directly into the appropriate Team, Program, or Solution backlogs.

The following sections briefly describe SAFe’s four Kanban systems. A more detailed article supports each Kanban system.

Team Kanban

The Team Kanban system contains user and enabler stories from the Program Backlog and stories that arise locally from the team’s context. It may also include other work items, representing everything a team needs to do to advance their portion of the system. The Product Owner (PO) or another similar role manages and prioritizes the Team Kanban and backlog.

The flow of user stories and enablers typically operates in a broader context, building a solution that requires multiple Agile Teams and possibly the collaboration of ARTs within a Solution Train.

Program and Solution Kanban Systems

The Program and Solution Kanban systems facilitate the flow of business and enabler Features and Capabilities through the Continuous Delivery Pipeline.

Product and Solution Management prioritize and manage the ART and Solution Train Kanban systems. Features lend themselves to the Lean UX process model, including defining the Minimum Marketable Feature (MMF), a benefit hypothesis, and acceptance criteria. The MMF helps limit scope and investment, enhances agility, and provides fast feedback. Capabilities behave the same way as features. However, they are at a higher level of abstraction and support the definition and development of large Solutions.

Portfolio Kanban System

The Portfolio Kanban is particularly important because it helps align strategy and execution by identifying, communicating, and governing the selection of the largest and most strategic initiatives (epics) for a SAFe portfolio. Lean Portfolio Management (LPM) operates the portfolio Kanban system, which uses the strategic portfolio review and portfolio sync events to prioritize, manage and monitor workflow.

 


Learn More

[1]  https://kanbanguides.org/english/

[2] Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Sequim, Washington: Blue Hole Press, 2010.

Last update: 26 July 2022

 

Author