command and control - The exercise of authority and direction by a properly designate commander over assigned and attached forces in the accomplishment of the mission. Also called C2.
That is a quote from DOD Dictionary of Military and Associated Terms, see this link.
Any endeavor will have an authority, a direction, and the forces. The key is that you can do that in many ways, Even in the military field you have options: a commando team will have another approach than a regular army platoon. Authority .. could result from a collaborative way of taking decisions. Direction should be the subject of adapting to context changes (could be very fluid for commando troops, for example).
Software development domain traits suppose contexts with high complexity and high incertitude. From math perspective that is a complex problem. For such problems we have only feedback based solutions. "By definition" you will need an approach that is adaptive, lean and that will be adapted to the context. It is our choice to call this approach Agile (.. or not).
At a first view, Agile will solve the small parts (see Uncle Bob blog post In The Large; ... where I do not agree with <We, humans, are actually very good at building big projects>, and my post it is a kind of answer). Anyway, somehow we will always need to address also large problems: even with small releases, we will finally need to build and change and products that could be significant and large. The solution is not dummy, is not Flaccid Scrum ~ just adopting iterative development and basic collaboration. We could add (whenever is possible) small releases. We can add <Agile engineering practices> such TDD. We could also adapt our process to the context.
At a first view, Agile will solve the small parts (see Uncle Bob blog post In The Large; ... where I do not agree with <We, humans, are actually very good at building big projects>, and my post it is a kind of answer). Anyway, somehow we will always need to address also large problems: even with small releases, we will finally need to build and change and products that could be significant and large. The solution is not dummy, is not Flaccid Scrum ~ just adopting iterative development and basic collaboration. We could add (whenever is possible) small releases. We can add <Agile engineering practices> such TDD. We could also adapt our process to the context.
It is that enough ? What is the big picture ?
We need to apply feedback-based "control" to all levels of the development. We need to balance the look-ahead approach with the just-in-time approach. Here is a proposed (Information Rolling Wave) model. A command and control approach with too few feedback for solving complex problems will suppose - concrete mathematics - division by zero. So, here is how will sound a too few feedback command and control approach to software development:
"I command you to divide by zero ... and then I will control you" :) :)
