The system demo is a critical aspect of SAFe for
each PI, but many people 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 critical ART event.
This article is not meant to re-define the System Demo; that’s already been done quite well in the SAFe
guidance article on the System Demo. It provides very clear direction on the
importance and objectives of the System Demo. 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. The System Demo is a great way to
start to change that mindset.
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). This pattern needs to be replicated in some
form in every ART to create the right alignment to deliver on a common
value stream.
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.
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 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 it’s 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 running system demo’s
team-by-team or even story by story, but that's really for the team demo. The
system demo is about showing the entire system and how all teams have
contributed to moving it forward 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 its advanced, combining 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.
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(s),
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,
