The knowledge we glean from reviewing the previous six months is invaluable. However, for operations, it can be a daunting task to implement the sheer amount of process changes all at once. So this time around, I wanted to try out some experiments and track progress on a more regular basis.

Project Post-Mortems

Project management 101 tells you that the easiest way to do this is through project post-mortems. We’ve been conducting these for a while now, where the entire project team meets after the project is complete and reviews what went well and and what didn’t.

We keep a folder in google docs for the team to look back at project notes in case they’re tackling similar project types or we’re working with the same client again.

Though this is an effective way of revising our process and bringing new knowledge into the next project, it doesn’t really help the current project. And as our projects started getting larger over the last year, it was increasingly challenging to think about specific project details four to five months later.

Couple months back I had lunch with a fellow process geek who gave me the suggestion of introducing project retrospectives into our process. They had been working really well for him as it allowed for his team to step out of the day to day grind and to solve immediate problems that would effect the next sprint.

What is a Retrospective

There’s a fair bit of literature out there on what a retrospective is, but I’ll walk you through how we’ve implemented them at Jet Cooper.

When: Our retrospectives happen every two weeks, closer to the end of the week and ideally on a Thursday morning, since Friday’s can get hectic with client deliveries or demos.

For how long: Each project team meets for 45min to an hour and discusses what’s working well and what isn’t.

Exercise: It can often be challenging for the team to step away from the day’s delivery, or bug fix, or design revisions… so, as the facilitator, I start the meeting off with an exercise.

Each team member is given a Post-it pad and a Sharpie. They are asked to write down what is going well and they aren’t allowed to discuss with the group.

Then, I take those notes and start arranging them on the left side of our whiteboard wall. Before we discuss anything, I ask the team to start writing down what isn’t working well on another set of post-its. I then take those notes and arrange them on the right side of the whiteboard.

Discussion: We review each note as a group and ask the person who wrote it to elaborate. As they’re discussing with the group, I scan the board and start grouping notes based on the themes I’m hearing in the discussion.

This is incredibly important as a facilitator, as notes can be repetitive and certain conversations can lead down rabbit holes. It’s also important that as a facilitator you spend most of the meeting listening and asking ‘why’. You’ll notice to the most interesting patterns in how people work with each other, deal with unknowns, and face external factors.

Actions: We then create a set of actions items on how we can continue doing what’s working well and fix the things that aren’t working. It’s important that each action has an owner and a timeline associated with it. The actions then get summarized and sent to the team on Basecamp. Before each retrospective, I review the notes with the group and follow-up on actions and anything major that has changed since the last retrospective.

Do we have to go to this meeting?

It’s always challenging to bring another meeting into someone’s world, so of course I anticipated some backlash to the bi-weekly retrospectives. The best way to combat this is to have a firm stance on the meeting and the value of the exercise. I knew it was something we definitely needed as we changed our process and grew our team.

I started by making the two people with the busiest schedules optional (Verne & Satish) and focussed it on the project team. This way, if they can’t make it, we still go on with the meeting. I rarely reschedule retrospectives, and since I’m human and get stuck in traffic, if I can’t make it, I ask one of our Product Managers to lead the meeting.

The coolest thing about retrospectives is seeing actions from the previous meeting actually improving the process and team collaboration. You can visibly see it in the notes and team dynamic! Not to mention the individuals that were the most apprehensive about this exercise now look forward to it.

Best of all, we’re looking forward to the next set of post-mortems where we’ll be armed with a collection of retrospective notes for more substantial discussions.

Do you hold project retrospectives? We would love to hear how they play a role in your process.