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.
From http://www.noop.nl(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Titus Roth replied on Sat, 2009/10/31 - 1:35pm
Some not infrequent problems that might foil a more hands off style management:
1. In practice team members do not always reach consensus because of big egos, laziness, or vested interests. At such times an enforcer may indeed be needed to prevent, well, not always anarchy but stalemates or "analysis paralysis."
2. You've heard the pejorative phrase "design by committee." Or maybe, "too many cooks spoil the broth." There is a bit of folk wisdom in these phrases that applies here too, I believe. In even a team of two, everyone wants to add their inputs to the task. Not all of these brilliant ideas can or should be done. Again, an enforcer may be just what is needed.