The annual agile retrospective report describes the state of practice in agile retrospectives. Let’s explore some of the conclusions from the 2017 report to understand how retrospectives are currently being done and the value that they bring.
Survey
The survey has been done by Retrium; I helped them getting the message out to the agile community by announcing it on my blog (see Join the 1st annual Agile Retrospectives survey) and by sharing it in social media. And of course I also participated by submitting the survey.
The aim of the survey is to gain a deeper understanding of how retrospectives are used in the real world and find out how good we are at retrospecting.
277 people from all over the world responded from organizations that use agile software development practices and run retrospectives with their team. A nice result given that this was the first time that this survey was done.
The annual agile retrospectives report 2017 was announced at Agile 2017 early August. I did an interview with David Horowitz on InfoQ where we discussed the results from the survey.
Benefits of retrospectives
Retrospectives help teams to improve collaboration and communication is what I have stated over and over. The survey report confirms this, 85% of the respondents mentioned improved team communication as a benefit that they got out of their retrospectives.
Creating an environment of trust, improved team productivity and improved quality of work are also mentioned as benefits coming out of retrospectives. Trust is key for people to work together, great to see that that retrospectives result in higher trust levels. I’ve seen this happen in many retrospective; when the right atmosphere is there then people will be open and honest which leads to more trust.
How often are retrospectives done
Most teams do weekly retrospectives at the end of every sprint, every other week. This is a great way to do continuous improvement.
I hear the same when I’m teaching agile retrospectives, and I also advice Scrum teams to do a retrospectives at the end of every sprint. For Kanban teams my suggestion is to do weekly retrospectives; my experience is that Kanban teams tend to be more mature in agile and prefer to do small frequent improvements.
Who attends the retrospective
Teams often struggle with who should be invited to join the retrospective. This is what the survey reported:
I’m surprised to see that only 75% stated that the Scrum master should be there. I can only hope that other respondents see their Scrum master as a team member, or maybe don’t have a specific Scrum master assigned (something I see with Kanban teams or very mature agile teams).
Doing retrospectives without the Scrum master for me doesn’t make sense; collaboration and communication between the team members and the Scrum master is crucial and the retrospective helps them to improve this (which is what the survey results confirmed).
Only 66% stated that the product owner attends the retrospective. I discussed this before in should the Product Owner attend the retrospective:
Preferably, the Product Owner is there, after all, the entire Scrum team evaluates how the sprint has gone, and the Product Owner is part of the Scrum team. In addition, cooperation between the Product Owner and the development team is something that can be explored in retrospective, which makes it important that the Product Owner is there to participate in the discussions.
Retrospective exercises
When it comes to the techniques (exercises) that are used in retrospectives the data from the survey confuses me a bit.
It looks like many teams are just following the Scrum guide using the three questions. There are other techniques like the sailboat (described in my book), 4Ls, 5 why, and Stop-start-continue (which I enhanced into start-spice-up-stop) and it looks like people know some of them and sometimes use them. But I’m getting the impression that many teams are not getting real value out of their retrospectives, they could improve the outcome by varying the exercise.
In my InfoQ Q&A with David Horowitz I asked him whats keeps people from using different exercises in their retrospective
It’s clearly not a surprise that that’s the most common technique and the survey proves it with 88% of respondents indicating they have used it as either a facilitator or participant, including a whopping 46% saying it was their most commonly used technique. You’re also right that there are countless other techniques teams can use, but don’t.
Perhaps the reason why most teams stick to “what went well and what didn’t go well” is that teams, companies, and even our industry aren’t placing sufficient emphasis on the value of the retrospective. It becomes a Catch 22. People complain that their retrospectives are boring, but don’t put time and effort into learning new techniques to help overcome the lack of engagement. And because they don’t learn new techniques, their retrospectives remain boring.
We need to break this vicious cycle. Unfortunately, just saying, “use a wider variety of techniques!” doesn’t seem to work. Instead, it’s up to us to prove the value of the retrospective, even via its most basic “what went well and what didn’t go well” format. If people find that their retrospectives are driving real change, they will become more interested in learning new and innovative techniques.
I tend to agree with him. In my retrospective workshops I practice different exercises in teams. I often hear from the attendees that they didn’t know that these exercises exist! I created the Retrospective Exercises Toolbox to make it easier to find exercises and try them. And you can Ask your Retrospective Question, most questions asked are actually about which format/exercise to use.
It helps: I train teams throughout the year all around the world, every day hundreds of people visit the toolbox, and I hear back from people who played the exercises that I suggested. But it’s not enough.
Value of retrospectives
David suggests that we should “prove the value” of retrospectives. Showing how retrospectives deliver value isn’t easy, but it can be done.
I’m sharing my experiences with retrospectives. I collect research on the business benefits of agile, some of these reports dive into the results of continuous improvement and agile retrospectives. And there are many guest posts on my website, again some are about how they do their retrospective and what they get out of them.
And there will be the first World Retrospective Day on February 6 2018 …
Retrospecting retrospectives
A big thanks to David Horowitz and the team at Retrium who did this first annual survey on agile retrospectives. The insight that the report gives into the state of practice in agile retrospectives helps the agile community to further improve retrospectives and increase the value of them.
I’d like to hear from you. How are your retrospectives doing? Do they bring value to your teams?
Hi Ben,
The pure averages do not matter that much. I would like to see correlations between these figures and effectiveness. Are teams really happier if different formats are used? Does the sm really add much value? Etc. Of course, correlation is not causation, but still, it would be food for thought.
Those are good questions Zoltán! Unfortunately we can’t get answers on them from the survey.
Speaking from my own experience, teams appreciate it when you vary the exercise and tailor it towards their needs. Some of the high maturity teams that I worked with would ask for specific exercises, knowing that they would help to get more out of the retrospective that way.
Who facilitates, and how, matters! I see it time over time in the teams that I work with, in my workshops, and in the retrospectives that I facilitate. For new teams I recommend to have an independent facilitator.
Causation would be even better, but then we should do root cause analysis on retrospectives that are successful and on the ones who failed. I did it occasionally myself, but I haven’t found good data on this …
Hi Ben. A useful and interesting article, thanks for sharing. One thing which stood out for me was that there was no reference to “if” and “how” learnings from the retrospective are implemented. It’s all well and good if the benefits are (or appear to be) understood; the sessions are conducted at regular short intervals; they’re attended by the right people and productive techniques are used – only for the learnings and the behavioural changes to sit on a wiki page or, worse still, lost as the whiteboard is cleaned…
The report contains two pages with data on action follow up, it’s in there. Conclusions are that actions are mostly assigned to people, some have deadlines, and some are written in a SMART format. There’s no survey data on the actual implementation of the actions.
Doing the actions is what brings the real benefits from retrospectives, and this tends to be the hard part in many organizations. A mindset and culture of continuous improvement is essential to make this work.
Better and fewer actions increase the change of effective implementation leading to benefits, as I explained in Vital Few Actions. But still, it’s up to the team to actually do them.