The objective of the pull event was simple. It was designed to focus the development organization on a tangible event to force completion of a learning cycle with the objective to physically demonstrate it.

—Dantar P. Oosterwal, The Lean Machine [1]

Solution Demo

Definition: The Solution Demo provides stakeholders an integrated view of the contributions of multiple ARTs and suppliers to obtain objective evidence of solution performance and to gather feedback.

The Solution Demo presents the combined development efforts of multiple Agile Release Trains (ARTs)—along with the contributions of Suppliers and other solution participants—to Customers and other stakeholders. This demo is critical for the Solution Train to receive objective evaluation and feedback. It’s also a moment to celebrate the accomplishments of the last PI.

Each solution demo represents a significant learning point in the history of the Solution, converting some product development uncertainty into knowledge. The results of this demo determine the future course of investment in the solution.

Details

During the solution demo, Agile Teams demonstrate the solution’s new Capabilities, its compliance with Nonfunctional Requirements (NFRs), and its overall fitness for purpose. To ensure progress throughout the PI, ARTs and suppliers should strive to continuously or partially integrate their changes whenever possible. (See also the discussion of frequent integration in Enterprise Solution Delivery). At a minimum, changes across the entire Solution Train should be integrated before the solution demo. (Figure 1).

Figure 1. Solution Trains integrate changes at least every PI
Figure 1. Solution Trains integrate changes at least every PI

The solution demo provides essential input to near-term Development Value Stream and Portfolio Level investment decisions. The objective measure of progress gives early validation and mitigates investment risk.

Solution Demo as a ‘Pull’ Event

As the quote at the top of this article suggests, the solution demo is a deliberate and high-profile ‘pull event.’ It ‘pulls’ together various aspects of the solution and helps ensure that the ARTs and suppliers create an integrated and tested solution that is fit for its intended purpose. This demo accelerates the integration, testing, and evaluation of the entire solution under development—something that’s all too easy to defer until too late in the development lifecycle.

Enterprises sometimes create even more significant pull events within a portfolio, during which several Solution Trains come together for a ‘roadshow’ of their accomplishments (see [1] for example). The portfolio’s senior leaders and stakeholders review progress in a broader context and make decisions about initiatives’ continuation (or cancellation). Or, they might decide to make changes to the investment in their development value streams.

Preparation

A solution demo is a critical event that requires preparation, which often begins with Pre-Plan, where the results of the most recent solution demos are available. Those results inform the people staging the demo on what specific capabilities and aspects of the solution can and should be demonstrated. Since the Solution Train is large and usually distributed, logistics do matter. Video conferencing technology should support remote attendees to observe and participate. Timing, presentation format, and professionalism enhance the experience. It may even influence the outcome.

Attendees

Attendees for a solution demo typically include:

Event Agenda

A typical event agenda includes the following activities:

  • Briefly review the Solution Train PI Objectives for the PI
  • Demo each PI objective and capability in an end-to-end use case
  • Identify business value completed for each PI objective
  • Open forum for questions and comments
  • Wrap up by summarizing progress, feedback, and action items

The day can be even more interesting if multiple solutions are demoed together. A popular format is the ‘science fair,’ where each solution has an area to demo progress and allow stakeholders to ask questions and provide feedback. Each solution has a timebox to demo its accomplishments to a set of specific stakeholders following the agenda above, but all solutions are constantly available for demo. Members from other solutions and stakeholders can attend each other’s demos to get a less formal demonstration and provide feedback.

Guidelines

Here are a few tips to keep in mind for a successful demo:

  • Timebox the demo to one to two hours. Sticking to the allotted timebox demonstrates professionalism, respect for people’s time, and solution readiness.
  • Share demo responsibilities among lead engineers and team members who have new capabilities to demo.
  • Minimize slides; demonstrate working and tested capabilities only.
  • Minimize demo preparation. Demo the working, tested capabilities, not slideware.
  • Discuss the impact of the current PI on the solution NFRs and Solution Intent.
  • Demonstrate in the Solution Context (see below).

Demonstrate the Solution in Its Solution Context

Solutions may have varying degrees of coupling with their solution context. Sometimes, a solution is mainly independent of its environment, and an isolated solution demo may be adequate. However, when the system is highly dependent on the solution context (a system of systems, for example), the isolated approach is inadequate and may even be misleading. In this case, the solution should be demoed in an environment that is representative of its solution context. When that’s not practical, development should plan for some cadence of integration with the broader solution context.

Strategy, Investment, and Timing of Solution Demos

Large systems can be hard to integrate. The Solution Roadmap communicates the anticipated, demonstrable capabilities for upcoming PIs that align ARTs and suppliers and set expectations for what can be demonstrated at any point in time. Routinely demonstrating a solution increment requires teams to invest in the Continuous Delivery Pipeline, grow testing and Built-in Quality practices, and evolve supporting infrastructure. Even then, the extent of integration and testing may be less than 100 percent and may need to vary across multiple integration points. To reduce the integration burden, teams leverage virtualization, environment emulation, mocks, stubs, and reduced test suites to demo the completed parts. Also, some effort for integration, demo, and time to invest in the supporting environment may need capacity allocation during PI Planning.

As for timing, the solution demo may lag slightly behind the last system demos in the PI. However, this creates a delayed feedback loop that increases risk and decreases Solution Train velocity. Here are some tips for minimizing the lag:

  • Plan to demonstrate a subset of the PI objectives, which may require some staging and configuration management to support partial demos.
  • Set aside time during the Innovation and Planning (IP) Iteration for this high-level integration.
  • ARTs that broaden their areas of responsibility for integration and testing can create more overlap with the subsystems and capability areas of other trains. As a result, even the individual system demos offer a better approximation of the fully integrated solution demo.

Finally, the solution may be designed to support better integration and testing, significantly lowering the demo’s cost. Agile architecture practices such as standard interfaces, strictly defined APIs, and containers help teams spot problems and inconsistencies early on, making end-to-end integration and testing of subsystems easier.

Learn More

[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.

Last update: 9 October 2023