Sprint Retrospective - The event to tap into your improvements.
The Sprint Retrospective is the concluding event of the Sprint, timeboxed for 3 hours or less for 1 month Sprint. This is an Inspect-Adapt opportunity for the Scrum Team to figure out how they could become more effective in the upcoming Sprint. It begins by exploring the current Sprint, its outcome, the way team members interacted, the processes-the tools used and all the interconnections between them. The focus is to find out ways to improve as a unit and avoid any challenges that the team faced, in future Sprints.
Sprint Retrospective - The Dysfunctions
The Sprint Retrospective has a clear purpose - to find how the Scrum Team can become more effective in the upcoming Sprints. However, the Sprint Retrospective is often marred with multiple dysfunctions. Here are a few dysfunctions that I have often observed in Scrum Teams:
- The Retrospective that never happened
- The Retrospective which has no objective
- The argumentative Retrospective
- The Retrospective with no outcome
- The Retrospective with huge list of todo items
The Retrospective that never happened
“Hey Scrum Master, we are running late on our testing bit. Shall we skip the Retrospective? This will give us extra time to get the pending work done” - said the Developers on the Scrum Team. And a good Scrum Master, obliges the Developers because delivery is important.
This is fairly a common scenario that I have encountered in Scrum Teams. Often it comes with a promise that we will take all the issues in the next Retrospective. But next Sprint, the same situation and so the Retrospective never happens. Or in some cases someone needs to put a tick against a checkbox then it is hurriedly done without any focus on the purpose.
The Retrospective which has no objective
Another common dysfunction that I have observed with Sprint Retrospectives is that they don’t have any clear objective. Scrum Teams fall for a practice and then simply keep doing it. The most common practice that Scrum Teams use is answering three questions, first individually and then talking about them as a team:
- What went well?
- What did not go well?
- What can be improved?
When I teach Scrum in my PSM I class and ask this question, how many different techniques do the Scrum Masters know to facilitate the Sprint Retrospective? This three question technique is pretty ubiquitous.
The problem with this technique is that there is no common ground, everyone often brings up different issues, different improvements or different things that worked for them and so the Retrospective turns out to be an individual, self-serving meeting instead of a team event focused on improving as a unit.
The argumentative Retrospective
This one is a fun to observe Retrospective (sarcasm). Here we often have either two individuals or two groups (often differing skills) whose only purpose is to highlight that something was not done or delivered because the other could not do their job properly.
A ping-pong tournament of blame starts right at the beginning and often lasts till end of the Retrospective, not allowing the team to focus on improvements. The clear focus is on “I” instead of “WE/US. Commonly heard statements in such Retrospective include:
- I told you at the beginning…..
- I knew he would not deliver…..
- He always creates this dependency and then he is not available…..
- He doesn’t even know how to write a simple unit test…..
- I have to do all the heavy lifting here…..
- And so on…
The Retrospective with no outcome
Have you ever been part of Sprint Retrospective where the Scrum Team comes together, answers the three questions:
- What went well
- What did not go well
- What to improve
But yet at the end of the Retrospective they do not have any clear outcome of what they would like to do in the next Sprint to become better. In fact, there are no improvement items identified. Scrum Teams simply agree that whatever they are doing is just perfect in their context and there is no need to change the status quo. Sometimes, if ever, they find an improvement, the Scrum Master will make a note of it and will put it on the improvement board and that’s it. After that it just ends in an icebox. No further discussion or followups required.
The Retrospective with huge list of todo items
And then there is this another Retrospective where a huge list of action items are identified. I was invited to a Sprint Retrospective a few years ago to observe and share feedback. At the end of the Sprint Retrospective, the Scrum Master made a list of 25 items that they wanted to improve; what they didn’t agree to was how and when these items would be addressed.
Another observation that I shared with the Scrum Master after the Retrospective was that many of the items that they identified were out of their control. Some had dependencies on other teams while others required a direct intervention from the senior management.
Now if the Sprint Retrospectives are marred with either these or any other dysfunctions, Scrum Teams will struggle to become effective and this will impact value creation.
Sprint Retrospective - How to get the most out of it
A couple of years ago I wrote an article - 5 Tips to Improve Your Retrospective; it is available here. In this article, I highlight how I used the learnings from the book “Agile Retrospective” and complemented those with some facilitation techniques to make the Retrospectives more valuable.
In this post, I will like to share some more tips without dwelling into how to set up the Retrospective.
Mix up and add variety
One of the observations I have about WHY Sprint Retrospectives are neglected or skipped is because they become mundane. Team members do not find any value of just going through the motion, answering three questions every time they get together for the Retrospective.
A Scrum Master, as a facilitator, may bring in variety by trying different techniques for the Retrospective or, even better, delegate the responsibility to facilitate to other team members. This also promotes self-management within the team. A couple of different techniques to facilitate the Sprint Retrospective include:
- Speed Boat
- Rocket Retrospective
- Liked, Lacked, Learned, Longed For
Establish a clear objective
Every Scrum Event is an opportunity to Inspect and Adapt. This notion is pretty clear with other events as compared to the Sprint Retrospective.
For example, when the team gets into Sprint Planning they are well aware that they have to select a few items from the Product Backlog that would help them to move closer to the Product Goal. And at the end of Sprint Planning, they should have a Sprint Backlog and Sprint Goal established.
At the Sprint Retrospective, we say look back at the Sprint and find improvements. That doesn’t really help. Having a clear agenda or objective set up at the beginning of Sprint Retrospective often helps the Scrum Team to be focused and come up with targeted improvements.
For example: After a difficult Sprint where a lot of bugs or issues were identified, a clear objective could be to focus on improving the quality of work and Sprint Retrospective discussions could be structured around it.
Showcase Implementation
Once improvements are identified and if they are not implemented then that also leads to disengagement of the Scrum Team from the event. Having clear and concise improvements that can be implemented without outside support and within the team will give the team a sense of accomplishment and they would look forward to being part of the Sprint Retrospective.
Make your improvements SMART
To ensure that improvements identified are actually implemented, I always suggest the team make the improvements SMART. An improvement item that is Specific, Measurable, and Time-bound will enable the team to focus on getting it done. This also means that the improvement needs to be Realistic and Achievable.
An improvement that says the team will refactor the entire codebase to eliminate all potential bugs is an amazing improvement but not realistic. On the other hand, if the team establishes that every Sprint they will pick one Product Backlog item to pair-program; then it is definitely doable.
Empower and Ownership
Finally, to really implement any improvements empowerment and ownership is needed. There is no point in having a long list of improvements but no one is accountable for getting them done. Or people may pick up an improvement to apply but then get stuck in decision making hierarchies.
A Scrum Master should empower the team to decide on which improvements to focus on, who will take the ownership of and how it will be done. Establishing clear ownership avoids the “bystander effect” and gets the improvements implemented and enables the team to see how the Retrospective is making the team more effective.
That’s all for now. I hope this was helpful.
Let me know if you have any questions or feedback through the comments.