The System Demo is a critical aspect of SAFe ® to ensure alignment and integration, but many practitioners misunderstand the reason for it and the outcomes we are looking for.  The System Demo is much more (and much less) than what is sometimes practiced, and understanding the goals and ‘better’ practices will help you get the most out of this ART event.

Before I begin, please make sure you have read the SAFe guidance article on the System Demo.  It provides very clear direction on the importance and objectives of the System Demo.  This article is not meant to re-define the System Demo; that’s already been done quite well.  What I want to call out is the importance of making this demo Team Agnostic.  The problem that I have seen quite often is that many ART’s have not fully grasped the importance of a Team of Teams, and still function as a Collection of Teams.  General Stanley McChrystal laid out what a true Team of Teams looks like in his incredible book “A Team of Teams”.  (please see John Pearson’s blog for a great summary)  The System Demo is a great way to start to change that mindset.

System demo organization line diagram with text What we were designed for and What we were facing

Let’s first clarify the difference between the System Demo and the Team Demo (or Team Review). The team demo in SAFe is very similar as in Scrum; as a team we are demonstrating what we were able to accomplish to gain feedback and course correction. It’s not about showing how much we accomplished (it’s not a status report), but rather about showing the progress we made on a given effort so that we can get input on direction and possible course correction.

Three plants at different stages of growth

The system demo is very similar in that we’re really looking for feedback on what we’ve accomplished to gain course correction. We are also looking to measure progress against our team and Program objectives. Just like the team demo, this is not to show that the team is getting work done but much more to show how we’re doing against our stated objectives and helping us to see if we need to pivot to be able to meet these objectives.

The core difference between a system demo and a team demo however is really in the scope and the manner in which the demo is presented. By the very name, system demo, we are showing how far we have advanced the system, not just what each team has done. So from that perspective I believe it vital that the system demo is done team agnostic, e.g not done team by team. I see a lot of ARTs that are demoing team-by-team or even story by story, but that’s really for the team review. The system demo is about showing the entire system and how it has incremented during the last iteration. In fact, the system demo is one of the best ways to show the critical distinction that this is a team of teams, rather than a group of teams. By demonstrating the system and how it has advanced, agnostic of each team’s contribution, we bring the perspective that this is really a team of teams working together towards a common goal and not just a collection of teams.

Humanoid figurine pointing at Agile board of system demo

Another important note is that the system demo is generally presented from the product management to the stakeholders. I see a lot of ARTs that use this opportunity to demonstrate to product management how the system is incremented, but this progress should be discussed with Product Management outside of the system demo and during the iteration. The Product Manager, just like the Product Owner, should see the progress as the system moves forward during the iteration.  This does not mean that the Product Managers are not learning more about the system and providing course correction and direction during the demo, it just means the bulk of the course correction and feedback should be coming from stakeholders,

Please, take this time to look at how your system demo is functioning, and if it is delivering the key elements needed: fast feedback, course correction, and risk/impediment addressing.  If your demo’s are currently team based, try this approach for 2-3 iterations, and then especially for the PI System Demo during the Inspect and Adapt workshop.  Survey and measure the change in the ART, I believe you will see a significant increase in the validity and usefulness of the system demo, as well as see a “Collection of Teams” become a true “Team of Teams”.

A crew team rowing in unison like a functional system demo