Friday, November 29, 2013

My Retrospective About My Retrospective

Business as (too) usual

Back when I was working for my previous employer, we used SCRUM as our development methodology. As part of this methodology we used to end every sprint (3 weeks of work) with a retrospective.

During the retrospective, the team would sit down together and discuss what had been done well and what had not.

This was a recurring ceremony in which the team-leader guided us into talking about the painful pain points (along with the good things we've done - we don't want to be ALL negative). We used to discuss various issues; a lot of those times it was done with a lot of enthusiasm, maybe even some arguing.

Let's make things more exciting

During one of our 1x1s, my team-leader told me that he felt like we had to shake the dust from the retrospective process a bit, make it more exciting and, more importantly, more productive. His suggestion was to have a rotation between team members and let each of us lead a retrospective. We were encouraged to freshen things up, any way we deemed fit.

What should I do?

I started thinking about what I wanted to do when it was my turn to lead a retrospective. Should it be around one specific topic? Should it be a game? Should I stick with the original format?

I decided to think about what was bothering me in our retrospective process. It was a sort of a retrospective with myself about our retrospective.

I narrowed it down to 3 issues:
  1. Priorities: I realized that we don't always address the most important issues. We let our emotions, instead of our common-sense, affect the topics we discuss. Instead of finding 1 or 2 things that can improve us best, we discussed things that really annoyed us. We could not always change these things , or know that the change would have a great impact on the team or productivity, even if it happened.
  2. Not everyone's voice can be heard: Some people are more passionate when they speak, some are shy and some are more verbal and can convince others. It's hard to let everyone be equally heard and it was really important for me to try.
  3. Action items: We all want to change the world, or at least our organization, for the best. But we have to be realistic and set feasible goals that, in each sprint, would improve us a little more. 
So I decided to create a flow in my retrospective which will allow everyone to speak their minds, and will lead to an extremely focused set of 2-3 feasible and improving action items.

So that's what I did

Step 0: Preparations

I booked a room with a big erasable board. Before the team arrived I wrote down all of the stories we worked on during this sprint with different colors (in order to make it very clear where we were at the end of this sprint):

I put some papers and pens on the table for the team to use later on.

This is how the board looked like when the team arrived

Step 1: Map the problems

I asked the team (myself included) to take 3-5 minutes and write down the four impediments which bothered them most. After all were finished we took turns in reading our notes and then wrote each of those on the board, near the stories that were already written there. Everyone could speak their minds about what was bothering them, without interruptions.

In Step 1 we added our painful impediments

Step 2: Suggest solutions

Pointing what's wrong or what's painful is fairly easy. Coming up with a solution to the problem, may sometimes be a bit more complicated. I, again, asked everybody to write down their suggested solutions to the impediments that were raised. When finished we took turns of reading the solutions and wrote down these suggestions on the board as well. This uncovered two interesting issues:
  1. Unsurprisingly - some of the problems had the same solution
  2. For some of the problems we couldn't find a solution with a good ROI (ROI = Return Of Investment: Meaning - all the solutions we found weren't worth their effort) 
This step made us focus on a smaller set of problems and their solutions. And again, everyone had their chance to suggest solutions.

Lastly - we added our suggested solutions

Step 3: Let's vote!

Lastly, I told the team that each team member gets 10 points. Those points were used for voting on the solutions that were suggested in the previous step. Each team member was allowed to distribute the points in any way (s)he wanted to. At the end, the top 3 solutions were chosen as our action items for the next sprint.

Step 4: Leave with a good taste

Before wrapping up I asked everyone to say what they thought was good during the sprint. I wanted the retrospective to end with a positive note. Also, it's important to preserve what we do well.


After the retrospective, I again did a little retrospective with myself. I tried to figure out if I managed to address the 3 problems I tried to face at the beginning. The democratic nature of the retrospective allowed everyone's voice to be heard, as I wanted, and prevented unnecessary arguments about the priorities. Also, at the end, we had to vote on some action items. Having time to think about what's really important and what we can really change, made us choose action items that were feasible. Those action items were tracked during the next sprint - I sent an email that sums up the retrospective right after this meeting. During the sprint I sent a reminder when we encountered an issue that was brought up in the retrospective. Finally, before the next retrospective I sent an email describing our decisions from the previous retrospective and whether we applied the action items or not. At the next retrospective we made sure we followed on those action items, but that's another team member's story to tell :)

A word of thanks to Gal Zellermayer, my team-leader at the time, who pushed me into thinking out of the box and conduct this retrospective.

Find me on Twitter: @AviEtzioni

More interesting posts from this blog:

Friday, November 1, 2013


I'm not sure when was the exact moment in which I knew I wanted to become a software-engineer. My first "Hello World!" was at the age of 10. But it wasn't until I was 18 that I started to actually work in this profession.

At first I was a bit intimidated by the assumption that software-engineer's work is usually lonely. You sit by the computer and code. By yourself. And, considering myself a people's person, it made me rethink whether this line of work was for me.

Over the years I have come to the realization that software-engineering is not lonely. Quite the opposite. Software-engineering is about people almost as much as it is about technologies. Only great teams build amazing products.

In this blog I write about technology and culture. I hope you will enjoy it.

Find me on Twitter: @AviEtzioni

More interesting posts from this blog: