System demos are an essential part of agile development, as they provide an opportunity to showcase the value and progress of the solution to the stakeholders, customers, and users. They also enable feedback and collaboration, which can help improve the quality and alignment of the solution.
However, not all system demos are effective or beneficial. There are some common pitfalls and bad practices that can undermine the purpose and value of system demos. These are known as **anti-patterns**, which are recurring solutions to a problem that are ineffective, counterproductive, or harmful.
In this article, we will explore one of the most common anti-patterns related to system demos and how to avoid it.
Contents
Team demos instead of system demo
One of the common anti-patterns related to system demos is having team demos instead of a system demo. This means that each team on the agile release train (ART) presents their own demo of their features and functionalities, without integrating them into a coherent and comprehensive view of the whole solution.
This anti-pattern can have several negative consequences, such as:
– **Lack of visibility and transparency**: The stakeholders, customers, and users may not be able to see the big picture or understand how the different features and functionalities work together to deliver value. They may also miss out on important dependencies, risks, or issues that affect the solution as a whole.
– **Lack of feedback and collaboration**: The stakeholders, customers, and users may not be able to provide meaningful feedback or suggestions on how to improve the solution, as they only see isolated parts of it. They may also not be able to collaborate with each other or with the teams on the ART, as they do not have a shared understanding or vision of the solution.
– **Lack of quality and alignment**: The teams on the ART may not be able to ensure that their features and functionalities are compatible, consistent, and compliant with the standards and requirements of the solution. They may also not be able to test and validate their features and functionalities in a realistic and production-like environment, which can lead to defects, errors, or failures.
How to avoid this anti-pattern
To avoid this anti-pattern, it is important to have a system demo instead of team demos. A system demo is a demonstration of the integrated and complete solution that is delivered by all the teams on the ART over the past iteration. It provides an objective measure of progress and value, as well as an opportunity for feedback and collaboration.
According to Scaled Agile Framework, a system demo should have the following characteristics:
– It should take place at the end of every iteration, as close as possible to the iteration boundary.
– It should show all the features and functionalities that were developed by all the teams on the ART over the past iteration.
– It should test and evaluate the complete solution in a production-like context (often a staging environment) to receive feedback from stakeholders.
– It should involve Business Owners, executive sponsors, other Agile Teams, development management, customers (and their proxies), and other relevant stakeholders who can provide input on the fitness for purpose for the solution under development.
– It should last no more than 15 minutes per iteration.
To prepare for and conduct a successful system demo, it is recommended to follow these steps:
– Establish a clear goal and agenda for the system demo, based on the iteration objectives and acceptance criteria.
– Ensure that all the features and functionalities are integrated into a single solution that can be deployed and tested in a demo environment.
– Assign roles and responsibilities for presenting, facilitating, observing, recording, and providing feedback during the system demo.
– Practice and rehearse the system demo before presenting it to ensure that it runs smoothly and covers all the relevant aspects.
– Invite and engage all the relevant stakeholders who can provide feedback and collaboration during the system demo.
– Collect and analyze feedback from stakeholders after the system demo and use it to improve future iterations.
Conclusion
System demos are a vital part of agile development, as they provide an integrated view of value and progress for stakeholders, customers, users. However, they can also be prone to anti-patterns that can reduce their effectiveness or benefit. One of these anti-patterns is having team demos instead of a system demo. This can lead to lack of visibility, transparency, feedback, collaboration, quality, and alignment. To avoid this anti-pattern, it is important to have a system demo that shows all the features and functionalities delivered by all the teams on the ART over the past iteration in a production-like context. This can help achieve better outcomes for both customers and teams.
