Retro Grade

Out of all the Agile ceremonies, it seems like retrospectives tend to go to pot first (if they’re done at all).

They turn quickly into complaining sessions, with no visible signs of progress. It’s easy to schedule an hourly meeting every couple weeks. We can say objectively that that happened. It’s much harder to actually fix all those things people complained about.

And there’s nothing more demoralizing and demotivating than marching through a ceremonial process over and over that we know is not going to change anything.

I propose that every worthwhile retrospective must begin by discussing the progress made on the action items produced in the previous retrospective. This of course necessitates that action items from a retrospective are first-class members of the next sprint backlog, i.e., the list of work items the team commits to delivering by the end of the sprint. Without accountability and trackability, let’s just admit our retrospective is a show trial—a farce—lip service to the Agile ideal of continuous improvement.

And the thing is, once you begin this backslide, there’s no returning. The retrospectives become less and less productive, people stop speaking up, and the value of the ceremony erodes into nothing. Why is no one speaking up in the retros anymore? Because they know it’s pointless.

Unfortunately, there’s no escaping hard work in software development, no matter how many meetings we put on the calendar and what we call them.