Retrospectives: Why?
If you’re new to retrospectives, you might think it’s just about solving problems. Of course, largely, it is, but it’s kind of bigger than that. Following on from my last post, I did some thinking about the real reasons, the underlying reasons, we do retrospectives. I think it’s ultimately about team improvement, both addressing problems but also finding ways of amplifying and repeating successes. If you follow the practice of categorising retro topics under smilies and frownies, even then, you could easily populate the smilies column with things to celebrate (hey, celebration is good) and miss the opportunity to post new techniques or working practices that were successful (e.g. “I cut my coding time in half by having a deep conversation with marketing first”).
There’s a follow-on to the objective of improvement too. The question “Do we need to do retrospectives ?” becomes “Can we improve ?” and I think the answer to that is almost always yes. Granted, I guess there will be some teams for whom this kind of inspect/adapt cycle happens spontaneously without the formality of a retrospective, but for the vast majority of teams, retrospectives pay dividends.
So anyway, I tried to sum this up in a statement which could be read out with the prime directive, or rolled into working practices, or whatever.
We would like to think we could be the perfect team, but we accept that almost nothing is perfect, and we can improve how we work.
Since the last retrospective, we did lots of things, and lots of things happened. Some were good, and maybe some were bad.
Let’s look at the most significant of those things, and see what we can learn about improving how we work as a team.
