Pre-recorded demo?
I recently ran into a team that presented the work done in the Sprint to the stakeholders on a pre-recorded screen video instead of a real, live demo showing the working product increment.
At first, I thought there was some extraordinary technical difficulty with the environment, and because of this, it was impossible to present the real, working software. Later it turned out that this was not the case. "Video demo" is standard practice for this team.
In my opinion, this is a bad practice because the question is not whether there was a moment at some point during the Sprint when the Product Increment provably worked, but whether the team can reliably, regularly deliver a releasable Product Increment (that complies with the quality described in the DoD).
I don't dispute that a pre-recorded "successful" demo can be valuable at the Sprint Review meeting since the stakeholders can also give feedback on the product increment based on a video. However, this kind of approach kicks transparency in the knees because it does not show that there is a real, releasable product. Thus the Product Owner is not in a real decision-making position regarding the release.
Not to mention that it weakens the team's commitment to quality (DoD). It creates a quasi-comfortable situation because the team does not feel the "internal urge" to create a working product increment in every Sprint since they show something on the video that worked there and then.
NOT showing a real, working product increment at the sprint Review compromises transparency.
This practice should be avoided.
Potential root causes behind this phenomenon
There may be several reasons behind this phenomenon (without claiming to be exhaustive):
- There are problems with the quality; not the entire increment works correctly, only a part of it, so they show what works, not what still needs to be worked on.
- The consequence of the first point is that there are leftovers; the team has unfinished backlog items carried over to the next Sprint in every Sprint.
- The team has external dependencies (e.g., integration with a component delivered by another team), and it is not guaranteed that the dependent component works.
- The environment in which the team wants to demo is unstable, i.e., it is not guaranteed that the environment will work during the Sprint Review.
- Fear of bad judgment - the team is afraid that the demo will not succeed (classic demo effect), making them appear in a bad light in the eyes of the stakeholders - especially their managers. The reason for this may be the fear culture, blaming culture, and "no mistakes" culture present in the organization, which kill transparency.
- The team does not understand or does not interpret well the mandatory element of Scrum: a working product increment must be produced by the end of the Sprint at the latest.
SUMMARY
Even though there might be situations when a pre-recorded demo comes in handy, this should be rather exceptional. Transparency is seriously compromised if it's an established practice, and this practice should be dropped.