"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.