Only People Are Qualified for Control

In any software project only people are capable of accumulating knowledge and exhibiting creativity, and only people have the ability to initiate interaction.

But there is a third reason for people being the center of attention in agile software development. It has to do with the Law of Requisite Variety:

If a system is to be stable the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled.

– The Law of Requisite Variety (W. Ross Ashby)

Simply put, this law states that a system can only be controlled by another system when the other system is just as complex as, or more complex than, the first one.

People are the most complex elements in any software project. This makes them best qualified to directly control their own projects, as people are the only systems with sufficient complexity to deal with the variety of states that they are confronted with.

Neither documented processes, nor code generators, nor company rules, nor project management tools, nor the most exquisite up-front designs, can ever hope to have the amount of complexity that any ordinary software project possesses. Processes, tools and designs cannot outperform their masters. Without people, they are useless.

The Law of Requisite Variety makes it quite clear that, if some level of control is needed in a project (Mike Cohn called it micromanagement by the team), then you better select people as the control mechanisms. They are the only ones complex enough to actually pull it off.

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
Accountable or Responsible?
Communication = Information * Relationships
Creativity as the Root of Software Development
  • Innovation is the Key to Survival
  • Top 200 Blogs for Developers (Q3 2009)
Related Posts
free book
“How to Change the World”
  • Kyle

    I have seen this same concept of Requisite Variety in my graduate studies in control theory. It is actually the motivation behind the state observer ( design in feedback systems. The problem I see with your use of it here is that you think it is necessary to have the complexity in the controller to keep the entire system stable. In reality, it can only be shown that having a controller as complex as the system is a sufficient way to handle all the perturbations that could occur.
    For example, the temperature in my house is determined by a large number of states. It will change depending on whether I am watching TV, using the computer, cooking, leaving the front door open, on the weather, etc. But my thermostat, only has two states: on or off and it adequately and stably regulates the temperature of my house.
    That being said, my house does get warm when we cook and my bedroom is colder than my guest room. Regulating these problems (or abstractly achieving higher performance from the system) requires that my thermostat starts to be smarter about my house.
    I do agree with your outcome though. I remember a recent post of yours about pulling terms from academia into other realms and about how keeping the original intent intact during the transition can be difficult and thought that this might be a good example of that.

  • Jurgen Appelo

    Hi Kyle,
    This is exactly why I’m writing my blog. To get this kind of feedback. Thanks, it’s very useful, and I’m going to think hard about it!

  • Dennis Stevens

    Great post. Super interesting train of thought.
    The thermostat example above misses the point. The temperature control mechanism consists of the thermostat, an air conditioner, a furnace and a system of ducts and filters. The system is sufficient to influence the environment and achieve its purpose of a comfortable temperature in most circumstances.
    To your point, just as the thermostat serves as an observer to trigger the control mechanism, documented processes, (maybe) code generators, company rules, project management tools, and (minimal) up-front designs can serve as benchmarks to trigger the project control mechanism.
    But projects take place through a social construct. Only people have the ability to act on this social construct sufficiently to influence the project environment to achieve the projects purpose.
    This is a key distinction. Understanding the distinctions and interdependencies between observer and change agent, management tools and leadership, goals and self-organization are important as we figure out how to create efficient and adaptive technology development teams.

How to Change the World - free Workout - free