The team has worked as creatively as possible, building a product increment that exceeded what it committed to in the sprint planning meeting. At the sprint review, the team proudly presents the increment to the Product Owner, stakeholders, and senior management. Senior management is present to support the overall Scrum concept. At the end of the presentation, the entire audience breaks out in applause.
What is wrong with this picture?
First of all, the sprint review is not a presentation. It is also not a time to sell Scrum. Neither is it a time for senior management to show their support. All of these are good, valuable activities, but all interfere with the true purpose of the sprint review. The sprint review is designed to be the Product Owner’s inspect-and-adapt point for optimizing return on investment. Based on the Product Owner’s goal, he or she inspects and adapts what has been built. In consultation with the team and other significant stakeholders, the Product Owner then restructures the product backlog for the next sprint. The purpose of the sprint review is to cause this interaction between the Product Owner, the people he or she represents, and the team. Collaboration, further exposure of salient information, and brainstorming should occur so that decisions are made with the best information possible.
Turning the sprint review into a presentation lowers the probability that the adaptation will optimize return on investment by taking away the time needed for this work. Worse, if the team starts seeing the sprint review as a presentation, it will start presenting. PowerPoint slides will be prepared, conference rooms will be reserved, and the team members will dress up. The team will stand at the front of the conference room, with everyone else seated, ready for the presentation. Everyone will enter into the dynamics of a meeting, where the presenter tries to be perfect and the audience tries to be constructive and critique what they are seeing. This has very little to do with the need for collaborative decision making.
Secondly, the sprint review is not a time for judgment, so please, please never applaud. Doing so implies that what the team did is good. The point of empirical process control is that that team does what the team does. The team commits at the start of the sprint and then—based on the complexities and unexpected circumstances during the sprint—does what it can. As the team progresses, sprint by sprint, the commitments may match more closely what was completed, but there are always surprises. At the end of the sprint, the Product Owner has a point in time to inspect and adapt based on what was done. To do so, transparency is required, as much as possible. If a team feels it is being judged, it may not be as forthcoming as it should be.
Moreover, it is human nature to want accolades; once heralded, the team will start working to gain more. If applause occurs when the team does what or more than what it commits to, it will always try to show this at the sprint review—no matter that it has to work overtime (and cut quality) or just cut quality to do so. The team becomes an applause pig. The team does this because the opposite of applause is approbation. If completing all of their tasks was good, they think, not completing what was committed to must be bad. Nothing could be further from the truth. Not completing all the tasks in an iteration may not be what one would hope for, but inspect-and-adapt’s purpose is not to support hopes, but to help people make intelligent decisions that optimize the opportunity to achieve hopes and goals.
At your next sprint review, put away your laser pointers, focus on collaboration, and by all means, keep your hands tucked under.
