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.
Program and Solution Kanban
The Program and Solution Kanban systems are methods used to visualize and manage the flow of value from ideation to analysis, implementation, and release. They support the flow of features and capabilities through the full Continuous Delivery Pipeline of Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand.
The Kanban systems allow Agile Release Trains (ARTs) and Solution Trains to manage capacity based on the Work in Process (WIP) limits of the different states of the process. This helps prevent the system from operating with large handoffs, and identifies bottlenecks and opportunities for improvement. It provides clear guidelines for the policies governing each state, as well as the criteria for moving to the next state. This combination of visualization, WIP limits, and policies fosters collaboration and effective decision-making, which facilitates a faster flow of value through the system.
Kanban systems visualize the flow of value through a value stream by showing the location of all work items moving through the system. Enhancing a pull mentality by using WIP limits and explicit policies, Kanbans are the primary mechanism to achieve SAFe Principle # 6, Visualize and limit WIP, reduce batch sizes, and manage queue length, as well as the Lean concept of “flow.”
Program and Solution Kanban systems help teams:
- Increase visibility into existing and upcoming work, and better understand the flow of work.
- Ensure continuous refinement of new value definition and acceptance criteria.
- Foster role collaboration across disciplines, functions, and levels.
- Instantiate economic decision-making by setting the priorities for the pull-based mechanism.
- Establish connections between the Portfolio, solution train, and ARTs.
The Program Kanban
The Program Kanban is used by the ART to facilitate the flow of features through the Continuous Delivery Pipeline. A typical program Kanban is illustrated in Figure 1. The policies applied to each state, and some example WIP limits, are highlighted.
Features originate in Continuous Exploration, and may begin locally or come from an upstream Kanban. Local content authority, Product Management and System Architects manage the Kanban. The following states describe Kanban feature flow:
Funnel – All new features are welcome in the “Funnel.” They may include new functionality, or enhancement of the existing system functions, or Enabler features.
Analyzing – When capacity is freed up to analyze features, those that align with the Vision and support Strategic Themes are pulled into the “Analyzing” state for further exploration. This state requires refinement of the key attributes of a feature: the description, business benefit hypothesis, and acceptance criteria.
General sizing of features also occurs at this state, estimated in normalized Story points. The purpose is to support economic estimating and forecasting of value delivery over a longer period of time based on scope. Some features under analysis may require prototyping or other forms of exploration that involve Agile Teams. Typically, such exploration is included in the PI plan. The WIP limit at the analyzing state is based on overall availability of Product Management, other subject matter experts, and the capacity of teams dedicated to exploration activities.
Program Backlog – The highest-priority features that were sufficiently elaborated and approved by Product Management move to this state. Then they’re prioritized with Weighted Shortest Job First (WSJF) relative to the rest of the backlog to 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, these selected features get broken down into stories 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 the validating-on-staging state. At this point they’re integrated with the rest of the system on a staging environment (or its closest proxy), tested, and presented for approval at the system demo to Product Management and other stakeholders.
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 environment) the feature gets deployed to production. If it’s deployed but turned off (see Release on Demand for more details), then it moves to the ready part of the state to await release. Otherwise, it moves directly into the releasing step. To avoid the buildup of features that are deployed but not yet released, this state is WIP-limited.
Releasing – When there’s sufficient value, market need, and opportunity, features are released to some or all of the customers. In addition, the benefit hypothesis is evaluated and this state moves to done. The evaluation, however, might spawn new features in the funnel state.
The above Kanban is prototypical—a good starting point for most ARTs, as are the policies we’ve described. ARTs, however, can customize this system to fit their process, defining their own WIP limits based on the available capacity for the work, and their specific policies for movement from state to state.
Program Epic Kanban
Some initiatives are too big to be completed in a single Program Increment. These are Program Epics, identified and managed in a separate Kanban system, as shown in Figure 2.
The goal is to analyze and approve program epics, splitting them into features that will be further explored and implemented in the program Kanban. Depending on how frequently program epics occur in the local context of the ART, this Kanban system is not always used.
For this Kanban system to succeed, it must engage a higher level of stakeholders to explore and approve program epics—typically those at the solution train or portfolio level. The flow generally mirrors the states in the Portfolio Kanban:
Funnel – All big initiatives are welcome in the Funnel state. There is no WIP limit.
Reviewing – This state allows the assigned analysts to perform initial exploration of epics and rank them roughly using
WSJF to determine which ones should move on for deeper exploration. Again, WIP limits apply.
Analyzing – At this diagnostic and exploration state, stakeholders are encouraged to:
- Refine size and WSJF compared to other epics.
- Consider solution alternatives.
- Identify possible Minimum Viable Products (MVPs).
- Determine the costs involved, technology and architectural enablement, infrastructure, etc.
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 against other features. WIP limits apply.
Similar to portfolio epics, program epics may require Epic Owners to help with the definition, exploration, and implementation.
Managing the Program Kanban with the ART sync
One significant ART event is the “ART sync meeting,” which is attended by Scrum Masters and Product owners. During the ART sync, participants review the program Kanban system from right to left, pulling in more work based on the available capacity at each state. Participants, discuss new work, prioritize, schedule meet-after’s, and make deployment and release decisions as necessary.
Further, the Program Board (see PI Planning) serves as a ‘zoom-in’ for the implementing state, allowing more in-depth discussion of dependencies and execution.
The above describes the program Kanban in depth. For Large Solutions, the Solution Kanban generally repeats this structure. It operates with Capabilities instead of Features, however, and is managed by Solution Management and Solution Architects.
In addition, where useful, teams apply a Solution Epic Kanban section that parallels the Program Epic Kanban.
Last update: 5 May, 2016