I have spent some time working on an internal application to support Agile developers (sort of like Microsoft’s TFS but without the enormous price tag, and closely integrated into our documentation and management systems). Because of this, I have done quite a bit of thinking about Agile and Agile development. There appears to be a consensus that Agile is good. In fact, the opposing paradigm, “waterfall” development, is widely described as an accident, or an anti-process. Winston Royce, the Waterfall’s erstwhile creator, presented the model and in the same breath stated “I believe in this concept, but the implementation described above is risky and invites failure.”1
However, the two models are arguably equally effective as long as the development environment is completely static: if new information never comes to light, specifications and requirements never change, and all details of implementation are known from the get-go, then the waterfall method and the agile method should have identical outcomes by the time the software is done (Agile development, however, should be producing useful stuff throughout the entire period as well, which some Agile evangelists will say can generate revenue. But once the development cycle ends, Waterfall “catches up” by producing the entire finished product. In theory.)
Of course, no real-world development occurs under such ideal circumstances. Change is inevitable — changing knowledge, changing requirements, and even changing personnel — and that’s where teams get into hot water. The waterfall method has no mechanism to respond to change.
Agile and non-agile development both follow the same general process:
- Collect information from users, managers, and other stakeholders about their desires, expectations, or specifications for the application.
- Synthesize these into a software design. What are you building? What is it expected to do, and what features are optional? How should the functionality be implemented?
- Decide which things you are actually going to commit to, and distribute responsibility for these things among the team.
- Actually do the development, resulting in a working, QA-tested product.
The difference is that Agile teams navigate these four steps in a matter of 2-4 weeks. Waterfall teams can take months or years to complete the process. This is important because Step 1 is the only time you can respond to changes in the environment, which means that you risk wasting time in steps 2-4 if your information is out of date. This risk increases the longer your loop becomes, such that waterfall teams almost always encounter situations where they have to break out of the cycle in response to changed requirements — or worse, they simply plod on, only to find, 8 months later, that customer requirements have changed, that the wrong features were implemented, or that there is simply no market for the product they created!
Software development isn’t the first profession to realize that only adaptive, iterative processes, which rapidly adjust to feedback, are suited to environments in flux. The Agile Manifesto would make perfect sense (software references aside) to Sun Tzu, who proposed similar ideas two and a half millennia past. More recently but in the same field — military strategy — an Air Force fighter pilot, John Boyd, introduced the same concepts to the U.S. military at the cost of his career. Probably his most famous idea was the “Observe Orient Decide Act loop”, or OODA loop, which he presented in his brief called Patterns of Conflict.
The concept of the OODA loop is extremely simple. Wikipedia puts it succinctly in terms of physical action [2]:
- Observation: the collection of data by means of the senses
- Orientation: the analysis and synthesis of data to form one’s current mental perspective
- Decision: the determination of a course of action based on one’s current mental perspective
- Action: the physical playing-out of decisions
OODA loops aren’t limited to individual action; Boyd believed the concept existed in organizations as well: a single corporation can encapsulate many different, nested loops. Whether the loop is personal or organizational, Boyd’s suggestion is to “get inside” the enemy’s (or competitor’s) OODA loop. This basically means that if you change the circumstances on the enemy faster than they can observe and react, you can outmaneuver them. If you can get inside their loop, the theory goes, victory will follow. In the military, these principles are generally categorized as Maneuver Warfare.
Does this sound familiar? Agile is maneuver warfare, applied to software development. At least — some of it is. Obviously there’s a little more to the Manifesto than just a speedy development cycle, and a little more to Agile than the Manifesto. Nevertheless, the two are closely intertwined; development in short iterations is probably the central attribute of an Agile development process. So, what can Agilists learn from the OODA loop?
First, it’s absolutely critical to be responsive to feedback at all times but especially after each development iteration. Agile teams need to make sure not to skip the “observe” step — getting customer feedback, examining outcomes, and team introspection are all part of the observations that should be made during the first phase of the cycle. If the cycle is not executed completely, including re-observing and re-orienting after each iteration, the biggest benefit of a short development cycle — responsiveness — is quickly lost. Second, the OODA loop gives Agilists a way to explain the benefit of having agile teams within a waterfall company, where the Agile “value proposition” is made less clear by company policy limiting incremental product deployment. Even if the company has large OODA loops that progress at a glacial pace — like multi-yearly release cycles — smaller sections of the organization can still benefit from the implementation of Agile. If individual development teams can be freed from the release cycle (or if they directly and regularly interact with customers themselves), implementing Agile will allow them to quickly respond to new customer interests, industry trends, development by other teams, or any of the changes that flux the development environment. Instead of being limited to a long release cycle, the team can quickly turn around with results, potentially improving customer satisfaction or outmaneuvering a competitor. Even if teams can’t be freed from the organizational release cycle, using Agile principles can still help the teams adapt quickly to changing internal requirements or other new information.
Indeed, this was Boyd’s key recommendation to the military: that power be pushed to the fringe of an organization, where the OODA loops are smaller. Leaders, he suggests, should train their subordinates extensively and then give them as much decision-making power as possible. A well-trained man in the field can recognize and adapt to changing circumstances much faster than the officers in High Command. Therefore, an organization which trains its operatives to quickly make decisions in response to their observations in the field will be able to outmaneuver an organization which centralizes tactical command.
The Agile correlate: give teams the training, freedom, and exposure they need to quickly respond to changing circumstances or new developments in the field without tying them down in corporate process.
