Dead Easy Informal Restrospectives

Recently, I was introduced to restrospectives by a wise colleague of mine. Something I had heard about, but really not gotten around to using in my software development process yet. After participating, I found the retrospective really useful, hence I thought I would share.

A restrospective in an agile process is the simple idea about “stepping back and looking at the process”. What we did, was take out 30-45 minutes, where:

  1. the development team meet up
  2. an outsider acts as facilitator

I like agile processes for software development, but aside from that, I do not care much for a lot of process. I like my time spent on development – designing and writing code. This is also why I liked (and was surprised that) an agile restrospective can be so short and lightweight.

In the retrospective I participated in, I acted as the facilitator. As such, I was not a part of the development team. I had some, albeit little, knowledge of what they were developing, but that turned out to matter less. In short, this is what we did:

  • on the morning of the retrospective day, we agreed on time to meet later
  • at that time, the team and I met up in a meeting room – pretty much blank and unprepared
  • I, the facilitator, started asking questions against the process
  • the team answered and discussed back and forth

The whole thing took around 30 minutes. The questions asked were stuff like:

  • what went well in the last sprint?
  • what did not go that well?
  • what to take with us and repeat in coming sprints?
  • what to do better in coming sprints?
  • …

but the really nice thing is, that having a project-external facilitator proved to be really helpful in the way that:

  • He (the external facilitator) will ask the questions, that lies as implicit knowledge in team members, and hence wouldn’t be touched upon. Like, when I asked “how do you do your etimates”, which led to a discussion on diffent ways to do estimation.
  • The team being retrospected can get new input from the knowledge of the facilitator – and the other way around, making the facilitator take something with him too (a true win-win)
  • The facilitator gets insight into how other projects in the organisation is run and what they do. This is knowledge and project-status sharing while retrospecting.

All in all, I had the fealing that this was helpful. As a consequence of this, I repeated it on a project at a client where I was part of the team, and we brought in another party as facilitator – a developer on another project, but from the same organization.

Some important rules I feel compelled to emphasize:

  1. Keep the retrospective short (less than 60 min), and
  2. Come largely unprepared and resist documenting the output.

August 22, 2009 В· polesen В· No Comments
Tags: ,  В· Posted in: Software Process

Leave a Reply