Agile Retrospectives, an Effective Tool for Continuous Improvement

Most teams that are doing agile development and are using Scrum have heard about agile retrospectives. Often they also start doing retrospectives after one or more sprints. Some teams keep on doing them, but I’ve heard a lot of teams that didn’t do them frequently, or stopped doing them after some time. The reason I hear most is that they are not getting enough benefits out of them. But if not doing retrospectives means that you will not improve your way of working, and adapt to changes in your team or in your organisation, that may be a high price to pay? My suggestion: Do your retrospectives!

Are retrospectives difficult? No! Are they valuable? Certainly! But you have to know how to do them, to turn them into an effective tool for continuous improvement.

Why do Retrospectives?

Let’s first start by understanding why you would want to do them. The Agile Manifesto provides us with a couple of good reasons. It starts with the first sentence of the manifesto:

“Uncovering better ways” tells me that there isn’t 1 solution, not 1 best way, or silver bullet to do software development. And since we are uncovering it, we will have to try things and reflect to see how it works. This is where retrospectives come in, as a way to reflect at the end of the sprint to see how the team has been doing their work. And to uncover what worked, and what didn’t. Having an agile mindset means that you want to reflect and learn, and keep on reflecting and learning. You’re never done!

And then there are also the principles behind the Agile Manifesto. The 12th principle says: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” It is often called “inspect and adapt”, which start by doing things, learn, and improve along the way. Just like you don’t know all requirements up front when you start developing a product, you start working with what is clear and needed and then change based upon the feedback. Retrospectives are a way to “embrace change” in the way you work as a team.

Retrospectives aren’t something that agile or Scrum has invented. Getting feedback to improve yourself is much older. Actually, even project management methods like Prince-2 and the PMBoK has reflection included in the way that they propose to manage projects. What Scrum has done is to define a ritual to do the reflection, and to give it a clear spot in the software development cycle.

How to do Retrospectives

So now that we understand why to do retrospectives, let’s discuss how to do them. What I have found to be very important in having effective retrospectives is that the right culture is set at the start. I use the Prime Directive to assure that a retrospective is a positive and fruitful event. It states: “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”. With the Prime Directive, a retrospective becomes an effective team gathering to learn and find solutions to improve their way of working.

In a retrospective, a team reflects on their way of working. There are a lot of different techniques that can be used to do retrospectives, varying from asking questions with post-its to gather and organise the answers, building a timeline, root cause analysis to gaming (see Getting Business Value out of Agile Retrospectives which describes many of them that I have used in retrospectives). Depending on the situation at hand and what the team would be looking for, I usually pick a technique that would be suitable.

A technique that I use often is to ask “the four key questions”:

• What did we do well, that if we don’t discuss we might forget?
• What did we learn?
• What should we do differently next time?
• What still puzzles us?

For me these questions have shown to be very effective. I like the question “What did we do well”, it’s a Solution Focused approach to find strengths which can be deployed to improve further. The addition “if we don’t discuss we might forget” makes this question even stronger: If something good happened by accident, that’s great, but what can you do to assure that you will keep on doing it? Also the question “what puzzles us” has given very useful insights for teams, by revealing things which had remained unspoken before I asked the question.

Getting the Actions Done

I stimulate teams to use whatever means they already have to make their retrospective actions visible. Stick them to the wall at their workspace, put them on their planning board, use them as input in the planning game, etc. For bigger improvements it often helps to define a User Story (describing who, what and why), and plan time to do it. By doing it like this, I’m helping teams to develop continuous improvement skills, being able to efficiently manage their own improvements and delivering more value to their customers. For some examples on visibility, “Continuous Improvement, Make it Visible!“.

In a retrospective, I also check if the team has been able to finish the actions that they committed in the previous retrospective. If not, then it’s good to discuss which impediments the team sees for not being able to do the actions. Maybe there’s a deeper problem that’s blocking them? Or they came up with actions that turned out to be infeasible, or not useful? Either way, it’s good to reflect on the actions, to make sure that retrospectives are bringing value to the team.

Conclusion

Agile retrospectives are a great way for teams to improve their way of working. Getting actions out of a retrospective that are doable, and getting them done helps teams to learn and improve continuously.

Note: This Blog is written by Ben Linders and originally published in Bridge Global Blog