Improve your feedback loop by leveraging retrospectives!

The ability of a team to continuously improve their processes and practices is invaluable. A recent experience has led me to reflect upon how the principles behind a key scrum ceremony, the “Retrospective”, can help teams continuously improve outside of the end-of-sprint activities. This post echoes my thoughts over the past few weeks about how the retro can be useful outside the traditional scrum ceremonies – James Hume (Delivery Lead). 

Recently I was invited by my colleague, Paul Thornton, to help facilitate a series of interactive workshops aimed at helping one of our clients mature their DevOps practices. We were to deliver the two-hour workshop on five separate occasions to different stakeholder groups who worked across different business domains. 

Over the course of the workshop, we found that we spend a fair bit of our time reiterating how to complete certain activities or providing additional context which was required to properly engage in the activities. Something just hadn’t quite clicked this first time around. 

Toward the end of the workshop, Paul turned to me and asked me whether I was happy to run a quick retrospective with the group. At first, I thought this was a bit odd. Wasn’t a retro just a ceremony used to help reflect upon the previous sprint and determine how to continuously improve for the next sprint? Then it hit me, why couldn’t it be a more general tool for continuous improvement! Jumping at the chance, I entered my first “workshop retro.” 

If you are reading this and interested to read more about my take on retrospectives including what they are, why they are useful and how to conduct one click here.

How did it help?

As mentioned, Retros are a fantastic way to help teams engage in continuous process improvement practices in a format that is simple enough for everyone to engage in. So why should we bother saving it for the end of a sprint!? 

Retros are an awesome tool to use when you are engaging in a regular repetitive activity such as our DevOps workshop. 

We only reserved the final 5-10 minutes of the workshop to conduct a retro-style activity. Basically, we wanted to simply understand what we can do to make the workshop better for the next group. Taking inspiration from the happy/sad/puzzled technique,* we were able to identify key action points based upon how people felt with different aspects of the workshop.

For example, the purpose of the workshop session was to gain a high-level understanding of how teams could improve their DevOps maturity across the entire maturity matrix. Team members naturally wanted to get into the detail of why they could/could not progress and, as a consequence, felt they were rushed and did not get enough time to adequately discuss the topics.

Following this feedback, we took an action item to set better expectations from the outset. We started the next workshop by highlighting that the focus was on the breadth of content rather than the detail. We also advised that people may feel pressed for time and want to discuss other topics, so we provided them with a series of sticky notes where they could record these thoughts for the follow-up sessions. The end result – in the first workshop we only covered the first five topics in the matrix; however for every workshop afterwards, we finished the matrix. Mission Accomplished.

This simple exercise of using the retro to create a quick feedback loop greatly improved the outputs we were able to achieve in the same two-hour block of time with different groups of people. Ultimately, we created a killer workshop that people loved to be involved in and drove engagement in the topic through the roof (even with participants who were originally adverse to change!). After this experience, I am definitely going to start using the retro more frequently as a tool in my agile toolbox.