Agile and Cybernetics

Self-organisation is used to beat complexity. Why? Ashby’s law may give an explaination.

Software development is a complex endeavour, that’s why Agile is very relevant. Agile methods enable us to cope with this complexity. I want to give one explanation why Agile works.

Credit: Flickr – Dave Gray

This post will also prove that command-and-control is not working to solve a complex problem. I will show this by linking software development to Cybernetics, the science of controlling. The special discipline of Management Cybernetics was introduced by Stafford Beer in 1959 and relates Cybernetics to management. Economist Fredmund Malik references Management Cybernetics in his work. As I mentioned in the previous post, the science for leading agile organisations already exists.

Ashby’s Law

Ashby was a pioneer in cybernetics. Ashby’s Law is also called the Law of Requisit Variety. Understanding Ashby’s Law requires to understand variety. The variety is a measure of a number of distinct states of a system. This measure can be used to exemplify complexity in a system. Ashby’s Law describes the condition for the variety in two systems, that make it possible for one system to control the other.

Simplified, the law leads to the following rule: The higher the variety of the controlling system, the better it is able to cope with the variety of the system under control. If the system that I want to control has three different possible distinct states and the controlling system has only two possible distinct states, then the direct control will be impossible.

Let’s take another simple example to explain this law in our domain. The system that we want to control is an existing legacy software and the controlling system is a programmer that needs to fix a defect. Variety in a software system is higher, if the software system has more lines of code. The more options the programmer knows to change the code, the better are the chances to fix the defect. Or on the side: more simplicity in legacy code leads to better chances to fix the defect.

Imported to note is that we have two possibilities to get to a successful control and therefor a successful software development.

  1. Reduce variety in the system under control, which means simplify the problem that we are facing. It would mean to simplify the software or the scope of the problem.
  2. Create a controlling system with more variety, which means you get a more complex organisation in the project team.

Agile and Ashby’s Law

Let’s apply this to a another example. The system that is under control is a business problem that needs to be solved by creating a piece of software. The system that want’s to control is the project team. What can we do to improve the variety of the project team:

  • Skilled team members – the more tricks they know, the more options they have to contribute to the solution.
  • Collaboration between people to combine the variety of every single person. This increases the total variety of the team.
  • Team members from different function in one project team – a tester may see different options to solve a problem than a programmer.

These are only three things that help the project team. What are the things that reduce the variety of the project team, which we should avoid:

  • Hire less skilled people or don’t train people – well, that’s obvious.
  • Have a single person that commands other team members to execute his ideas. The variety of the whole project team is reduced to the variety of this single person.
  • Less possibilities to collaborate. Team members wont share their thoughts and combine them with others.
  • A fixed organisation with defined roles (Architect, Lead Developer, …). This reduces the options that the team has to re-organize and adapt in the solution process.

This explains quite nicely why so many things in Agile are helping us to get the job done. It also explains, why a command-and-control culture is not helping us to solve a complex problem.

What are the implications for management?

In Agile we make all the things explicit that increase the variety, e.g. self-organised teams that are empowered to make the decisions, no explicit roles in teams and close collaboration. As a manager you create the environment for such an organisation. This organisation is a complex social system and can be very precious, when it’s functioning well. You can compare it to a biotope. Like with a biotope, you cannot mindlessly intervene in the system. Making a change in the system may have destructive results, that you cannot foresee.

Since it seems very difficult to lead such a complex social system, managers usually fall back into old habits. They constrain the individuals, introduce roles, create hierarchies or directly intervene in the solution process. But all this reduces the variety in the development organisation and therefor will create a system that is not able to cope with the complexity. Additionally the complexity of the problem to solve will be reduced by demanding big upfront specification. And then we are back to the waterfall environment.

How can you create and lead an agile organisation, to actually cope with more complex challenges of the enterprise? I will cover this in the following posts.