Agile development teams, work in small iterative cycles, continually delivering incremental features. Each cycle prompts self-reflection and actively seeks to improve the team’s efficiency. In principle, this is the perfect solution to developing quality software. Iterative feature releases via a transparent roadmap. But what is the point of transparency if no one looks and why have agility if no one changes. Suppressed iterative self-reflection over time, just becomes stagnant. Without feedback from outside the team, we end up delivering the wrong products whilst exceeding budgets and deadlines.
In the classic movies, bad guys were always dressed in dark menacing clothing, had great dastardly quotes and over acted in pseudo nasty scenes. Throughout history though, both sides always stated they had a righteous plan and neither saw themselves as baddies.
Developers are often seen as the bad guys of software delivery. It’s as if the end user envisions a scruffy developer, delivering an evil cackle as they purposefully and conspicuously hide bugs within the software, delay releases and intentionally deliver useless features.
We can retrospectively identify, as with the vision of bad guys throughout history, that views and opinions are not often comparable with reality. It could be said that inaccurate views and opinions are detrimental to productivity, and instead unbiased and constructive feedback must be utilised, if we are to facilitate efficiency.
The Three Musketeers, a trio of sword wielding heroes, won battles and admiration under the unity of their motto, “One for all, All for one.”. Their loyalty and belief in each other and themselves were of the highest value.
Scrum also commands such unity. Scrum is built upon 3 pillars; transparency, inspection, and adaptation. An all visible transparent process, with timely checks on progress and the ability to adapt quickly to change. The sprint review is fundamental in supporting these pillars. The review acts as the stated point of inspection, it expects feedback for adaption and is delivered with complete transparency. To facilitate these pillars, a Scrum team upholds 5 core values, known as the Scrum Values; Focus, Openness, Respect, Commitment, Courage. When a Scrum team absorbs and upholds these values above all else, then they are unstoppable.
For feedback to be true and valuable, then it too must abide by the Scrum Values. It is important that the reviewers understand their role in the review, especially if they are stakeholders.
Most of us have been shopping with our partners and received that ominous and pointless question, “Does my bum look big in this?”. There is no correct answer. We lose on all fronts. The Agile sprint review can often fall into the same hole. The sprint review is often perceived as a demonstration session. This is what we did, and we are going to release it tomorrow. Do you like it? Or, “Does my bum look big in this?”. Although structured as a question, this is more of a statement with dire consequences. If the reviewers don’t like it, then the developers get upset. No happy or progressive result, often meaning that people are reluctance to participate or feedback.
Better communication can be achieved by asking instead of telling. Think about open and inviting questions. Such as, “How could a user add notes?”, is better than, “Users won’t like it because adding notes is ultra-important.”.
A Sprint Review should always be at the same time and in the same place to ensure that it is easy for reviewers to attend. Ideally, the reviewers should understand exactly what is being reviewed upfront, so that they can prepare themselves. This context and vision should be reiterated and enforced at the start of the review. So often a review will commence with the actually developed features, without any context and scene setting. By understanding value and reason, a reviewer can direct appropriate questions.
Throughout the review, maintain eye contact and move forward at a steady pace. Mumbling into the laptop will alienate the reviewers, whilst conversations off topic will lose context. Additional meetings can always to arranged by the Product Owner to discuss detailed points or any off-topic confusions. It is important that the development team and reviewers make a unified connection and that all reviewed items are understood, value quantified, and feedback inspired. Opinions which facilitate inspections and adaption are imperative.
All Scrum teams are required to deliver potentially shippable features, at the end of each sprint. During the Sprint Review, only the completed features are assessed against the sprint goal and committed stories, to clearly identify if the sprint was successful and the formulate plans to adjust the backlog accordingly.
A sprint review is defined by inspection and adaption. Review what has been delivered and ensure that the backlog reflects the unified vision. But, so often a sprint review forgets to listen to the feedback, placing us back at a point where we are merely demonstrating new features. Instead, at the close of the review, it is imperative that all points are concisely and verbally summarised, the product vision is reiterated, and the reviewers invited to assist with adapting the product backlog. This will ensure that everyone feels that their feedback is valued and that they are part of the product vision.
We should all be on the same journey together. This improves perceived interest and results in credible and valuable feedback. Early feedback, results in a quicker response and greater satisfaction. Mick Jagger sang, “I can't get no satisfaction”. Maybe he just needed a sprint review and early feedback.
Effective sprint reviews should:
- Be clear.
- Be informal.
- Be concise.
- Be honest.
- Set context.
- Clarify value.
- Review only what is achieved and assess this against the committed work and sprint goal.
- Uphold the Scrum values.
- Give feedback to help drive towards a shared goal.
- Inspect the Increment