Are Retrospectives Crucial to a Project's Success?

In my previous role, I worked for a large corporation in a technology factory setting. Our main responsibility was to perform inspections and maintenance on existing equipment across a very large campus. From time to time, as I’m sure you can imagine, things would not go exactly as planned and, as a large corporation hired by another large corporation, there would have to be answers for why. Was there a process issue? Were the machines being inspected at the required frequency? Did the person who normally performs this work pass down everything the new person needed to know?

The process answering these questions was called an After Action Review, or an AAR, and was outlined in an old Word document that was largely centered around The 4 Whys (which is: Why? Why? Why? Why?... Just like that… in a Word table). It was a miserable process. After interviewing the people involved, taking pictures, and writing up a historical record, you would be asked to present a root cause. The written procedure has not been updated to the new specifications, for example.

Missing from this process, though, was any form of retrospection. The team members, who would be responsible for continuing work on whatever was broken, did not have much say in how to improve the process or avoid this mistake in the future. So, you can imagine my surprise when I went through Scrum Master certification and found out there were two hour retrospective meetings to talk about a 2-week period of work. What could they possibly talk about after the first few meetings?, I naively thought.

Having the space to openly discuss why something didn’t work, without the fear of having to drill down to a root-cause analysis level, or present a big document about why, is what makes retrospectives crucial to the success of Agile projects. The team has the chance to iterate on ideas and talk about improvements together. We can set ourselves up for the next sprint with new processes to experiment with, or a more clear direction, or even more planning than we thought we needed in the previous sprint.

What the After Action Review failed to consider was incremental improvements and reflections on a process. Often, the managers (myself included) were not looking for a long term solution to the mistake, but a root-cause that could be added to a presentation. At Planet Argon, it feels good to present something you want to try, either in a sprint retrospective, or just in the normal churn of business because there is the feeling that folks will embrace it with you, and give something new a shot. Everyone is a professional, everyone wants to do good work for their clients. So why not iterate? Why not reflect and talk through a process issue with the people you have hired to be developers?

A final note about success: it’s tricky to know when something is "done" in iterative software development because the work continues on (or around) something that continues to exist. So one of the ways I try to communicate success to the team is by logging feedback from a client during a sprint. We work closely with our clients, especially during some time sensitive, sprint-based work periods, and it is really easy to lose the nice things people say when you’re exchanging a high amount of messages in Jira, or on Slack, or through email. I like to start retrospectives with these messages, even if the development team has heard them before, because it sets a tone for the conversation. It reminds people that they’ve done good work and that the client sees them.

I would encourage any organization to implement some form of retrospective on a period of work. It doesn’t have to be a two-hour sprint retrospective, but it does have to be an open conversation about what worked, what people would like to iterate on in the future, and how the amount of work felt. More importantly, a retrospective allows everyone to be involved in the work process, which will lead to the cooperative feeling of improvement and, hopefully, success.