Working software is the primary measure of progress.
Nothing works until it’s tested . . .
—A SAFe assumption
System Demo Abstract
The primary measure of Agile Release Train (ART) progress in SAFe is the System Demo, a fortnightly demonstration of the subject system being built by the ART. The importance of the system demo cannot be overstated. It is the means for gathering immediate, ART-level feedback from the people doing the work, as well as from sponsors, stakeholders, and Customers. The demonstration of the fully integrated work from all the teams during the prior Iteration is the only true measure of value, velocity, and progress.
Planning for and presenting an effective system demo requires some work on the part of the teams, but it is the only way to get the fast feedback needed to build the right Solution.
The purpose of the System Demo is to test and evaluate the full system that the Agile Release Train is working on and to get feedback from the primary stakeholders—including Business Owners, executive sponsors, other Agile Teams, development management, Customers, and customer proxies—on the efficacy and usability of the Solution under development. This feedback is critical, as only they can provide the feedback (see Figure 1) that the train needs to stay on course or take corrective action.
The System Demo occurs at the end of every Iteration. It provides an integrated, aggregate view of the new Features that have been delivered by all the teams on the train in the most recent iteration. It provides the ART with a fact-based measure of current, system-level progress within the Program Increment (PI) and is the only true measure of ART velocity. Achieving this means that the teams must implement the scalable engineering practices necessary to support integration and synchronization across the ART.
At the end of each PI, a special system demo is held. It is a somewhat more structured and formal affair, as it demonstrates the accumulation of all the features that have been developed over the course of the PI. This demo is usually held as part of the Inspect and Adapt workshop, which feeds into the retrospective and various measures of PI progress, including the predictability Measure.
Note: For purposes of clarity, the system demo is the integrated demo of the work of all teams on the train. It is in addition to—and does not replace—each team’s local Team Demo, which also occurs at the end of every iteration. In multi-ART Value Streams, the system demo feeds into the aggregate Solution Demo.
Timing of the System Demo
The system demo happens as near as possible to the end of the iteration—ideally, the next day. However, there are a number of complications that can make that impractical. These include:
- The result of the full integration effort is typically only available at the end of the iteration (of course the goal is to strive for Continuous Integration across the full stack, but that isn’t always feasible).
- In addition, each new increment may require extensions to the demo environment, new interfaces, third-party components, simulation tools, etc. Of course, the System Team and the Agile Teams can plan for that, but some late-breaking items are inevitable.
However, the system demo must occur no later than within the time bounds of the following iteration. Otherwise, the feedback to the teams will be delayed so as to potentially put the program increment at risk. The ART must make all the necessary investments to make the system demo happen in a timely manner.
Balancing Integration Effort and Feedback
The goal of the system demo is to learn from the most recent development experience and adjust the course of action. However, when the concerns for an ART span software, hardware, mechanical systems, supplier-provided components, etc., integrating all assets every two weeks may consume too much capacity and create an unacceptable transaction cost. Simply, continuous integration may not be economical or practical in such environments.
However, no or deferred integration is far worse; it significantly inhibits learning and creates a false sense of security and velocity. Therefore, if full integration is not practical, it is critical to find the right balance, and to also continuously improve integration and testing automation to lower the cost of future integrations. Figure 2 shows a U-curve cost optimization for integration efforts.
When full integration at every iteration is too costly, the teams should consider:
- Integrating a subset of Capabilities, components, or subsystems
- Integrating to illustrate a particular feature, capability, or Nonfunctional Requirement (NFR)
- Integrating with the support of prototypes and mock-ups
- Integrating every other iteration
It is also important to remember that frequent integration represents a natural challenge for groups that are in the process of transitioning to Lean and Agile methods. That is normal and should not be an excuse to reduce the scope or extent of integration. Most of the challenges should disappear with the increasing maturity of the train, but only if the teams start immediately.
Process and Agenda
Having a set agenda and fixed timebox helps lower the transition costs of the system demo. A sample system demo meeting script follows:
- Briefly review the business context and the PI Objectives (~5 – 10 mins.)
- Briefly describe each new feature that will be demonstrated (~5 mins.)
- Demonstrate each new feature in an end-to-end use case (~20 – 30 mins. total)
- Open the forum for questions and comments
- Identify current risks and impediments
- Wrap up by summarizing progress, feedback, and action items
Attendees typically include:
- Product Managers and Product Owners, who are usually responsible for running the demo
- One or more members of the System Team, who are often responsible for staging the demo on the QA or demo environment
- Business Owners, executive sponsors, Customers, and customer proxies
- System Architect/Engineering, DevOps, and other development participants
Below are some tips for a successful system demo:
- Timebox the demo to one hour. This is critical to keep the continuous, biweekly involvement of key stakeholders. It also illustrates team professionalism and solution readiness.
- Share demo responsibilities among the team leads and product owners who have new features to demonstrate.
- Minimize PowerPoint slides; demonstrate only working, tested solutions.
- Discuss the impact of the current solution on NFRs.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 9.
 Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, chapter 15.
Last update: 21 April 2016