Agile Development and Military models
I’ve had the title of this blog post kicking around in my “To write” column for a little while. It’s a post drawing comparisons about military teams and Agile teams - they are more similar than you think!
Whilst the subject has been sat rotting away in my list, not getting written, I travelled to work today and realised that on August 2nd 1993 (20 years ago to the day) I was a nervous 17 year old making his way from home to start his basic training in the British Army.
This photo was a few years later, I think 1995 - some of the guys here are still serving so I obscured their faces.
So, what is worth comparing about military teams and models and Agile software development.
Gene Kim makes an excellent point in Visible Ops about the people that lead high-performing IT organisations.
When we first studied the high performing IT organizations, we noticed something unusual. The backgrounds of the people leading them typically came from one of three backgrounds. They were either a non-commissioned officer in the military (usually E-5s or E-6s), they were chemical engineers, or they were auditors.
We then started asking, “what values do these three professions have in common?” And the answer became obvious. They valued rigor and discipline.
Non-commissioned officers give live ammunition to 18 year olds. The remarkableness of this became even more extraordinary, which I learned that in restaurant operations, management often doesn’t even like giving knifes to 18 year olds, because the accident rate is so high.
Chemical engineers have long, elaborate and ordered recipes, where an endothermic reaction can become catastrophically exothermic if steps are mis-ordered.
And auditors? Well, they love almost any control.
So perhaps there is some truth here.
Serving in the military has a number of interesting characteristics - you work in small teams that are designed to be stable.
In an airborne infantry battalion there is an formation of around 600 men. But the organisation is structured around “sections” of 8 men that remain constant. Members change over time through promotion, or through leaving the service (and sometimes in more tragic circumstances) but largely sections live, train and work together with the same setup.
Teams that remain stable quickly improve and develop their own sub-culture and rhythm. They abide by common rules and conventions but ultimately have their own way of working. Newcomers to the section, even experienced people, have to learn the new way of working.
Is there a comparison here with Agile teams that are small in number and perform better if they don’t change between projects?
Infantry section commanders try and disseminate skills across the men they command. A section contains soldiers that are general purpose and have common soldiering skills, but there are also specialists.
A section would have a machine gunner, a signaller, a medic and perhaps a demolitions/explosive expert. But of course, in that line of work, you can’t guarantee that your experts will be available when you need them.
So military teams are cross-trained to guarantee continuity of service - if people are otherwise unavailable you can carry on.
Very similar to Agile teams that are cross-functional to avoid silos of skill.
Military teams work under duress and make a lot of mistakes :-)
But more importantly than the mistakes that are made is the culture of improvement. When training exercises end teams are happy to talk about what worked well, what didn’t work and how to repeat success and avoid repeated failure.
This extends from personal inspection (if my kit didn’t perform as I wanted and I spent nights shivering in a wet sleeping bag I’d be sure to avoid a repeat failure) to section level and higher to the entire battalion.
Agile teams meet at regular intervals to hold retrospectives
During large scale exercises - at battalion level (600 men), brigade level (1,800 men) or higher - there is an amazing amount of planning and logistics involved.
But military planning is a lot more agile than you would think.
There is a famous saying within the military phrased by German Field Marshall Helmuth von Moltke the Elder (1800 - 1891)
Moltke’s main thesis was that military strategy had to be understood as a system of options since only the beginning of a military operation was plannable.
As a result, he considered the main task of military leaders to consist in the extensive preparation of all possible outcomes.
His thesis can be summed up by two statements, one famous and one less so, translated into English as “No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength” (or “no plan survives contact with the enemy,”) and “Strategy is a system of expedients.”
Compare “no plan survives contact with the enemy” to Agile thinking that the best plan will emerge in response to quick feedback from real experiences
And lastly - as a sweeping generalisation - members of military teams love being part of their unit and appear to be arrogant arseholes about it… by design.
The Army puts a huge amount of effort into developing esprit-de-corp, team cohesion and morale.
The British Army especially with its antiquated and archane regimental systems maintains a huge amount of duplication and waste to preserve the loyalty that soldiers have to their own regiments.
According to Alexander H. Leighton, “morale is the capacity of a group of people to pull together persistently and consistently in pursuit of a common purpose”
An American general defined morale as “when a soldier thinks his army is the best in the world, his regiment the best in the army, his company the best in the regiment, his squad the best in the company, and that he himself is the best blankety-blank soldier man in the outfit.”
H. R. Knickerbocker, 1941
Ever met an Agile team bursting with self-confidence bordering on arrogance? Think the Agile methodology ever encouraged that team cohesion??
So there are the comparisons between Agile and Military teams
But this doesn’t explain why some ex-military people do well in Agile software development or IT Operations.
The last comparison I can make is the extensive use of models.
The Army loves models - it builds on past learnings and reuses tactics for years to come. Models provide a framework in which to work and they allow flexibility and creativity to customise within the framework.
Models provide a proven best practice, examples and context in which to operate. They are sometimes hard to learn, but generally easy to follow and get the practitioner proficient and productive quickly.
Make your own comparison on this one :-)
The photo I posted above was a few years after my first day in the Army - I just found this one which I think was 20 years ago tomorrow. First map reading lesson, lost somewhere in a field.
