Bigger retrospective - my first time

Finally I did it! I had my first bigger/higher retrospective. It wasn’t perfect, but I learned a lot.

In April last year I wrote a post on the internal forum at my company about Retrospective on a higher level, where I discussed that we missed some form of finalizing, round-up of each project. A planned time were all developers, testers, architecture's and manager sit together a put there view on how they thought it went. A possibility to visualize choices that resulted in good and bad,  from which we can learn from.

Why bigger?

Running retrospectives after each sprint is a great way to reflect after small changes. Maybe your team has tried pair programming or TDD for a sprint and then its perfect during the sprint retrospective to reflect over what everyone thought about it.


But during a project for several months or years it happens a liitle bit more:

• Several teams are working with different parts and the code changes a lot.
• There will be lot of communication ans synchronization  between the teams and managers.
• New way of working like remote-pair-programming.
• New tools are introduced .
• People leave the company and new people start.

This list can be made long. My point is that some changes a three week sprint is not enough to make reflection from. You need more input data to spot the delta.

My frirst trial

After I have read Joakim Sunden’s post, Running big retrospective at Spotify I finally moved from just talking about it to actually doing it. And it was great!

What I did was:

• I invited all how has been involved during a 6 month period.
• Booked a conference room for a hole afternoon.
• Prepared me well with agenda, post it notes, etc.
• No computer!
• Happy mode curve.

As I mentioned in the beginning the result wasn’t perfect, but it was ok. Unfortunately only developers attended, which only give one side of the project. What I missed was that several invited was invited as optional and not required. Yes, some people actually take notice of this.

The good part was I really believe everyone who was there really enjoyed it. One important part, that I also put extra care to, was that everyone should participate. It’s very common that there are only one or two who speaks all the time (some smart people sit silent in the back and don’t care about agile and processes). By letting everyone write down what they did during the gathering data phase, and put them on a timeline on the whiteboard afterwords, everyone got a chance to share there thoughts and feelings.

Another good factor was the happy mode curve. Everyone was asked to draw a “sinus curve” describing what they felt for the task during the hole project. Is was a clear correlation between the curve and “how well” the project went.

Another the last success factor was to not bring any computer. We did it truly kindergarten way. We used pencil and paper.

I will do it again!