Skip to main content

Blog Post

The Power of Retrospectives

What is a retrospective?

A retrospective is a meeting of a project’s team members to discuss what went well, what did not go well, and consider ways to improve things. They are done once a software project or sprint has ended. It is part of the continuous improvement feedback loop which is key to making things better.  

Retrospectives are also known as post mortems. I prefer to call them retrospectives (retros) since post mortem has such a dire tone. Also, it is not the ‘end’ of a project. There is usually more work to do such as enhancements and maintenance. 

Why retrospectives are important? 

Retros are a valuable way to get constructive feedback that are used to improve current and future projects. Feedback is vital to any company’s survival. Retrospectives are a great tool to have in any project toolbox and can add tremendous value. Employees feel engaged and empowered to contribute to positive changes. It provides a communication venue where ideas are openly shared. Action items are decided on by the whole team. 

When should we have retrospectives?

In most cases retrospectives are conducted at the end of a project or a major milestone. They can also be done during the middle of a long project when using waterfall. In agile shops, they are done after each sprint if the sprints are three weeks or more and every other sprint if they are two weeks or less. It is really up to the team and how they benefit. Retros should organically become part of the team’s culture

To make sure that retros are being done, they need to be scheduled as part of a project. The meeting should be held at a time when everyone can attend and usually last an hour. Retros should not be done only after a bad release, but also after good ones. I have seen where retros are only done after a bad release which sends the wrong message and compromises the value they bring. Retros are a positive tool and should be done whether the project was good or bad.

Who should attend?

All members of a project team – developers, QA, PM, product owners, etc - should attend retro meetings. They can also include members of other teams that participated in the project, particularly when there were dependencies on them. 

Retros can include clients as well. Their presence should be welcomed. It provides a wonderful forum to demonstrate and add value for the client. They provide a great opportunity to get feedback from the customer and to appreciate them.

How are they run?

To run a successful retro you will need an impartial moderator. He or she should not be from the team nor have any “stakes in the game”. Someone needs to keep notes and track action items. The moderator should solicit discussions and feedback, but needs to keep track of the time to make sure all points are discussed, and not get bogged down on any one point. Keep the conversation flowing. If there is a real sticking point then set up another meeting. Or bring it up again at the end once the other points have been discussed. Going into a retro, everyone needs to believe that all participants tried their best with the information provided to them. 

I have been in retros that turn into a blame or complaint session. These are not productive and uncomfortable to be in. Everyone needs a chance to vent some as long as it doesn’t become the main focus of the meeting. 

What should the agenda be?  

The retros I have been to have an agenda which include discussions on:

  • What went went well?
  • What did not go well?
  • Appreciations
  • Action Items

There are different variations of these including the Good, the Bad, and the Ugly.

 

One of the first things to go over is progress on assigned actions items. If they are not brought up at the beginning of the meeting they often are forgotten. Also, it keeps folks accountable for their items. Most action items come from the ‘not so well’ category and provide a great source of improvements which in turn become action items. Make sure someone is assigned to each action item. Don’t let just one or two persons do all the action items. It is a team effort. 

After the actions items, it’s best to start with - What went well. Starting there sets a positive tone. I have also seen where appreciations are done first. 

What is expected of the participants? 

Throughout the project’s life cycle, team members should keep individual notes and look for things that can be improved. Make a note anyone doing a good job so they can be appreciated in the retro. 

During the retro meeting each team member writes notes on what they have observed and place them in the corresponding categories. This usually can be done in 10 minutes. Some retros do that before the meeting and some during, or a combination of both. Whatever works for the team is best. Notes can be anonymous. The facilitator organizes the notes on a board and discussions can begin. They need to bring sticky notes or index cards as well as pens or pencils to the meeting.  

When everyone is located in a physical room then a board is used. Since a lot of teams have virtual members a virtual board can be used or a computer screen shared. When using something new test it before the meeting. 

To conclude, retrospectives are a powerful tool and need to be used often. A cost efficient and great way to get feedback. I have seen a lot of valuable ideas that improve a company come out of retros   These idea will improve efficiency and reduce costs. Best of all it give the participants a real feeling of engagement and empowerment. 

Website Launch Checklist

Additional Resources

Why QA Your Website? | Mediacurrent Blog Post
5 Easy Ways to QA Your Site | Mediacurrent Blog Post