Skip to main content

Agile Lessons from the Army Leadership Field Manual

You will be amazed to learn that Army Field Manual number 6-22 is entitled Army Leadership, Competent, Confident and Agile.  If it weren't for the small word, "Army," at the beginning of this title, any aspiring lean/agile leader might eagerly browse through this readily available text for tips and tricks to warm the heart and increase the team velocity.  In case there's any suspense, I'm going to suggest that despite the title, you do exactly that.

Of course, in the world of the Army Field Manual, command-and-control, like gravity, isn't a guideline--it's the law.  And we in the agile/lean community typically frown on command-and-control right along with "waterfall," "big modeling upfront," and using pens smaller than sharpies.  See, for example, this impassioned description from the "Energized Work" blog:

Command and control elicits compliance to enforced processes through management by policy. Focusing on process fixates management on the means rather than the result. Emphasis is placed on building hierarchies, formalising roles, and people are viewed as resources. All this amounts to bureaucracy and adds no value. Hierarchies introduce protracted decision-making. Decisions made up the hierarchy typically don't involve the people who will be tasked with fulfilling the decisions. And consequently, the support from these people for the decisions is absent. These decisions aren't easily reversed. All this nonsense doesn't exactly set the project up for success. I can't think of a better way to demotivate people and reduce productivity. 

Interestingly, however, although FM 6-22 is uncompromising in the matter of the leader's authority and concomitant responsibility for the results achieved by her team, it describes a philosophy and practice which would add a lot to any agile work environment.  It turns out that although the ideal Army leader works within a command-and-control framework, her leadership style is the opposite of that outlined by the Energized Work blogger.  For example:
  • People versus process:  in FM 6-22, leaders (and soldiers) are defined by character, knowledge, and application, or "BE-KNOW-DO" for short:  results come first from who you are, second from what you know, and third from what you do.  FM 6-22, in fact, is uncompromising about the fact that people are always more important than process:  "Respect for the individual is the basis for the rule of law—the very essence of what the Nation stands for. In the Army, respect means treating others as they should be treated. This value reiterates that people are the most precious resource and that one is bound to treat others with dignity and respect." (4-18)
  • Means versus results:  FM 6-22 outlines ten ways for leaders to influence their teams which are better than simply issuing a direct order.  "Compliance-focused influence is not particularly effective when a leader’s greatest aim is to create initiative and high esteem within the team."  A good leader is a person focused on results, not process, and who knows how best to work with her team to achieve that result (options include "pressure," "legitimate requests," "exchange," "personal appeals," "collaboration," "rational pursuasion," "apprising," "inspiration," "participation," and "relationship building.) (7-3 to 7-17)
  • Developing the team:  agile theory is pretty silent on this matter, and indeed in practice, companies love to hire young people infatuated with software but who won't throw their weight around when it comes to making decisions.  FM 6-22 puts "developing the team" front and center as a responsibility of a good leader, and provides an entire chapter on how to choose your team and how to counsel each individual to help her advance.
Certainly, FM 6-22 occupies a world foreign to what most of us experience in the "trenches" of corporate America, where good leadership can literally mean life or death to a large number of people.  Certainly I have no knowledge about how the ideals of FM 6-22 are applied on the ground by actual Army leaders.  Likely, they are as bad at "command and control" as our own corporate commanders. Certainly we in the agile/lean community embrace an egalitarian philosophy that says the person doing the work knows more about the problems at hand than a Vice President eight levels above her.  Certainly we don't want to put as much energy into organizing our hierarchies as the Army has done over the past 200 years--picture what that would do to our deadlines.

But this field manual is a gold mine for suggesting how to be a leader, how to scale leadership techniques, how to motivate, counsel, and talk with other people.  I can't do it justice in a blog.  Please think about reading it.

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
WBABA: in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…