Variations:
- During a good Review, developers show everything they have done
- Every backlog item must be part of the Review
- The Review meeting is the (bi-)weekly status report where management gets to inspect the team's productivity
Danger: High
The basis of the myth
There are many people who believe that the Sprint Review is a meeting for management to see what the teams did. Probably the most noteworthy source of misunderstanding is the SAFe4.0 Scrum Master Orientation, which names an event called the "Team Demo" where, quote, "Teams demonstrate every Story, spike, refactor, and NFR".Why is it a myth?
There are some misconceptions about the nature of the product: First of all, the Review is an Inspect+Adapt event for the product, not for the work. Secondly, the 10th agile principle states, "Simplicity- the art of minimizing the amount of work done - is essential.", so teams should actually have done as little work as possible.Assumption #1: "Work done" matters
Neither spikes, refactoring, bugfixing, tests, documentation nor models are customer relevant.
When you go to a restaurant, you don't care if the cook had to run to the nearest gorcery, get fresh vegetables, peel them, cut his finger, run to the doctor, get a tetanus shot and a bandaid, find a helper who can continue the peeling duty ... well, you care that you get a platter of food - preferably one that looks and tastes great.
What matters is tangible customer value. The customer cares about only one thing: "What can I use?" - as such, a Review should focus on the customer's perspective, not on the team's "Done" backlog.
Assumption #2: The team has to justify what they did
As a business owner, I don't care (at all) who did what. I care that I get what I paid for. If I don't get that, then it doesn't matter what the team did - they failed. If I get that, then it doesn't matter what the team did - they succeeded.
Typically, customers do not pay for spikes or refactoring - they pay for a useful product. If the team has no useful product to show, they have nothing to show. And they shouldn't bother inviting stakeholders to show nothing.
Typically, customers do not pay for spikes or refactoring - they pay for a useful product. If the team has no useful product to show, they have nothing to show. And they shouldn't bother inviting stakeholders to show nothing.
Assumption #3: The team is good when they did many things
Coming back to Agile Principle #10, the team is probably not good when they had to do many things. In many organizations, there is a pervasive culture that people should be busy. On the contrary, value creation works best when people are not busy!
Management must abolish the thinking that it's a good idea to track how many things developers did. If the value the team creates is worth the investment, the team is good enough. If that isn't the case - the team is working on the wrong things (i.e. the Product Backlog isn't good enough).
Consequences
Boring Reviews
When teams use the Review to tick off backlog items one by one, people will feel very bored. How often do you plan on attending events where people pretty much waste your time by overloading you with details that are completely irrelevant? Probably not often. Important stakeholders will stop attending, eliminating the entire purpose of the Review.
Lack of feedback
As teams force-feed their "work done" to others, the Review becomes a one-way communication channel. The primary intention of the Review, collecting feedback to maximize the value of the product, will be missing.
Utilization culture
Utilization culture
Once teams feel the need to show their work and the Review focuses on demonstrating as much work as possible, the organization displays a utilization centered culture. As there is only one "center", this idea is contrary to the idea of customer centricity. Teams that learn showing as much work as possible is beneficial will lose sight of the customer and be unable to please the customer in order to maximize output.
Remedies
The Scrum Master needs to work with the Product Owner, teams and management alike to establish a Review that centers fully on customer value.
Questions such as "Why do you think this backlog item is important to the customer?", "Why do you [as a manager] care how the team completed this task?"and "What impact will the presentation of this backlog item have on the future backlog?" help the organization reflect on the current value of their Review meeting.
Questions such as "Why do you think this backlog item is important to the customer?", "Why do you [as a manager] care how the team completed this task?"and "What impact will the presentation of this backlog item have on the future backlog?" help the organization reflect on the current value of their Review meeting.
