Two challenges that project teams often face are capturing and acting on knowledge during a project and continuously improving during a project. How can teams capture learning in a way that enables them to act on lessons learned before it is too late? What tools can teams use to improve now rather than later?

Learning from experience during a project can be one of the most important parts of the project for teams that struggle to continuously improve. On Agile projects, retrospectives typically take place at the end of each sprint and provide teams a means of exploring what went well and what could have gone better. Teams emerge from the retrospective energized and ready to improve on their next sprint.

On the other hand, gathering lessons learned in the traditional project management mode typically happens at the end of the project or phase. Information presented here is usually after the fact, when the project has concluded and teams cannot act on the information they generate. Teams often emerge from lessons learned meetings feeling drained, if they choose to attend at all, because the lessons they generate can only be applied to future projects. When one meeting encompasses the entire project, team members may forget about things that happened earlier in the project, which biases the meeting toward the most recent events. As a result, valuable insights from earlier in the project might be lost entirely. In addition, there is less incentive for team improvement given that the team might split up after this project and members might move to different projects.

The good news is that the retrospective structure can work just as easily in a traditional project management environment as it does in Agile. The main change is that the team must establish frequent and consistent checkpoints. Both Agile and Waterfall teams also need to make sure that insights generated in a retrospective are tracked somewhere and are visible to teams. Many insights are actionable, but without attention and follow-up, no action will be taken on them.

What are the steps to holding a retrospective?

1. Include all relevant stakeholders.

The first step to holding a retrospective is to ensure the right stakeholders are included. The whole team should be there if possible, as well as key stakeholders and decision makers.

2. Set meeting logistics, including duration and venue.

Many teams set the meeting duration using the rule of thumb of 45 minutes for every week of sprint length/gap between meetings. For example, the retrospective for a 2-week sprint should last 90 minutes. While these guidelines are useful, a retrospective can take as little as 30 minutes to complete. If possible, schedule a retrospective for the same space so that all attendees are familiar. If there is any way to leave previous feedback untouched in the same room, that is ideal so that meeting attendees can note feedback from the last retrospective before starting the current one.

3. Prepare and conduct the retrospective.

Sticky notes or sticky flipcharts are commonly used during retrospectives to display feedback. Sticky notes serve two functions. First, notes can be moved and regrouped to identify larger themes of feedback to address. Second, notes allow team members to submit anonymous feedback. Generally, participants should feel empowered to provide feedback anonymously so they don’t self-censor out of fear of repercussions or based on any comments already posted. In organizations with strong cultures of transparency, where team members won’t feel at risk for sharing their ideas, retrospectives can drop the condition of team members sharing ideas anonymously.

Each retrospective should address the following three questions:

1. What has gone well so far?
2. What could be done better?
3. What action items will we take to continuously improve?

Participants write their ideas on the sticky notes and put them on the wall. Give them about 5-10 minutes per question to allow them to organize their thoughts.

4. Collect feedback and find themes

After each question, once all the notes are on the wall, the facilitator should read the notes and look for groupings. For example, if a major issue in the last sprint was lack of communication and over half of the meeting participants have written about that for the second question, then the team should discuss the theme of communication. Generally, if three notes or more reference the same topic, then it can be considered a theme.

5. Determine and assign action items.

Teams should generally feel good about the major accomplishments and opportunities for improvement being discussed openly. They should not forget the last crucial part of the retrospective, which is to determine action items to do things better and continuously improve. Based on findings of the retrospective, teams should brainstorm action items to address what could have been done better. For example, if lack of communication was a major issue, one action item is to set more frequent communication. Action items should be posted along with the retrospective’s findings at an information radiator where all team members can see them.

6. Follow up on retrospective and action items.

Insights gathered from a retrospective and action items to improve the team are only useful if they are followed up on. Follow up on action items to ensure they are carried out, and make sure that team members can see the knowledge gained from the retrospective so they can use it.

Both Agile and Waterfall teams can use these steps to set up retrospectives that capture knowledge and generate valuable action items on a regular basis. By linking the lessons learned to action items, teams can make lessons learned proactive rather than reactive, making the retrospective setup more valuable. By setting regular retrospectives, teams set themselves up for continuous improvement and increased project delivery capability.