Edge of Chaos and Hyper Productive Software Development Teams

Many researchers tend to think that CAS may work efficiently at the edge of chaos. A system with a very high order can’t solve complex creative tasks, as well as a pure chaotic system. It seems the system should balance between chaos and order to survive and adapt.

The “edge of chaos” term was emerged during self-reproductive cellular automata researches in 1990. It appeared that at a particular noise level the system can reproduce its state, while at a low noise levels states are random. This edge value was mathematically analyzed and it was shown that in such a state the system has a maximum of information.

The “Edge of Chaos” term  spread and applied to complex adaptive systems. For example, we may suggest that evolution drives systems to the edge of chaos, and it is one of the reasons of life origin. Life is a very interesting and complex thing in itself. Most likely it could not appear neither in order state and in chaos state. Life exists if there is a stable base, but with possibilities of changes.

Edge of Chaos and Software Development

How can we apply the edge of chaos concept to software development? Obviously, edge of chaos is a state where the development team works with maximum efficiency. Complex processes and explicit rules impede creativity. The team becomes too ordered to think :). On the other hand, no processes and no rules lead to chaos. The development team can’t complete anything useful, and that is something we call hack & fix process.

As a software development folks, we are particularly interested in two questions:

1. How can we drive the team to the edge of chaos?
2. How we will ensure that the team is at the edge of chaos?

The human who knows the answers to these questions most certainly will be rich and famous. However I am not sure whether you can find such a man.

It is obvious that edge of chaos = hyper productivity. This term often used in Scrum. However it is quite hard to define hyper productivity.

Hyper-productive teams are hard to define. To paraphrase a common quote: “it’s like porn…you can’t define it, but you know it when you see it”. In addition to talent, hyper-productive teams are the greatest contributors to the creation of a hit game.

Well, currently we may discover hyper productive teams and identify their properties. But if we try to apply CAS to the edge of chaos, we may define the following properties that may lead a development team to hyper productivity:

1. Feedback
2. Information exchange
3. Cooperation
4. Self-organization
5. High Adaptability

Agile software development processes have some of these properties explicitly, and some implicitly. For example, feedback, information exchange and adaptability are roots of agile development. Self-organization is something most are expecting to have in an agile process, but sometimes it is skipped. I think it is a huge fault if, for example, Scrum Master does not include self-organization into development process. All these properties are important and must have to build a highly efficient team. If you have 4 of them, but missed the last one, you do not have hyper productive team.

Clinton Keith identified four important conditions for hyper productive teams:

1. Independence and a sense of ownership - The team needs to feel that they can contribute creatively and have some control over the game.
2. Leadership - There needs to be one leader on the team who can communicate a vision between the team and the customers and keep the team focused.
3. A core competency - Not everyone on the team needs to be an expert, but on the hyper-productive teams I have seen there have been at least one core expert. This isn’t a lead position defined by a role, but by actions. This person supports the vision with brilliance that the team can be confident in and rally around.
4. Team collaboration - Teams grow into great teams organically. This is where facilitation can help a team transform itself.

Let’s try to bind these conditions to CAS properties defined above. Independence is one of the self-organization pre-requisites. Leadership on my opinion is not a must, but likely is an effect of self-organization. The development team got a leader as a result of natural selection :) Core competency is a result of a feedback, learning and adaptation. The last condition obviously is an information exchange and cooperation.

We may easily define conditions, that block hyper productivity:

• No feedback. That is one of the reasons for waterfall process failure. In a waterfall process feedback is delayed and sometimes even does not exist. Team can’t learn and adapt. Efficiency is low.
• Poor information exchange. Large teams, distributed teams, huge functional divisions, interpersonal problems - all that impedes information exchange.
• No cooperation. Political games inside a company or inside a development team, dumb corporate rules, wrong motivation schemes, communication problems due to personal likes and dislike - just some factors that make cooperation almost impossible.
• Impossibility of self-organization and weak adaptability. Complex corporate rules, hard hierarchy, command and control management, no autonomy make self-organization impossible.

We’ll cover these problems in more details later. Even in such a brief overview it’s getting clear what the main responsibilities of CTO, CIO, PM, Scrum Master, etc. should be. They should remove obstacles listed above (and more) that block a trip of the development team to the edge of chaos.