Video Transcript



Retrospectives are a valuable tool for software engineering teams. Heroku consistently uses retrospectives to review operational incidents, root cause problems, and generate remediation tasks to improve our systems. Increasingly we use retrospectives for another purpose: to improve teamwork and interactions on projects. Here we intentionally avoid technical discussions and focus on the emotional and human aspects of work, with the goal of creating positive insights into how to improve as a team.


The most common times people conduct retrospectives are after some bad incident, or at the conclusion of a big project. These are worthwhile times, but there are now other times that we use retrospectives too.

For example, a good time to conduct a retrospective is mid-project to course correct. Is a project not going swimmingly? Taking the time to stop and evaluate how the project is going wholistically -- beyond the typical status checks -- can positively impact the remainder of the project.

Weekly is another option. While this may seem excessive, it works well. It can be a good opportunity to blow off steam if nothing else, but it is a value use of 15 minutes or even an hour if it helps you work more effectively as a team.

One insight is that increasing our frequency of retrospectives allows us to practice and improve the process of the retrospective itself.

When Tactically

A 90 minute meeting Friday afternoon, a week after a project conclusion works best.

Don't conduct a retrospective the day following. Let people rest and have reflection time. Don't do it 3 weeks later when people have forgotten relevant details.

Don’t rush, as it takes a good amount of time to shift from work mode to reflection mode. And don’t cram it into a busy work day and ask everyone to context shift twice. How

A good retrospective depends on an active facilitator to help guide a group to meaningful insights. This starts with best practices for hosting a meeting:

  • Generate a clear agenda document ahead of time
  • Generate a broad guest list with project stakeholders, engineers, supporting teams and more
  • Create a calendar event with the time, room, attached agenda and video call, and email the guest list
  • Setup A/V 10 minutes ahead of time

What to do during

There is an art to good facilitation to actively but neutrally guide discussions, a few keys we've found helpful:

  • State a clear purpose: “To help the team improve by focusing attention on teamwork and interactions of the PX Dynos project”
  • Facilitate from a neutral perspective. If you can’t, ask an outsider to facilitate.
  • Ask questions of everyone
  • Social engineer unique and constructive interactions

Finally, by providing guided activities we're able to have a clearer agenda and remove some of the monotonous work that exists at each retrospective. Typically conducting a single exercise or two during a retrospective works to keep people active and engaged, and allows you to extract something new. A few of the guided activities we've found helpful are:

  • A round-table checkin where everyone in the meeting gets 30 seconds to say how they are doing or why they are here
  • A timeline activity where everyone remembers key events and puts them in rough order
  • A “five whys” analysis
  • Start Doing / Stop Doing / Keep Doing brainstorming

Whether it's to review and improve from an operational incident, or simply to improve how you work as a team we've found retrospectives a useful tool in our toolchest. Hopefully you can find the same or can expand their value from applying some of the above.

Originally published: August 14, 2014

Browse the archives for engineering or all blogs Subscribe to the RSS feed for engineering or all blogs.