It is said that improvement is eternal and infinite. It should be the duty of those working with Kanban to keep improving it with creativity and resourcefulness without allowing it to become fixed at any stage.

The Kanban systems help Agile Release Trains (ARTs) and Solution Trains match demand to capacity based on Work in Process (WIP) limits, and visualizing bottlenecks in each process state helps identify opportunities for relentless improvement (described in the SAFe House of Lean). The Kanban system also includes policies governing the entry and exit of work items in each state.

Details

Implementation and management of the program and solution Kanban systems occur with the support of Product and Solution Management. Implementing the Kanban systems require an understanding of Lean and Agile development and how capacity is available for new development, business-as-usual maintenance, and support activities. When these are understood, the Enterprise can then evaluate Program and Large Solution level initiatives logically and pragmatically, supporting their analysis and forecasted timing for implementation based on Metrics.

The Program Kanban

The program Kanban facilitates the flow of features through the continuous delivery pipeline. Figure 1 illustrates a typical program Kanban, as well as example policies and WIP limits governing each state.

Figure 1. A typical program Kanban

Features begin with Continuous Exploration and may originate locally from the ART or come from an upstream Kanban (e.g., solution or Portfolio Kanban). Local content authority, Product Management, and System Architects manage this Kanban. The following process states describe its flow:

Funnel – All new features are welcome here. They may include new functionality, enhancement of the existing system functions, or Enabler features.

Analyzing – New features that align with the Vision and support the Strategic Themes are further explored by Agile Teams when they have available capacity. Refinement includes the collaboration to define its description, business benefit hypothesis, acceptance criteria, and size in normalized story points. The feature may require prototyping or other forms of exploration by Agile Teams. The WIP limit for this state must account for the availability of Product Management, the capacity of teams and other subject matter experts.

Program Backlog – The highest-priority features that were analyzed and approved by Product Management advance to this state, where they are prioritized with Weighted Shortest Job First (WSJF), relative to the rest of the backlog, and await implementation.

Implementing – At every Program Increment (PI) boundary the ART pulls the top features from the program backlog and moves them into the implementing state. Through the PI Planning process, they get split into stories, planned into iterations and subsequently implemented by teams during the PI.

Validating on staging – At the end of every iteration, while the ART prepares for the System Demo, features that are ready for feedback get pulled into this state. The teams integrate and test them with the rest of the system in a staging environment (or its closest proxy), and are presented to Product Management and other stakeholders for approval at the system demo. Approved features move to the ‘ready’ part of this state, where they’re prioritized again using WSJF to await deployment.

Deploying to production – When capacity becomes available for deployment activities (or immediately in a fully automated continuous delivery environment) the feature gets moved to production. If it’s deployed but turned off (see Release on Demand for more details), then it moves to the ‘ready‘ part of this state to await release. This state is WIP limited to avoid the buildup of features that are deployed but not yet released.

Releasing – When there’s sufficient value, market need, and opportunity, features are released to some or all of the customers, where evaluation of the benefit hypothesis happens. While the feature moves to the ‘done‘ state, new work items may be created to support the MVP or MMF.

The Kanban system described here provides a good starting point for most ARTs. However, it should be customized to fit the ART’s process, including the definition of WIP limits and the specific policies for each process state.

Program Epic Kanban

Some ART initiatives are simply too big to be completed in a single PI. These are Program Epics, identified and managed in a separate Kanban system, as shown in Figure 2. Also, some portfolio epics may require splitting them into solution and program epics to facilitate incremental implementation. While mainly a local concern, program or solution epics may have an impact on financial, human, and other resources that are large enough to warrant a Lean business case, discussion, and financial approval from Lean Portfolio Management (LPM). That’s what makes an epic, an epic.

The primary purpose of this Kanban system is to analyze and approve program epics, splitting them into features that will be further explored and implemented using the program Kanban. Depending on how frequently program epics occur in the local context of the ART, this Kanban system may not be required.

Figure 2. A typical program epic Kanban

The program Kanban typically requires the engagement of large solution or portfolio stakeholders to explore and approve the program epics. The process states in this Kanban usually follow those in the Portfolio Kanban, for example:

Funnel – All big program initiatives are welcome in the ‘funnel‘ state. There is no WIP limit.

Reviewing – This is where subject matter experts and stakeholders perform the review of the epics and prioritize them using WSJF to determine which ones should move on for more in-depth exploration. Again, WIP limits apply.

Analyzing – During this diagnostic and exploration state, subject matter experts and stakeholders are encouraged to:

Determine the costs involved, technology and architectural enablement, infrastructure, using a Lean business case (described in the epics article).

Guided by analysis and insights, Business Owners (and typically Lean Portfolio Management personnel) approve or reject the epics. Approved epics then get split into features and transitioned to the funnel of the program Kanban, where they will be prioritized based on WSJF. WIP limits also apply to the analyzing state.

Similar to the portfolio level, program epics may require Epic Owners to help with the definition, exploration, and implementation.

Managing the Program Kanban with the ART Sync

One significant program event is the ART sync meeting, where Scrum Masters and Product Owners review the program Kanban system and pull in more work based on the available capacity at each state. Participants discuss new work, prioritize, schedule meet-afters, and make deployment and release decisions as needed.

Further, the Program Board (see PI Planning) facilitates reviewing items in the ‘implementing’ state, including discussion of dependencies and execution.

The Solution Kanban Systems

This article described the program Kanban systems in depth. For organizations using the Large Solution level or configuration, the solution Kanban follows the same structure and process used for the program level. However, Solution Management and Solution Architects manage this Kanban, which operates with Capabilities instead of features. Also where useful, teams employ a Solution Epic Kanban for solution epics that mirror the Program Epic Kanban.