One of the best parts about creating great software is getting to collaborate with others. It's also one of the hardest things to get right. The best software developers are not the 10x developers who know how to build everything themselves. They are the team players who know how to be a force multiplier for all the other people involved with a project.

In Agile methodology, a retrospective is run at the end of each sprint. When run properly, with a willing team, a retrospective accomplishes the core mission of enhancing collaboration across a development team and increasing the overall efficacy of the development process.

Retrospectives allow a team to identify and discuss issues within a project and work together to solve those issues.

What is the goal of a retrospective?

Retrospectives (i.e. retros) are meetings that generally uncover three things:

1. What went well during the sprint?
2. What didn't go well?
3. What could be done better next time?

These seemingly simple questions have a huge impact on team morale and cohesion and help teams refactor their process by learning from past mistakes and growing together.

“Greatness is not a function of circumstance. Greatness, it turns out, is largely a matter of conscious choice, and discipline.”

• Jim Collins: Good to Great

Chances are, a team is a mix of different skill levels, aptitudes for social interaction, and hopefully different backgrounds. It is said that diverse teams build better software, but how does a team learn to gel? How do people know the right feedback to give or when to give it?

What happens when:

• A project or week doesn't go well?
• Rifts begin to build in teams?
• People get angry or frustrated and have unproductive disagreements?

It would seem like stopping everything to address those concerns would make sense - however, the feature requests and bug reports don't stop, and the team still needs to deliver effective software. If left unaddressed, those ragged edges will continue to fray and eventually pull teams apart. So what's the solution? While not a silver bullet, sprint retrospectives are a great place to start.

Make retrospective meetings more productive

Meetings can often have too much unhealthy agreement vs. healthy disagreement, with retros commonly falling into the former.

So what are the pieces that need to come together for an effective retro?

Set ground rules

Instead of jumping right to the formal retrospective questions above (which can often lead to blank looks or tacit agreement), start by laying the ground rules. This frames the conversation and sets up people to think about the conflict before it starts.

Here are some ground rules that are helpful to establish:

Be respectful

Creating software and building products is much more than just putting in time and money, and having excellent features come out. Everyone is on the same team - work together, respect one another, leave egos at the door, and enter each retro with a growth mindset.

What's said in a retro stays in the retro

Retros are the time and place to push people to be their best selves, be critical, and talk about how certain behaviors impacted the team. It's a safe space to ask for help and identify areas of improvement. It's also best practice to not keep audio/video recordings, and clarify that notes of the meeting will be shared between the meeting attendees only.

The goal is to work on the process

When developers write software, it's a reasonably personal endeavor - and sometimes they feel other people are blocking their work. But it's important to realize everyone is on the same team, and it's not the time or place to make things personal. Questions about code quality are not the point of a retro and should stay in respectful code reviews.

Stay on track

In general, retros should be around an hour. Software developers are well known for "solutionizing" and over-engineering. But the goal of a retro should be to suss out issues - not come up with solutions to every problem. It's easy to break down the first problem that is presented and spend the rest of the meeting coming up with a solution. Instead, note the issues and move on. Problems that require follow up will become apparent, and solutions for those issues should happen in a separate meeting.

Focus on unity

It should go without saying that projects are more effective when team members feel safe to share their experiences and have a desire to work on growing together. Retros are not a place for anger or decision making by seniority. All ideas should be on the table, and nothing should be shot down without healthy discussion. Effective retros will elevate the entire sprint process by helping the team to work with, and not against, each other.

"If you could get all the people in the organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time."

• Patrick Lencioni

Have a prepared facilitator

The facilitator should guide the meeting intentionally, not letting any one person or topic dominate the discussion in an unhealthy way. This process can often be difficult when team members are invested in their issue or point of view, resulting in lots of discussion on how to move forward. The goal here is to make sure everyone is heard and divert conversations that aren't immediately applicable to future actionable items.

The bottom line - if the facilitator senses unnecessary discussion, off-track topics, or that things are going too far, they need to get the meeting back on track.

Have actionable takeaways

It's not enough to write items down and never revisit them. Each action item should either be assigned to an individual or put in place as a new standard for the team. That way rather than only reminiscing on the tough parts of the last sprint, having clear action items and assigning them to the right people will leave everyone feeling empowered, excited, and with a sense of forward momentum. Write action items down during the retro and review them at the end to get buy-in and a sense of shared team accountability.

When retrospectives don't go well

That all sounds great...but in reality, it's not always that cut and dried. What are some common reasons retros don't go as planned?

Retros are an afterthought

This is the most common reason given from people who don't like retros. When they seem like an afterthought and little time is spent on them, of course, they aren't well received. But, just like many things in agile, the important part of sprinting is taking action to correct issues over time - not letting those issues continue sprint after sprint.

There are no effective outcomes to the retro

Retros provide a format for everyone to be heard on a development team. Sometimes being heard is enough, and retros can provide a safe space to vent. But some issues are more critical than others and require action to be taken - sometimes immediately. If those issues aren't taken seriously and no corrective measures are put in place, it can feel like a lot of wasted effort. Keeping good notes and writing down action items is a good first step to combat this issue.

There are zero or few issues brought up from the retro

There are always problems - no matter how many people tell you that everything is peachy, things can always get better. For teams that haven't seen a retro before, or have seen ineffective retros, there can often be a propensity to just ignore issues because "nothing changes".

Refresh your retros with new ideas

The solutions to these problems are not to stop doing retros. It's rare to hear, "the process is perfect, we should never change it" in any development project. So what are some ways to approach retros in new ways and unlock a better process?

Start with a light question

Developers are often stuck working in their own world. They often have to stretch their comfort zones to work well with others - but it can be hard to connect with everyone, and some people on the team may be less outspoken. One way to help set the tone is to ask an ice breaker question or a question focused on feeling. People open up more and are better able to give/receive criticism when they feel they are in a safe and trusted environment.

Some suggestions for kicking off the meeting:

1. Ask for a "feel color" (i.e., red if things are going terribly, green if things are going great)
2. Ask about weekend plans
3. Other ice breaker topics that can get the room talking

Change the facilitator

In the capital "A" Agile methodology, retros are supposed to be run by a scrum master. However, this choice can result in lower than ideal participation - especially if no action occurs. This meeting should not be hogged by a team lead or someone "up above" - this is to help developers increase efficiency. One way to encourage the team to be open and have a growth mindset is to have one of the developers to facilitate the meeting.

Ask for feedback before the retro

If there is a group of non-participants, it can be helpful to ask those people to write their opinions down before the retro. Then at the meeting, ask those people to share what they wrote down prior. This goes a long way to increasing participation from people who feel they can't share at the moment or need more time for preparation.

Retros at Headway

Retrospectives are crucial for us here at Headway. They not only help us hone our process and continuously improve each week as we work to bring new ideas to market - they also help improve relationships with clients and partners, and in turn, help us build better products.

Retros fit well with our Guiding Manifesto and are imperative to ensure that we grow together, rather than separately. While we still spend time individually improving ourselves and enhancing our craft, retros let us do that as a team - which improves our ability to deliver software together on a sprint by sprint basis.

Free Download - Project retrospective template

This is the retro document we use at Headway. We hope you'll give it a shot! If you find it useful, feel free to share it with your friends and colleagues.

Template for Retrospective Meetings

Thanks to Amy Marco for encouraging me to explore team building and for the structure of the awesome retro document that I continue to use to this day.