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

The solution demo presents the combined development efforts of multiple Agile Release Trains (ARTs)—along with the contributions from Suppliers and other solution participants— to Customers and other stakeholders. This demo is a critical event 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 to knowledge. The results of this demo determine the future course of action for the investment in the portfolio.

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. During the PI, ARTs and suppliers should strive to continuously or partially integrate their changes (‘continuouish’ integration).  At a minimum, changes across the entire solution train are integrated to provide true objective evidence on progress and to allow for adjustments (Figure 1).

The solution demo provides essential input to near-term Development Value Stream and Portfolio Level investment decisions. As the only tangible measure of progress, it provides 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, 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 entire 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 [1] 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 their development value streams.

Preparation

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. Since the Solution Train is large and usually distributed, logistics do matter. 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:

• Solution Management
• Solution Train Engineers (STEs)
• System and Solution Architects/Engineers
• Customers
• ART representatives, Product Management, the System Team, Product Owners, and representatives of the Agile 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

Event Agenda

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.

Guidelines

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.
• 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 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 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

Big systems can be hard to integrate. Routinely demonstrating a solution increment requires teams to invest in Continuous Integration practices, 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. The Solution Roadmap communicates the anticipated, demonstrable capabilities for upcoming PIs that align ARTs and suppliers. To reduce the integration burden, they may 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. 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

Last update: 10 February 2021