One way of improving a software development team is to regularly hold retrospectives (or ‘retros’ for short). A retrospective is an exercise where a team sets aside a timeboxed amount of time (typically one hour) and looks back on previous times, discussing what went well, what problems could have been avoided, and what could have been done better. Retrospectives are an opportunity to identify and discuss problems, as well as introduce ideas to make the team better. Retrospectives work best when performed in consistent intervals, whether it be every week, every month, or every project.
Who Should Attend the Retro?
Typically, when it comes to who attends a retro, smaller groups of people are better. Speaking from personal experience, I have been in several retros involving large groups of people (sometimes as large as the entire office!) and they were DISASTERS. With large groups of people, retros tend to go for much longer than intended. People get tired and lose focus. Conversations that occur in the retro may be of interest to only a small percentage of the people in attendance, leading to people messing around on their phones and not paying attention.
All of the developers on the team should attend. If the office has tens of developers who work on smaller feature teams, then the developers on those feature teams should attend. Any BAs or QAs who work directly with the developers should be there as well. Managers and bosses should not attend. Their presence may cause people to not be totally honest about how they feel for fear of some type of retribution.
Ideally, an impartial third party should be the moderator of the retro.
Retro attendance should not be mandatory. If anyone on the team feels like retrospectives do not bring value, or if the person feels like their time will not be effectively spent in the retro, they should not be forced to come.
Where Should the Retro Be Held?
A room large enough to comfortably hold all of the people attending the retro should be used. There should also be a whiteboard available. The whiteboard will host the data provided by those attending the retro.
What materials are required?
Writing utensils, such as markers or pens, are necessary. Index cards and Post-its are great, especially if there are multiple colors. Many retro exercises make use of different colored paper in one form or another. The moderator may want a timer to make sure things don’t run too long.
How long should the retro be?
An hour should be sufficient for retro. How that hour should be allocated will be elaborated on shortly.
The Flow of A Typical Retrospective
A typical retrospective can be divided into several phases:
- Set the stage - 5 minutes
- Gather data - 10 minutes
- Generate insights - 20 minutes
- Decide what to do - 20 minutes
- Close the retrospective - 5 minutes
The times I have specified above are not absolute. Feel free to tweak these values to make them fit better for your retros. This is an example of what a retro might be for a small team. Larger teams will obviously require more time. Longer retros should have breaks interspersed.
Set the stage
At the start of the retro, the moderator should thank everyone for coming. The fact that people are attending alone shows that the people in the room have a desire to make a better team. The moderator should explain the purpose of the retro, as well as the schedule, for any people who are unfamiliar with how a retro works.
Tell the team that the purpose of the retro is not to blame anyone. Read them the Prime Directive:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
Remind them that this is an opportunity to learn and get better, not to blame.
One exercise that I like to do is an ice-breaker. I pose a simple question that asks for a short answer to everyone in the room. An example would be ‘In a few words, how do you feel the last week went?’ The objective is to get everyone to start talking. Once they start talking by answering a simple question such as this, they will be more prone to engage in conversation throughout the retro. This exercise also gives a reading about how the team feels in general.
Gather data
The next phase in the retro is where members of the team provide data about the period of time the retro is focused on. There are a number of exercises that can be done to collect data. Some of my gotos are Mad Sad Glad, and 4 L’s (Liked, Lacked, Learned, Longed For). These types of exercises allow the group to generate data from multiple emotions and mindsets, providing a comprehensive picture. It’s best if this data is placed in an area where everyone in the room can look at it, such as on a whiteboard. Different colored index cards or post-its help with associating with different emotions (red for mad, blue for sad, etc.).
Generate insights
Once data has been collected, that data can tell a story. One way of generating insights is by mute mapping. Allow 10 or so minutes for everyone to go up to the board and group data that they think are related. After these groups are formed, circle them or box them to signify that they are grouped together. Try to come up with themes for each group. Allow the team members to vote for one or two topics to talk about. Let the team discuss the topic(s) in detail.
Decide what to do
At this point, there should have been discussion about the time period the retro is focused on. Team members should have some ideas of things they want to do (or keep doing) to make things better. I recommend steering the team toward making SMART goals. SMART is an acronym.
- Specific
- Measurable
- Attainable
- Relevant
- Timely
SMART goals are concrete and are easy to see if they have been met or not after a specified period of time. They are also realistic. Have the team come up with two or three smart goals. Place them somewhere everyone can easily see them so that the goals are not easily forgotten about.
Close the retrospective
End the retrospective by retro’ing the retro. Ask the team for feedback. What was good? What was bad? What was missing? Tell the team that you welcome any feedback they want to give you, whether it be in public or private.
Finally, thank everyone for investing their time in coming to the retro.
Conclusion
Retrospectives are a great way for a software development team to identify problems and look for ways to improve. If you want a great resource on retrospectives, check out Agile Retrospectives - Making Good Teams Great. Pretty much everything I talked about in this post (and more!) can be found in this book.