Guest Blog Post on the amazing Tricia Broderick's new website: Ignite Insight & Innovation
Update Nov 2020: The New Scrum Guide 2020 has been released!
Read the updated blog post below:
I often come across teams that have been “Scrumming” for a while, but reluctantly decide to remove Scrum events from their schedules, as they no longer or never have found value in them.
Whenever this occurs, my response always begins with a couple of questions: “Are you doing the pre-work necessary to prepare for the event?” and “Are you using the event time for the purpose intended”?
More often than not, these questions quickly highlight why teams run into trouble around their Scrum events, and demonstrate how they can quickly regain the value intended from them.
With this in mind, let’s dive into what happens when the event in question is the Sprint Retrospective (fondly known as the “Retro”).
First let’s understand the purpose behind the Retro.
At the end of the Sprint, the teams have a clear opportunity to inspect and adapt their process by participating in the Retro. The idea is to look back at the Sprint they just completed and discuss as a Scrum team any improvements that could be implemented moving forward, especially in the upcoming Sprint.
Most teams typically begin with the following three questions, or some version of them, which results in understanding how things went during the last Sprint and any potential changes.
1. What went well?
2. What didn’t go well?
3. What can we do to improve?
Reviewing these questions, it becomes apparent that the Retrospective is about continuous improvement. But, what if this discussion results in a list of items to improve, but the Scrum team does not actually action them? That would be a very good reason why teams would feel the Retro is burdensome to attend and do not find much value from it.
The Retro is intentionally timed in the Sprint cycle to occur at the end of the current Sprint – just prior to Sprint Planning for the upcoming Sprint. This is so that the improvement items or actions deemed necessary which are raised in the Retro can potentially be put into practice in the upcoming Sprint. So always ensure that the Retro occurs after the Review and before the next Sprint Planning event.
When exiting the Retro, ensure the action items are clear. Teams will often come up with many action items, something that can be detrimental. It’s important to make sure the actionable items are manageable and achievable. Start by creating just one action item and putting it on your Sprint backlog, where it will be transparent to all and it becomes easy to follow its progress.
I love this image about why reflection is important. Very often, teams get caught up in the day to day and find it difficult to pause in order to inspect and adapt. Are you running on “square wheels” when, in fact, you could run smoother with round ones?
Another reason why Retros fail may also be due to a lack of a psychologically safe space. The session must lead to a place of trust, where participants can openly share honest feedback without disregarding anyone’s opinion. You may also find that having individuals with a “louder voice” take over the session or leadership members in attendance creates an environment where some members are uncomfortable speaking up. If this is happening, it’s very important to understand who should be attending the Retro and whether you have the right conditions and environment to have a fruitful session.
In attendance should be your ScrumMaster, the Developers, and your Product Owner (the entire Scrum team). Yes! Your Product Owner (PO) should be attending the session. Teams often forget that the PO is a member of the Scrum Team. PO's should also be a partner in creating a psychologically safe environment to build trust and also generating open communication to create the best change for the teams.
The ScrumMaster prepares the Retro, helps time-box, conducts the exercise/facilitates, shares the purpose of the Retro, encourages improvement and engages the team.
The PO & Developers participate and provide honest feedback. They can actively help with facilitation and may even run future Retros. When both are in attendance, it helps bridge the gap between product/business and engineering, since a better understanding can develop between both around progress and challenges the team encounters throughout the Sprint.
Sometimes Retros can also fail because they simply get boring. The same three questions, potentially no action items, and the same people speaking up – these are perfect reasons to claim the Retro does not bring value. If you encounter this situation, it’s probably well overdue for you to change things up!
The Retro doesn’t only need to be run a single way (i.e., with these three questions)! There are hundreds, maybe thousands of different ways to run really engaging and fun (yes, you can have fun!) retrospectives.
They can be topic-focused or generic. They can be specific to a challenge or even focused on people’s interactions and relationships. There are SO many ways and formats to run Retros! Try a quick Google search and see what you can find!
In the remote landscape we are currently working in, teams often do away with Retros, as they are now unable to have Post-itTM or whiteboard sessions, and so it seems overly tedious to continue them. To address this situation, there are many different online collaboration tools available. Using them are pretty straightforward, and many offer facilitation tools, including timers, voting, anonymity, and virtual Post-it notes. Some tools I’ve used include: FunRetro, Miro, Mural, Google Draw, Trello, and Google Jamboard.
There’s a lot more insight that can go into planning and conducting good Retros. However, you must always ensure that you walk away from the session with at least one clearly defined and feasible action item. I can guarantee this will be the start of your happy ever after for Retrospectives to come.
Views and opinions are my own.