July 7, 2008

...Learn TDD with Codemanship

Agile Governance Game - Recap

If you've played a few rounds of the Governance Game, you might well have left wondering "yeah, and?"

There are a number of theories being tested by the game - and its variations. Some of them have already been explored on this blog in days of yore.

I thought it might be useful to gather together the main theories in one post for convenience, so here it is.

The aim of the Governance Game is chiefly to allow me to test a variety of management strategies in a simulated project (or portfolio of projects). The key question I've been asking through the game is how do we manage projects in the face of inescapable uncertainty?

Most project management texts I've seen have suffered from what I consider to be a delusion; namely that we can reduce or even eliminate uncertainty. I have - in the past - referred to this as reductionist or linear management. The reality I see every day is a world away from this. Not only can we not eliminate uncertainty, but our very efforts to do so are usually counterproductive.

Software development is a creative process. It's a sequence of innovations, and the thing about innovation is that it is inherently risky. If it's new, that means we've never done it before. If we've never done it before, we cannot know in advance what effort, cost or reward it might entail. If we have done it before, then that's not innovation. That's duplication of effort. (Or "copying".) In a 100% effective development process, whenever we hit problems we've already solved, we reuse the solutions. The rest of the time, we innovate. In practice, even very similar looking solutions can turn out to be markedly different when it comes to realizing them. The devil, as they say, is in the detail.

So the reality is that we're stuck with high levels of uncertainty because that's at the heart of the very nature of what we do. We innovate. And innovation is risky. There's no getting away from that.

But in real projects, we are often clouded by the sheer complexity of software development, and it can be hard to see how certain kinds of management approach help us to improve (or reduce) our chances of success. I was struck by how, in many branches of science these days, simple games and simulations were being used to explore often incomprehensibly complex problems - like earthquakes and stock market fluctuations. Could it be that something as frighteningly complex as software development could be distilled down to a simple game, where a couple of dice played the part of "that which is beyond our control"?

The purpose of the game is to allow us to explore the things we can control as managers, and get a feel for how they might help us to stack the deck in our favour. (I'm mixing metaphors quite liberally, here.)

A practical explanation of the game can be found here.

Strategy #1 - Prioritising

The basic game allows us to explore prioritisation strategies. Even though we cannot control the dice, we can control the order in which we play the moves around the board. Simulations across millions of games suggest very strongly that the best strategy is to start with the most valuable, least risky moves.

If we plotted a graph of each planned move with the risk on the X-axis and the reward on the Y-axis, we would want to start with moves in the top-left of the graph (high reward, low risk) and work our way down to the bottom-right corner (high risk, low reward). Proiritising these "low-hanging fruit" can very significantly improve our chances of delivering more value in a project with limited time and resources.

Strategy #2 - Iterating

In a variation of the basic game, teams plan and execute their routes around the board 20 dice throws at a time, effectively giving them 5 iterations and 4 opportunities to come up with a better plan. Iterative and incremental delivery is an absolute must-have strategy in any sufficiently complex process. Many would argue you need to iterate because the nature of the problem you're trying solve (e.g. the business landscape that your software will operate in) might be changing rapidly, and you therefore need frequent opportunities to adapt your plan. Actually, to be frank, most business landscapes are so ill-defined that it's impossible to know if they're actually changing. And, in fact, it doesn't matter if they aren't. It's not the fact that they might be changing that should concern us, is that fact that they are so complex that forces us to iterate our solutions.

In comparison to many software solutions, a grid of 12x12 squares is actually very simple. And yet, even there, there are actually many millions of possible routes around the board, each offering a different set of odds of scoring a certain amount of points. What are the chances that first route we choose will be the optimimum solution? Vanishingly small. After playing a few moves, it's quite likely that you'll spot a better route. Iterating allows us to learn and our solutions to evolve. Evolution is a very successful natural search algorithm, proven to work in solving very complex design optimisation problems.

Strategy #3 - Capability & Resourcing

In another variation, teams can select which kind of dice to use in each iteration. This allows them to manipulate the odds of, say, throwing a 6 or a 10 or whatever numbers might be required by that segment of their plan. Throwing a 4 with two four-sided dice is significantly easier than throwing a 4 with two 12-sided dice, for example. But the best dice are in limited supply (remind you of anything?), and in observing this variation of the game, I almost always see teams timing the start of iterations to improve their chances of getting better dice. They also collect intelligence on which teams have the dice they want, and how long it might be before they'll be finished with them. If your plan would work best with two four-sided dice, for example, and you see that another team has the dice you want, but they will be handing them back in a few minutes, you might choose to wait. But if they have literally just started their current iteration, you might choose to compromise (e.g., two 6-sided dice).

Again, simulations very striongly suggest that there is a useful strategy here - in knowing when to wait for the right people and when to compromise. I have rarely seen real development organisations strike that balance, though. I think we tend to compromise far too quickly, and end up hampered with less productive teams in the long term, to the detriment of our projects. Speaking from experience, it can also be to the detriment of the better developers. If being available to start work on Monday outweighs your ability as a developer in hiring decisions then there's little incentive to learn and improve.

Strategy #4 - Backing Winners, Shooting Losers

The last variation I want to discuss here concerns managing multiple teams. A new role is introduced into the game, called the guv'nor. The teams play as before, but the guv'nor now allocates dice throws in each iteration to the teams he or she feels will give the best return (in terms of points scored). There are still 20 dice throws for each team in the game, but the guv'nor can choose to give all of them to a single team and force the other teams to sit out that iteration, for example. So if there are 5 teams, the guv'nor must allocate 5 x 20 throws among them in each iteration. The guv'nor also gets to decide when iterations start and end. Beyond that, they are not allowed to interfere in the individual teams' games, and have no visibility other than the scores of each team and the number of dice throws they used.

Now that we've established that there actually are strategies that can be applied, and that there is therefore some skill involved, we get to explore the kinds of decisions that we normally associate with executive governance.

Again, simulations across large numbers of games strongly suggests that the skill here is to allocate more resources to higher-performing teams. Teams that are falling behind significantly should be starved of resources. There are, of course, time pressures that prevent the guv'nor from allocating all the dice throws to a single team, so in this variation of the game the brutality of the fuinding decisions is limited by the constraint that you must allow the time to actually plan and execute each short iteration.

How unlike the real world, though, where projects that fall behind are - often for entirely political reasons - given more resources to try and get them back on track. The reality is that this rarely works. Adding more developers to a late project will usually make it later because of the learning curve and the exponentially rising communication overhead associated with larger teams. I've seen resources diverted from projects that were actually doing quite well to try and prop up failing projects, which is the exact opposite of what should be happening.

There are more variations that I've toyed with, and I can think of even more that I've never gotten around to trying yet. But I hope you can get a sense from this little write-up that, even in the face of inescapable uncertainty, there are strategies we could apply that will improve our chances.

Posted 12 years, 7 months ago on July 7, 2008