There are a couple specific activities that define the scrum process, the specific implementation of the more general category of “agile” software development. One of these ceremonies - the retrospective - stands out to me as critical. Conducting regular retrospectives is so important, it alone deserves recognition as a core value for any organization.

A retrospective is any opportunity to look back and ask yourself “what could I have done differently to get better results?” It’s not a time for finding fault. It’s not specifically a software development thing. It’s a core function of a highly functioning team, whether it’s a team of one or ten. People run retrospectives differently, and the core benefit is the same. Inject feedback into the system. Encourage continuous improvement. Anyone who isn’t looking to continuously improve is going to lose in the long run.

When can you apply a retrospective?

I like to challenge myself to apply the concept of the retrospective in many different situations. The traditional scrum application of the retrospective has the team coming together at the end of an iteration and doing a simple “start/stop/continue” exercise. One instance of the scrum process has the team use sticky notes to put up as many ideas under start/stop, do a sorting exercise into themes then voting to choose what to focus on in the upcoming iteration. Jim Shore does a great job at talking about how the retrospective can be applied in the agile software development process.

Another, very different example, comes from my friends at Manager Tools called the “hot wash”. The hot wash refers to the quick and simple mechanism of taking time to look at what works and doesn’t work. The MT folks apply it to a regular standing meeting. Say your staff meeting with your technical leaders. Take 10 minutes at the end and ask “what’s working, what’s not working” as a way to get quick feedback to incorporate into the next few months of your meeting series. This is a good example of how not every retrospective is tailored to self-organizing teams. It’s you getting feedback from your team that you choose how to apply.

I would argue that we all should be doing individual retrospectives for our own progression to our goals. We should set time aside to ask “are we making the progress we expect?” and setting up some feedback loops around what’s working and what isn’t working. We should be doing this more than the traditional “new year resolution” annual exercise. At least every quarter your goals probably change, and you should be asking if you achieved what you expected. How often do you sit down and think about what you should start, stop or continue in support of your goals?

How do you run a retrospective?

Whether it’s just you or a small team of folks, there’s no reason to overly formalize the retrospective. You need to capture the output. You need to create an opportunity to get free input. There’s two types of input - brainstorming to get ideas on the table, and refinement to evaluate what ideas are worth focusing on. Finally, take a moment to capture an action or two as a constructive change. All of this can be accomplished in 10 minutes at the end of a standing meeting. Or in 30 minutes to an hour for a more serious regular process.

What next?

Run your own retrospective on your goals. Make it an introspective exercise. Or, pick a standing meeting and reserve time at the end of the next one for a hot wash. Attend your development team’s next retrospective and observe if you’re hitting the right mark of continuous improvement for a self organized software development organization.

If you’re always improving you’re on the road to winning.