Ekipa.co – 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.
Read More: Best Agile Training Program This Year
Why do Agile 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 a 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 starts by doing things, learning, and improving along the way. Just like you don’t know all requirements upfront 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 have 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.
Read More: Most Credible Agile Scrum Master Certification in Indonesia
How to do Agile 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 many different techniques you can use to conduct a retrospective, from asking questions with post-its to collecting and organizing answers, building timelines, root cause analysis to playing games (see Getting Business Value from an Agile Retrospective which explains many of these have been review use retrospectively). 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?
- Should we do it differently next time?
- What still puzzles us?
Insight of the Questions
For me, these questions have shown to be very effective. I like the question “What did we do well”. It is a solution-focused approach to finding useful strengths 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 that had remained unspoken before I asked the question.
Read More: 6 Steps to Begin Your Agile Transformation
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 in their workspace. Then, 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). Then, plan the time to do it. By doing it like this, I’m helping teams. Also, it develops continuous improvement skills, being able to efficiently manage their own improvements and deliver more value to their customers. For some examples of visibility, Continuous Improvement, Make It Visible!“ by Ben Linders.
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 did they come 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.
Read More: Things You Should Know about Agile and Innovation
Conclusion
Agile retrospectives are a great way for teams to improve their way of working. Getting actions out of a retrospective that is 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.
