How the U.S. military prepared me for Agile

When I retired from the military at the ripe old age of thirty-eight, I had spent four years in the United States Marine Corps and sixteen years in the United States Army. As the retirement pay for a First Sergeant/E-8 with just over 20 years of service was not enough to fully support a family, I had to get another job—and fast. At that time, I had an Associate Degree in Computer Programming, so I took a position as a full-time programmer trainee and went to college at night to get my Bachelor Degree in Software Engineering. I had never really considered how my career in the military affected my civilian career until I started learning about agile. Don’t get me wrong, I knew that the military-instilled discipline and sense of honor and loyalty had made me not only a better man but also a better employee; but I had never really considered how my skills as a First Sergeant could have made me a better software engineer.

During my time in the military, I learned principles that mirror those I have seen in some of the common practices that several of the agile frameworks/processes espouse. I would like to compare some of these practices with what I learned in the military. As you read, please keep in mind that I am coming from a combat arms unit, mainly infantry, perspective and that this perspective is based on the time I spent in the military (1971-1992). Things have changed dramatically since I was on active duty, so what was common practice then may no longer be in effect. I also understand that the Marine Corps has established a few doctrines that are somewhat based on the principles and practices of agility.

The first concept I want to address is organizational structure. Both the military and civilian businesses are extremely large organizations that have multiple layers of geographically dispersed groups. Like many civilian organizations, the military has some form of matrix management. However, the combat arms (infantry, armor, artillery, etc) divisions of the military are completely dependent upon the concept of small co-located teams. Here is a quick primer for those that have never served in the military and do not understand the structure. Generally, the organizational structure of an Army consists of the following:

Army Organizational Structure

Let’s break down the structure and add some leadership roles:
Fire teams: 1 team lead + 2 – 3 people
Squads: 1 squad leader + 3 – 4 fire teams
Platoon: 1 Platoon Leader, 1 Platoon Sergeant, 3 – 4 Squads
Company: 1 Company Commander, 1 First Sergeant, 3 – 4 Platoons
Battalion: 1 Battalion Commander, 1 Sergeant Major, 3 – 5 Companies

I am sure you get the idea, so I will not go above the Battalion level. The military perfected the concept of small teams working in parallel a long time ago. Missions are broken down into the smallest assignments so that eventually each individual fire team member knows what he/she has to do to achieve the team’s mission and thereby make their superiors happy.

Project Assignments
In the military, as in the civilian world, someone at the top decides that they need something done, when they want it done, and even sometimes how it should be done. Fortunately, in both the military and civilian world some leaders understand and practice the concept of servant-leadership. While individuals may not always be allowed to choose their assignments, these servant-leaders allow and encourage collaboration and self-organizing teams. Many times throughout my career, I was given the opportunity to discuss the best way to accomplish a mission with my team(s) as well as the team leaders within my platoon and/or company. As you can see, we were using agile concepts long before they were called agile.

We also had micro-managers who wanted to dictate everything; these folks did not usually last too long. During the vast majority of my career, I knew that I had the ability to inform my superiors if I thought there was a better way; sometimes they listened, sometimes not. Another aspect that needs to be addressed is flexibility. In the military, we had to be flexible in order to adapt to ever-changing circumstances. At any moment, a situation could pop up that was not planned for or anticipated. We had to be able to analyze the changes very quickly and to inspect, to adapt, and to overcome. We were able to do this on all levels, from the highest to the lowest.

Delivering Frequently

How do you eat an elephant? One bite at a time.

From the dawn of time, all military organizations have understood that winning is impossible if their troops are overextended. Therefore, the missions of military teams are normally broken down into very small chunks that can be accomplished quickly. At no time during my career was I ever on a specific mission that lasted more than 2 – 3 weeks. If the missions were longer than that, the teams became exhausted and weary, the supplies were diminished, and continuing support was difficult. We can see today, both in the military and in the civilian realm, how long missions (projects) affect overall results. In my experience, longer missions (projects) usually result in higher costs and higher rates of failure. I learned as a young Non-Commissioned Officer that the key to success was to have short missions that allowed the team to accomplish something of value more frequently thus increasing the morale of the team(s) and improving the overall chance of success on future missions.

Planning

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” Dwight D. Eisenhower

One of the most difficult things I have had to learn in my agile transformation was how to determine when you have had just enough planning to get started. I experiencved this in the military and still experience it today. I have been asked this question on every single project I have been on. The best answer I can come up with is to say the following:

If you have enough information to start work for the first sprint, then you are ready

This doesn’t always work though, especially for people that still believe you have to get every minute detail documented before you can even think about starting a project. This is where the military deviates dramatically from agile. There are numerous regulations that describe in detail how to properly conduct Military Operations Planning.

Unfortunately, even the best-laid plans cannot and normally do not take the unexpected into account. Business and marketing people, like military planners and intelligence officers, do not always have the best and latest information; so while a plan is an absolute necessity, history has taught us that even the best-laid plans can fall short. My take on all of this is to FAIL FAST, FIX FAST. You do this by getting just enough information to get started, then see if it works or not. If you fail, no problem, you have identified an issue early on and can figure out how to fix it or change it.

Retrospectives
The military perfected this practice long before I began crawling on the sand at Parris Island. What Scrum would call a Retrospective, the military labeled an After Action Report (AAR). AARs were conducted after every field exercise and/or mission. The difference between an AAR and a Retrospective are varied. AAR’s have a prescribed format and are usually attended by the leadership. I don’t ever recall being invited to an AAR as a private. However, I always knew when I didn’t do what was expected of me.

The leadership sent the message down the chain; then on a regular basis, each team would brainstorm ways in which to perform at a higher level. We spent hours and hours looking at various ways to do something; and our more experienced leaders at the Team, Squad, and Platoon level were continually showing us how to do something they had learned on previous missions and/or exercises. As I moved up the ranks, I added what I had learned experientially to the knowledge base that was imparted to me; and just like those who had gone before me, I began to train others to find a more efficient, effective way of performing tasks.

Conclusion
I believe agile is like a multi-faceted diamond. It takes a trained eye to spot all of its brilliant dimensions. But if you take the time to stare into it long enough, you will see that each angle reflects light differently. Remember, you are not here to “be” agile like anyone else. You are here to “be” agile like only you can. You are unique. No one else has your experiences and your knowledge; they are yours and yours alone. My years in the military have enriched my agile practice. I hope that this article spurs you to take some time to think about the principles of agile and to consider how you may have used them in your day-to-day activities without even realizing it.

I appreciate the time you have taken to read this post, and I look forward to hearing from you.