Geeks With Blogs

Geekus Con Livus Malcolm Anderson's home for Geeks With Lives

"Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity."
George Smith Patton


We talk a lot in the agile development circles about something evil and bad called "Command and Control."  I've found that most people believe that the term comes from the military and that it means "massive top down planning combined with myopic micro-management." 


It's true, the term does come from the military, but the concept was meant to describe the effective foundation of the military separation of responsibilities.  To overly simplify things, in the military, it's the the officers job to command (give the what), and the control (the how)is left to the enlisted personnel. 


This can be illustrated by a simple mental leadership test I learned from my USMC recruiter many years ago.

You are a lieutenant who has been given the task of raising a flag pole. 

You have at your disposal, a flag pole, a sergeant and 7 privates. 

How do *you* get the flag pole raised?



The correct answer, of course, is, "I say to the sergeant, 'Sergeant, get this flag pole raised and report back to me when it's done.'" 




I can hear you asking, "So what?  What does this have to do with Scrum?" 


Well, I'm glad you asked.  Scrum fleshes out and leverages command and control in its original meaning.  The business owner works with the product owner to determine what the business owner wants.  The product owner then goes to the scrum team and asks, "Get this done, and show me demostratable progress every 2 weeks"


By using the Scrum framework (ask me why you should *never* call it a methodology) you can leverage the power that comes from separating these two responsibilities.  You as the business owner can focus on the high level "whats" and the development teams can focus on a slightly lower set of "hows".


The nice thing is, that if you have the discipline to hold that separation, Scrum can scale easily.

Posted on Sunday, August 15, 2010 12:41 AM Agile Development , Leadership , Scrum | Back to top

Comments on this post: Scrum, the ultimate "Command and Control" framework

# re: Scurm, the ultimate "Command and Control" framework
Requesting Gravatar...
Well, you have certainly changed my definition of “command and control”. I will not look at that term in the same way again, and I would not automatically apply it to Waterfall as I have done in the past.

And, no… I will not ask you THAT question...
Left by Martin Hinshelwood on Aug 16, 2010 8:36 AM

# re: Scrum, the ultimate "Command and Control" framework
Requesting Gravatar...
As per you product owner says to team "Get this done, and show me demostratable progress every 2 weeks".

Sorry, I do not agree with you. In Scrum this is not acceptable. The team has autonomy and selects the stories from product backlog. Anyone can assign a task or a group of task to the team. So the product owner cannot say "get this done". PO just offers some prioritized stories. And then the team selects, estimates and details them. You see that the PO cannot say how, when or what. Just offers some undetailed stories for everyone easily to access and follow the project plan.

Can you do this in army?
Left by Zulfikar Karakaya on Feb 02, 2015 2:17 AM

# re: Scrum, the ultimate "Command and Control" framework
Requesting Gravatar...
Hi Zulfikar

Thanks for taking part in this conversation.

This is a tricky subject and I'd love to continue the conversation.

Let me first start out by asking, "Have you read 'The Scrum Guide' ?"
(It published in over 30 different languages at
It's 10 - 15 pages long, easy lunch reading.

If you could take the time to read the product owner section (it's 5 paragraphs and 5 bullet points) we would literally "be on the same page"

It would be interesting to see how closely your company is following scrum.

The problem is that Scrum acts as a diagnostic kit that highlights and raises visibibly on company dysfunctions. Specifically dysfunctions that that prevent the company from producing rapid, high-quality results.

This visibility threatens certain groups for different reasons.

Typically, when scrum is introduced to a Fortune 1000 company, the threatened groups "optimize" scrum into something that is harmless to them.

One way to insure that Scrum is "harmless" is to strip all the power away from the product owner.

Again, I would be highly interested in your feedback after you take a quick read of the scrum guide.
Left by Malcolm Anderson on Feb 02, 2015 1:33 PM

# re: Scrum, the ultimate "Command and Control" framework
Requesting Gravatar...
Hi Malcolm,

Yes, I have read the offical document many times, and with your kindly asking I have read it again, especially product owner section and also other sections for being sure about the team and PO roles. Check the following lines, from development team section :

"They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality".

So I think this is enough to show that the development team is independent and has autonomy in Scrum.

You also mentioned about PO's power. Actually there is no management power for PO. All stakeholders (team, scrum master and others) just have to be respectful against PO, and rely on him about prioritizing tasks in product backlog, and also preparing release plans. It is just regarding respectfulness, there is no executive here. Executives and managers are at the outside of the scrum. The PO just makes everything visible and transparent for all executives, managers, and for all stakeholders.

So managers should not be worry about that. On the contrary they can use this functionality to control everything and to be sure to step further.
Left by Zulfikar on Feb 03, 2015 3:01 AM

# re: Scrum, the ultimate "Command and Control" framework
Requesting Gravatar...
Hi Zulifkar

Interesting. I see where you are getting your understanding. No where in the scrum guide does it say, "the development team with pick items off the top of he backlog."

There are at least 4 different ways for me to explain this concept. The main difference comes from your current role.

Are you a product owner, a scrum master, a company founder or something else?
Left by Malcolm Anderson on Feb 03, 2015 11:02 AM

# re: Scrum, the ultimate "Command and Control" framework
Requesting Gravatar...
Hi Malcolm,

Here is a quotation from the scrum guide.

"The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint."

I think this is enough to say that development team pick items out from backlog. The PO just define the sprint goal. So the team is a goal oriented team, not task oriented.
Left by Zulfikar Karakaya on Feb 05, 2015 1:46 AM

# re: Scrum, the ultimate "Command and Control" framework
Requesting Gravatar...
Hi Zulifkar

Exactly, the PO defines the goal (command) and the goal oriented team figures out how to best accomplish that goal (control).

Now, if you have outside managers who believe that they are in control, your results will be sub-optimal.

Left by Malcolm Anderson on Feb 05, 2015 9:28 AM

Your comment:
 (will show your gravatar)

Copyright © Malcolm Anderson | Powered by: