- Why Agile Product Delivery?
- Customer Centricity and Design Thinking
- Develop on Cadence, Release on Demand
- DevOps and the Continuous Delivery Pipeline
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Develop on Cadence, Release on Demand
The second dimension of Agile product delivery is to develop on cadence but release on demand. This dimension helps customer-centric enterprises offer a continuous flow of value to the market and customers (Figure 7-8).
)
Figure 7-8. Develop on cadence and release on demand
As described in Principle #7, applying cadence to development makes routine what can be routine and increases predictability of the inherently uncertain nature of product development. However, the timing of releases is a different matter. Release timing and frequency are determined by market and customer needs and the economics of value delivery. Some enterprises may release frequently (continuously, hourly, daily, weekly), while others may be constrained by compliance requirements or other market rhythms that motivate less frequent releases. Collectively, the Scaled Agile Framework (SAFe) refers to these capabilities as release on demand.
The Program Increments (PIs) shown in Figure 7-8 are a larger timebox, a planning interval that consists of multiple iterations during which a team of Agile teams (an ART) delivers incremental value in the form of working, tested solutions. PIs are typically established as fixed 8- to 12-week periods, comprised of three to five development iterations, followed by one Innovation and Planning (IP) iteration. Shorter PIs are often employed when the market is more dynamic. Releasing can happen at any time during a PI, and at any frequency.
Program Backlog
The work of a train is defined by the program backlog, which consists of upcoming features intended to address user needs and deliver business benefits.
A feature is a distinctive characteristic of a product or service that fulfills a stakeholder need. Product Managers, in collaboration with Product Owners and other key stakeholders, define them in the local context of an ART. They are sized to be delivered in a single PI or less and are specified using a Features And Benefits (FAB) matrix (Figure 7-9).
Feature. A short phrase giving a name with context.
Benefit hypothesis. The proposed measurable benefit to the end-user or business.
)
Figure 7-9. FAB matrix
Enabler features are technical investments that create the architectural runway to support future business functionality. The program Kanban (see later in this chapter) is used to maintain enablers alongside business features. It promotes a healthy balance with all the work needed to both develop and maintain the solution. Feature acceptance criteria are typically defined during program backlog refinement.
The backlog is ‘anchored’ by NFRs that help ensure the usability and effectiveness of the system. NFRs define system attributes such as security, reliability, and scalability, and they serve as constraints on system design. Failing to meet any of them can result in systems that do not meet business, user, or market needs, or other requirements that may be imposed by regulatory or standards bodies. Unlike features, they do not enter and leave the backlog when done; instead, they are persistent qualities and restrictions that govern all new development.
Prioritizing the Program Backlog
Product Management has the primary responsibility for developing and maintaining the backlog and for making decisions regarding the sequence in which to implement features. SAFe applies a comprehensive model called Weighted Shortest Job First (WSJF) to prioritize work based on the economics of product development flow.7 WSJF is calculated by dividing the Cost of Delay (CoD) of a job by the duration. Jobs that can deliver the most value (or CoD) in the shortest period are typically selected first for implementation.
In SAFe, the ‘jobs’ are the features in the backlog. Since it’s rarely possible to determine their duration before they are planned for implementation, SAFe typically uses relative job size as a proxy for the duration. Relative proxy measures are also applied for the CoD based on three components, as shown in Figure 7-10.
)
Figure 7-10. CoD has three primary components
Using a simple table to compare jobs, WSJF is calculated for each feature (Figure 7-11). Unless there are sequencing dependencies between the jobs, the features with the highest scores are implemented first.
)
Figure 7-11. A table for calculating WSJF
Each feature is estimated relative to the others for each of the three components of CoD and job size. The smallest item in each column is set to ‘one,’ and the others in that same column are estimated relative to that one. The CoD is the sum of the first three attributes for each item. WSJF is calculated as CoD divided by job size. The job with the highest WSJF is the next most important one to do.
Executing PI Events
As we will describe shortly, the backlog is implemented and delivered by the activities of the CDP. As illustrated in Figure 7-12, developing on cadence is supported by a series of additional cadence-based events during each PI.
)
Figure 7-12. Events that support PI execution
The following sections describe each of these events.
PI Planning
PI planning is a cadence-based event that serves as the heartbeat of the ART, aligning all the teams on the ART to a shared mission and vision (Figure 7-13). PI planning is held face-to-face whenever possible. For geographically distributed ARTs, PI planning may occur at multiple locations simultaneously by maintaining constant audio and video communication between all sites. In some circumstances, like the COVID-19 crisis that is ongoing at the time of this writing, PI planning is fully distributed. The advanced topic article “Distributed PI Planning with SAFe”8 provides additional guidance and considerations for successfully managing this scenario.
)
Figure 7-13. Face-to-face PI planning. Remote teams are planning at the same time using video conferencing
Facilitated by the Release Train Engineer (RTE), PI planning includes all members of the ART. It typically takes place over two days and occurs within the IP iteration, which avoids affecting the schedule and capacity of other iterations. PI planning is essential to SAFe: if you are not doing it, you are not doing SAFe.
Business Benefits of PI Planning
PI planning delivers many business benefits, including:
Aligning development to the business context and goals, vision, and team and ART PI objectives
Building the social network the ART depends upon
Identifying dependencies and fostering cross-team and cross-ART collaboration
Providing the opportunity for ‘just in time’ and ‘just the right amount’ of requirements, design, architecture, and user experience guidance
Matching demand to capacity and eliminating excess Work in Process (WIP)
Faster decision-making. All the relevant parties are focused on the same objectives and can consider and make necessary tradeoffs in real time
Inputs and Outputs of PI Planning
Inputs to PI planning include the business context, roadmap and vision, and the top ten features of the program backlog. Outputs of PI planning include the following:
Committed PI objectives . A set of SMART9 objectives that are created by each team with a business value assigned by the Business Owners.
Program board. It highlights feature delivery dates, dependencies between teams, and relevant milestones.
Conducting PI Planning
The RTE facilitates PI planning, and event attendees include Business Owners, Product Management, Agile teams, System Architecture and Engineering, the System Team, and other stakeholders, all of whom must be well prepared. The active participation of Business Owners in this event provides an essential guardrail for prioritization of business value. Figure 7-14 illustrates a typical standard two-day PI planning agenda.
)
Figure 7-14. Standard two-day PI planning agenda
Day 1 Agenda
Business context. A Business Owner or senior executive describes the current state of the business, shares the portfolio vision, and presents a perspective on how effectively existing solutions are addressing current customer needs.
Product vision . Product Management presents the current vision (typically represented by the next top 10 upcoming features) and highlights any changes from the previous PI planning meeting, as well as any upcoming milestones.
Architecture vision and development practices. System Architecture and Engineering (typically a CTO, or Enterprise Architect) presents the vision for architectural changes and a senior development manager may introduce new or revised Agile development practices for the upcoming PI (e.g., such as introducing test-driven development or adjusting the CI/CD pipeline).
Planning context and lunch. The RTE presents the planning process and expected outcomes of the event.
Team breakouts #1. In the first breakout, teams estimate their capacity for each iteration and identify the backlog items they will likely need to realize the features. Each team creates their draft plans, visible to all, iteration by iteration.
During PI planning a program board (Figure 7-15) is used to visualize and track dependencies and to identify opportunities to eliminate or reduce them.
)
Figure 7-15. Program board showing features and dependencies
Draft plan review. During the timeboxed draft plan review, teams present key planning outputs, which include capacity and load, draft PI objectives, potential risks, and dependencies. Business Owners, Product Management, and other teams and stakeholders review and provide input.
Management review and problem-solving. It’s almost certain that the draft plans have identified challenges associated with scope, people and resource constraints, and dependencies. During the problem-solving meeting, management may negotiate scope changes and resolve other problems by agreeing to various planning adjustments.
Day 2 Agenda
Planning adjustments. The next day begins with management presenting any changes to prioritization, planning scope, people, and resources.
Team breakouts #2. Next, teams continue planning based on their agenda from the previous day, making the appropriate adjustments. They finalize their objectives for the PI, to which the Business Owners assign business value, as shown in Figure 7-16.
Figure 7-16. A team’s PI objectives sheet with assigned business value
Final plan review and lunch. During this session, all teams present their plans to the group. The team then asks the Business Owners if the plan is acceptable. If the Business Owners have concerns, teams are given the opportunity to adjust the plan as needed to address the issues identified. The team then presents their revised plan.
Program risks. During planning, teams have identified program risks and impediments that could impact their ability to meet their objectives. These are addressed in front of the whole train and categorized into one of the following ROAM categories:
– Resolved—The teams agree that the risk is no longer a concern.
– Owned—Someone on the train takes ownership of the risk since it cannot be resolved during PI planning.
– Accepted—Some risks are just facts or potential problems that must be understood and accepted.
– Mitigated—Teams identify a plan to reduce the impact of the risk.
Confidence vote. Once program risks have been addressed, teams vote on their confidence in meeting their team PI objectives. Each team conducts a ‘fist of five’ confidence vote. If the average is three fingers or above, then management should accept the plan. Any person voting two or fewer should be given an opportunity to voice their concerns. This might add to the list of risks, require some re-planning, or simply be informative. Once each team has voted the process is repeated for the entire ART with everyone expressing their confidence in the collective plan.
Plan rework. If necessary, teams rework their plans until a high confidence level can be reached. This is one occasion where alignment and commitment are valued more highly than adhering to a timebox.
Planning retrospective and moving forward. Finally, the RTE leads a brief retrospective for the PI planning event to capture what went well, what didn’t, and what can be done better next time.
)
Over the course of the program increment, the ART proceeds to execute the PI, track progress, and adjust plans as needed to adapt as new learning occurs. Execution of the PI begins with all the teams conducting planning for the first iteration, using their PI plans as a starting point.
Scrum of Scrums and Product Owner Sync (ART Sync)
After PI planning, the RTE typically facilitates weekly (or more frequently, as needed) SoS and Product Owner sync events. The SoS helps coordinate the dependencies of the ARTs and provides visibility into progress and impediments. The RTE, Scrum Masters, and others (where appropriate) meet to review their progress toward milestones and PI objectives, as well as dependencies among the teams. The event is timeboxed for 30–60 minutes and is followed by a ‘meet after’ where individuals who need to resolve specific problems or questions can remain behind. Figure 7-17 shows a suggested agenda for the SoS event.
)
Figure 7-17. ART sync, Scrum of Scrums, and PO sync
Like the SoS, Product Owners and Product Management often hold a Product Owner sync. This event typically occurs weekly, or more frequently, as needed. The Product Owner sync is also timeboxed (30–60 minutes) and includes a meet after discussion. Sometimes the SoS and Product Owner sync are combined into one event, referred to as an ‘ART sync’ (Figure 7-17).
System Demo
A system demo is a significant event that occurs at the end of each iteration, which provides fast feedback about the effectiveness, usability, and releasability of the system (Figure 7-18). It offers an integrated view of the new features delivered by the ART over the past iteration, providing a fact-based measure of system-level progress and velocity within the PI.
)
Figure 7-18. The system demo
This demo is done in a production-like environment (often staging) to receive feedback from stakeholders. It helps ensure that integration between teams on the same ART occurs regularly and that the emergent behavior of the full system can be evaluated. These stakeholders include the teams, Business Owners, executive sponsors, development management, and customers (or their proxies) who provide input on the fitness for purpose for the solutions being developed. The feedback is critical, as only they can give the guidance the ART needs to stay on course or make adjustments.
Prepare for the Next PI Planning Event
While we note this activity as a PI event, in reality, preparing for the upcoming PI is an ongoing process, with three primary focus areas.
Alignment and organizational readiness for planning
Backlog and content readiness
Facility readiness—the actual logistics for the event
Since any one of these items can interfere with the potential outcome—a committed PI plan—careful consideration and planning is required for all three focus areas.
Inspect and Adapt
The I&A is a significant event held at the end of each PI, just prior to the next planning. It consists of three parts.
PI system demo. This demo is a little different from the regular system demos because it shows all the features that the ART has developed throughout the PI. During this demo, Business Owners collaborate with each team to agree on the actual business value achieved for their specific PI objectives.
Quantitative and qualitative measurement. Teams collectively review any quantitative and qualitative metrics they have decided to collect and then discuss the data and trends. One primary measure is the program predictability measure. The RTE summarizes the planned versus actual business value for each team’s PI objectives to create the overall program predictability measure.
Retrospective and problem-solving workshop. The ART runs a brief retrospective, the goal of which is to identify a few significant issues they would like to resolve. For addressing systemic problems, a structured, root-cause problem-solving workshop is then used to determine the actual root causes of a problem. The result is a set of improvement backlog items that go into the program backlog to be addressed during PI planning.