I learned the importance of rapid feedback as a swimmer in high school and college. Like most people, I started my swimming career in the pool. If you head off course in a pool, you get instant feedback from bumping into a lane line.
Eventually I tired of swimming laps in a pool and moved to open-water swimming. Instead of flipping direction every 25 meters, open water swimmers often swim multiple miles between two or more points such as across a bay.
When swimming in the ocean there are no lane lines to keep you on course. It’s up to you to set a path. If you deviate too much, you’ll end up swimming much farther than you intended.
Swimmers’ main strategy for staying on course is to periodically lift their head slightly to confirm the path.
How often to do this is key. Do it too often and it’s tiring; don’t do it often enough and you risk going off course. The more often a swimmer gets feedback, the less they veer off course.
It is exactly the same with agile teams. The short feedback loops in Scrum give teams multiple opportunities to inspect and adapt, ensuring that products are headed in the right direction.
Increasing and Improving Feedback
Let’s look at a few things you can do to improve the timing and usefulness of feedback.
First, if you aren’t already holding a review meeting at the end of each iteration, now’s the time to start. Some teams think they are saving time by conducting sprint reviews less frequently. This creates problems because a small misunderstanding in one iteration can compound into a much bigger issue a few iterations later.
With today’s globally distributed workforces, you should also consider making a recording to share with those who cannot participate live in the review meeting. In some cases you can record the actual review meeting. In most cases, though, you’ll be better served by creating a narrated screen recording that demonstrates the new functionality.
Creating a screen recording like this can be very quick if you do it after each iteration. After all, there isn’t usually that much functionally added. A link to the screen recording can be shared with everyone or just those who could not participate live. You can request people send you feedback directly or allow people to leave feedback on the page with the video.
In addition to an iteration review meeting, you may want to consider a series of one-at-a-time feature reviews. As each feature is implemented, show it to the small number of stakeholders or users who requested it and solicit their feedback right then.
Not everyone who participates in an end-of-iteration review needs to offer feedback on every feature. Doing one-at-a-time reviews with select audiences can often generate higher quality feedback earlier.
When soliciting feedback, ask a variety of questions. In many reviews the only question asked is “Whaddaya think?” That often generates comments such as “I like it” that are hard to act on.
I like a lot of things—but a lot of things could be a little bit better. I like the tacos from my nearby taco truck, but they’d be a bit better if they were spicier.
Asking “Whaddaya think” usually fails to get the detailed feedback we need. Consider asking more targeted questions instead, such as:
- Is there anything we overlooked that users might want to do here?
- Would any of our user types find this confusing?
- Do you see anything here we could leave out?
Drill down further: When asking questions such as these, consider asking them of specific individuals rather than the full group. Be open, of course, to anyone’s comment—but directing questions to a particular participant reduces awkward silences and can sometimes lead to better conversations.
Timing of reviews is also critical. Try to demonstrate and get feedback on features well before they are 100% done. Suppose you are developing a new capability that can only be delivered after ten product backlog items have been completed. Don’t wait until the tenth and final backlog item is done before soliciting feedback.
Whenever possible, strive to get feedback directly from users rather than from stakeholders commenting on their behalf. For internally used products, this can be as simple as inviting users to participate in reviews. For commercial products you might need to create a public forum on which users can share feedback.
Finally, be sure the team includes time in their plans to act on the feedback. Nothing is more disheartening to stakeholders and users than to provide feedback only to see it ignored.
A Recap
Here’s a recap of the seven things you can do to improve the quality and timeliness of feedback:
- Start doing iteration review meetings if you aren’t already.
- Send a screen recording to people who could not participate.
- Do one-at-a-time feature reviews for those who requested a feature.
- Ask more targeted questions, of specific individuals.
- Solicit feedback on partial solutions rather than waiting until all product backlog items are complete.
- Seek feedback from users instead of stakeholders commenting on users’ behalf.
- Leave time for the team to act on the feedback.
Getting rapid and frequent feedback enables teams to build products that meet users’ needs. A team that gets feedback too infrequently should not be surprised when they veer as off-course as a swimmer who fails to check that they’re not nearing Niagara Falls.
What Do You Think?
How do you ensure you are getting early and valuable feedback? Please share your thoughts in the comments section below.