Retrospectives provide teams with an opportunity to reflect. They’re an opportunity to discuss what is working, and what isn’t, with the goal of iterative improvement. The meetings themselves should be a safe place for team members to share and constructively discuss processes and practices. Then, as a team, come up with actions to resolve problems or otherwise improve how the development team functions.
Yet, often this isn’t the case – retrospectives break down, become unproductive or just don’t happen at all.
Here are 3 core failings with retrospectives, along with potential causes and remedies:
1. Retrospectives That Don’t Lead to Real Change
At the heart of retrospectives is the desire for continuous improvement. Feedback gathered during the meetings should result in action items. These actions items, upon completion, should deliver positive change. But if action items aren’t completed, or the true cause of problems is not identified, then belief in the process can wane.
This can come about for a few reasons:
Too many action items
It’s important that you don’t try and tackle too much and fail to make real progress with any of them.
Items are vague or have no clear resolution
The action items you create need to be specific and have a definitive end point. Items like ‘improve test coverage’ or ‘spend more time refactoring’ lack specificity and need to be quantified. Concrete action items provide demonstrable results – allowing the team to see and feel the improvements achieved by following the process.
A lack of responsibility for actioning items
Often the facilitator can end up with all the issues, or items are assigned to groups of people. This is a mistake – each item should have a clear owner who is charged with ensuring it gets done, even if a team will be completing them.
Too much emphasis on technical issues
Working with tech is what we do, so identifying problems about systems, servers, libraries and tooling is easy. But you need to ensure that you give just as much attention to working practices, communication, and people problems. Otherwise, these key impediments to improvement will hold you back.
Whatever the reason, it’s important that you’re completing action items. So prioritize them, and focus on just a handful of items that you know can done before the next retrospective. Break down larger issues so that you can begin to make progress with them too. Track items raised at previous retrospectives and review results each session. This sense of momentum helps to build and maintain a belief in the process and fuel future improvements.
2. Retrospectives That Don’t Occur Often Enough
If retrospectives don’t happen often enough, it can cause a number of knock-on effects:
Too much to go over in any one retrospective
This results in meetings that fail to get to the cause of issues. Or due time isn’t spent on issues important to attendees, which can be disheartening.
Previous action items are no longer relevant
So much has changed since the items were identified that the issues raised are no longer a priority. This doesn’t mean they aren’t important. More often, it just means you’re compounding them with others and you’re missing an opportunity to improve.
3. A Lack of Participation in Retrospectives
This can often happen if the meetings aren’t managed effectively:
Sessions are long-winded
You should decide on the agenda before the meeting to avoid straying off topic and unfocused discussion. You might want to consider time-boxing sections of the meeting. This helps to ensure discussion on one section or type of problem doesn’t consume all available time and attention, and that all areas get adequate attention.
Sessions have become stale
Change things up. Try removing seating for one session, so people don’t just sit back and switch off mentally. Or change the format so you aren’t just repeating the same old questions. There are plenty of different techniques: from the Starfish and 4Ls to FMEA if you decide to deep-dive on a specific issue. Or just pair off and discuss items to bring back to the group. Some people open up better in smaller groups. And one-to-ones force a conversation, otherwise things gets awkward.
There’s a lack of trust
A lack of participation can also result from a breakdown in trust. You should only invite team members to take part. Observers, especially management, despite noble reasons for attending, should be dissuaded from doing so. It may seem to make sense to share feedback so that other teams can learn from it too. But the specifics should be kept in the room. People might not contribute if they know there will be a long-term record of it, or if attributable comments are shared. Just share the action items or areas you’re looking to improve.
Sessions are too negative
Retrospectives should encourage introspection and improvement. But this doesn’t mean it’s just a time to moan. It can be too easy to focus on the things that aren’t working or you failed to do. So it’s important to make an effort to highlight improvements, and not just from the last iteration but over time too.
With a few changes and a renewed commitment to the process, retrospectives can be a great way of ensuring you’re constantly improving. They can be an important part in making the working lives of your developers better and more productive.