A software project is a network of people, interacting together for their own purposes. We can see part of that network as the system of team members producing value, and another part of it is the environment of stakeholders consuming that value.

W. Ross Ashby, one of the fathers of General Systems Theory, came up with one of the basic principles for systems, called Ashby’s Law, or 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.”

In other words, in order to survive a system must have an internal model that reflects the variety it encounters in the world outside.

Nobel-prize winner Murray Gell-Mann, founder of the famous complexity institute in Santa Fe, wrote it like this in The Quark and the Jaguar:

“The genotype of each organism, or else the cluster of genotypes that characterizes each species, can be regarded as a schema that includes a description of many of the other species and how they are likely to react to different forms of behavior. An ecological community consists, then, of a great many species all evolving models of other species’ habits and how to cope with them.”

Not being a founder of any scientific field or institute, I have my own simplistic version of the same idea:

“It takes complexity to handle complexity.”

Software teams have three options when dealing with a troublesome environment:

1. Reduce the complexity in the environment;
2. Increase the complexity inside the system;
3. Ignore complexity (survival is not mandatory).

The first is rarely possible. The third is rarely smart.

That leaves software teams with the second option: try to match the ever-changing complexity of the environment with social complexity (people & interactions) and continuous improvement (embracing change).

This is, I believe, the core of Agile and Lean thinking...