Most bad scrum practices are merely bad because they waste your time, and sap your energy. What makes retros special is that their impact goes well beyond their wasted time.
The first time I had a retro session, it started as an event scheduled for an hour, that turned into an out of control whining and blame session that took the whole afternoon, only for nothing to get done. Taking into account the salaries of the people involved, the number of them, how long it took, and the frequency, the waste was staggering. The powers that be balked at expenses that were far cheaper when you calculated them.
But that's because the retro was unproductive. No one took notes, no one did anything with what was said. It was just a perverse reverse therapy session.
It turns out that retros can actually get less productive with this. At my next company retros were different. They had a leader who wrote down a list of actions. And that's when things got really bad.
Like so much of agile, retros intuitively sound like a good idea. Who wouldn't want to regularly reflect on how well they're doing and see how they can improve? But, like the rest of agile, this is just warm and fuzzies without substance.
Far from improving things, retros are the root cause of so much process and red tape.
This is because:
- They aren't driven by need, but by methodology
- You have to find some action otherwise it's seen as a waste
- The only available tools are bureaucracy / process
Lets go over those points in turn and see what the consequences are.
Retros Aren't Driven By Need
Like the rest of scrum, retros are a scheduled "ceremony" that takes place during a sprint. Without retros, people generally notice when they have problems and talk to each other. If it's serious enough, they try to organise something with the wider team and do something about it. And when things are OK, or only slightly inconvenient, they don't bother. But with retros you always have them, even if things aren't that bad. Of course, scrum fans appeal to humility "we can always do better!". But in reality there aren't always problems, and trying to solve problems that aren't really problems is bad.
A Problem / Action Must Be Found
In an effort to avoid the first scenario I mentioned, the "on it" people will always try to write something down and show that they've done something as a result of the retro. And the retro format means people will look for some problem, to which we discuss and schedule a "solution".
One of the more insidious cases of this is when there's a problem during a sprint that's clearly a one-off. Maybe someone just left or joined the team and there's an adjustment period. Or maybe it's during a launch event. Or maybe it's the Christmas holidays and there aren't many people around. These events are clearly exceptional, and yet when people are asked to think about problems these come to mind regularly as they're happening. Any "solution" to those problems that you have to keep doing the rest of the year is going to be wasteful, and if it weren't for retros people wouldn't bother.
People are also incentivised to find problems. One of the pieces of feedback I've gotten was that I needed to speak up more in ceremonies. Indeed, talking is how you get recognised and promoted. The more problems you can find the wiser you seem.
Process Is The Only Tool
Almost invariably, every action has been some sort of extra step we have to manually follow, another meeting, or another flaky and demanding step in a pipeline. They never agree to something like getting rid of scrum.
This is why people with scrum often feel helpless, because it seems like there's a grievance process to address their problems, and therefore any problem they feel is their fault.
Putting This All Together
Imagine a weekly health checkup that must end with a prescription. How is your life going to be like after a year, when you need pill soup every 15 minutes? "But no one has perfect health, we can always improve!" In this scenario the cure is clearly worse than the "disease". If every 2 weeks we accumulate 3 pieces of process, that's 78 pieces of process a year. Complying with that much process makes it a huge fucking pain to get anything done, and that cost is a worse problem than most of the things people complained about during the retro.
Maybe every single one of those 78 actions, viewed isolation, had a greater benefit than cost. But, when evaluating process you shouldn't evaluate things in isolation - you should look at the meta-process that results in you adopting a process, and compare the total cost of all the processes it will make you adopt, and compare that to the total benefit.
Far from resulting in enlightened, well oiled teams, retros are red-tape factories.