Code Retreat in Wroclaw

October 21, 2010

Next weekend there’s a Code Retreat in Wroclaw: http://coderetreat.wroclaw.pl. I’ll be there so If you want to cut some code together retreat with us =)


remote retrospectives

September 21, 2009

Ideally, I don’t like doing retrospectives remotely but many times I just have to. I live in the era of distributed teams. If this is not enough, there are usually more prosaic reasons: people working from home, lack of decent conference room, etc.

Many times I have to help with remote retros where people dial in from their desks, homes and remote offices. They don’t see each other, they only listen to each other. And there’s a gotcha.

The quality of the retrospective depends a lot on communication. We know that large percentage of communication is contributed by… non verbal stuff (was it 70%? or 80%? Look it up yourself =). You can add problems with quality of phone lines, latency, etc. This practically means remote retros are pretty much a challenge. Let me share a couple hints on dealing with remote retrospectives. I’m going to focus mostly on tools and I would really appreciate if you point me to some even better tooling.

1. MS Office communicator and its shared white board. By the Big ‘M’ company that rules the world (Hopefully, I didn’t offend the Big ‘G’). The communicator is an example of non web-based tool for shared meetings. We started using it instead of twiddla (see #2). The communicator has fairly nice shared white board. The only downsides I encountered so far are:

  • occasionally someone cannot take part in a shared session.

Successful retrospective with MS IM might look like:

end of MS communicator facilitated retro screenshot

End of remote retro with MS communicator

I’m sure there are other peer-to-peer shared white board tools. Let me know if find something interesting.

2. Twiddla is an example of web-based, multi-user, shared white board. We actually tried it for several retrospectives with various success rate. The problems we encountered:

  • too many features, some of them deadly enough to remove everything from the screen
  • voting on items to discuss was somehow difficult
  • we had some minor usability problems and once we couldn’t set up a meeting for unknown reason

We had successful retrospectives with twiddla, for example:

End of twiddla-retro screenshot

End of remote retro with twiddla

You might want to try out twiddla or look for similar tools out there. There are bunch of web-based tools to facilitate shared meetings, shared sticky notes, shared white board etc.

There is one great benefit of using tools like #1 or #2 for shared meetings. It really does not matter if you use a web-based tool like twiddla or just an instant messenger with shared white board like MS communicator. Doing shared meeting with any of those tools allows unsure team members to speak up: they can participate almost anonymously by sticking items on the shared white board. Certain level of anonymousness increases the chance unsure/diffident team members actually participate.

3. Emails. That’s basically my plan B for remote retros. (Although my favorite plan B is forcing plan A). There are number of ways of doing the remote retro with emails. For example, I can ask everyone to spend the next 5 minutes on thinking of three :)’s and three :(‘s and send me via email. Then I say what are the items most people wrote about and we discuss it. I don’t waste time on sharing the contents of the emails. This gives me a unique chance of steering the retro a little bit. If I feel that there’s an item only few people wrote about but I think it is really important… I can lie just a little bit =)

One other thing I find useful is that sometimes it’s better not to discuss most voted items. Let’s say 70% of retro’s participants are developers based in the same location. There’s a big chance they have similar problems and those problems are technical. In that case, most votes might go to technical problems related to the very same group of the team. I don’t like it… Many times I even skip technical problems during the retro so that we don’t waste customer’s time talking about issues with build. (or am I just too tired of talking about maven?).

***

Finally, I wish your team develop a habit of continuous improvement so that you don’t need a lot of ceremonial retrospectives to get better. Improve daily but if you don’t know how then by all means do retrospectives regularly.