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.

Comments

  1. At Chapter 9 Achieving, the content of paragraph 'Reverse Planning' remembered me the use pull system in Lean sw development.

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica