Agile

To Improve Agile Retrospectives, Learn What’s Wrong

Luis Ortiz

— 3 min read

The problem is not your team, or the process. The problem are your outputs.

Based on an article by Leon Tranter.

If you are part of a software development team that uses Agile methodologies, then you know that the key to your team’s continuous improvement in the long term are the Retrospective sessions. Yes, there are a few more events in Agile (stand-up meetings, estimations, etc.) but Retrospectives are specifically designed for continuous improvement.

Does the following scenario resonate with your situation? Your team, including Project Managers, Scrum Masters, and Software Development Engineers, has embraced Agile methodologies. You are familiar with Retrospectives, where you gather at the conclusion of each sprint to reflect on successes, areas for improvement, and potential enhancements.

However, despite these efforts, your team feels that the Retrospective sessions are not yielding tangible benefits. The recorded results seem to be forgotten, resulting in a lack of action and a demoralized team. You have experimented with various formats and techniques, but unfortunately, you have not witnessed any noticeable improvements.

What’s wrong?

Leon tells us that most people will try to change the inputs, (inviting different people, getting a different facilitator) or changing the process (the questions or structures around the meeting). But the problem is usually with the outputs.

If your Retrospective sessions primarily consist of complaints, questions, blame, or general negativity, it can create an atmosphere resembling a witch hunt rather than a constructive evaluation. Consequently, trust may erode, and the discussed issues fail to generate meaningful outcomes. In such a scenario, it's unlikely that any significant changes will occur. Consider what you expect your team to achieve with these outputs (complaints, rants, etc.). For genuine transformation and progress, the outputs of your Retrospective sessions should focus on actionable items with assigned owners and clear timelines. It's crucial for every team to commit time to continuous improvement, and a practical approach is to learn from past experiences and plan changes for future endeavors.

This came up during our conversation with Luke Homann, Conteneo’s CEO. The team will most likely point out something very general: “QA is taking too long” or “Communication needs to be improved”. Not that those are not valuable contributions, and if that’s the case, the whole team will most likely agree. But if that’s the result of your Retrospective, then again: What do you expect your team to do with these?

To ensure the value of a Retrospective, it is crucial that the output consists of actionable items—precise, explicit, and actionable items that drive concrete change.

The facilitator holds the responsibility of delving deeper to uncover the root causes behind the raised issues and establish actionable items. One effective technique to achieve this is the "5 Whys" method, which helps identify underlying causes. For instance, by applying this technique, you might discover that QA delays stem from a configuration problem within specific components, as Luke discovered. Alternatively, you might realize that the true communication issue lies in the team's time zone differences, requiring a solution such as leveraging a convenient Slack bot (such as StandBot) to facilitate asynchronous meetings.

But that's just the initial step. Progress won't happen automatically. It is equally important to assign a team member who takes ownership of the action item, define a timeframe for its completion, and consistently follow-up on its progress. This ensures accountability and maintains the momentum for implementing the necessary changes.

So it goes like this:

Have a Retrospective > Find Issue > Establish Action Item > Assign an Owner > Determine a Time Frame > Follow up > Next Retrospective.

Continuous Improvement is a cycle.

Considering that these action items are in no way user stories or tickets; how do we keep track of them?

The most effective approach is to display the open action items from each retrospective on the team's task board, whether physically or digitally. These items should be easily visible to the entire team, distinct from the sprint board. If you are using Atlassian tools, utilize the Retrospectives add-on for Confluence or the Agile Retrospectives for Jira version to document and track these items. If you prefer, there's also a Trello Retrospectives power-up or a monday.com Agile Retrospective app. This way, you and your team will have clear visibility of the progress.

It's important to note that not every action item will be resolved within a single sprint. Therefore, it is good practice to begin each subsequent Retrospective by reviewing the action items from the previous session and discussing the progress made. If any action item remains unresolved, you can choose to escalate it, persist in addressing it, or, as a last resort, decide to abandon it. However, giving up on an action item should always be the last option considered.

Come and explore the wide range of innovative tools for hybrid and remote teams at Catapult Labs! Experience the power of our cutting-edge solutions firsthand and discover how they can elevate your team's productivity and collaboration. Join us now for an exciting journey of enhancing your Agile practices!

Trying to improve your #Agile practices? OR are you getting started with Agile? Are you in a remote team? Check out our products for Agile teams at CatapultLabs. We focus on making agile ceremonies more effective and easier to adopt for remote teams.

Check out our Atlassian tools:

Follow us on our networks:
Facebook: /CatapultLabsTeam
YouTube:CatapultLabs
LinkedIn: @CatapultLabsTeam
Email: hello@catapultlabs.com
And Subscribe to our blog below!

Read more