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 organization, 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 organize 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?