Sprint retrospectives. We’ve all done them. We’ve all come out of them hoping and wishing that things will improve next sprint. Sometimes they do. Sometimes they don’t. But what would happen if they always did?

During a sprint retrospective, you cast your mind back over the past sprint and think about what went well and what did not go well. The major take homes from a retrospective are to:

  • keep doing the things that work
  • stop the things that did not work
  • suggest ideas to improve the things that did not work, with the goal to ensure they improve next sprint

We can conclude from this that any sensible and proactive team is working towards only ever doing things that work well. We can also conclude that this same team is working towards never doing things that do not work well.

Given enough time plus a team that only ever improves their way of working, we could say the team is ultimately heading towards their perfect way of working. Conversely, we could also say they are heading towards spending progressively less time improving since there will be less to improve.

If a given team follows this pattern, and, over time that team heads more and more towards the perfect way of working, doesn’t that eventually reduce their need for a sprint retrospective? It may be a tad Darwinian, but couldn’t a self-managing and self-improving team ultimately evolve beyond the need to retrospect ever again?

Of course, we must consider the factor of change. Change is often not foreseen, and can be frequent, annoying, beneficial, derailing, motivating, you name it. For a team, a change (positive or negative) could cause an issue. In a retrospective, you work the other way around - you try to convert an issue into a positive change. So can the theory still hold true? An unforeseen change occurs which causes the team an issue, the team retrospect the issue and deal to it. They get back on track, moving full steam ahead, meanwhile holding their breath before the train master yells out again “All change, please!”

All theories have caveats, so here are a few:

  • The team members never change - no one joins, no one leaves
  • The team always implements every single improvement proposed during a retro
  • The team is working on a single project
  • The team is capable of converting all unforeseen change to their benefit
  • The project lasts forever

Clearly, these caveats are very unlikely to be true in reality and I am sure you can think of more. However, the definition of what a retrospective aims to achieve suggests that, at the very least, they should become shorter and easier with time.