Reading Time: 5 minutes
Retrospectives are a tool that can provide a primary data gathering mechanism for a team’s health and delivery process and are performed at the completion of an iteration of work.
The purpose of the retrospective is to help teams improve continuously by learning from their experiences and improving how they work and collaborate with each other.
Establishing a feedback loop using retrospectives is usually the first practice I recommend teams adopt when trying to customer experience, improve delivery processes, or ‘implement DevOps’. This is the second post in a series exploring approaches for gathering and incorporating feedback into your delivery and engineering processes.
This post describes:
- the general goals and practices of a retrospective
- my own variation of a retrospective and supporting template
- how to close the feedback loop
Introducing retrospectives
A retrospective is a meeting wherein team members share feedback on their recent experiences as a team or project collaborator.
A leader facilitates the retrospective by eliciting feedback from participants and keeping conversations aligned with the purpose of the retro: improving the team’s collaboration and delivery practices.
Participants can and should share how and why they were or were not able to accomplish their work candidly and respectfully in this forum. Retrospectives are not the right forum for detailed technical discussions.
The classic introductory form of retrospectives has people answer:
- what went well?
- what did not go well?
- what should we change? (or better, what do we need?)
Those questions are a good place to start. Prefer exploring the circumstances and information team members used to do their work rather than hypothesizing about what might have been (1).
There are many ways to run a retrospective to gather feedback from a team after an iteration of work has completed in order to learn. As your team gains experience running retrospectives, you’ll probably want to experiment with the format. Books like Agile Retrospectives can help you find good approaches for particular situations in addition to safely diving deeper into challenges your team faces.
It’s almost canon for agile leaders to share how they tend to do it, here’s mine.
My approach to retrospectives
My team uses the following process and this template to reflect upon an iteration, which also ties back to planning. As you might guess, our work consists mainly of building tools and reusable Terraform infrastructure modules for AWS, and helping clients use those tools within migrations. YMMV.
During planning, we identify the iteration’s Objectives in terms of the product/project and team. When using Scrum, we also record the initial number of Stories planned for the Sprint.
At the retrospective, I usually warm up the discussion by reviewing our original Objectives followed by a quick recap of the stories completed in the iteration. This primarily serves as a reminder of what the team did in the iteration. It’s not uncommon for people to forget what they accomplished on Tuesday, especially if Thursday and Friday were tough.
Next, we list the things we accomplished in the sprint. The intent is to recognize and celebrate progress. Accomplishments may include:
- Completing or making significant progress towards one of the planned Objectives
- Building some knowledge or capability, planned or not
- Reaching a business or project milestone such as ‘used by 5 customers’
- Improved structure of main and test codebase through refactoring and enhancing tests
The ‘Retrospective’ section contains a table where team members summarize what went well, what did not, and what they need. We use these bullet points as jumping off points for discussion in the retro. Again, I recommend exploring the circumstances that led to this feedback more than what might have been if a different action had been taken.
Finally, we move on to summarizing what we learned within the sprint. I think it’s important to quickly capture in a team-level statement what we learned as a team about the business, the problem domain, our solution, etc. This summarization is then followed by prompts some prompts for long term-knowledge building and improvement.
The Decisions section reminds us to think about whether anything important was decided during the iteration and record that in a decision record.
The ‘Improvement Actions’ section identifies the one or maybe two improvement opportunities the team has selected to pursue. Examples of improvement actions are: complete training on AWS cloud architecture, reduce function complexity and enforce in code review, or clarify acceptance criteria for stories.
The feedback loop is ready to close.
Closing the loop creates the value
Team leaders and managers now have curated feedback on what the team wants to do to improve. The feedback is ready to be acted upon at the start of the next iteration. Collecting feedback and not acting on it is worse than doing nothing at all; that’s just wasting people’s time, energy, and hope.
Close the loop!
Kick off your planning meeting by reviewing the previous iteration’s retrospective for Improvement Actions. Make an Objective and a plan that moves the team down the improvement path.
Many improvement actions can be implemented with small investments in effort or behavior changes.
For example, consider a team that notices ‘known issues’ are slipping through their code review process. They might decide to create and adopt a code review checklist that reminds them of these common issues, including those that are specific to their technology stack and domain. This is probably a small effort for most teams and so can be added to the sprint and its efficacy can be reflected upon in the next few retrospectives.
It may appear difficult to accommodate large improvement actions, because it does not look easy to ‘slip in’ alongside ‘regular’ work. Of course, you can adopt the obvious practice of breaking larger efforts up. But this approach may hint that you’re looking past a more serious problem.
If a team says ‘we need to improve X’ and X is hard or uncomfortable, leaders need to respect the feedback and work with the team to find an appropriate solution. Ignoring a team’s feedback is much more likely to make the team members go away than the underlying problems.
Start by reserving around 20% of a team’s efforts for these continuous improvement efforts. If a team’s delivery and operational processes are flailing, reserve more time for improvement until it’s under control. There’s no upside to burning people out.
The great news is that gathering and acting upon team feedback using retrospectives can work wonders. Many struggling teams have ‘turned around’ in a couple months or less using retrospectives as a key practice in their continuous improvement processes. And once the continuous improvement flywheel is turning, you’re set on a course to excellence.
#NoDrama
(1) Read Lorin Hochstein’s ‘The problem with counterfactuals‘ for more on the risks of hypothesizing.
