Wandering discussion. A sprawling lack of focus. Thoughts that echo through your head such as, “Oh my God, if I hear another comment about needing better snacks, my head is going to explode!” Does this sound anything like your experiences during sprint retrospectives?
Most of us fall into one of two camps: We want to find ways to get more out of our team’s sprint retrospective time, or we’ve given up on retrospectives altogether.
This can happen even though we’re moving quickly as a team, with our goals clearly in sight. Retrospectives should be a key tool to continuous improvement, a way for the team to improve with each iteration, to remove roadblocks, and to facilitate the team’s success. At regular intervals, the team should reflect on how to become more effective, then tune and adjust its behavior accordingly, as the 12th principle of agile says.
If that’s not happening—if your retrospectives are broken—here’s how you can change the conversation.
Prepare for your retrospectives, and be ready to scale
You might invest a lot of time in preparing your product backlog and planning your sprints, but how much time do you dedicate to improving your sprint retrospective process? And yet the payoff can be enormous. Lousy retrospectives waste time and deplete morale. Good ones contribute to continuous learning and team coherence.
In my team’s case, one of the snags we hit as we were rapidly growing was caused simply by the scale of the team; we had grown too large to have a single retrospective. So we splintered into individual groups that conducted brainstorming sessions and then joined together to share the insights and actions that were uncovered. As described in Esther Derby and Diana Larsen’s seminal book, Agile Retrospectives: Making Good Teams Great, this set the stage for the team retrospectives. What most teams miss, and what is only briefly highlighted in the book, is the preparation needed for setting the stage and how that preparation, combined with the use of data, focuses the conversation.
Or, more precisely, the conversations. To be effective, you need to be prepared to have two types of conversations: one that is quantitative, backed by numbers, and one that is qualitative, centered on the team’s feelings.
One of the best prompts for the hard-numbers conversation is the cumulative flow diagram. It’s a complete story packed into a single chart that indicates how well the team is working the process of delivering value, how well prepared the team was headed into the sprint, and how well it executed the timing of delivery.
These hard numbers matter. They tell you whether your team met its commitments and whether any missed commitments were surfaced ahead of the retrospective. Put the agile metrics you’re already tracking to work and get the team prepared for the best retrospective conversation possible. But keep the focus on numbers and facts. That will help take the emotion out of the discussion and give the team room for meaningful self-reflection without blame or stigma.
Then there’s the f-word: feelings—the team’s sentiment, its perception, its take on how things went. The feelings of your team members should not be discounted. The products we build are the sum of the teams building them, and the teams are the sum of the individuals. Neglect feelings and you’re missing half the conversation.
Jeff Sutherland talks about a happiness metric, but I’ve found that a more focused approach works better for most teams. To measure happiness, measure team morale, and to measure team morale, ask questions along the dimensions you and the team care about: speed, quality, accuracy, and the processes that drive success—autonomy, mastery, and communication.
For our products, we were already using the Net Promoter Score (NPS) to measure customer satisfaction, so we turned that inward and rolled out straightforward polls on a regular basis that take the pulse of the team and quantify dips and gaps in morale. The polls included questions such as these (with responses using a scale of 1 to 10):
- “How prepared were we for this sprint?”
- “How productive as a team were we on this sprint?”
- “How valuable was the work we delivered with this sprint?”
- “How well did we communicate as a team?”
- “How do you feel about the upcoming roadmap?”
And a great question that always has the power to identify gaps between product owners, manager, and the development team:
“What’s your confidence level in the current code quality?”
These polls aren’t intended to be perfectly precise, but visualized over time and coupled with the hard numbers from your cumulative flow, they give you what you need to spark deeper, more focused, and more meaningful conversations. For example:
- If your work-in-progress numbers seem to indicate that the team is blocked, and the polling ahead of the retrospective reveals that team members didn’t feel prepared for the sprint, then the retrospective is a good opportunity to have a discussion about backlog grooming and the quality of stories being worked on.
- If your velocity is dropping, team members don’t feel productive, and they’re perceiving less value delivered sprint to sprint, then retrospective conversations might center on technical debt, tradeoffs, and how to balance maintenance against new features.
The typical sprint metrics used in a vacuum won’t help your retrospective, but when they are highlighted for everyone on the team ahead of the retrospective and matched against the responses from the regular polling, they can spark the conversation that you want to happen, giving you a new way forward to measure progress and demonstrate its impact.
Best of all, mashing up of the quantitative and qualitative measures brings the quieter voices on the team to the fore and gives them a direct feedback mechanism they are comfortable using.
Pull in all your individual teams for a mega-sprint retrospective
Once your individual teams begin to have focused discussions where members share their sprint metrics alongside their take on the team’s sprint performance, you’ll want to bring the larger group together to decide what to do next. Developing an action plan is a critical step that many teams shortchange. They’ve invested the time and resources in their retrospectives, but making a real impact is impossible when they neglect to prioritize next steps and measure the change.
I like to have each team highlight the most important findings from the data and polling it has reviewed, and then have the larger group prioritize those findings by giving each team member the opportunity to allocate three votes toward the topics they view as most important. Besides keeping the group retrospective dynamic, fresh, and interactive, this surfaces the common challenges each team is facing and the top priorities to tackle next. The top priorities should then be treated as being just as important as any of the other goals you have set.
Then run through your process of goal-setting (SMART is an example: specific, measurable, achievable, relevant, time-bound) to define next steps and assign owners for your targeted improvements. Track the changes across all the teams, and review progress heading into the next retrospective. You’ll be able to articulate the return on investment the retrospectives are having, and you’ll earn the teams’ confidence.
Show your appreciation
A proportional and authentic show of appreciation is a great way to close out your retrospective. It’s easy to get lost in the everyday routine and forget to take a moment to acknowledge good work. Retrospectives are a good time for team members to revisit the kudos they’ve given to teammates over course of the sprint.
Doing so can have measurable effects on team performance. Charles Pellerin, the development lead for NASA's Hubble Space Telescope, documented how a social shortfall trumped engineering expertise and led to a flawed mirror—a huge failure for the telescope. He reacted by incorporating authentic appreciation into the team’s habits.
Your retrospectives don’t have to be broken, and they don’t have to be an investment without a return. By leveraging metrics you’re already tracking, such as cumulative flow, and adding in team polling questions, you can spark the right conversations at the right time that lead to increased awareness, action, and morale on your teams. You will move far away from retrospectives filled with talk about needing better snacks.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
