<span id=Notes from a Product Manager: Running Better Agile Retrospectives" />

Agile retrospectives are an opportunity for engineering teams to reflect on a project in order to identify what went well and areas of improvement. The goal is for continuous improvement of how software gets built.  Retrospectives are of particular interest to us at Pinpoint as we are on a mission to improve the way teams build software. Our teams are working every day to  reimagine agile (amongst other engineering workflow challenges.) We recognize that the software industry has evolved at an incredible rate, but the processes we’ve relied on for decades to do the work of building software just haven’t kept up. 

When building our product, we want to ensure it is inclusive and valuable to everyone involved in software building. We are (virtually) sitting down with different people that represent different perspectives in a software organization to understand how particular processes or ceremonies like retrospectives, impact how they approach their own work, where are the friction points and if we could re-imagine a better way of doing the work, what would that look like? 

So what does Matthew Tibbit, Pinpoint’s Product Manager have to say about retrospectives?

Q: Why are Retrospectives important to your role as a Product Manager? 

A: One of a Product Manager’s many responsibilities is to deliver genuine value to stakeholders (whether customers, users or internal) as quickly as possible. Occasionally things will go exactly as planned but often the road is bumpy and mistakes can happen. This is a natural part of building software products but it is crucial for agile teams to learn from their experiences and continuously improve.

Retrospectives help us do that by setting aside time to reflect on the past sprint or work cycle and really dig into what is working for us, what isn’t and what we can change to improve things. Emphasizing and living a culture of continuous improvement only helps agile teams get exponentially better over time which ultimately leads to better software, delivered faster.

Q: What is the most difficult thing about facilitating a retrospective?

A: The most difficult thing for me has been finding a tool or method to run retrospectives so they're fun for teams rather than a burden which can result in a team just going through the motions. Since we switched over to Pinpoint Retrospectives, engagement is so much higher compared to the time we spent using custom Kanban Boards for our retros. This higher engagement results in more topics, higher-quality discussion and better outcomes.

Q: What do you think makes a good retrospective?

A: For me, the most important thing is that everybody on the team is engaged, has a voice and feels comfortable talking openly to ensure that real issues are discussed. On the more tactical side, making sure the expectations for action items are clearly defined to avoid diffusion of responsibility is important. 

Ultimately, every team operates a little differently and should be empowered to own the retrospective ceremony. Typically Product Owners/Managers should attend as part of the team but should not dominate proceedings.

Q: Conversely, what are some typical mistakes that are made in retrospectives?

A: In no particular order here are some of the things I have run into:

  • No prep. Spending the first half of the retro just trying to work out what we did over the past sprint/work cycle so that we can talk about it.
  • Missing structure. What do we discuss first? What is most important to the team? 
  • No Follow-Through. If nobody is closely keeping track, it is too easy for an action item to be recorded during the retro and then never see the light of day again (until the issue that prompted the action item reoccurs)!
  • Lack of "Safety." Retrospectives need to be somewhere team members are comfortable talking honestly and openly or else the value of the Retrospective takes a huge hit.
  • Ignoring the positives! Discussing problems is an important part of improvement (and can be cathartic) but don't forget to focus equally on what went well and celebrate wins! 

Q: How has Pinpoint helped your retrospectives?

A: Pinpoint Retrospectives actually solve most of the issues I mentioned before. 

The team instantly knows what was done and what was unfinished because we pull in all of your issue and code data for the sprint/work cycle so there is no rushing around generating reports at the start.

The Pinpoint Retrospective structure is clearly defined with instructions for each stage so even teams who are completely new to the concept of a Retrospective should have no problems running one. Voting ensures that the team focuses on the important discussion items first.

As of V2, Pinpoint Retros help hold us accountable to action items previously defined. This is done by automatically carrying incomplete actions items from one retro to the next, while allowing the ability to assign an action item to a specific user so we know what needs to get done and by who. In addition, Pinpoint Retros now allow us to compare our current Sprint Ratings to the previous sprint so we can see how we’re trending.

You can hear more from Matt in this post: Notes from a Product Manager: 6 Tips and Tools for Empowering Engineering Teams

Running your own Retrospectives 

If you could re-imagine your own retrospectives or other Agile processes, what would you change? We love hearing from teams about how they work and getting feedback on what we are doing.

Here are some ways to learn more and get involved: 


Get the data science behind high-performance teams.