September 16, 2006

...Learn TDD with Codemanship

Agile Governance - Sept 14th

On Thursday evening I was given a generous invitation from a team working in a well-known Internet company (who I've been asked not to name) to conduct further evil and twisted experiments in Agile Governance, using them as guinea pigs.

Yet again, my job was made so much easier by the intelligence and enthusiasm of the participants, and the workshop seemed to go very well, which is more a testament to their abilities than to my skills as a facilitator. They were one of those rare teams that I wish I was working with. It sounds as though they know what they're doing.

Every time I run the workshop, I spot something new and interesting: perhaps a new strategy or some interesting effect that I hadn't noticed before.

A few things in particular stood out:

* A couple of times I failed to explain new rules clearly enough (which I need to work on), and some teams were at a genuine disadvantage because of this. What was especially interesting, though, was how sometimes teams would imply their own constraints on the game, putting themselves at a similar disadvantage. One strategy that might help in these situations would be to test the boundaries of the game thoroughly, to help us understand what we really can and can't do. I've lost count of how many projects I've seen suffer because the team were imposing constraints upon themselves that really weren't constraints at all. Statistically, less constraints means a wider solution space, and therefore a greater probability of finding a successful solution with limited time and resources.

* I think I'm finally getting a handle on what the skills of the Guv'nor really are within the game, and I'm building a nice picture in my head of how this might apply in real-world domains like IT management. My last-but-one blog post explains some basic ideas I've had along these lines.

* A very interesting thing to witness was the way the team competed for the best dice. Because of the layout of the game grid, most planned moves tend to be fairly small - 3, 4, or 5 spaces. The best odds for these kinds of numbers come from a pair of 4-sided dice. There were two pairs of 4-sided dice to share among 3 teams. There is definitely a strategy here that could give one team a much better chance of success than another. That still needs thought, but I certainly enjoyed watching the scramble to finish one iteration and get the best dice for the next iteration. (I changed the rule so that teams couldn't use dice with the same number of faces for two iteratons in a row).

* One question that stands out for me is which makes the biggest difference in the game: the plan or the dice? In project management terms, since the dice represent capability, I ask myself whether a good team with a bad plan would have more or less of a chance of succeeding than a bad team with a good plan. Ideally, we'd want a great team with a great plan. But that's not always possible, given the scarcity of great people from which to build a great team. (And the scarcity of great planners, I should add).

The key reason why I ask this question is to clarify a problem I've been sitting on for years now - who is the bigger factor in Agile Software Development: the developers, the project manager or the customer? If the plan makes the biggest difference, then surely it's the customer. If capability is the deciding factor, then it's the developers. I'm still trying to understand what role, if any, is played by the project manager. Certainly I've seen projects going very well with no project manager, only to grind to a halt when one is appointed. In that respect, a bad project manager can scupper a project's chances of success. But can they bolster them, too? And how? That's another aspect of the game I'd like to explore in the future.

A question that's come up since the workshop is about the difference between luck and chance. I've been emailed a couple of links that throw some light onto this topic:

The respondant adds:

"Note: There's a difference between luck and chance. Chance is dice rolls. Luck is probably using the 4-sided dice."

I found this fascinating. Just as I've only recently learned to distinguish between performance and capability, should I be learning to draw a similar distinction between chance and luck?

Anyhoo, the workshop was fun and the beers and pizza were appreciated. So thanks to you, anonymous team from Internet-company-who-shall-not-be-named! Thanks especially to Simon Baker from Think Box for setting the workshop up and helping it to go smoothly on the night. Simon's a highly-respected Agile coach over here in the UK, so I was delighted that he recommended my workshop.
Posted 15 years, 2 months ago on September 16, 2006