Introduction
Here’s a dollop of wisdom from a professional trainer. If you tell a partial truth enough times, and with enough confidence, it ultimately becomes a lie. There are exceptions to every rule, and any best practice can be followed to the point of absurdity. In this respect, I believe we are leaning too much into OODA.
Many Agile and/or business consultants make a big thing of OODA. In case you are unfamiliar with the OODA loop here’s a review. It was invented by US Air Force Colonel John Boyd to try and summarise the steps involved in reacting to a threat during combat operations. We Observe some event (such as a puff of smoke and a zinging sound), Orient toward it (We’re under fire!), Decide what to do (Take cover!!) and finally Act (dive into the trench).
Agile consultants reference the OODA loop as a justification for making teams ever more flexible and responsive to change. The thinking is the more we can tighten and optimise this loop the better the odds of success. Whilst this view is not without merit, I believe it is flawed in two ways. In this article I would like to explain what they are.
OODA is an Obstacle, not an Objective
Outside of my day job in software I volunteer as a martial arts instructor, specialising in combatives and self-defense. We do teach OODA, but only as a really bad idea. Simply put, if you need time to think, then it's too late.
In an emergency, the time to orient and decide is entirely absent. You have to act and hope your instinctive reaction is the correct one. In any crisis adrenaline brings speed, but it removes wisdom. As the Greek poet Archilochus said:
"We don’t rise to the level of our expectations; we fall to the level of our training."
Every combat sports coach is familiar with Hick's Law — the more options you have, the longer it takes you to come to a decision. This has been the downfall of many a rookie fighter.
This is why in your training you should:
- Boil down the potential options to a limited set that works for you
- Act according to high level goals that can be expressed in many ways
- Aim to transcend technique Shuhari and respond spontaneously
With this kind of focus you can skip the OOD part of the cycle and proceed directly to A. Its not about streamlining the decision process but removing it entirely.
Hopefully these ideas sound familiar, because they are as old as the hills and baked into the original concepts behind lean and agile decision making. To take three examples:
- The Dreyfus model stresses unconscious competence at the highest level of proficiency. The doctor starts running to the patient before they know why. The goalkeeper starts their dive before the striker kicks the ball.
- eXtreme Programming contained the idea of a System Metaphor, which was as simple as possible and intended to facilitate communication within the team.
- David Marquet’s famous video on decision making stresses the autonomy of individuals, and placing responsibility beside competence.
So perhaps what we should be focusing on is not speeding up the collective decision making within the team, but empowering individuals to make the right choices in moments of crisis. In the aftermath if there are apologies to be made, and damage to be swept up, that’s just part of the game.
It Pays to be a Warthog
My second criticism of OODA is that raw speed isn’t the only variable that determines success. In the race between the Tortoise and the Hare the Hare doesn’t always win, especially when the Tortoise has a machine gun.
Given that OODA originated in discussions about Fighter Aircraft, I invite you to consider the A-10 Thunderbolt II.
This couldn’t be further from our mental image of a fighter jet. But it is an aircraft beloved by the US military, and more than capable of holding its own in the sky. The design is based not around speed but resilience, reliability, redundancy and the huge rotary cannon that occupies most of the forward space.
Although not intended for dog fighting, a fighter trying to attack an A-10 has issues slowing down enough for a second shot. Should the more agile fighter overshoot the (heavily armoured) A-10 then it’s in trouble. Its delicate avionics and intricate airframe won’t hold up against a 1800 kilo Gattling Gun.
The lesson for software teams is that it’s a great thing to be able to react quickly to change, but sheer manoeuvrability isn't the be-all and end-all. A team that knows its strengths, trusts in its core values and refuses to be blown off course is always going to be a force to be reckoned with.
Conclusion
To reiterate, I don’t have anything against the concept of OODA, or using it as a mnemonic to increase the efficiency of communication within a team. However, the best teams will support individual action in anticipation of later debate. After all, that’s what retrospectives are for. Plus when all is said and done every team should play to it’s strengths. If your team is more of a Fezzik than an Inigo, maybe that’s something to celebrate…
This article was previously published on Medium.
