Retrospectives

Last week I spent most of my time facilitate our retrospectives, that is I spent a lot of time chairing meetings, encouraging and monitoring debate, and far too much time manipulating Post-It notes. Let me explain.

Within the development group, we base our working practices on Agile development and part of that suggests that at the end of each release cycle you should hold a retrospective session to pinpoint things that went well, things that didn’t go so well and to assign actions which will help improve things next time. It’s all about continuous improvement and we do get a lot of benefit from them.

Don’t be put off by the name, it’s essentially a debrief session that is focused on a particular area, and the process is quite simple although ours has changed a few times and the sessions we held last week were, again, something new to try and improve the retrospective process (we actually hold retrospectives of the retrospective to make sure that the retrospective is improving as well… ).

Our development group is broken into teams, and each team is asked to consider their own working processes within the overall adoption of the Extreme Programming methodology (the branch of Agile development we follow).

And then it’s Post-It note time!

Each team member is given a pad of Post-Its, and we spend 10-15 minutes jotting down things that went well, one item per Post-It. Once the time is up they Post-Its are stuck up on a wall or whiteboard, and grouped into common themes. Then we do the same for the things that didn’t go so well (ok ok, “what went wrong”) and again they are stuck on a wall and grouped.

The common groupings in each category give you things to continue doing (what went well) and things that need improved (what went not so well). Then comes the fun bit!

Each team is given control of their own working processes, and are encouraged to discuss and decide on actions to improve the process where it’s been identified as being weak.

We then gather each team together for a reporting session at the end of the week, during which I teased out the common threads in each category, the items that everyone identified. That final session was interesting, and suggests that, despite having been split into small teams (8 people per team, including 1 tester and 1 technical writer) everyone identified some similar issues, and everyone agreed that certain things were working well.

One of the common “what went well” topics was agreement that having a tester and a technical writer embedded in the development team was of benefit, something I thought but hadn’t ever received feedback on until now. That was a nice moment.

Call it a debrief, call it a retrospective, but an honest appraisal is hugely beneficial. It can be hard, and at times the discussions were heated, but everyone was honest and upfront and we should see the benefits over the coming weeks of this release.

Now, does anyone know what I can do with a few thousand Post-Its??

UK readers, Skill Matters are running a session on Agile Retrospectives next week.

One comment

  1. Sounds like they went really well, probably helped by the fact that there was someone in the explicit role of facilitator. I’m impressed that you (as a company) made time for it – whenever I’ve been involved in such post-mortems they’ve been useful, but it’s so easy to get caught up with the next project and skip the retrospective.

    Are your post-it notes different colours? You could use them as big ‘pixels’ to create a mosaic on a wall of the office 🙂

Comments are closed.