Saturday, February 26, 2011

Curing distributed Agile Illnesses: Diagnosis

In my session on 'When Agile Offshoring fails' at AgileNCR this Saturday I decided to harvest ideas from the attendees on different illnesses. The results were beyond my expectations; in this blog I will share a few of them and give a few preliminary comments on the result. The general plan is described better with the following diagram.

First I would ask the attendees to come up and write down all the symptoms related to failing distributed agile teams on a sticky. These we put on one part of the walls of the room. Then I would ask them to write causes for symptoms on stickies and put them on another part of the wall. Finally we would all try to come up with a possible mitigation for each cause. It worked beautifully, let me show you.

Interestingly I intended to do in this session exactly what Olav would be urging for the first day of the conference: analyze agile failures so we can inspect and adapt and become more effective. But let me get to some details before I give up and fall asleep.

The following is a (very poor) picture that I took of my hotel wall after rearranging the stickies I had stuffed in my bag. 

Now that I have this, the real work can begin. First I will look at the causes and cures to see what fits with what, sift out the duplicates and see if I can formulate a couple of likely experiments. Then I intend to formulate a challenge and post that at the Xebia blog

One attendee commented (and rightfully so) that it was a bit ungratifying that we didn't come to a full conclusion after the session. There's no closure here for sure. While the intent of the session was to sparkle the interest as opposed to satisfying the attendees, there is no reason to be mean. Here are a few highlights that I can see through the fog already:

  • Frequent co-location is mentioned the most as a solution by far, it mitigates whole bunch of problems
  • By far the most problems evolve around exchanging information, but a remarkable second is trust 

One other interesting thought that keeps nagging at me is that many of the listed symptoms and causes are reenforced by larger team sizes. This is the case with both co-located teams and distributed teams, but because the mitigation here is usually sought in colocation I am inclined to consider that in co-location larger team sizes are possible than in distributed team.  Given the other factor that co-location is expensive, this poses an interesting optimization problem that only in certain particular configurations distributed teams are more cost effective than co-located teams. It would be great to get some data on this...

I'm now torn between digitizing the cards on linoit and my bed. I'm affraid the bed is winning at the moment. I hope you enjoyed this, stay tuned for more analysis.

Posted via email from Iwein's braindumps

No comments: