This is a pretty controversial thing to discuss in a climate where Agile is the go-to methodology for most prolific design and development agencies, but I figured this could be my first blog post as it’s something I can so easily launch into a rant about.
So, here’s my point of view: I have never observed a team retrospective that has achieved anything useful.
For those of you who aren’t as au fait with Agile and its associated ceremonies, a retrospective is a meeting that tends to happen once per sprint, involving the whole team, and gives everyone an opportunity to reflect on ways of working and to understand if they can improve anything moving forward. This is usually done by the team talking about things that they thought went well, didn’t go so well, or could change in some way.
On paper this sounds like a totally plausible – nay, admirable – exercise which can surely only result in the team becoming stronger, working smarter, and producing a burndown chart that brings a happy tear to their scrum master’s eye.
Unfortunately this is rarely what I see in practice. Here’s some examples of the retros I’ve attended…
The Blame Game
Everyone knows why we’ve only burned through 4 points, and it’s because of that d**k Clive. Except Clive says that he couldn’t get any of his work done because of that idiot Sally, I mean her code looks like something out of the early nineties. But Sally says that she was supposed to get extra training from Dan as part of this project but he’s been working from home like, basically the whole time so when exactly is she supposed to learn the new stuff? Essentially, it’s everyone’s fault except yours, and because it’s not your fault there’s no way in hell you’re going to commit to doing anything to fix it. Let the rest of them get their s**t together first. Ugh.
The Shy Ones
The room is quiet, and uncomfortable. The team are determined to maintain peace. It’s just easier to say nothing, keep heads down and get on with it. At least that’ll get us out of this meeting quicker…
The Super Positives
But seriously guys, isn’t everything going amazingly?! Aren’t we such a great team? Let’s spend the next hour talking about how well we’ve handled this sprint. I mean sure, we didn’t finish everything, but pointing that out is just going to hurt morale. And we are really just one happy family, so let’s not do that!
The Genuinely Committed
This is the group that the whole retrospective thing really ought to work for. They want the project to succeed, they’re not afraid to speak up about things that aren’t quite working, but they’re not just going to bitch about each other. Except, there is still a problem here. The prime directive for retrospectives is:
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.
And the problem? It’s that so often, this team knows that one, maybe two people are not pulling their weight. So we don’t believe that at all. And we spend an hour – maybe longer – coming up with solutions to a problem that actually doesn’t exist. Because really all that’s needed is for someone to say, “Lisa. Come on. Sort it out. You’re letting everyone else down”.
However, aside from all of these things – even if it was the last type of team, and everyone was working hard and knew their stuff – there is still a fundamental issue with retrospectives, which is:
If you had a problem getting your work done, why have you waited up to two weeks to do something about it?
The whole deal with Agile teams is that they’re supposed to be, well, “agile”. To be able to adapt to change. There’s even a scrum master role, whose main purpose is “make sure the team has everything they need to do their jobs”. Blockers are (or should be) raised at the daily stand up. If the team is communicating with each other, is there really a need for a retrospective at all?
I realise this is probably going to be pretty contentious and anyone who’s worked with me will likely know my feelings about Agile (that it’s good, it’s considerably better than Waterfall, but boy is it not perfect yet). So I would be really keen to hear from anyone who has found retrospectives to be particularly useful – and why that was.