Command and control in Agile

Command and control.  Pretty simple concept, eh?  You report to me, I tell you what to do.  It gets done or you get fired.  Everybody understands how this works.

But is it successful?  In the archaic corporate structure from the last millennium, it was very successful because all parties understood their role.  Those who were happy with it and “played the game” moved up in the company, thus creating disenchantment in the ranks below – you know, where the real work gets done.

Then Agile came along, that is.  Suddenly teams were telling management what was going to be done,when it was going to be done by, and how it was going to be done.  Managers, especially insecure managers, are not entirely comfortable with this approach.  They ask themselves, “what does this do to my position, my role, my future?”.  The real question they should be asking is, “How can I help?”

When Agile works, it is a beautiful thing – teams are productive, software is produced and made available to customers on a regular basis for their feedback.  When companies say they are Agile, but still have a command and control culture, I don’t know what that is….but it ain’t Agile.

Agile should enable creativity, innovation, and accountability on a team.  Command and control introduces fear, which shuts down these admirable traits and forces teams to rely on only one trait:  survival.  Here are just a few of the types of managers who can hinder, and even stop, your Agile adoption due to their ability to introduce fear into the work environment:

 

Kaptain Kaos – Everything is a crisis when he’s around.  Everything has to be done with haste and if quality is sacrificed, so be it – we’ll just fix it later.  However, later never seems to come.  Since it has to be done NOW, he feels like he needs to tell you exactly what to do.

 

The Clam – This manager is never around when you need him and is impossible to find.  However, he will “come up from the sand” if you start to threaten the kingdom he has built over the years and threaten him with innovation.  Often likes to say, “We’ve always done it this way”.

 

The Ostrich – Similar to The Clam in that he’s never around when you need him.  However, he seems to be impossible to find when feeling threatened by anyone since he really does not like confrontation….at all.  Do not expect support, guidance, or much of anything from this guy.

 

The Beggar/The Pleader – This manager will only come to you when he wants something else done and it is never what you are already working on.  Otherwise, you really don’t matter to him.  See Bill Lumbergh in “Office Space” for the prototype.

 

The Rainman – This manager will confuse you with obtuse facts and obscure data that no one else seems to know.  While he may be correct, his end game is to confuse you so thoroughly that you begin to question your own actions and have no choice but to go to him for help.

 

Groundhog Day – Keeps asking you or the team the same question in different ways over a period of several successive days.  His hope is that eventually he will trick you into giving him the answer that he wants, or, beaten down, you will just give up and give him the answer he wants….and then you’ll be held to it.

 

The Wimp – Tells you that he will back you up, but when challenged, folds like a tent in a hurricane and throws you under the bus.  You are now alone as you face the wolves.

This list is not exhaustive.  What are some types of managers you have encountered that have been detrimental to your Agile adoption?

What makes these individuals even more dangerous to your Agile adoption is that they generally have positive intent.  They are trying to do good, for the most part, but are just going about it the wrong way.  The Dunning-Kruger effect (illusory superiority) can also magnify this type of behavior.

The best type of manager to work for in an Agile environment has these qualities:  supportive, trusting, focused on your career, optimizes workflow for the team, enables the team to grow, removes impediments, allows decisions to be made at the lowest possible level, and shields the team from the types of managers listed above.  I have worked for some very good managers that meet most, if not all of these qualities.  They are an absolute joy to work with (notice that I didn’t say ‘work for’) and truly make a difference by only stepping in when necessary, and no more.

There is another part to this Agile equation – an effective, self-organized team that is truly accountable.  If the team is not stepping up, it only creates fertile ground for the types of ineffective managers listed above to come into being.  The team can be dysfunctional and also hold back your Agile adoption….but that is a blog for a future time.

2 Replies to “Command and control in Agile”

  1. One more type to consider: The Controller. They don’t just manage the resources. Instead, the resources *belong* to them, so everything needs their approval. Teams, along with their product owner, are not able to decide on delivery without permission from this manager. This manager will also decide to trump the priority list set by the product owner if they don’t agree with the request.

Leave a Reply

Your email address will not be published. Required fields are marked *