Base milestones on objective evaluation of working systems.
—Lean-Agile Principle #5
The System Demo is a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the Agile Release Train (ART). Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI).
A system demo is a critical event. It’s the method for gathering immediate, ART-level feedback from the people doing the work—as well as from sponsors, stakeholders, and Customers. The one real measure of value, velocity, and progress is the demo of the fully integrated work from all the teams during the prior iteration.
Planning for and presenting a useful system demo requires some work and preparation by the teams. But it’s 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 in the staging environment that the ART is working on and getting feedback from the primary stakeholders. These stakeholders include Business Owners, executive sponsors, other Agile Teams, development management, customers (and their proxies) who provide input on the fitness for purpose for the solution under development. The feedback is critical, as only they can give the guidance (see Figure 1) 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, comprehensive view of the new features that have been delivered by all the teams on the train in the most recent iteration. It offers the ART a fact-based measure of current, system-level progress within the PI. It’s the only real measure of ART velocity. Achieving this requires implementing the scalable engineering practices necessary to support integration and synchronization across the ART.
At the end of each PI, the ART holds a final PI system demo. It’s a somewhat structured and formal affair, as it demos an increment that includes all the features developed over the course of the PI. This demo is usually part of the Inspect and Adapt (I&A) event, which feeds into the retrospective and various PI progress Metrics, including the ‘program predictability measure’ and ‘program performance metrics.’
Note: The staging environment is best suited for the system demo, as this environment usually mirrors production as much as possible. In large Solution Trains, the system demo feeds into the Solution Demo.
Timing of the System Demo
The system demo takes place as close to the end of the iteration as possible—ideally, the next day. There can be some complications, which can make that timing impractical. These include:
- Typically, the results of the full integration effort are available only at the end of the iteration. (Of course, the goal is to strive for Continuous Integration across the entire stack, but that isn’t always feasible.)
- Also, 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 within the time bounds of the following iteration. Otherwise, feedback to the teams will be delayed, potentially putting the PI at risk. The ART must make all the necessary investments to allow the system demo to happen in a timely cadence.
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, and supplier-provided components, 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, deferred integration, or none at all, is far worse. It significantly inhibits learning and creates a false sense of security and velocity. Therefore, if this is not practical, it’s critical to find the right balance and to 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)
- Partial integration with the support of prototypes and mock-ups
- Less frequent integration (e.g., every other iteration) until it’s feasible to do it more often
It’s also important to remember that continuous integration represents a natural challenge for groups still transitioning to Lean and Agile methods. That’s normal and should not be an excuse to reduce the scope or extent of integration. Most of the challenges should disappear as the train matures—but only if the teams start immediately.
Process and Agenda
Having a set agenda and fixed timebox helps lower the transaction costs of the system demo. A sample agenda follows:
- Briefly, review the business context and the PI Objectives (approximately 5 – 10 minutes)
- Briefly, describe each new feature before demoing (about 5 minutes)
- Demo each new feature in an end-to-end use case (around 20 – 30 minutes, total)
- Identify current risks and impediments
- Open discussion of questions and feedback
- 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 setting up the demo in the staging environment
- Business Owners, executive sponsors, customers, and customer proxies
- System Architect/Engineering, IT operations, and other development participants
Below are some tips for a successful system demo:
- Timebox the demo to one hour. A short timebox is critical to keep the continuous, biweekly involvement of key stakeholders. It also illustrates team professionalism and system readiness.
- Share demo responsibilities among the team leads and Product Owners who have new features to demo.
- Demo using the staging environment
- Minimize the use of slides; instead demonstrate only working, tested solutions.
- Discuss the impact of the current solution on NFRs.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
Last update: 13 November 2017