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 solution demo is where the results of the combined development efforts of multiple Agile Release Trains (ARTs)—along with the contributions from Suppliers and other solution participants—are shown to customers and other stakeholders. This demo is a critical time for the Solution Train, an opportunity for 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 to knowledge. Results of this demo determine the future course of action for the investment in the portfolio.
Solution Demo as a ‘Pull’ Event
As the quote at the top of this article suggests, the solution demo is a deliberate, mandatory, and high-profile ‘pull event.’ In other words, it pulls together various aspects of the solution and helps ensure that the ARTs and suppliers are creating an integrated and tested solution, fit for its intended purpose. In this way, it accelerates the integration, testing, and evaluation of the solution under development—something that’s all too easy to defer until too late in the development lifecycle.
Within a portfolio, Enterprises sometimes create even larger pull events, during which several Solution Trains come together for a ‘roadshow’ of their accomplishments (see  for example). There, the senior managers, stakeholders, and other portfolio fiduciaries review the progress in the broader portfolio context and make decisions about the continuation (or cancellation) of initiatives. Or, they might decide to make changes to the investment in the value streams.
Such a critical event requires preparation, which often begins at Pre- and Post-PI Planning, where the results of the most recent solution demos are available. Those results inform the people staging the demo on what specific capabilities and other aspects of the solution can and should be demonstrated. Also, even though the solution demo may not have a large group of attendees (scope considerations usually prevent most development team members from attending in person), logistics do matter. Those who do attend are important to the value stream supported by the solution, and attention to logistics, timing, presentation format, and professionalism enhances the experience. It may even influence the outcome.
Attendees for a solution demo typically include:
- Solution Management
- Solution Train Engineers (STEs)
- ART representatives, Product Management, the System Team, Product Owners, and representatives of the development teams themselves (to experience the customer feedback firsthand)
- Lean Portfolio Management (LPM) representatives
- Large Solution SAFe stakeholders, executive sponsors, and senior management
- Deployment Operations representatives
A typical event agenda includes the following activities:
- Briefly, review the Solution Train PI Objectives for the PI (10 minutes)
- Demo each PI objective and capability in an end-to-end use case (30 – 60 minutes total)
- Identify business value completed for each PI objective
- Open 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. 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 one-hour 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 other stakeholders can attend each other’s demos to get a less formal demo and provide informal feedback.
Here are a few tips to keep in mind for a successful demo:
- Timebox the demo to one to two hours. Any longer and the attention of the stakeholders is lost. Sticking to the allotted timebox demonstrates professionalism, respect for people’s time, and solution readiness.
- Share demo responsibilities among different lead engineers and team members who have new capabilities to demo.
- 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 last bullet point is particularly critical, as different solutions may have varying degrees of coupling with their solution context. In some cases, 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), then the isolated approach is inadequate and may even be misleading. In this case, the solution should be demoed in an environment that is fully representative of the 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
Big systems can be hard to integrate. Routinely demonstrating a solution increment requires teams to 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 integration points. Often critical components of the solution are not ready, and teams leverage virtualization, environment emulation, mocks, stubs and reduced test suites to demo the completed parts. Also, some effort for integration and 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 just a subset of the PI scope, which may require some staging and configuration management to support the partial demonstration.
- 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 itself may be designed to better support integration and testing, which significantly lowers the demo cost. Elements 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 Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
Last update: 27 September 2019