Whether your team follows a specific framework or has taken a mix-and-match approach with its practices, a tenet of agile is the use of short feedback loops to support inspection and adaptation.
Whether your team sets a regular cadence for external product reviews or they are conducted on a just-in-time basis, it is important to get actionable feedback. But conducting a review is not just a matter of bringing people together.
While there are probably more than just these ways of messing up reviews, here are seven which I’ve witnessed.
- The only attendee is a Product Owner (or similar role representing the voice of the customer). While we expect that Product Owners are knowledgeable, their feedback is one step removed from that of real external stakeholders. The Product Owner can judge whether the product is meeting needs, but the team loses the benefit of asking questions such as “What new ideas for the product does this feature give you?” or “How could we make this feature add more value to you?“. In addition, Product Owner feedback should be received by the team on (ideally) a daily basis rather than having a special event just for that purpose.
- Cramming too much into a review and not allowing stakeholders sufficient time to digest what they’ve seen. As teams get better at delivering, they might be able to complete more work in the same amount of time. In such cases, the frequency of external reviews should be increased so the content reviewed is less and the content covered should be organized in some prioritized order.
- Holding a demo rather than a two-way exchange. If the only purpose of a review is to show what the team has completed, that could be recorded and provided to stakeholders to watch at their leisure. The real value of a review is the rich back and forth discussions which happen between team members and stakeholders and between different stakeholders based on what they are seeing. Using powerful, open-ended questions is one way to ensure that the knowledge sharing doesn’t just happen in one direction.
- Having the wrong people in the review. It is almost as bad to have the wrong external stakeholders in the room as it is to have none. If personas are being used to facilitate requirements discovery, there should be representation for each persona if the content of what’s being reviewed impacts them. And because a review is a working session and not just a forum for sharing information, we don’t want to have too many people in the room either.
- Making commitments during the review. It can be tempting for a team member or the Product Owner to try to curry favor from a powerful external stakeholder by committing to a specific product change or to a release date, but this is not the right forum for it. Desired content and target dates can be captured but the Product Owner and team should take the time to understand the impacts of such changes.
- Open criticism of the team’s work. It is natural for an external stakeholder to get frustrated if their expectations weren’t met for the content being reviewed. Such feedback is crucial to help the team improve over time. But if that criticism is provided in an abusive manner, the team’s morale and productivity will take a hit.
- Not taking sufficient time to analyze what was learned during a review. If we are using up valuable stakeholder time, it behooves us to use their feedback well. It might be convenient to hold a retrospective or similar event immediately after a review but this might not allow the team and Product Owner the time required to properly digest the feedback they received.
Well-run reviews are a key ingredient of building the right product for our customers, so avoiding these seven sins will go a long way to getting real value out of these critical events.
(If you liked this article, why not pick up my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores)