Sprint review demo is a well-established practice for many teams striving for agility in their process. There are obvious reasons for conducting demos. For instance, you can get feedback from the product owner and provide a boost in team motivation. However, demos also provide an opportunity for more subtle, long-term benefits.
To clarify, we’re talking about presenting a product increment during the internal development phase, not about a presentation of a polished product to an external audience (e.g. at a conference). Obviously, some aspects mentioned here will be shared in any kind of product demonstration.
In my experience, demos are a great opportunity to learn. You learn how to explain things better, how to give a smooth performance, and what actually makes the stakeholders tick.
Presentation skills are the most obvious aspect. You practice, you learn. This is why it’s worth encouraging different people to give demos over the course of the project. Don’t just have the same person do it over and over again unless you need to put on a show to delight the stakeholders – if that’s the case, it’s probably best to pick your most compelling presenter. At Objectivity, sprint demos are conducted by people in various roles: business analysts, technical architects, developers, testers. Running demos can be stressful and requires a skill-set that’s not on the radar of many people in technical roles.
The first thing you learn quickly is that it’s not easy to prepare a smooth presentation. Without dry runs you’ll make mistakes, stall, go overtime and have trouble providing context. Without backup environments, your demos will fail utterly. If you don’t test videoconference equipment, the demo will often get delayed due to technical issues which are much more frequent than we like to admit. In other words: there are a lot of details you need to get right to make a smooth demo. It’s also hard to recover from a bad start.
The next benefit is that people will realise that others often have no clue what they are saying. The reason is that project stakeholders are often non-technical, and it’s not trivial for a technical person to come up with the right kind of introduction that will be both short and approachable. The reality is that you need to provide a lot of context to the person listening to you if you don’t work with them on a day-to-day basis. It’s important for the audience to help with this; i.e. the product owner and other stakeholders must be proactive and ask questions when they don’t understand what’s being said. It is all too common that people sit quietly in meetings even though they are no longer following the conversation. As a presenter, you do have influence over their behavior. Before the demo, you can invite your team to interrupt you and ask questions. When the demo starts, invite all participants to engage in a dialogue. This should make it more likely that they will speak their mind.
Another level of learning happens during discussion about the product increment. When this happens, people who are emotionally invested in the project will help sell it to the more distanced stakeholders; they will explain difficult design decisions and defend the project if necessary. This is something they probably do anyway on a daily basis but, in my experience, it can be a great moment for the team to witness how much these people care about the project and how well they can speak about it, even if the development team hasn’t heard it before.
Sometimes people find it hard to explain why certain features were really built. Demos can provoke discussions about the rationale for certain features, helping detect ‘featuritis’ and giving further insight to the product owner, development team or other stakeholders about the real priorities of the product.
Another set of benefits is less tangible and centers around awareness and influence. If you run good demos, your team will become progressively more respected within the client’s organisation. This can help the delivery managers on the client’s side to gain influence (and thus serve the needs of the team better); it also allows individuals to become recognised for their work, which for certain roles, helps to improve their relationships. If the infrastructure you are using is particularly bad or good, the client will have a chance to notice this. This can be useful if your client fails to recognise the impact of poor infrastructure on your work.
It is up to you to balance out how much you want the demo to be a show (in which case you’ll pick the best presenters) and how much you want less experienced individuals to share responsibility and develop their soft skills.
We’ll look at specific tips for novices, which can help you run a great demo, in the next blog post – a checklist for smooth demos.