Why We Delegate: The Darkness Principle
Each element in the system is ignorant of the behavior of the system as a whole [...] If each element ‘knew’ what was happening to the system as a whole, all of the complexity would have to be present in that element. – K.A. Richardson
What we learn from the Darkness Principle is that each team member can only have an incomplete mental model of the whole project. That is why they have to plan and decide together. It is why Scrum and Extreme Programming require the whole team to be present during planning meetings and daily stand-ups. The team members must aggregate their limited mental models and agree on a joint approach.
Some managers are not comfortable with the idea of allowing a team to make decisions together. They feel they lose control over what's happening when teams make decisions without them. Managers assume that decisions must be enforced, or otherwise anarchy unfolds. But that same anarchy has constructed an entire universe, all by itself. So it cannot be all that bad.
“The switch to worker self-management is occurring because it is a way to increase control over the uncertainties facing a work team.” – Kenneth Thomas
Managers must learn that they are “in charge, but not in control” (Ralph Stacey). In fact, any attempts to “control and contain” usually don’t work, and sometimes even have counterproductive consequences. For example, it is found that attempts of the police to control and contain crowds can cause the problems that the police is trying to prevent (New Scientist).
Nobody on a team (or in a crowd) has a complete picture of all that's happening in the entire group. By letting them solve their problems and make decisions together you actually increase control over the situation.
Mike Cohn once said that agile software development is micromanagement by the team. The Darkness Principle makes it clear that it is this micromanagement that must be delegated from the manager to the team.