Creating a retrospective process for non-agile teams

A few months ago I was messy-bun-deep into a web project that was consuming all of myself and my team’s time, energy, and resolve. The project was tough for a number of reasons (actually, all of the possible reasons) and led to a lot of emotional highs and lows for everyone involved, as well as a good amount of frustration.

Luckily, I was working with an amazing team. Our collective frustration led to long talks while venting, but also talking through processes and analyzing the avenues that had brought us to where we were.

I knew as we worked through the project that we shouldn’t walk away from these discussions once the project launched. Having worked with other teams using agile methodology in the past, it seemed to me that a retrospective would be the best way to make something constructive of all of this feedback and frustration on the project and use it to mold project processes moving forward.

With that in mind, I reached out to friends in the PM community to understand how they run their team retrospectives at the end of sprints and projects. I received valuable feedback, and took a weekend to read through all of the resources pointed my way to create a process for my team.

The agenda

Here is the format I came up with through lots of questioning and research (resources linked here) and added to a Google Doc. This Google Doc was collaboratively edited and viewed live by everyone involved in the meeting:

Questions to ask:
– What worked well
– What didn’t
– What were the best ways we adapted, if we did
– What was most frustrating/a barrier to doing your job
– What did we not adapt well to
– What did we not communicate well

Filter the data: talk through patterns, issues, what may or may not have been an actual issue but just frustration

Next steps
– Move towards conclusions
– Identify 2-5 actions to focus on improvement
– Can ‘we’ achieve this?
– What does success look like?
– What’s the first step?
– Who is going to own this?

Closing retrospective (rework these statements) – is the following true?
– I felt I could talk openly in this retrospective
– I am satisfied with the last iteration
– I am happy with the quality of our code
– I think our continuous integration process is mature

How did the meeting go? What worked? What didn’t?

The ‘how’

This team is an all-remote team of contractors, so I set up a Google Hangout (we generally use voice rather than video) for myself, the two main developers/designers on the project, and our two company partners/account managers to meet for our retrospective.

The project had consisted of two key phases—a redesign component (which ultimately was cancelled), and a rebuild component. I treated each phase as a separate entity while asking for feedback within each of the above discussion categories, in the hopes that this would provide more focused insights.

I asked everyone to contribute in a roundtable style as we worked through the questions in the agenda I created. My hopes had been to avoid too much of a deep dive into the weeds of the emotional parts of the project, since that was a common issue when we got talking through many frustrations on regular project calls.

However, after the fact, I found that this was not necessarily the most meaningful solution (more on that later).

Meeting notes and length

I took notes on the meeting in our Google Doc as we all viewed it and talked through the topics. I tried to include all notes and comments from our call in a constructive, positive manner, without obscuring the facts or issues. I thought it was important to keep a record of tone but in a way that was still constructive – so that in the future, we could release notes to the rest of the team without worry that it shows our clients in a negative light.

The problem we were reviewing was our process and team communication, not a deep analysis into client psyche (even though that was tempting!).

I scheduled an hour and fifteen minutes for our retrospective. It ran about 20 minutes long, and everyone was pretty drained at that point. In the future for a project of this magnitude, I might try breaking up the meeting a bit more with a break, or schedule a separate meeting for solutions a few days later once everyone’s marinated in the discussion that occurred.

Alternately, I might try pinpointing key issues that came up on the project and using those as a jumping off point to get the project going.

Team feedback on the retrospective process

The general feedback I received was positive in having a retrospective itself—our team had never done one before, and getting issues and thoughts into the open with all levels of management present was incredibly valuable.

I spoke with each member of our team after the retrospective to see how they felt about the meeting: did they feel they were able to say what they needed; did they feel comfortable speaking to the team; were they satisfied with the outcome of the meeting as a whole?

The specific feedback was mixed, and extremely helpful for future retrospective planning. Below I’ve broken down the feedback a bit for clarity:

Managers:

Overall enjoyed hearing all perspectives, but felt that the narrative should have been more coherent to get a better sense of the big picture issues on the project. It was also mentioned that there was not enough focus on discussing specific solutions, and a plan to implement and own those solutions.

Developers/Designers:

Felt that they weren’t able to fully express their frustration and feedback in a linear way, which led to lots of forgotten project pain points that might have been useful to explore. Also felt that while large-scale solutions were discussed, that no resolution was fully realized. All of these team members appreciated having owners in the meeting to hear first-hand what project issues existed.

Conclusions

In the next few months, I’ll be working with other managers to try to talk through and implement solutions to some of the issues we talked through during the retrospective. Some discussions will be more clear to work through and implement than others—such as using a more agile workflow for large projects, and creating better practices and time spent around estimating projects.

Other processes will have to start at a much larger, deeper company level, but are great to start talking about—such as creating a process or standard for when to say goodbye to a client, criteria around accepting projects, and a clearer process and understanding of how to adjust when timelines and budgets are in danger of going over the estimate.

Meeting Outcome

My opinion is that overall, the project retrospective was a success and should be folding into the regular project process. This sentiment is supported over the team—which is great! However, next time the meeting itself needs to be run differently, with a chance for everyone to individually talk through the story of their involvement on the project and prompted to provide more feedback in the areas identified in the meeting outline if not mentioned.

It’s clearly an important part of the retrospective process to be able to give a contextual view of the project and issues/successes encountered, and to also feel everyone’s been heard.

Future Thoughts

In the future, I will also focus more on group brainstorming towards measurable goals on the next project—not necessarily solutions, but steps to get to a better place so that solutions and problems don’t seem as overwhelming. I think this would go a long way in making the meeting more productive and having clear goals coming out of the retrospective, even if the overall issues and solutions are more difficult to extract.

Do you run retrospectives with your team?