Base milestones on objective evaluation of working systems.

—Lean-Agile Principle #5

System Demo

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 assessing the Solution’s current state and gathering immediate, Agile Release Train-level feedback from the people doing the work, as well as critical feedback from Business Owners, sponsors, stakeholders, and customers. The demo is the one real measure of value, velocity, and progress of the fully integrated work across all the teams.

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.

Details

The system demo tests and evaluates the full solution in a production-like context (often staging) to receive feedback from 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 the ART needs to stay on course or make adjustments.

Figure 1. The System Demo

The system demo occurs at the end of every Iteration. It provides an integrated, comprehensive view of the new Features delivered by the ART over the past iteration. It offers the ART a fact-based measure of current, system-level progress within the Program Increment (PI). It’s the true measure of ART velocity and progress. Achieving this requires implementing the scalable engineering practices necessary to support Continuous Integration across the ART.

At the end of each PI, the ART holds a final PI system demo that shows all the features developed over the last PI. Since its scope is larger, the audience may be broader and include customers, Portfolio representatives, and other additional stakeholders. 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.’

In large Solution Trains, the system demo feeds into the Solution Demo.

The Timing of the System Demo

The system demo takes place as close to the end of the iteration as possible—ideally, the next day. While that is the goal, there can be some complications that make that timing impractical. Immature continuous integration and Built-in Quality practices can delay the ART’s ability to integrate frequently. Also, each new increment may require extensions to the demo environment including new interfaces, third-party components, simulation tools, and other environmental assets. While the System Team strives to provide the proper demo environment at the end of each iteration, the integration may lag.

The system demo must occur within the time bounds of the following iteration. ARTs must make all the necessary investments to allow the system demo to happen in a timely cadence. In fact, a lagging system demo is often an indicator of larger problems within the ART, such as continuous integration maturity or System Team capacity.

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, some components don’t lend themselves to continuous integration – hardware, mechanical systems, and supplier-provided components, and scarce components due to costs or availability. 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.

Figure 2. Integration u-curve cost optimization

When full integration at every iteration is too costly, the teams should consider:

  • Using Test Doubles to speed integration and testing by substituting slow or expensive components with faster, cheaper proxies
  • 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 in place of scarce or expensive components
  • 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 ART matures.

Continuous integration validated by the system demo contributes to the ability of the Lean Enterprise to achieve faster time-to-market through a more continuous flow of value to its customers as outlined in the Agile Product Delivery competency.

Attendees

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
  • ART Agile team members attend whenever possible

Event 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

Guidelines

Here are a few tips to keep in mind for a successful 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, Product Owners, and even team members who have new features to demo
  • Demo using the staging environment
  • Minimize demo preparation. Demo the working, tested capabilities, not slideware.
  • Minimize demo presentation time. Demo screen snapshots and pictures where appropriate
  • Discuss the impact of the current solution on NFRs

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

Last update: 10 February 2021

 

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.