Table of Contents
Why Do We Do a System Demo in SAFe? - SSA
One of the base practices in SAFe is the System Demo practice. What I find interesting is that there is also a lot of confusion around this practice, and a lot of questions that seem to come up. This article is aimed at addressing some of these questions.
Before we get started, here is some context:
- We are in a true ART situation; we have a multi-team situation with dependencies between teams and need to have an aligned work effort.
- We have true Features. In other words, most take more than one iteration to complete the work of the Feature or involved multiple teams to get them done. The reason this is important is that if you do not have this, then there will be a lot of overlap between a System Demo and an Iteration (Sprint) Review.
What is the Purpose of a System Demo in SAFe?
The main purpose of the System Demo in SAFe is to:
- Provide a train-level, objective view of the progress of work during a Program Increment by showcasing real, working systems (this supports SAFe principle “Base milestones on objective valuation of working systems”)
- Generate fast feedback for the work so we can ensure we are building the right solution (heading in the right direction), or adjust course if necessary
As such it is a significant event in SAFe. The System Demo literally functions as the heartbeat for the delivery of value to the business. In addition, it is a key mechanism to reduce the risk associated with our plan. Features demonstrated in the System Demo no longer have risk associated with them; we know that they are delivered and there is no question about the functionality.
There is a secondary reason to do a System Demo and that is to provide the opportunity to stakeholders to understand that the technical team is being a responsible steward of resources, that they are focused on the of delivery of business value, and that they really want to understand the needs of the customer. Traditionally the business asks, and the technical team provides. The problem is that this is not always a clear cut discussion, with the result that trust is eroded between the business and technical groups as a result of commitments not met or poorly delivered as a result of misunderstanding. The System Demo is an opportunity to understand what is possible, and course correct if required.
The System Demo is also one of those events where there is a lot of confusion how it works, who is involved, and how it fits in with other SAFe events. The following sections will clarify some of these ideas.
Why do we run a System Demo when we’ve just done a Sprint Review or Iteration (Team) Review?
For many people it seems like we are doing double duty when we run both an Iteration (Team) Review and a System Demo; aren’t they showing the same things? While there is clearly a relationship between is what being demonstrated at these events, the focus for the Iteration (Team) Review and the System Demo is different; Iteration (Team) Reviews demonstrate “done” user stories while System Demos demonstrate “done” features. This has several implications:
- While Iteration (Team) Reviews of stories could be demonstrating progress on features, they don’t show the whole feature when all the stories that make up that feature are complete. The result is that from a Feature perspective, the demo is piecemeal. The System Demo is different in that the demonstration shows the complete Feature, showing the result of work that could have come from multiple iterations and teams.
- If the work a team does doesn’t result in the completion of a Feature for a particular iteration, then their work will not be showcased in the System Demo. This means most System Demos showcase the work of a few of the teams on the train; it is a train event. This is different to an Iteration (Team) Review where teams are expected to demonstrate all stories every iteration.
- The System Demo is based on Features and their related PI Objectives which represent a business value delivered that the customers and the business is interested in. This means that a different level of stakeholders will be interested in the System Demo than those involved in Iteration (Team) Demos with a different level of feedback, and a different set of expectations.
Who is invited to the System Demo?
The following groups of people are typically invited to the System Demo:
- Customers. Especially those who have an interest in the specific items being demonstrated. We want to get immediate feedback to ensure we are heading in the right direction.
- Organizational stakeholders. This includes business owners, others representing the business, sponsors, functional areas in the organization (such as security, sales, marketing, etc.), organization management, and other interested parties.
- The train. It is obvious that people involved in the System Demo would be invited. What might not be so obvious is that everyone on the train should also be invited. This allows people to understand what else is happening on the train; you never know what people will find useful. More importantly it helps develop the understanding that we are all part of the train and that we are collectively responsible for delivering on train commitments.
How do we determine what to demonstrate in the System Demo?
The best way to determine what will be demonstrated in the System Demo is to look at your (up to date) Program Board. The Program Board shows the iteration when Features are expected to be complete, and so it is a simple matter to look in the column representing that iteration on the Program Board determine System Demo candidates.
In this example, we are trying to determine what we will demonstrate in the System Demo associated with Iteration 3.4. The image is color coded with blue representing features, red representing dependent work, and orange representing a milestone. In this case you can see that Team 3 and Team 5 have features that are expected to be complete in Iteration 3.4. These features, and the associated PI Objectives, forms the basis for the content of the 3.4 System Demo. Note that Teams 1, 2, 4, and 6 do not have any features completed in 3.4 and so are not expected to showcase anything in the 3.4 System Demo.
ART Sync (PO Syncs and SoS) events will ensure that the Program Board is up to date.
In addition, since we have the “team (Iteration Review) demos, then System Demo” we can validate whether we have finished all the stories for a particular feature, or not, and so ensure we are working the latest, most valid information about real progress.
When should the System Demo be scheduled?
As noted, the general pattern for System Demos is “team Iteration Review, the train System Demo”. Systems Demos are usually set up on a cadence just like team Iteration Reviews. So, for example, you might set up a System Demo “one week after the Iteration Review”. The use of a cadence here is a forcing function to ensure that we build an integrated solution and so can truly understand the progress of the solution we are delivering; we see a working system.
At a minimum the System Demo for this iteration should be completed before the end of the next iteration. Over time, because of investments in automation in the CI/CD pipeline, we should be able to bring the System Demo closer and closer to the Iteration Review. This usually means the train is improving their ability to deliver (reduce time to market, improve quality).
What is the typical agenda for a System Demo?
In general, you want to time-box a System Demo to be about an hour long. Again, the purpose is to establish an objective milestone of progress toward PI Objectives, and to generate feedback on key items. It is not to showcase how busy the train has been.
A typical System Demo agenda will call for the following elements:
- (Brief, and if required) Review of the Purpose of the System Demo
- (Brief) Review the business context of the System Demo
- (Brief) Review what happened to the feedback from the last System Demo
- (Brief) Review of current state of the Program Board, and any changes that have occurred since the last System Demo
- (Brief) Review features to Demo
- Demo of each of the features
- Describe the Feature and the related PI Objective
- Do the Demonstration
- Q&A and gather feedback
- Summary of key metrics
- Features completed vs expected
- PI Objectives completed vs expected
- Wrap up with
- Summary of what was heard and what will be done about it
- Expectations for the next System Demo
In general, the Product Management team will determine the best order for the demonstration.
What tips and tricks do you have to make a good System Demo?
Here are a couple of ideas on how to have a great System Demo:
- As you work a Feature make sure you are constantly asking yourself about the System Demo. For example, during feature analysis and PI Planning yourself “how will we demonstrate this feature to get feedback?” And as the team works on stories associated with the feature they should reference the feature to ensure they understand expectations, including how the feature is to be demonstrated.
- Make sure you use the context of the feature, the business hypothesis and the acceptance criteria as a “script” for the demonstration. Since these are written from a user’s perspective, and since they represent the business need, this approach will help with communication and ensure we do not get lost in the technical details.
- Make sure you talk about what happened as a result of the last System Demo. If feedback was provided, what changed as a result of that feedback? If nothing changed, why not. This way people will be encouraged to provide feedback.
- Make sure you talk about overall progress toward the objectives of the PI. Be honest: if you don’t think something is going to be complete tell people about this as early as you can. If the metrics are not looking “good” show the metrics and talk about what you are learning and changing as a result. As they say “bad news doesn’t get better with age”. We want to provide data to the business as early as we can so that we can determine what adjustments need to be made.
- Be enthusiastic! Be celebratory! We are delivering value to customers and this should be celebrated.
What Anti-patterns Do You See with the System Demo?
- Not having a System Demo
- A System Demo that is just the Team Review as a combined meeting
- No feedback from participants in the System Demo
- The content of the System Demo “surprises” the Product Management team
- Great demo, but no one knows where are up to in the PI
- Or System Demo doesn’t show metrics of progress
- System Demo is not showing the work on a single “close to production” system
- System Demo only talks about Features and does not reference PI Objectives
- The System Demo is more a PowerPoint presentation or discussion than a demonstration of real working software
- Related, the System Demo doesn't use real data and real scenarios, but rather test data, to show the working system
- System Demo does not talk about what happened to the feedback that was previously provided
- Spending too much time preparing for the System Demo
- Team members of the ART are not invited to the System Demo
Want to Know More?
- How Can We Improve The Quality of Feedback at a Iteration Demo (Sprint Review)? - Talks about Iteration Review but some of the same thinking can be applied to the System Demo.