July 16, 2007

...Learn TDD with Codemanship

Hiring - Wait For "Mr Right" Or Compromise?

The Agile Governance Game builds on the notion that there is a significant element of chance in software development.

It's not an idea that sits comfortably with many managers - that we can boil down the process of creating software to a series of dice throws. But all the evidence, and the theory, points to that reality. Projects are complex, and complex things tend to be unpredictable.

Asking the question "how long will it take us to deliver this feature?" is, indeed, the same kind of question as "how many dice throws will it take to complete this move?" Beneath it all, they are essentially the same game.

God does not play dice with software projects?

Similarly, the overarching question "which projects should I invest in?" has direct parallels with the scaled-up version of the game, where a "Guv'nor" allocates dice throws to teams in each iteration, based on their performance in the last iteration and - possibly - the potential value in their plans for the next.

I'm surprised myself at how successful the game is at revealing or explaining key project and program management strategies. But maybe I shouldn't be.

It seems that these days it's quite fashionable for Physicists to use toy examples - games - to explore complex phenomena like earthquakes and forest fires. Get some key details right, and - in essence - you have the same game. A bunch of wooden blocks, connected by springs, slipping and sliding between two sheets of wood, might seem like a gross oversimplication of plate tectonics, but the results of simulations using this model bear a startling similarity to the real thing.

A software project is essentially a grid of 144 randomly valued squares - at least, the ones I work on are

So, too, does the Agile Governance Game. Plot a burndown chart for a game and for a real project, and one might struggle to see the difference. And, in terms of strategies, what works for the game may well work in real life.

Take, for example, the strategy of procuring the best dice. The dice simulate capability - the probability of performance - and teams quickly learn that getting your hands on the best dice (for your particular plan) can be a critical factor. It can pay to wait to start an iteration until the dice you need become available. But waiting too long can hurt you even more. So there has to be a careful balancing act between building the best capability and making actual progress in the time you have available.

My experience of the hiring process has left me feeling that we tend to err on the side of "now!". If we exercised a little more patience, we might end up with stronger teams and a much better chance of success. Understanding where the lines meet - where the time we're losing outweighs the benefits of waiting - is surely a key factor in recruiting strategy.

At some critical point compromising becomes a better bet than waiting. But where is that point?

Certainly, the truth is that the best developers can be ten or more times as productive - whatever that means - than the average John Q. Programmer. This is not true of the dice. Two 4-sided dice will not gvie you ten times the chance of success as two 8-sided dice, for example.

Frankly, you could probably get 2/3 of the way into a project schedule and - if you found the right developers - still end up with more by the release date than if you'd hired an average team at the start.

I have no proof of that, of course - other than what I've experienced myself and the anecdotal evidence of others. But it would seem to make sense. If your release deadline is 12 months from now, it might be better to wait 8 months for the right people than to jump straight into development with whoever's available to start on Monday.

Of course, knee-jerk hiring is the standard today. It doesn't help that there's this crazy idea going around that one developer is pretty much the same as the next. Recruitment professionals have helped to create this myth, since it's better for the scalability of their businesses if we're a dime a dozen. But it does lead to wierdnesses - like project managers picking up the phone and asking for "6 Java developers to start on Monday", like we can just pop down to the supermarket and pick up a family pack.

The people on the team are a major factor - actually, THE major factor - in project success. If I were funding a software project, I'd want to know which developers were "attached to the project". I mean, that's how it works in the film industry and other creative disciplines. Can you imagine Steven Spielberg calling his casting agent and saying "I want 3 white guys, 2 black guys and a Chinese kid to start shooting on Monday"?

No. That would be crazy. He can't start shooting until he has the right cast, of course. Starting on time is far less important than getting the right people.
Posted 13 years, 11 months ago on July 16, 2007