How to Breathe Life in Your Retrospectives

I mentioned in a post a few weeks ago that our development team was singing the retrospective blues and was going to implement a retrospective meeting that turned the tables on how feedback from the team was provided.

Yesterday we relaunched the fantastic looking Business.com, which is the product of a lot of planning and hard-work across a project that lasted 4 development sprints. I took this opportunity to try out the format that Marc Nazarian laid out on ScrumAlliance.com and here's what happened:

(note: we ran this as a project-wide retrospective, but the same process is to be followed on sprint retros)

I sneaked into the board room early and laid out four cards with two different colors in front of everyone's seats. It was clear when everyone stepped into the room that things were going to be different this time.

The first task for the team was to rate how the project went from their perspective.  Needless to say I'm pleased with the results:

We hold our teams to really high standards and have communicated that a 5 in a situation like this would mean an absolutely flawless project, which in my eyes is nearly impossible to achieve. Our teams can always improve and this project was no different.

With that out of the way, it was time for the team to find out about the cards. Each person was to write down one thing that went well on each yellow card and one thing that didn't go so well on each of the red ones. Instruct your team to keep it 3 words or less.

Tip: Naturally, everyone said it would be difficult to keep feedback to just a few words, but encourage them to play along as it will become evident why in just a few minutes.

Tip: Instructing people to come up with feedback on the spot can be tough in a group environment because time is always a constraint and people feel on the spot. What I did to mitigate this was tell everyone in advance to come up with two positives & two areas in need of improvement. Even with preparation this still took longer than I wanted so watch the clock.

The next step is to tell everyone to pass their red cards to the person to their left and the yellow cards to their right. They now know each person will have to read someone else's cards. It was precisely at this time that, with a huge grin, one of my developers blurted out "this is so much better than what we've done in the past!" Results.

You then go around the table with the team trying to explain the issues that were brought up on the cards in front of them. It's a very powerful exercise as it gets the team to put on the shoes of someone who may have a completely different job description and see the world from their perspective. After the presenter was through describing their cards, I asked the author of the cards to rate how the presenter did in getting to the crux of the issue. Every single one was rated 5. A well-aligned team indeed :)

At this point the feedback was flying in fast and keep in mind that this is a team who normally would do their retrospectives in 5 minutes time with most of the feedback being of the "I think the sprint went great" variety. The team was noticeably excited to have an engaging forum to improve the process.

Tip: As the feedback comes flying in, it can be helpful to write the areas of improvement on the board because you will be coming back to these.

After everyone is finished presenting, the team passes their two red cards to the left (discard the yellow ones for now) and you go around the room suggesting improvements for each.

Tip: As Mr. Nazarian warns, everyone is going to want to chime in on most issues, so be sure to have the person reading the card provide their ideas first. Everyone will have a say in the end, but it's best to get a suite of ideas instead of only from those who traditionally dominate meetings. Sometimes the best ideas come from the most unlikely sources.

If you're doing this right, you'll have three lists on the board: what the team should stop doing, start doing, continue doing. From these the team will take the top priority ones and decide how they will change for the better.

Our biggest issue that we're going to be tackling is how we use our tracking tools to aide the development process. We have a pretty basic configuration of JIRA to track requirements docs, psds, bugs, and issues while the developers use Pivotal Tracker for their "marching orders" and sprint organization. The team felt frustrated with our convoluted integration of these two tools as well as the difficulty in tracking versions of documents and the changes within. Since this is a large issue, there will be future discussions on how to fix these problems, but the feedback so universal around tracking that it's imperative we solve these problems.

At the end of the meeting, I once again asked the team to rate something; this time being the return of investment of their time for the retrospective. Here was the result:

Though I may have missed vote, the tally was merely for posterity. Everyone was delighted with the effectiveness of the new retrospective format and I honestly (and perhaps cheesily) think the team walked out of that board room with an improved sense of unity and camaraderie. The process was engaging, fun, and elicited a treasure trove of thoughtful feedback. I'm now tremendously motivated to re-evaluate all of our agile cadence meetings to hit the bar that was raised with this new retrospective.

Tip: As ScrumMaster, you are the time keeper. I knew we would be pressed for time and even so our meeting went thirty minutes over. Perhaps this was because we were reviewing the whole project, but there's a lot to discuss in 60 minutes so try to keep things moving.

Here is some of the feedback I've received since the retrospective:

As posted by our Lead Designer in Yammer (to our entire company):

If you call it a debrief, postmortem or retrospective,the fact is Tim Sorweid nailed it today. Mr. Sorweid facilitated an excellent session with key members of the  team. The focus of the event was to identify wins and opportunities for improvement. One team member was overheard saying "Tim is scrum master equal to none."

And in an email to the team from an engineer:

I want to thank Tim again for re-evaluating the Retrospective Meetings and coming up with a new format that was truly valuable.  I think we can all agree that the old format had become monotonous, and we were no longer taking anything valuable away from the meeting. Once again thank you Tim, it's ideas and meetings like this that are going to help shape this company. 

I'm not trying to toot my own horn (that much), but am instead trying to show the immediate gratitude by the team of finding a format that is useful for them. If you've been struggling with your retrospectives you owe it to your team and company to try this right away!