Agile Zone is brought to you in partnership with:

Jurgen Appelo calls himself a creative networker. But sometimes he's a writer, speaker, trainer, entrepreneur, illustrator, manager, blogger, reader, dreamer, leader, freethinker, or… Dutch guy. Since 2008 Jurgen writes a popular blog at, covering the creative economy, agile management, and personal development. He is the author of the book Management 3.0, which describes the role of the manager in agile organizations. And he wrote the little book How to Change the World, which describes a supermodel for change management. Jurgen is CEO of the business network Happy Melly, and co-founder of the Agile Lean Europe network and the Stoos Network. He is also a speaker who is regularly invited to talk at business seminars and conferences around the world. After studying Software Engineering at the Delft University of Technology, and earning his Master’s degree in 1994, Jurgen Appelo has busied himself starting up and leading a variety of Dutch businesses, always in the position of team leader, manager, or executive. Jurgen has experience in leading a horde of 100 software developers, development managers, project managers, business consultants, service managers, and kangaroos, some of which he hired accidentally. Nowadays he works full-time managing the Happy Melly ecosystem, developing innovative courseware, books, and other types of original content. But sometimes Jurgen puts it all aside to spend time on his ever-growing collection of science fiction and fantasy literature, which he stacks in a self-designed book case. It is 4 meters high. Jurgen lives in Rotterdam (The Netherlands) -- and in Brussels (Belgium) -- with his partner Raoul. He has two kids, and an imaginary hamster called George. Jurgen has posted 145 posts at DZone. You can read more from them at their website. View Full User Profile

Why We Delegate: The Darkness Principle

  • submit to reddit
From a complexity perspective, there is a good reason why teams in an organization must be able to make decisions together. This follows logically from 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.

Published at DZone with permission of its author, Jurgen Appelo.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Titus Roth replied on Sat, 2009/10/31 - 1:35pm

What you say definitely has its merits. Like all things in life, though, software architecture and design have no silver bullet that works in all circumstances. The maturity and skills of individual members makes a difference in what approach works.

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.