Lessons in Strategy from Playing Dune

Don’t fall into the trap of doing things the same way every time…

I know what you’re thinking: “this article is to put a thin veneer of respectability on David’s time wasting playing a computer game.” Perhaps I’m deluding myself, and it is… Or perhaps playing a game might remind you that you too easily fall into your natural pattern at work; and perhaps you shouldn’t!

Many years ago…

In the late 1990s I first played Dune, a game based loosely on the series of books by Frank Herbert, which concern great houses that colonize a desert planet, populated by monstrous sandworms and weather-worn Fremen people, in order to harvest the valuable spice growing there. I recently re-discovered it, in the form of an open source re-implementation, as part of Open Red Alert. A couple of happy weeks of playing when I had a spare hour or two thus ensued.

The objective is simple: survive attacks from the other houses, build up infrastructure and armies using the money you gain from harvesting spice, and thus eliminate all opposition. Of course, there are lots of variations, many different types of unit you can build, and, notably, maps you can play on.

And the maps are what make you think.

A simple game consists of you versus a single (computer) opponent. Build up enough of an army, wipe out their base, and you’ve won. Provided you can build up enough defensive capability quickly, you can survive light attacks whilst you build up a big offensive army. “Job done”, as they say.

We’ll call this the carefully-planned, well-resourced, low-risk approach.

Of course, you then make it more complicated. Add in another couple of opponents, each of you starting at a different corner of the map. Now the world is a little different: if you’re lucky, two of your opponents will be too busy fighting each other (at least initially) to bother you, hence you only have your most proximate neighbour to contend with. But if you attempt to hide until you have a large offensive force, you may well find that you have two strong opponents, rather than just one. In this case, an early (if relatively weak) strike on your neighbour is advisable, probably in a couple of bursts, before then focussing on building up your expeditionary force to take on your remaining opponent on the other side of the map.

Let’s term this the early half-baked, late well-done approach.

And then there were six.

Four players eventually becomes easy. Six is far more interesting. Now you have three on each side of the map, and if you’re unlucky, you now have an opponent to the North and one to the South (never mind three others over to the East/West on the other side of the map). You need to hit them before they hit you. But you can’t commit all your forces to attacking one, because the other is certain to try to do the same to you. So you take a balanced approach, trying to combine the tactics you used with two and four players, hitting one opponent as early as possible with a few resources, in multiple waves, inflicting enough damage to cause them to need to repair rather than gain the ability to attack you. Clearly you have to build up and maintain a defensive capability too, to avoid succumbing to the same fate from your other neighbour, resulting in dilemmas of how to balance the two. Hopefully you prevail, though, at which point we’re back to a version of the four player game.

You (or at least I!) might call this the balanced investment, early iteration, late commitment approach.

Great; thanks for the game-play advice. So what?

Everyone has their “standard” approach to a problem. It’s probably mainly to do with how much appetite you have for risk taking. Some of us like to plan carefully, ensure that we have a surfeit of resources, and only execute when we are almost guaranteed to achieve our goals. This is the carefully-planned, well-resourced, low-risk approach, which you could argue is akin to classic waterfall project management. It’s good: it delivers. We all know, though, that it can also be inefficient, and moreover doesn’t tend to adapt well to change. That doesn’t mean it’s wrong: clearly in the two player case above it’s a sane approach with a high probability of success.

But waterfall is a recipe for disaster when we’re not really sure about our plan.

Aha, no problem. We’ll gamble a little, early, to make an initial prototype that reduces the risks long-term. Let’s attack one of our problems, to get the really nasty bits sorted out (come up with a half-baked solution), whilst we push forward on the rest of our waterfall project in parallel, investing lots of energy in our primary mission (do achieve a well-done outcome later on). This approach definitely has its advantages, in that with only a small (but non-zero!) risk budget we can achieve significant savings later by solving thorny problems early (or failing the whole project fast). Again, it’s the right approach for some problems, particularly those where you know the overall project is likely to be a success, if only you can solve one or two well-specified sub-problems.

But early prototyping doesn’t mean you can cope with walk-ins.

Like the six player game of Dune, some situations call for a lot more risk taking to achieve a successful outcome. All-out risk taking can sometimes work, but on many projects you’ll want to be hedging somewhat (at least until you know what you’re really doing). Iteration is key (lots of early stabs at the big problems), before you really understand what big, expensive plan of campaign you want to invest in. Keeping resources aside to deal with unexpected events (walk-ins), but balancing that with spending as much as you can on the iteration is a skill. And all of this requires you to be happy with half-baked prototypes, accepting that failure is a real possibility because you do not have excess resources, and admitting that waiting for perfection in your planning may in fact mean you do fail. Arguably, this is what “Agile” development is about.

It’s not the case that any of these approaches is the right one to use in all scenarios. Look at the map.

In my opinion, we all find it too easy to assume that our default approach (waterfall, early prototyping/late waterfall, or agile) is the best one for everything. Again, it’s about our appetite for risk, about what projects we’ve done before, and, of course, organisational culture.

Too often people worry that if a project fails, blame will be apportioned, and thus it is better to “play safe”, be that by inflating estimates to ensure capacity; adding large quantities of contingency time; or writing up long lists of risks in order to be able to point at them in the event of a problem, as if to say “I warned you of these!”. I’m not talking solely about team projects: one can do this on one’s personal projects, too.

However, it’s also very easy to be “overly agile”. To ignore the need for businesses/bosses to have some kind of expectation of what will be delivered when; to begin iteration without having agreed what the desired outcomes are; to avoid any kind of planning; to context switch so much to deal with walk-ins that there is a huge, but hard to quantify, cost.

These are easy traps to fall into. But we shouldn’t. Culture can definitely help. But so can a little bit of self-reflection; and that’s relatively cheap.

Is this going to make any difference?

I’ve had my fill of playing Dune for a while. But it’s made me think about my day to day approach: for some projects, I’ve tended to err on the side of caution when I need to be more agile. For others, I’ve assumed that I can cope with walk-ins “on the day”, where perhaps I should be planning more. Taking a few minutes to question my approach is likely to be time well-spent.

(Oh, and I guarantee that I’m failing to do this enough! Lest anyone think I was some paragon of self-evaluating virtue…)

Ultimately, are you really thinking which strategy to use? Or are you ignoring the map and assuming what you normally do will work?

Aside 1: there’s also an eight player scenario in “Dune”. I think I’d class my tactic for that as the “let everyone else hit each other and see who’s left” approach ;-).

Aside 2: talking of maps and business strategy, Simon Wardley’s maps are very interesting. Not certain what my opinion is of them just yet, but well worth a read of his book (particularly chapter 2) on the subject.