Be PROUD: Make reviews great (again)
Why regular reviews matter, and how to get the most out of them.
To review, or not to review, should not be a question
The team was put under pressure to deliver to a challenging deadline. The PM was put under pressure to drop any unnecessary meetings and to get everyone heads-down. She wouldn’t budge on the need to have regular stakeholder reviews. The challenge came back:
Calendars are already-stacked. There’s no slack in the plan. How do you justify taking time from people's days to carry out progress reviews?
“In short“, she responded, “because the payback is huge.“
Regular reviews enable teams to:
Stay aligned with the company mission.
Remain focused on delivering the best outcomes for their customers.
Ensure stakeholders are bought in to the work of the team.
Without regular stakeholder engagement, you may think you’re driving forward, but team drift is inevitable, manifesting as:
Unproductive meetings, which are often rescheduled or cancelled.
Lack of team clarity of purpose, leading to duplication of effort or rework.
Unresolved interpersonal conflict.
Lack of context, so the team doesn't understand what success looks like.
Poor stakeholder engagement.
Why is it hard?
Apart from the aforementioned stacked calendars, teams can struggle with reviews for a variety of reasons, including:
Workflow.
Stakeholder engagement.
Confidence.
Lack of structure.
Let’s look at each of these in more detail.
Workflow
Teams that follow Scrum will generally do a Sprint Review at the end of every sprint. Teams following other frameworks, such as Kanban, may not understand the value of regular reviews. I’ve worked on teams through long-lived projects where the punctuation of a fortnightly review has reassured everyone involved that the team is making progress. Before their introduction, it felt like the team made endless effort but little headway because of the long-term nature of the problem we were trying to solve. Adding a regular review enabled us to celebrate progress, while creating an early warning system if we were deviating from our goals.
Workflow, however, is irrelevant if you don’t have stakeholder feedback.
Stakeholder engagement
Sometimes, stakeholders are not sufficiently engaged with the team and reviews don’t happen because of a perceived lack of interest or support. This robs the team of the opportunity to inspect, learn and adapt.
If your stakeholders aren’t turning up for reviews, approach them separately and ask if there’s a better time for you to hold reviews so they can come. Ask them for feedback. Listen to their concerns without judgement, and then leverage the feedback to ensure they attend the next review, where they can hear their concerns being addressed directly by the team.
Without stakeholder engagement, it’s hard for a team to know with confidence that it’s doing the right thing.
Confidence
It’s hard for a team to create psychological safety when it’s unsure of its direction. Psychological safety has been found to be a major predictor of team performance.
If you suspect a lack of psychological safety within the team, it’s vital to invest time in building trust and creating an environment where people feel it is safe to express themselves. One of the things that helps with ensuring teams will feel able to express themselves is well-structured meetings with clear, pre-shared agendas.
Lack of structure
Holding reviews is no guarantee that they are effective. If you’re not sharing agendas in advance, you’re leaving people to guess what’s going to be covered, which is not a recipe for high trust. I’ve been to a lot of reviews where people share videos of themselves doing demos with the software. These are often over within 15 minutes, with no opportunity for debate. If people aren’t able to inspect the team at work, there’s not much point in there being a review at all.
So, what does a well-structured, effective review look like?
Conducting effective reviews - be PROUD
A well-structured review enables stakeholders and the team to inspect the work being done and to ensure the team remains aligned and focused on its mission. By presenting information and asking appropriate questions, the team builds confidence in itself and with its stakeholders around the solutions it is creating.
Methodology
I follow the PROUD acronym for structuring my agenda (Progress Review, Outcomes, Updates, Demos). This creates a compelling structure for the meeting, ensuring your reviews will always deliver value.
Let's step through each of the elements in turn.
1. Progress review
This methodology differentiates itself from most reviews in that it doesn’t just dive straight into an update or demo of software delivered. The facilitator begins by setting context on what the team is working on, and sets the scene for the rest of the review, which will culminate in the demonstration of completed work.
The Progress Review includes the value-adding activities of the team since the last review. It could include a summary of a recent design workshop, a discussion of some of the challenges the team has encountered, a consideration of some functionality the team is developing but is not yet ready to demo, or even an update on work being done to clarify dependencies with another team.
Invite stakeholders to interrogate this progress, encouraging open dialogue between them and the team.
Sample Questions to Ask
What have you learned?
What surprised you?
How does this help the team accomplish its goals?
How can the stakeholders help?
What to Watch Out For
Accidental influence.
Debates disappearing into the weeds.
2. Outcomes
Next, the team shares data on the performance of the software it has released. The Product Manager leads this section of the meeting, using data to measure chosen outcomes against the hypothesis they had when they decided to prioritise and release this particular increment of software. This should also inform upcoming work for the team.
Data is reviewed with stakeholders and results are discussed openly. This discussion aims to understand the reasons for the outcomes observed, and to create fresh hypotheses or new possibilities for the product.
Sample Questions to Ask
Is the marketing message and spend correctly targeted?
What is driving adoption among certain customers/market segments?
How do we get/remain on target?
Why did(n't) we meet our expectations?
What else does the data tell us?
What to Watch Out For
Opinions overruling data.
Politics interrupting honest interrogation of the data.
3. Updates
It’s easy to confuse the idea of Updates with the Progress Review. However, the scope of Updates is significantly wider. Here, we spend time on ensuring alignment between the team and the wider organisation.
The team provides updates on what it has learned from its customer and market research. The stakeholders can share any strategic updates from the organisation that may impact the team.
This should be an open debate (watch out for the timebox!) on priorities and their impact.
Sample Questions to Ask
Have the company’s priorities changed?
Have we learned something that suggests we should pivot?
Is the organisation on track to meet its wider objectives?
Do our core assumptions still hold?
Which of our hypotheses should we test next?
Are there company pivots happening that may impact the team?
What to Watch Out For
Irrelevant information impacting the team.
4. Demos
Finishing up, the team presents any completed work. It’s always fun to show working software, and it gives the team a chance to restate their driving hypothesis.
It also gives customers and stakeholders the opportunity to provide early feedback. Quite often, a usability or accessibility issue will be raised here, giving the team the chance to review the functionality before it is released. As with the Progress Review section, it’s important to listen to stakeholder feedback, but not to uncritically respond to it.
Sample Questions to Ask
Who is this for?
What are we trying to learn?
How does this address our most important concerns?
How confident are we of problem-solution fit?
What to Watch Out For
Off-topic feedback.
Misunderstandings of the hypothesis the team is testing.
If you like the methodology, how do you get started?
Advice for making your team PROUD
Don’t skimp on preparation
Preparation is everything in a successful review. You’re more likely to succeed if you do the following in advance:
Setting up the meeting series
Schedule for months in advance. Don’t move them around, and don’t ditch them last-minute. Reviews need to be a habit for the team and for stakeholders.
Keep to a regular cadence. I like to have fortnightly reviews. In my experience, this is a nice amount of time to elapse, where stakeholders are kept close enough to the team to be confident in their progress, and the team has enough time between reviews to make substantive progress.
Keep to the same length each time. I find that 45 to 60 minutes is usually the ideal amount of time, enabling you to create time boxes in each meeting that enable the team to focus on highlights and have a debate without getting bogged down in details.
For each meeting
Create an agenda.
Know who’s speaking - who will present each topic?
Anticipate challenges - what are stakeholders likely to say?
Timebox - give each topic a set time for discussion so no one thing takes over the agenda. Follow-ups can always be arranged if needed.
If you’ve got the preparation right, here are some things to bear in mind when actually running the meeting.
Running the review
I suggest the following ground rules for running a good review.
Credit where credit is due
The people who do the work present their work. This gives the team members valuable exposure and a chance to hone their communication and presentation skills.
Go broad...
Teams should welcome a broad audience to their reviews. As well as having people further up the chain of command, it’s useful to pull in people from across the organisation. Cast your net wide. Include Support, Customer Service Managers (CSMs), Product Marketing, and other software development teams impacted by your work.
...But not too far
However, it’s important to make sure that the people attending have a reason to be there. Better to have a small, focused group than boredom or disengagement among participants. It’s a good idea to record the reviews and share the video widely afterward, so that more distant stakeholders can catch up with the team’s progress at their leisure.
Some reminders
The review should be a conversation, not a presentation. While some presentation is required and the team needs to prepare accordingly, you want to avoid Death by Powerpoint. All presentations should be framed so that they are inviting comment and questions. To maximise opportunities for conversation, I prefer live demos over pre-recorded videos (I like to live dangerously!)
Queries and challenges from attendees are not just welcomed, but encouraged. Observe people’s body language and if you see someone react to anything in the presentation, ask them about it.
In summary
Conclusion
As well as giving you the chance to gather feedback, a well-structured review can energise the team and ensure that the team remains focused on the right outcomes.
Regular reviews keep the team connected to their stakeholders. Teams should be PROUD of their reviews. There’s no point in box-checking exercises. Using this formula can build credibility and relationships, keeping the team focused on the most valuable work.