Retrospectives are often referred to as the life blood of an Agile Team. Rightfully so, they help a team inspect what they are doing in the team construct and fine tune their behaviors to improve in the short and long haul. But the thought recently came to my mind of what really constitutes a good retrospective. I’ve seen games played, maps created, root cause analysis performed and many methods utilized for drawing out the thoughts and ideas of the team. Let’s dive in and discover some important and oftentimes overlooked aspects of this vital step in a team’s evolution with at least one format for a retrospective.
Identify the Wins
What has gone well for the team?
What have they been able to get completed together?
What goals did the team set and achieve from their improvement backlog?
All of these can be the subject of wins for the team and should never be overlooked. A team I worked with a couple years ago had gone through a refresher Agile training and relaunched their efforts as a team to try to be more successful. They had continually not been delivering valuable solutions at the end of every sprint. Within the first couple new sprints, they were seeing work get completed and the feedback cycle with the Product Owner work for the first time in months or longer. They all openly acknowledged how nice it was to be getting valuable work DONE that could potentially be released by the business. Another team I worked with just this past year noticed that when one team member had been out of the office sick unexpectedly everyone else banded together to get the work done that was committed to for the sprint. It felt nice to complete what they had committed to so the Product Owner knew that if they said they would complete something it would get DONE.
How has collaboration and teamwork helped your team be successful during their sprint?
What specific item can be called out as an example to share with the entire team?
Sometimes it becomes important that the Scrum Master prepares team members for the retrospective by encouraging individuals to share their experiences. I call it “priming the pump”. When a good experience happens, acknowledge it and take note of that situation to potentially be shared during the retrospective. The more that these situations are called out, the more they will continue within the team and become the norm for performance.
What is Slowing Us Down?
This will readily turn up areas that could also bleed into the areas for improvement, but it should be looked at very closely to see what things are truly not working well the way they currently are. This could uncover situations within and outside the team’s control. The Scrum Master should always encourage the team to acknowledge what is happening and depending on the context of the retrospective being used, root cause analysis could even happen to a certain degree to discover the real core of the problems discussed. One common “slowing us down” thing I have seen over the years is that the backlog grooming session doesn’t seem to yield the right level of detail for the team to be ready for the sprint planning session. I have seen teams strategize and try to discern what aspect of the meeting is not going as planned but the lack of appropriate detail for user stories can lead to many missed sprint goals and other more serious problems with releases.
Inspecting what real pain points exist, which ones need to stop and which ones just need to be adjusted slightly can lead to a much more productive discussion around team dynamics and performance. In a recent podcast episode, AgileDad’s very own Lee Henson pointed out a specific situation when there is a vocal member or members of the team speaking up about problems being experienced, but the silent majority do not speak up. He suggested a foray into a SILENT retrospective in his Minding the PEA’s and Q’s of the Retrospective podcast episode which opened up options on how to make sure we are truly hearing from everyone on the team before we Explore options for improvement.
Charting the Course for Improvement
Nothing gets omitted more often from a retrospective than the path forward for improvement. It is usually because not enough time is set aside for the retrospective. I always suggest having at least an hour set aside for the retrospective because at the 30-minute mark is usually when we have discovered some of the problems without any solutions for a go forward plan. And even when it is done, it most often becomes a laundry list for improvement instead of a concerted effort around 1 or 2 items to work on that help improve upon the team’s mutual performance. Teams in my career that have used this aspect of the retrospective see improvements on a sprint over sprint basis. Those teams that don’t tend to be more erratic or unpredictable in their improvement efforts. It’s possible that many of you are in the situation a Scrum Master was in a few years ago that I worked with. He was new to his role but not new to the team. He noticed that the improvement list items that were not completed from the last sprint just carried over from one sprint to the next. He decided that needed to stop so he had the team vote on their top 2 or 3 items to focus on for the next sprint. The top 2 vote getters continued on the improvement backlog and the others dropped off. This led to a more concerted effort for the sprint because everyone knew the two improvement items being focused on.
It could have been setting a team goal to always make sure they are collaborating on their user stories with at least one other team member. This helps to not only share knowledge but leads to opportunities that better code is written for software teams when a couple sets of eyes are on the problem at hand. It also could’ve been many other things that help the team improve with their delivery process, for instance, refining and following their definition of DONE as a team. Whatever the items are that come up, make sure the team has a say in which items they feel they have the most control over changing in the upcoming sprint so they can act accordingly to make those changes. Otherwise, obstacles outside the team’s control should become action items for the Scrum Master or Product Owner to work on addressing appropriately.
Recognizing Team Efforts that Lead to Mutual Success
I often hear this referred to as the Kudos or Shout Out section of the retrospective. Making sure the efforts, large and small, that have been put forth by team members are recognized in the team setting builds trust and camaraderie. I have even sat in on retrospectives in my career where the team spent so much time thanking each other for working together that it became very apparent to the team how to fix some of the vexing problems they were experiencing. Quite simply it required their mutual efforts to work through the solutions and find a way forward. This particular aspect of the retrospective promotes the self-organizing efforts of the team to get their work DONE as a collective instead of just as individuals. One team I remember working with vividly over the years regularly had everyone on the team that was recognized for their contributions. The Product Owner on this team tried to point out what he appreciated from the team on an individual and team basis. It was a great experience for everyone involved and led to more positive behaviors and teamwork as the team moved forward with each subsequent sprint.
Keep it Simple – Incremental Steps to Team Success
Regardless of the method you use to facilitate your retrospectives, consistency is the key. I will always remember one team when I was a relatively new Scrum Master faced with the prospect of cutting meeting time for the team that they plead with me to “Don’t Take Away Our Retrospective” as it helped them become who they wanted to be. Make sure you are spending the important time helping build up your team, find any deficiencies they are experiencing, help them make concerted steps towards improvement and acknowledge the individual and collective efforts of their team. Only by regularly reflecting on how to become more effective and then fine tuning and adjusting behavior accordingly can teams become high performing.