In Part I I promised a comparison of maneuver warfare and the values and principles of agile development. I was surprised to find so many similarities! One is a strategy around warfare and the other grew up around software development, so of course there are some differences. In the following you’ll find a list of the Agile values and principles, accessed from agilemanifesto.org, and similar concepts found in Maneuver Warfare Handbook, by William s. Lind.
As I noted in Part I, I’m no expert on maneuver warfare, as evidenced by not even having read the entire Maneuver Warfare Handbook, but only the introduction and first three chapters. Even so, there is a lot to draw on in these first chapters for comparison to Agile and I want to share what I’ve discovered.
| Agile Value | Maneuver Warfare |
| Individuals and interactions over processes and tools | All patterns, recipes and formulas are to be avoided. (p.7) Rather than concentrating on formulas and checklists – with their inherent predictability – maneuver warfare emphasizes a thought process. It is a process of seeing your options, creating new options, and shifting rapidly among those options as the situation changes. (p. 23) |
| Working software over comprehensive documentation | |
| Customer collaboration over contract negotiation | |
| Responding to change over following a plan | They must be able to see their options in the situation before them, constantly create new options, and shift rapidly among options as the situation develops. (p. 7) |
| Agile Principle | Maneuver Warfare |
| Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. | |
| Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. | Maneuver warfare means you will not only accept confusion and disorder and operate successfully within it, through decentralization, you will also generate confusion and disorder. (p. 7) Note: Agile doesn’t aim to generate confusion and disorder 🙂 |
| Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. | The mission is a shorter-term contract. It is a “slice” of the commander’s intent, a slice small enough to be appropriate to the immediate situation of the subordinate unit. (p. 13) |
| Business people and developers must work together daily throughout the project. | |
| Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. | A mission-type order tells the subordinate commander what his superior wants to have accomplished. That is the mission. It leaves how to accomplish it largely up to the subordinate. As the subordinate’s situation changes, he does what he thinks is necessary to bring about the result his superior wants. He informs his superior what he has done, but he does not wait for permission before he acts. (p.13) |
| The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. | |
| Working software is the primary measure of progress. | |
| Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. | |
| Continuous attention to technical excellence and good design enhances agility. | A major difference between a military that can do maneuver warfare in combat and one that can only talk about it is excellence in techniques. Sloppy techniques slow down your Boyd Cycle and make your action ineffective. (p. 12) |
| Simplicity — the art of maximizing the amount of work not done — is essential. | |
| The best architectures, requirements, and designs emerge from self-organizing teams. | Only a decentralized military can have a fast OODA Loop. If the observations must be passed up a chain of command, the orientation made and the decision taken at a high level, and the command for action then transmitted back down the chain, the OODA Loop is going to be slow. (p. 6) |
| At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. | Another principle that follows from this is: Never do the same thing twice. Even if something works well for you once, by the second time the enemy will have adapted. So you will have to think up something new. (p. 8) |
| (No corresponding Agile principle.) I was surprised to not find a strong correlating statement in the Agile Manifesto. I included the maneuver warfare item here because it’s relevant to agile. | Under such a system, how do you avoid mistakes? You don’t entirely. Mission-type orders and a “zero-defects mentality” are contradictory. (p. 14) A maneuver warfare military believes it is better to have high levels of initiative among subordinate officers, with a resultant rapid Boyd Cycle, even if the price is some mistakes. (p. 14) |
Photo by Irina Nalbandian on Unsplash
tl;dr
There are similarities between maneuver warfare, OODA Loops, and the values and principles of Agile development. Both acknowledge, accept, and deal with changing requirements and situations. Both espouse trusting the team to accomplish the mission. And both rely on excellence in techniques.
engineer your life
- Although the Agile Manifesto was created to guide software development, and maneuver warfare was documented as a combat strategy, are there any concepts of either you can draw on to make your work more efficient?
references
Manuever Warfare Handbook, William S. Lind, 1985
Agile Manifesto and Agile Principles quoted from https://agilemanifesto.org/, accessed February 8, 2020