Creating a Culture of Continuous Improvement with Retrospectives

Published:

My primary goal as a leader is to help teams continuously learn and grow. For teams to succeed, it is crucial to establish a culture of trust and psychological safety; retrospectives are one of the most powerful tools to accomplish this.

Retrospectives are essential for any team that aims to foster a culture of continuous improvement. They assist teams in building the four resilience factors of a resilient learning team, as defined in the book "Lead Without Blame: Building Resilient Learning Teams" by Diana Larsen and Tricia Broderick.

I have experience on teams that dismiss the value of retrospectives because they felt they weren't valuable enough given the time commitment. Chris Stone shared a poll on LinkedIn about the average duration of a retro. Many comments were about how much time was needed for a retro to be valuable. Chris noted that it is the team's decision on the value and the time commitment. I completely agree with Chris's perspective. It's entirely up to the team to decide. The agile leader's role is to assist the team in discovering value through continuous improvement.

The planning of each retro is critical to the continuous improvement process. When there is a lack of planning, the retrospective format is almost always what went well, what could have been better, and ideas for improvement. There is value to this retrospective format, but it can become dull and monotonous if there isn't some change to the event. However, there are other reasons this format is unsuccessful in driving change. There is often no change because of a lack of alignment, action, or follow-through with the insights captured during the retrospective.

Here is an example scenario:

  • A team works in two-week sprints and has a retrospective every other week.
  • The team gathers to discuss how the sprint went.
  • During the next sprint, similar items surface again. The team discusses the same items, the retrospective timebox ends, and the team moves on with their day.
  • Over the next several months, they shared their perspectives and ideas on what went well, what didn't, and ways the team might improve. Yet, very little was changing.

The problem was that the team needed an action plan to determine what to change and how to measure progress. Without a clear plan of action and follow-through, the retrospective meetings ended with nothing more than a "good talk, see you in two weeks." As this continued, the team became reluctant to commit their time, lost their trust in the value of retrospectives, and progressively dedicated less time to them. There are several reasons teams might experience this.

The most common reason I have experienced is that the team needs a dedicated agile leader or coach, and the person serving in that role is also an individual contributor. Serving both roles means they can only focus some of their time on helping the team grow and learn. It requires time and effort to facilitate continuous improvement. Another issue is requiring that person to be completely neutral during the facilitation. Being neutral takes significant effort and experience when you are an individual contributor.

I have participated in many retrospectives; the most effective ones had a dedicated leader. These happened when I worked at TechSmith, and Dave Desrochers led the retrospectives. Our team consisted of 15-25 people, mainly software engineers, with a few designers and test engineers. We would gather in a room, and the event would start with a temperature check of how we felt the sprint went. The temperature check was simple: did you feel Happy, Meh, or Stabby? I loved this temperature check activity and still use it to this day.

Dave is no longer with us, and I am forever grateful for his friendship, insights, and humor.

Then, we wrote a series of sticky notes to describe why we felt that way and shared them as we posted them on a whiteboard. The whiteboard contained previous retrospective data. It included the three improvement actions we were tracking and the top-voted items of the prior sprint. We had a working agreement (social contract) that we would only focus on three action items until the team determined one of three things:

  1. The improvement had become a habit and no longer required our focus
  2. That plan wasn't working as intended, and we needed to pivot
  3. That it is more important to focus on another area

As the team posted their sticky notes, we grouped them, labeled them, and voted on their importance. We then reviewed the previous sprints' improvement ideas and the three current action items in progress. We determined if any items had become habits, how we felt about the progress of those that weren't, and whether any new ideas were more important than any of the three in progress.

That was our agreed-upon process, and it was effective. Although I experienced this and have carried it with me, I have been in the position of having to be both the leader and an individual contributor. It is challenging to maintain a neutral position when you have so many ideas you want to contribute as a team member yet are responsible for guiding the team's continuous improvement effort.

I am guilty of being a non-neutral facilitator in the past. I have failed to achieve team alignment. I have been unable to help the team see the value of retrospectives. I use past success and failure experiences and build on them with education to improve. When I facilitate retrospectives, I plan them using the guidelines from Esther Derby's and Diana Larsen's book Agile Retrospectives: Making Good Teams Great, which are:

  1. Set the stage
  2. Gather data
  3. Generate insights
  4. Decide what to do
  5. Close the Retro

Following these guidelines helps set the agenda and determine the duration needed to be sure that we not only inspect but also have an action plan for adapting, along with the steps to make this a continuous process.

I recommend checking out Esther and Diana's book if you're looking for inspiration. It contains some fantastic ideas for retrospectives. I also highly recommend reading "Lead without Blame: Building Resilient Learning Teams" by Diana Larsen and Tricia Broderick. This book provides excellent insights into helping your team learn continuously and improve based on the 4Cs of Leadership (Courage, Compassion, Confidence, and Complexity), the 3 Essential Motivators (Purpose, Autonomy, and Co-intelligence), and the 4 Resilient Factors (Collaborative Connection, Inclusive Collaboration, Power Dynamics, and Embracing Conflict).

Retromat is a free web-based tool for planning retrospectives based on the steps Esther and Diana suggest in their book. It is a helpful guide and provides that first step without a blank slate.

Another tool I found but have yet to try is Retro Radar, created by Anthony Coppedge. Anthony is a business agility leader and describes Retro Radar as:

A visualization tool and technique for teams to reflect together in a spirit of continuous improvement. By highlighting what's working and what's not working, the Retrospective Radar combines a weekly team reflection (Retrospective meeting) for both prioritizing upcoming work and for providing feedback to immediate supervisors and up-line Leadership so that those doing the work directly affect the strategic planning for responsive pivots in the market.

Overall, retrospectives are essential for any team that aims to foster a culture of continuous improvement. It is up to the team to determine the value and time commitment required, and the agile leader's role is to assist the team in discovering value through continuous improvement. With a clear action plan and follow-through, an effective retrospective process can drive meaningful change and help teams continuously learn and grow.

Resources