Lean-Agile
Coaching and Training
Other
-
- Also some Useful Tools
Note that we have some Incomplete Pages That Require Work on this site:-)
Note that we have some Incomplete Pages That Require Work on this site:-)
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:
The main purpose of the System Demo in SAFe is to:
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.
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:
The System Demo is scheduled on a cadence. The typical pattern for Systems Demos (and the guidance from SAFe) is:
In general there are three key roles that orchestrate and facilitate the System Demo:
The following groups of people are typically invited to 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.
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).
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:
In general, the Product Management team will determine the best order for the demonstration.
Here are a couple of ideas on how to have a great System Demo: