Introduction To Agile Retrospectives: Project Manager Dos and Don'ts

I remember hearing about Agile for the first time. The concept behind it seemed pretty straightforward: sprints, planning sessions, and backlog—it all looked like it could really help us accomplish more in the same timeframe (especially in comparison to Waterfall). 

As a project manager, I was really eager to introduce all these changes in my teams and start driving performance skyward. However, what I had trouble wrapping my head around was the concept of “retrospective.” I mean, what was the point? Weren’t we supposed to focus on delivering projects instead of wasting our time on more meetings? 

I needed some answers. Here’s what I found.

What is an Agile Retrospective?

An Agile retrospective, or “retro” for short, is (typically) an hour-long meeting every team should hold after each sprint (or every week, if the team does not work in Scrum) to discuss what went well and what didn’t.

The team also examines any and all obstacles encountered in the previous sprint and discusses ideas for improvements that would allow them to avoid these issues or mistakes in the future.

The retro is also a good opportunity for the whole team to look for any outstanding issues in the workflow and collaboration practices. This isn’t usually possible when people are busy working. During a retrospective, you and your co-workers can relax and focus on finding ways to improve collaboration inside the team and, consequently, your overall efficiency.

The outcome of any retrospective is a list of points outlining what the team wants to improve on or what changes they’d like to introduce into their daily process. At the next retrospective, the team can check whether the issues brought up at the previous meeting have been eliminated and whether their ideas proved useful. That’s why it’s so important to have the meetings at regular intervals. Even if a team does not work in sprints, they should agree to either weekly or biweekly meetings in order to control progress and improve.

The Who-What-When Steps To Action activity helps define commitments and follow-up actions during meetings.

Why Are The Retrospectives Important?

It’s all about continuous improvement. Nobody likes making the same mistakes again and again. Me and my team were there. We were so focused on delivering new stuff to the client that each week we wasted a portion of our valuable time fixing the same issues we’d already fixed the week before. We didn’t even realize this was a recurring issue, happening each and every week for a month and a half. The only thing we had to do was notice this mistake and then stop making it, but we were too focused on the work! The amount of time wasted on fixing that particular mistake added up to nearly 20 hours!

That’s where the retrospective comes in handy because retrospectives are all about continuous improvement.

One of the twelve principles of the Agile Manifesto states:

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

The principle above, in my opinion, directly corresponds to another outlined in the Manifesto:

“Continuous attention to technical excellence and good design enhances agility.”

If a team is given an opportunity to improve their workflow, eliminate recurring problems, and focus on developing best practices, they will, in the long run, save themselves and the company a lot of time. That is a fact. 

Additionally, continuous improvement practices will start spreading to other teams and, ultimately, to the rest of the company, improving the quality of services rendered by the company.

What's The point of an Agile Retrospective?

• It creates an environment encouraging continuous improvement

A team which focuses on solving issues and finding ways to improve creates a continuous improvement culture. Such a team will get better over time, and, consequently, its members will figure out the most efficient ways of delivering the best value to the clients.

• It serves to empower teams

During the retrospective, teams make and own their decisions. They agree to improve something together and feel responsible for the outcome, which, in turn, directly affects the team’s maturity and efficiency.

• It works as a team-building meeting

This works especially well in “new” or “young” teams, where people are still getting to know each other. A retro can help them understand the value of being a team and solving problems together.

• It helps people vent their frustrations

We all get frustrated and a retro is the perfect opportunity to actually talk about this in a comfortable environment, where there are people who actually understand you.

Agile Retrospective Ground Rules

Before you get all happy about this magical solution to all your team’s problems, hear this. 

It’s pretty easy to screw up a retro.

So, to make sure you get the most out of your retrospectives, here are some good old dos and don’ts for all you Agile enthusiasts out there.

Dos:

1. Have a plan

As a project manager or Scrum Master running the meeting, it’s important to get ready ahead of time and prepare an agenda for the meeting. Also, there are many great ideas about how to run a retro session all over the Web.

2. Create a safe environment

People usually need to feel safe to be able to speak freely about any frustrations, issues, and obstacles. Make sure no one will interrupt the meeting. Also, remember to let everyone speak. If there are team members who would rather write than speak, prepare an exercise with post-it notes.

3. Criticize actions and behaviors, not people

Always focus on WHAT, not WHO. Find ways to improve your efforts together, as a team. Instead of blaming John for the team’s failure, focus on the mistakes he made and try to find solutions. 

4. Own the meeting and take responsibility for the decisions you made

If you make decisions as a team, you are also responsible for getting things done as a team. The team members decide who does what and later check on the progress during the next retro.

5. Analyze and observe the working environment

It’s a good habit to actually observe your working environment during the sprint, so you can all bring your observations to the meeting and discuss them as a team. Try asking questions like:

• What went well and should be kept in the workflow?
• What did not go well and how can we improve it?
• What are the main obstacles in our daily workflow and how can we remove them?

6. Team building—get to know each other

Chances are you’re going to be working on a project together for at least a couple of months, so it’s a good idea to invest some time in team building during the retrospective.

Here are a couple of pretty good team-building exercises you can use.

7. Have a meeting facilitator

Either a Scrum Master, a project manager, or a team leader, there should always be a person responsible for preparing exercises for the meeting, encouraging discussions, and taking notes. That person will also be responsible for making sure all team members can actively participate.

Go for simple, clear action points like:

• Set up weekly calls with the client’s IT department.
• Store all passwords in secure software or a secure extension.

8. Clarify and discuss

Make sure every issue or idea is clear to all team members and that you have all the necessary information before making any decisions.

9. Hold regular meetings

Having retrospectives at regular intervals (after each sprint) is very important if you actually want to make it work. If you don’t stick to a schedule, you won’t be able to check the team’s progress.

10. Summarize and take notes!

It is crucial to end the meeting with a set of ideas and action points to work on during the next sprint, so you can compare the results of a week’s/two weeks’ worth of work with what you’ve agreed to do.

Don’ts:

1. Hold “complaint sessions”

Avoid having a retrospective devolve into a never-ending litany of complaints. Sure, people should be able to vent their frustrations, but the most important thing is to find solutions and improvements. Track time and let everyone speak, but make sure the outcome of every discussion is an idea. Focus on solutions.

2. Encourage boredom

Team members won’t fully participate in the meeting and will be reluctant to share their insights if they are bored. Boredom usually strikes when teams have been working on a project together for a long time. That’s why it’s important to try different retrospective exercises and techniques.

3. Leak information without the team’s consent

Make sure the team can share their insights in a safe environment. If the team doesn’t feel safe, the retrospective will be useless.

4. List too many points to change

Underpromise and overdeliver—that’s what a good team should do. The same rule applies to the retrospective. Don’t try to improve everything at once. Focus on the most pressing matters and prioritize.

I hope you know more about the retrospective now and I hope it’s as valuable to you as it was to me. But remember, a retrospective is not some magic pill to cure all your problems. It’s a tool and like any other tool it will help you get your shit done, but it’s up to you how you wield it.

The point is to focus on continuous improvement. People who can rely on each other and have the same drive toward technical excellence create the best-performing teams.