Agile Retrospectives Improve Team Relationships

I get a lot of questions about agile retrospectives from existing clients who are familiar with agile, those new to it, and folks who don’t use agile (so, yes: everyone!). This is one in a series of posts on retrospectives covering a variety of angles on the subject. [Agile Retrospective Resources has a list of the upcoming articles and many other resources.]

What is an agile retrospective?

An agile retrospective (often simply called a retro) is a regular ritual focused on celebrating, learning, collaborating, committing, and improving the team’s relationship.  These items, taken together form the value of an agile retrospective.  There are different types of retrospectives (e.g. release and project retrospectives); though here I am focusing here on regularly scheduled team retrospectives (e.g. sprint retrospectives or iteration retrospectives).

If you are not familiar with agile, an agile team works to deliver results every few weeks. At the end of that period, the team looks back and considers how things went, what went amazingly, what did not, what ideas could produce improvements, and then decides if they (the team) want to commit to any of those ideas. The team focuses on what they can improve over the next iteration (or other short time frame).

Teams that work together and take time to have retrospectives learn about each other and improve their relationship as a team. Having time to pause and focus on the team and how it works together is a primary benefit of a team retrospective.

A primary benefit of a retrospective is improving the team’s relationship.

Teams that use agile approaches to deliver results schedule time for agile retrospectives in order to look back (in some cases forward – but that is another topic). For a team working in 2-week iterations (or sprints), there would be 26 formal times a year for the team to focus on this ritual. It is an amazing opportunity that many people in today’s work world do not have! If you have the opportunity, use it!  I’ll talk more about the specifics of how to run a retrospective in another article in the next week or so (subscribe if you want to be notified of new articles).

Change and improvement is often touted as the primary purpose of a retrospective. While ultimately true, just focusing on those two words can have negative effects. If retrospectives are only organized around the theme of “what can the team stop or start doing,” the value of the retrospective is lost.

We see a lot of situations where people generate a big list of “all possible changes” or “all the things that went wrong,” without any interest on celebrating (for example). Sometimes this is with best intentions; we want to see all the ways we could improve. Other times, this can manifest as someone trying to force a team to “do all the ideas on a list.” When this happens, people stop coming up with ideas and complain that retrospectives have turned into “blah blah blah” boring meetings. So change and improvement ARE important, but don’t let them cause you to sub-optimize and lose the overall value of the retrospective!

Do you have to be using agile, or even know what agile is, to use retrospectives? The short answer is no. Anyone can use them and should. It can be a little tougher if you are not focused on delivering incremental results, but it can and has certainly been done.

Team Relationship

The team’s relationship should always be improving. Certainly the team should work on improving other more tangible items as well, but don’t kid yourself–if they team’s relationship is a wreck, they won’t be able to commit to meaningful improvement!