tl;dr – retrospectives should be effective or abandoned; and retrospectives can only be effective if time and effort are spent on fixing the issues raised.
I first worked with agile in 2003. Back then, it was very much developer-led and it sometimes took significant effort to persuade clients or management to adopt these practises. Agile had to be justified by results, and those were compelling enough that larger organisations adopted frameworks such as Scrum.
Fitting flexible methodologies into corporate structures that require predictability is challenging. Sean Goedecke’s essay Seeing like a software company discusses how large companies sacrifice fast delivery for ‘legibility’. He makes a case for this trade-off, but the need for predictability often limits the benefits of agile, leading to top-down structures and, before long, something like SAFe, in which the team’s choices are restricted by the perceived need for centralised co-ordination.
It’s interesting to look back at things that were considered important in the early years of agile that have fallen by the wayside. A lot of teams have unclear or multiple sprint goals, and no longer able to deliver a single unit of value in a sprint. A sprint is never allowed to fail and restart, because teams are often expected to follow a company-wide agile calendar. Commitments to build features are made months in advance, defining future sprints and removing any real agility. Organisations even try standardising story points between teams to compare their output.
Another lost concept is that of the ‘sprint’ being a sustained, time-boxed period of effort, with breaks in between. You had a two- or three-week sprint, followed by a few days to reset, improve tooling, and prepare for the next one. Planning for the next sprint was not crammed into the closing days of the previous one. This allowed time for one of the critical aspects of successful agile: continuous improvement.
Too often, particularly under SAFe, teams have several development sprints planned out, leaving no room to invest in improvements. This leads to pointless retrospectives. The same complaints surface time after time, but there is no opportunity to address them. Developers are not allowed to improve their working methods – even though good developer experience and happy teams correlate strongly with high performance.
As a result, many agile teams fall into learned helplessness, feeling unable to change things. Teams accept limitations and stop challenging them. Rather than empowering teams, retrospectives simply confront the team with their own powerlessness, damaging morale. You can dress your retro up with as many light-hearted themes as you like, but if you’re not fixing anything, what’s the point? At its worst, a lack of continuous improvement means that process debt and technical debt slow the team down more as time goes on. Before you know it, you’re looking at year-long release cycles and all that.
Teams need to be given the space to improve their working practises and environments. It should be easy to make the case for this against feature work. Investing in the team’s velocity will always be a good investment.
In short, when something turns up repeatedly in retros it needs to be dealt with. Retro actions should be prioritised in the same list of work as everything else (see this essay by James Stanier, One List to Rule Them All). And, if your retros aren’t getting anywhere, then there are more useful ways to spend the time.