Broken Retrospectives and how to fix Them
Having worked on teams using agile methodologies for several years, retrospectives are a major part of my life as a product manager. Retrospectives (retros) are held at the end of each sprint cycle, at the end of the overall release, and sometimes to review other meetings or processes. Retros are intended to review your team’s successes and failures, with the goal of continuous improvement.
Retros are a great way to improve communication and foster teamwork. A team that is open and respectful of their colleagues will be much more successful than one that gossips at the water cooler because Johnny didn’t write test cases. A successfully executed retrospective would have brought to light the fact that test cases are extremely important and shouldn’t be overlooked, a conversation followed by a deliverable action to move forward with.
In my experience, however, more often than not retrospective meetings become just another agile ceremony.
Why Retrospectives Stink
At the end of each sprint, development teams around the world huddle into a room, or dial in to conference lines, to review the work accomplished in the previous sprint or release. These meetings can go in a few different directions.
If your team was successful over the last sprint, retrospectives are non-productive – a meeting that could have been avoided and instead memorialized with a great “thumbs up” giphy in Slack. Instead, you spend an hour splitting hairs in order to find something to look back on.
Conversely, if your team did not have a successful sprint, you’ll wind up with a mile-long list of action items. A list of action items that typically don’t get executed or followed up on. These lists are documented within some long-lost Confluence page or Box note. If your team is really on their game, these action items are reviewed at the next retro.
How to fix Them
Don’t be Scared to Skip
At Ncino, we found retrospectives are just another step in our development cycle. At the end of each sprint, good or bad, we meet to discuss how it went. We’ve found that if the team unanimously felt the sprint was successful, skipping that particular retrospective proved more valuable than having it.
If you don’t have anything major to discuss, don’t be afraid to skip, or at least shorten, your retrospective.
Celebrate that your team is crushing it, working together effectively, and meeting sprint commitments.
Instead of using an hour to talk about how great you are, give that hour back to your development team to keep crushing it!
Time-box and Stick to it
Time-box your retrospectives to less than one hour. After an hour of circling around the successes or failures of a previous sprint, you’ve probably covered the main issues (and probably in all columns; Start, Stop, and Continue), or you’ve upset Dave, your lead developer, who takes things too personally. With 10 minutes left in your time-boxed retrospective, start memorializing your action items.
If you find you don’t need the whole hour, write down your action items, give a few of high fives, and end early.
One way that my team has addressed the time-box issue is to ensure we come prepared. We use Ideaboardz.com as a simple collaboration tool to put down our retro topics. We send it out a few days before the next retrospective, giving everyone ample time to jot down their thoughts on how the sprint went. This way we know exactly what we are to cover. Coming prepared has allowed us to stick to the time-box and most of the time, end early.
Give it a shot and see how it works with your team.
Take Action on Your Action Items
Write them down. Print them out and post them around the scrum team area. Share action items out to a larger audience or across departments. Stick a sticky note on your monitor. Do something to track your action items.
Without tracking and measuring your results, I promise they will be forgotten, brushed under the rug; when they’re inevitably rediscovered during another retro as a continual issue, you’ll find yourself saying “That was a good idea… why didn’t we do that?”.
After failing several times with following up on action items, we started writing them down on a common area whiteboard. This simple action helps us to keep the topics top of mind and ensures that we don’t overlook them.
To be clear, I’m not advocating that you skip retrospectives. These sessions can be highly productive and add a ton of value if executed correctly. Continuous improvement is key for agile shops and retros provide the avenue to pause, look back, and evaluate in order to improve moving forward. However, if not executed correctly, retrospectives can lead to an unproductive time loss that does not bring value to the team. Make the most of your retrospectives (when needed) and ensure action items are actually pursued, and I think you’ll find your scrum teams operating like well-oiled machines.