Ahh the Sprint Retrospective. This could get interesting since there is quite a bit of dysfunction in the Scrum world when attempting to have retrospectives. Lets see how the Scrum Guide describes a Sprint Retrospective.
Scrum Guide 2017
“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”
Scrum Guide 2020
“The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”
– Ok, wording changed, but still the same message here.
Scrum Guide 2017
“The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.
”The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
”The purpose of the Sprint Retrospective is to:
• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.
The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.”
Scrum Guide 2020
“The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
”The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one month Sprint. For shorter Sprints, the event is usually shorter.”
– Where to start here.. It seems like a complete shift from the 2017 Scrum Guide to the 2020 Scrum Guide as far as the prescriptive nature of things and specifically calling out the Scrum Masters responsibilities and putting more of an ownership on the Scrum Team as a whole.
There is still the prescriptive nature of the time-box for the Sprint Retrospective;
“It is timeboxed to a maximum of three hours for a one month Sprint. For shorter Sprints, the event is usually shorter.”
But I think the approach is better in the 2020 Scrum Guide. If you are going to utilize the Scrum Framework, than possibly the Sprint Retrospective is the most crucial events. It allows the Scrum Team to take inventory of how they are working together, the tools they use, the process they follow and what Done really means. Inspecting and Adapting these aspects are critical to working in an agile way.
Here are some of the issues I have experienced with teams attempting to use Scrum as their “agile” framework when it comes to the Sprint Retrospective.
Not Having a Retrospective
Scrum Teams when faced with a prioritization issue and working scattered on too many things often vote to not have the Retrospective at all as to “save time to get more work done”. What issue this causes is we aren’t taking the time to address the real issue. We are working on too much at the same time in too many different directions, therefore we have no direction. This is a topic that can be addressed during a Sprint Retrospective.
The other reason I have seen is that the Scrum Team believes there is nothing to improve, so why have the event. Well, I am happy if people feel that way, but there are always pain points with interactions or tools or process that can be addressed and improved on. Don’t fall into this trap.
The Short-Short Retrospective
Scrum Teams will do this in an attempt to save time again due to too much work or other things that are viewed as greater value. When the Retrospective is rushed it quickly turns into something that has zero value to anyone and will be treated as such. Take the time to have the Retrospective and address concerns as a Team, come up with potential solutions to these problems and a plan to test out these solutions.
Complaint Department Retrospective
Using this time to complain about a situation the team is in rather than stating the facts of any issue and addressing them is actively destructive. People can vent, absolutely, but the key is to identify what the problem is that is causing this pain and again a potential solution to that problem.
Sure, Whatever Retrospective
When time after time the Team discusses an issue and nobody takes action to resolve it. If the Team identifies an issue and comes up with a potential solution, someone has to take up the ownership of doing that thing. And if they don’t, when we hit the next Retrospective, that needs to be discussed and sorted out. This is not pointing fingers or assigning blame, this is being accountable to your team mates. If you had an issue with tackling that solution, the Team member should feel free to let everyone know. If they are not, then that is yet another Retrospective topic on what I refer to as Psychological Safety.
Walled Garden Retrospective
Sprint Retrospectives should not be for just the Development Team, or the Scrum Master, or the Product Owner. They are for the entire Scrum Team. The Scrum Team uses this time to improve together.
Phil Connors Retrospective
The same Retrospective format is mentally exhausting. Please keep it fresh and exciting and have fun with it. There are plenty of great Retrospective ideas out there.
We’ll Do It Next-Time
I am guilty of allowing this to happen. And it had disastrous effects. But what I learned from that is the team wasn’t getting what they needed from the Retrospectives we were having. And in some cases the Team was over worked with things that were not being visualized to anyone else. I will admit though, with a few Teams, I have said “sure, lets get it next time” and even didn’t push when those teams wanted to not have the Retrospective again. What happened is the team settled into the status quo of how they were working, the divide grew amongst the team, and when we did have a Retrospective, the topic was around the value of the Retrospective and what we lost by not having them.
CSI Leadership
This is when leadership wants to see what the team discussed during their Retrospective. I have plenty of thoughts on this. I like Retrospectives to be a safe place for the Scrum Team to have an open discussion without fear of something they say coming back negatively to them. Some Teams even adopt a retrospective rule of “Vegas Baby! What happens in the retro, stays in the retro.” But this also points to a larger organizational dysfunction. If you are scared that what you say about a certain process or tool or interaction with people can get you fired, then you are not working in a very psychologically safe environment. And that needs to be addressed at the leadership level of the organization.
Now I have, and still do, like to divide a retrospective when needed. If we have a larger organizational issue that we are unable to get resolved, and need leadership to help us with, we will invite them to our retrospective for this topic. The Team will share what their experience has been and work to collaborate with leadership on an approach to resolve the issue.
But back to the leadership of the organization demanding to know what the teams discuss during their retrospective, I don’t like that. It sets up someone from the team, usually the Scrum Master, as an informant on the team and trust is quickly lost. Furthermore, the real issue is that leaderships lack of trust, and that needs to be addressed.
Please share any thoughts or experiences you have had with Retrospectives. As well as any ideas for keeping them fun and effective.
Chris Pipito 