Inspect & Adapt Demo Special: Practical Tips for Your System Demo

By Gerben Kollaard

Introduction

In the world of Agile, the Inspect and Adapt (I&A) event stands as a pivotal moment for teams to reflect, learn, and refine their processes. Within the Scaled Agile Framework (SAFe), this ceremony takes on added significance, serving as a platform for continuous improvement at the enterprise level. One part of the I&A is the System demo, which is a critical event and the real measure of progress at an ART-level.

As we have already seen in the Common Failures blog doing a System demo in the right way isn’t that easy. The demo is often to ‘technical’ and not shown from the a business perspective.

In this blog we will zoom-in on the System Demo, trying to help you making your System Demo better.

Who & Why?

Let’s start with the theoretical and technical information about the System Demo. The I&A System demo is a little different from the regular system demo after every iteration. The scope is broader, not one iteration but a whole increment, so also the audience is broader. The system demo should??? -just as the I&A- be for all the stakeholders. To be more precise you can think of the following stakeholders: Business Owners, Customers, Executive Sponsors, Product Managers, Product Owners, Portfolio representatives, IT operations and ART team members. They should all see the progress of the ART made last PI. Why? Because the demo is the objective measure of progress and the opportunity to give feedback on ART level.

Best Practice System Demo

In the best practice blog, we already discussed some practical tips and best practice of the system demo:

1. Let the business owners/users run the System Demo: letting the users run the system demo will make the demo more understanding for the rest of the audience which will also help on giving feedback and will improve the involvement of the user-group. Letting the business owners run the system demo will not only help with all of the above, but also will give the signal that the System Demo is really important.

The System Demo article on the SAFe website subscribes sharing the demo responsibilities among team leads, Product Owners and team members. Letting the business owners or a user run the System Demo goes a little bit further, but it will emphasize the importance of de value delivered.

2. Do something with the design of how you do your System Demo: Looking at demo’s is intensive, so variate the way of doing the demo. For example: let the Product Owner Pitch his Demo and let the audience choose or organize the demo’s in market style.

Again supported by the System Demo article on the SAFe website: design your System demo with a good preparation (minimum slideware), no longer than one hour and a level of abstraction high enough to keep all stakeholders actively engaged. Designing the System Demo as total part of your I&A, you can keep the I&A principles in mind: Adapt to your environment and train needs. Thematise and use engaging practices to make it more fun.

3. Demo value instead of technology: as a best practice, you should focus on showing the added value and things users can actually provide feedback on. Which often is very hard and teams love to share all the technical cool stuff they did to create the business value. If it’s hard for a team to provide a demo ‘because all the things we did were technical’ use a persona to tell with they did, why it was so hard and show the end-state users recognize. ?

Of course with user interfaces it easy to show something user will recognize and will be able to give feedback. But when the value delivered is less visible invest in showing the business value in a fun way. For example with a huge data migration: make a movie with the team and let them physically move boxes from point A to point B which represents all the products they are moving from system A to system B, how hard it is to do it correctly, what can go wrong if they make a mistake and which counter measure they have built to prevent mistakes from happening. Emphasize that the value delivered in this case is correct data. ?Users will be engaged and provide valuable insides on which data is really important to them (and they expect a counter measure on to make sure things go well).

Another example is with a rationalization of an old IT-system. Using a persona to give the integrated view between teams that are working on building collection the data from the old system, designing the new system and building the new system. In this case the persona was a ‘bad character’ that wanted to blow up the old system.

Besides the best practices from the earlier blog, there are some more:

4. Preparation of the System Demo: because the System Demo is such an important event for the ART and the attending stakeholders a good preparation is recommended. There are several parts to consider: putting together product owners and the product manager to brainstorm about the integrated view of the product to show, doing a small dry-run of the demo the day before the System Demo and doing a check on the audio and visuals in the venue the demo takes place. It’s all part of professional investment in this event. But do not overdo the preparation, the software should already be working, it should already be integrated, do not make 20 slides beforehand because you should just show the working solution!

5. Process during the System Demo: So it’s about showing a working software. Mostly you start with a small introduction that emphasizes the business value delivered. Showing the delivered solution is one thing, but receiving feedback on it is key. A System Demo with no interaction and no feedback is very expensive from a economic point of view. Getting interaction and feedback is something you should be focussed on during the System Demo. Ask the presenter questions, ask the audience for questions or simply repeat the showed value delivered will help you foster interaction. Also make sure the System Demo meets the timebox from one hour.

6. After the System Demo: It’s maybe a small point of attention but make sure that after the System Demo is done, the points of feedback are addressed by the product owner, product manager or the team. It’s closes the feedbackloop on the ART level progress.

Conclusion

The System demo is really a key event for the ART and its stakeholders. It touches the SAFe core value of transparency: building trust and open communication. It touches the core value of alignment: aligning the common langue of progress and connecting strategy to execution. And if you ask me, it also touches Respect the People: showing respect to the people doing all the work. Make sure you show that respect.