Is this a known pattern to you? On the last day of a Scrum sprint a team is busy preparing for the review. They know, some important stakeholders and also some bosses will be there. Hence they work hard on fixing final issues, preparing clean test data and some intro slides. When I coach such teams, I get out of their way. But I will give them a couple of questions about their ideas for the sprint review later.
Purpose of Sprint Reviews
While it can be a challenge for the team to face the truth in front of stakeholders and bosses – maybe something not working, looking unprepared, not everyone knowing all features well – this should actually be not an issue at all. The main purpose of a sprint review is not here for proving, what a team or even individuals did. It is about inspecting, where we currently are in terms of our goals, setting the baseline for learning and making new decisions. This means, what we are after, is feedback on the real situation, not feedback on anything faked. It is not about making stakeholders or bosses feel happy or safe. It is mainly about their honest feedback – subtle, but powerful difference. Whatever doesn’t work, helps us learn. And if we only had a nice demo, this was not enough. A good sprint review led to at least one change in the backlog. Something existing needs adaptation, some new ideas came up.
And if it’s about the learning from the real status, then nearly no preparation is needed. Slides don’t help to learn (we will finally not deliver slides to customers). We hopefully always run an integrated product version. Picking up the latest build, all tests green, test data available, no problem (by the way: this sounds something like Agile Fluency). The product owner does not see any new feature the first time. We might have had a sprint goal, some experiments, hypotheses. So we don’t need to prepare. We run the demo right from the place, where everything happens – directly from the rooms, where teams regularly work and meet. Where the new product lives and grows up.
Flaws of Sprint Reviews
In reality this often looks different. There is quite some distrust, that teams would not work hard enough, their velocity does not go up, the quality is not enough. Hence the organization engages a more rigorous process for sprint reviews, which might rather appear like control. Fear is in the air. It is more about justification, what we did over the past weeks. And there is quite some preparation effort for each review. Not to forget a not so fluent implementation process leads to even higher efforts. Product owners see some new stuff the first time during the review. And important stakeholders, whom we might provide feedback, never make it to the meeting. Finally the review ends up with more or less satisfied participants, but apart from this no true learning happened. No hypothesis validated, no changes to the backlog. Do some of these points sound familiar?
Making sense
Sprint reviews are checkpoints against our objectives. Hopefully we had some goal and even some hypotheses for validation before starting the sprint. At least we want to learn from running the sprint and delivering at the end. A review is the ultimative collaborative learning point within a Scrum process. There are many more of these. But this one is a minimum starter. In order to make a review work, we have to get literally out of the building with what we created so far. No gold plating, but learning – learning, if what we have so far, makes sense for the customer. If its about justification there can’t be learning. We also need a good chance for failure in order to learn, how to make a difference. Hence the option to learn has to be built upon hypotheses together with corresponding experiments. Hypotheses, experiments and validation will hopefully already taken care for before actually creating the solution. However, even after the sprint, validation is still in the middle of interest. This will open potentials for dramatic improvement on the product, value creation for customers. And this finally enforces a trust base within the system, the hierarchy, the network of stakeholders.
So how to go ahead in order to make sense of sprints?
- Do involve product owners during the sprint for feedback. For sprint review its then no surprises anymore, not a demo for justification. But a demo for triggering a dialogue between stakeholders, for generating new collaborative feedback.
- Do run a review directly from your working environment. No need for preparation, as you anyway take care for an always running system, ready to be used together with some test data.
- After the review do get out of the door at least with one change, a new item on the backlog, or a bigger one split into more concrete ones, maybe some items de-prioritized or even dropped. Maybe an need for a new experiment.
- And if you really want to briefly showcase some status to a larger group of stakeholders (e.g. to executives), reserve a timeboxed amount of the review for this. Maybe the first 15 minutes at the beginning, after which the real review will start.
Let’s face it – do your sprint reviews work? Do you really make a learning out of it? Is your process fluid, so you can easily accomplish your reviews?
- Weshalb gibt es kein Developer Team mehr in Scrum? - November 14, 2021
- Agile– Aber bitte nicht die Change Kompetenz vergessen! - September 19, 2020
- Agile Leadership. Focus on the Core and without Dogma - July 25, 2020
