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 development efforts from the Solution Train (e.g. multiple Agile Release Trains (ARTs) and the contributions from Suppliers) are integrated, evaluated, and made visible to customers and other stakeholders.
For a Solution Train, the solution demo is the apex event of the Program Increment (PI) cycle. This is where the results from all development efforts of multiple ARTs—along with the contributions from Suppliers and other solution participants—are shown to customers and other stakeholders. This is the most critical time for a fully-integrated, Solution-level demonstration; a time 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 the solution demo determine the future course of action for the major solution investment in the Portfolio.
The Solution Demo is a repetitive, major occurrence in the life cycle of a Solution. High-profile stakeholders come together during this cadence-based event to assess the progress the solution has made during the past Program Increment by evaluating objective evidence. During the solution demo development teams demonstrate the solution’s new Capabilities, its compliance with Nonfunctional Requirements (NFRs), and its overall fitness for purpose. Key stakeholders—typically including Solution Management, Architects/Engineering—and, whenever possible, customers—participate and provide direct feedback and observations.
The importance of the Solution Demo cannot be overstated. It is a showcase providing essential input to upcoming value stream and Portfolio investment decisions. The only true measure of progress, it mitigates investment risk for the solution.
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 Agile Release Trains 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 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 Reference 1 for an example). There, the 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, 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 System Demos are available. Those results inform the people staging the demo on 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 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 Level stakeholders, executive sponsors, and senior management
A typical event agenda includes the following activities:
- 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. A common 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 solution 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. This is critical to hold the attention of key stakeholders. It also demonstrates professionalism, respect for people’s time, 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 last bullet point 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 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 demonstrated 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 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. 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 allocated during PI Planning.
As for timing, the solution demo may lag 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. This may require some staging and configuration management to support the partial demonstration.
- Leave room in 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/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 transaction cost. Elements such as standard interfaces, strictly defined APIs, and containers help teams spot problems and inconsistencies early on. This makes 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: 5 June, 2017