The army is agile!

Up until recently I was a platoon commander in the Swedish national guard. Since all peace time activities in the Swedish national guard are based on work done voluntarily I applied a number of agile principles when running the platoon. I used a task board to visualize all activities needed to plan future exercises.  I had at least monthly meetings with all squad leaders to keep us all updated. At these meetings we also discussed how the platoon activities could be improved and planned for the next few weeks. So we definitely used the concepts of retrospects and task board. Not very militaristic but when working with volunteer weekend warriors I think it worked out pretty well.

The Swedish armed forces enforces mission type tactics. This leadership philosophy was used successfully by the Germans during the second world war  and have since been used in most special forces units. The basic concept is that each commander gives his subordinates the mandate to solve a task given the best way they see fit. The commander must also make sure the subordinates have enough resources to complete any task given. This sounds very agile to me. Maybe not what you expect an organization that is extremely hierarchical.

This made me think that there are maybe more military situations where we can see typical agile properties. And maybe even we can learn from the military to improve how we develop software in an agile way. The first thing I thought of was combat. Military combat means chaos. Agile software development is a try to control the chaos of software development. When I look at how I have prepared my previous platoon for and then engaged in combat have a lot of resemblance with how agile development projects are (or should be) run.


Almost all projects start with some kind of planning and so does military combat. There is also a military saying: "No battle plan survives the first shot fired". So how do I create a good battle plan for a platoon? Well, the bottom line is to provide as much information as I can about the situation and what I want to happen but without being too detailed. The first thing to do is to gather the platoon. The best plan is one heard by everybody and not just the squad leaders since when squad leaders tell their squad some information may be lost or accidentally changed. Once the platoon is gathered I start with giving them information about what's known about the enemy and what's known about other friendly forces. I also tell them what the task of the company is and what's our platoon's task.

When the situation is known I tell the platoon what the goal is. If our task is to assault a hill, I tell them where our squads should end up when the assault is completed. This is very important since during combat it will sometimes be hard to get all the needed orders out to each squad. But since everybody knowns what the goal is everybody can work toward that goal without explicit orders.

After I have told the platoon what our goal is I give quick overview of how I plan to get to the goal. Still without being specific. If there are any situations I can predict I would also tell the platoon what these are and how we should handle them by default.

Example: If we're ambushed from the right. The default action is to suppress with engaged squads and outflank with Hotel-Alpha (Hotel-Alpha being the call-sign of one of the squads).


Now that everybody knows the big picture, our goal and my intentions on how to get there it is time for orders. Exactly how these orders look like obviously depend on the situation. But I have always tried to give an order for what the squad leader can see. And one prepared order. A prepared order is most often what I intend for the squad to do once the order is executed but it can also be a reaction to one of the predicted alternatives we have. Example: Hotel-Alpha, advance as last squad toward target. Be prepared to outflank.

The reason to give an order which only includes one thing that the squad leader can see and one (or maybe two) prepared order is that I want leave as little room as possible for misinterpretation and not force the squad leader to think to much about what comes next. Also if something happens and the orders must be changed my experience is that no orders but a clear goal is better than a lot of orders with a clear goal because people tend to stick to the orders if they still apply.

A little comparison: The goal is to advance to and cross a road and then assault a house. Think about these two alternatives (where everybody knows we are to assault the house):

  1. Advance to the road and cross it. Be prepared to assault the house.

  2. Advance to the road. Be prepared to cross the road.

The second alternative (B) is much easier to do right. Also we don't know what will happen at the road.

Also the order includes important information like where wounded soldiers should be transported, where we should retreat to if the enemy turns out to be too strong and where the platoon commander will be during the assault.

Finally every order is ended with me asking each squad leader and then the platoon if there are any questions. Questions are answered and then each squad commander is asked to repeat his orders. This way I know they know what to do. Even with simple orders you'll be surprised how much can be misunderstood. Especially if you start trying to give orders for several steps of the assault.


So, no battle plan survives the first shot fired. So what do we do to control the chaos of a combat? Information is important. Observations by individual soldiers are shouted and repeated by all others so everybody knows what's happening and can adapt to the evolving situation. The same applies to orders and information from the commander. Also the goal (given previously during the order phase) helps pushing everybody in the right direction. Another important thing to win a fire fight is keeping the initiative. It is always better to act then react. Doing something is better than doing nothing.


So now we've won the battle and achieved our goal. What do we do now? The first thing that typically happens is that the squad leader gathers information from the squad regarding ammunition and injuries. This information is transformed into a summary to the platoon commander indicating what resources are needed (if any) in order to proceed.

Comparing with software development

I'd like to compare a military assault with an iteration. Giving the team the overall goal as well as the iteration goal will help the developers make the right decisions during the iteration.

If we compare the military order with the user stories in the iteration I think we can still learn something from the military. We should only have user stories the team can understand immediately (i.e. "see") and we should keep the number of options (prepared orders) to a minimum. Also make sure that important information such as where the product owner will be during the iteration is available to the team from the beginning of the iteration.

 In the day to day work ("combat") it is important that everybody knows what's happening. Especially when something important happens I think the team would benefit from adopting the military way of shouting out critical events and having everybody repeating them.


Military Software development
Reloading! Installing new version on test server!
Enemy to the left! Broken build!

There is no way anybody in the team would miss something if everybody shouted stuff like that out.

When the iteration is over we should naturally have a retrospect but there is one thing we can learn from the military. That is how we present the result of the retrospect. If the suggested improvements from the team are presented in terms of  "what we need to complete the next iteration" I think it is more likely to be taken seriously than if it's just "we want to do this since it will be better". Also it focuses on what's needed to improve the process now. Stuff that will improve the process later can also be handled later.

Comments (1)

  1. Military combat is not the only military concept where software development can learn. One thing we used

Skip to main content