I’m not really a big fan of war. I’ve never been in one, don’t want to be in one and I’m very clear that when it comes to war, I really have no idea what I’m talking about. In the past, I’ve given other people a hard time for talking about war as if it is the same thing as software. It is very important to understand that it isn’t the same. This is just another metaphor that we’re using to explore how to handle the massive levels of uncertainly and complexity that we have to deal with when we’re dealing with software development. Over the last few days I’ve found myself getting very excited explaining one of Boyd’s big breakthroughs - Energy-Manoeuvrability Theory, which combines an understanding of Thermodynamics with dog-fighting strategies and fighter plane design.
And I’ve been reading John Boyd’s later thinking on blitzkrieg and guerrilla tactics - and thinking about software development. To really, really simplify this. There are two major approaches to warfare [2] - “Traditional Warfare” - everything is commanded and controlled from the centre. The forces are massed and lined up against the enemy and they move in-step - with a single front. The idea is that side with the most men (they’re still mostly men), money and guns wins. This is what Boyd calls “Hey Diddle Diddle, straight up the middle.”
There’s another approach. In this approach, attacks are not tightly coordinated by “Command and Control” - general objectives are communicated to the commanders on the ground by the generals, and how those commanders achieve those objectives is left to the commanders to decide. The commanders are also not made to wait for each other. Their aim is to proceed as fast as possible into enemy territory with a view to joining up later. This kind of approach has on several notable occasions been extremely “successful” (depending, of course, which side you were rooting for). The German army had tremendous success with this approach - their version of it was called “Blitzkrieg” at the very beginning of WWII (and they had actually started to have some success with it towards the end of the WWI). The Viet-Cong had success with this kind of approach in the Vietnam war and the United States Marines, using John Boyd’s own version of this approach, had considerable success at the beginning of the first Gulf War.
And in a way, YOU’RE like that digital watch! Sorry, flashback to my Methodist Sunday School education, which was very heavy on the creaky and over-burdened metaphor (once the topic of discussion was a packet of special porridge that helped constipation).
But, meanwhile, back at the point. Software - you can do software development this way. Rather than trying to keep all of the software “in step” you can let individual teams get on with it - and link up later. That’s the important thing - link up later. This is very different from never link up and also it’s also different from insisting that all linkups are planned at the start (which is sometimes called dependency planning). This is what is the central I idea in this leaked post, comparing Google and Amazon.
I was imagining a game that you could use to show this. You could have some way of winning territory - say rolling a dice. When you “win” you can move counters (troops) into territory to occupy it. When troops occupy territory, they find resources. When they do they “raise a flag”. The flag says what they’ve got (water, food, medical supplies, visibility) and tells the other teams how to talk to them to get those things. A “second wave” of players then comes along to support those gains, while the first wave of troops applies this “like water” approach to the remaining areas that haven’t been conquered.
Like many of the lay Methodist ministers of my Sunday school days - this metaphor is a bit mixed/stretched, but I’m wondering if there’s a coding dojo-style game where you could do something similar. You divide the terrain into a set of “Stories” and the team explores the terrain they attack the “easiest” parts of the terrain first - they crawl over the requirements like water. When you think about attacking a software problem in this way, you start to see the role of product owner, as commanding officer, the role of Scrum Master as sergeant major (I know, I know, this is all heresy) and the role of senior product owner as a general. How do architects fit? How do UI/UX/Usability/Testing people fit into this?
But, also, I think you need someone else, in fact I think you need two people. You need one person who’s job it is, just to keep making sure that what’s happening on the ground is being communicated back to the generals - let’s call this person a senior Scrum Master.
But you also need someone who’s job it is to crawl all over the battlefield and collect and present data - let’s call this person and information officer.
Let me go back to Boyd for a moment.
The generals wanted faster planes - even though what country’s defence needed was more manoeuvrable planes as Boyd demonstrated. The generals wanted planes that would do Mach 3. Even though air-to-air combat rarely happens at speeds faster than Mach 1.5 and miles per gallon when you’re flooring the accelerator and taking it to Mach 3 means that you can do it for about 10 minutes, then you have to go home.
In software development, the generals seem to want something similar - they want to see software developed according to plans - on time and to budget and complying with standards.
[1]I’ve been on holiday for two weeks. I spent the first week letting my brain rest, reading endless Lawrence Block novels. Then I did some re-reading - I re-read “No One Would Listen” by Harry Markopoulos and I re-read “Boyd: The Fighter Pilot Who Changed the Art of War” by Robert Coram and that brought me onto “Mind of War” - another book about John Boyd. I’ll probably end up reading “The Pentagon Wars”, which is another book about John Boyd and his circle. Oh, and I ate roughly my own body weight in pork gyros.
[2] One thing I’ve been saying for a long time is that one of the main jobs of talking about, thinking about and actually doing software project management is coming up with helpful metaphors for software development. One thing that I’ve just realised over the last few days of reading is something that I vaguely got a long time ago - but it’s taken me until now to have it really sink in. All we have is metaphors - we don’t have any real world beyond the metaphors. The metaphors are it. And yes, I know, “software like water” isn’t a metaphor, it’s a simile. All we have is metaphors, similes and pedantry.