Solution Demo

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

Solution Demo Abstract

The Solution Demo is the apex event of the Program Increment cycle for a Value Stream. This is the event where the results of all the development efforts from multiple Agile Release Trains—along with the contributions from Suppliers and other value stream participants—are made visible to the Customers and other stakeholders. This is the most critical time for a fully integrated, Solution-level demonstration; a time for objective evaluation and stakeholder and Customer feedback. And it is a time to celebrate the accomplishments of the last PI.

It also represents one of the most significant learning points in the history of the value stream; results here will determine the future course of action for a major element of the Enterprise Portfolio.


The Solution Demo is a major event in the life cycle of a Value Stream Solution. This cadence-based event is the time high-profile stakeholders come together to view, via objective evidence, the progress that the solution has made during the past Program Increment. During the event, development teams demonstrate the new Capabilities of the solution, its compliance with Nonfunctional Requirements, and its overall fitness for purpose. Key stakeholders, typically including Solution Management, Architects/Engineering, and, whenever possible, Customers, participate in the event and provide direct feedback and observations.

The importance of this event cannot be overstated. It is a high-profile event, and the harbinger of near-future value stream and Portfolio investment decisions. It is the only true measure of progress, and the primary mitigator of investment risk for the value stream.

Solution Demo as a “Pull” Event

As can be inferred from the quote at the top of this article, the solution demo is a purposeful, mandatory, and high-profile “pull” event. It pulls various aspects of the solution together and helps ensure that the Agile Release Trains and Suppliers are creating an integrated and tested solution that is fit for its intended purpose. Thereby, it accelerates the integration, testing, and evaluation of the solution under development—something that is otherwise all too easy to defer until too late in the solution life cycle.

In the portfolio context, Enterprises sometimes create even larger pull events during which several solutions come together for a “road show” of their accomplishments (see Ref 1 for an example). There, senior managers, stakeholders, and portfolio fiduciaries review the progress in the broader portfolio context and make decisions about the continuation or cancellation of initiatives or changes to the budgetary investment in the value streams.



Such a critical event requires preparation. This preparation often begins at Pre- and Post-PI Planning, where the results of the most recent System Demos are available. Those results inform those who are staging the demo as to what specific capabilities and other aspects of the solution can be demonstrated. In addition, even though the solution demo may not have a large group of attendees (scope considerations usually prevent most development team members from attending), logistics do matter. Those who do attend are important to the value stream, and some attention to logistics, timing, presentation format, and professionalism enhance the experience. They may even influence the outcome.


Attendees for a solution demo typically include:

Event Agenda

A typical event agenda includes the following actions:

  • Review the value stream PI Objectives that were agreed to at the beginning of the PI (10 minutes)
  • Demonstrate each objective and capability in an end-to-end use case (30 – 60 minutes total)
  • Identify business value completed per objective
  • Open the forum for questions and comments
  • Wrap up by summarizing progress, feedback, and action items

In the case where multiple solutions are demoed together, the day can be even more interesting. One common format is like a science fair, where each solution has an area to demo progress and allow stakeholders to ask questions and provide feedback. Each solution has a one-hour timebox to demo its accomplishments to a set of specific stakeholders as per the agenda above, but all solutions are constantly available for demo. Members from other solutions and other stakeholders can go to each solution to get a less formal demo and provide informal feedback.


Of course there is no one right way to conduct a successful solution demo, but here are a few tips to keep in mind:

  • Timebox the demo to one to two hours. This is critical to keep the involvement of key stakeholders. It also illustrates professionalism and solution readiness.
  • Share demo responsibilities among lead engineers and team members who have new capabilities to demonstrate.
  • Minimize PowerPoint slides; demonstrate only working, tested capabilities.
  • 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

The latter bullet is particularly critical, as different solutions may have different degrees of coupling with their Solution Context. In some cases, a solution is largely independent of its environment, and an isolated solution demo may be adequate. However, when the solution is tightly dependent on the solution context (a system of systems, for example), then the isolated approach is inadequate and may even be misleading. In this case, the solution should be demonstrated in an environment that is fully representative of the solution context. When that is not routinely practical, development should plan for some cadence of integration with the larger solution context. However, in that case the real learning only occurs at the lowest integration rate.

Strategy, Investment, and Timing of Solution Demos

Big systems can be hard to integrate. In order to be able to routinely demonstrate a solution increment, teams must typically invest in integration, testing, and supporting infrastructure. Even then, the extent of integration and testing may be less than 100 percent and may need to vary across multiple early integration points. To assist, teams can leverage virtualization, environment emulation, mocks, stubs, reduced test suites, etc. In addition, some effort for integration and demonstration, and time to invest in the supporting environment, may need to be explicitly allocated during PI Planning.

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

  • Plan to demonstrate just a subset of the PI scope. This may require some configuration management enablement to support the partial demonstration.
  • Leave room in the Innovation and Planning Iteration for this high-level integration.
  • ARTs that broaden their areas of responsibility for integration and testing can create more overlap with the subsystems/capability areas of other trains. Thereby, even the individual system demos offer a better approximation of the fully integrated solution demo.

Finally, the solution itself may be designed to better support integration and testing, thereby significantly lowering the demo transaction cost. Standard interfaces and strictly defined APIs and containers for software are among the elements that 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: 31 March 2016