Self-steering or self-organisation that is the question

In an attempt to solve the confusion around self-steering, we have come up with the clever idea that we actually mean self-organisation. A handsome language game, which, incidentally, has not brought us a solution to the confusion. I first discuss self-steering and then continue with self-organisation. I also look at the role that an AgileLeader plays in this.

Self-steering

A self-steering team determines its own direction, that’s the meaning of the word. If someone else imposes his/her will, the team stops being self-steering. Agile teams, where a product owner and a scrum master (or agile coach) are involved, are therefore by definition not self-steering. When they need to adhere to a chosen agile framework (Safe, Less, Nexus, etc.), they are only partly autonomous in choosing the way of working together and the techniques they use. One might ask: ‘How autonomous’? If there is also a technical architecture, their choices are even more limited. When you are dealing with several teams, working on the same solution, how can you talk about autonomy? The more interdependency, the less self-steering. This is why scaling agile is so difficult. In short, autonomy is not that evident in the current forms of agile working. It is a myth!

Autonomy requires one single free will, which is rather complicated with a team. After all, a team consists of at least two people, so there are two distinct wills that have to agree on the small part in the whole on which they still have autonomy. Increasing the number of team members reduces the autonomy of the individual even further. With a tribe of 150 men and women, there is little left of individual autonomy. The only solution is groupthink, when the team functions as a unit. This is the fate of every well-functioning team! Because of the group pressure, the cognitive dissonance in the team is great and any dissenting opinion will be silenced. We no longer notice any signs of malfunctioning. The team is now completely self-steering and steers itself up the mountain or into the abyss. Self-steering does not necessarily lead to success.

Self-organising

The argument that we actually mean self-organisation when we speak self-steering does not bring us the desired solution, but it does lead to a new insight. By self-organization we mean ‘something’ that comes from within without an outside cause. Everything that somewhat resembles a network has this characteristic, chaos creates a balance, of itself, because that is the definition of self-organisation. If the cause came from outside, it would no longer be a self-organisation.

The question is whether this self-organisation actually exists. Is it not actually just the structure that we humans impose on something we don’t understand? The swarm of birds that are looking for a place for the evening fly this way because this requires the least aerodynamic energy. No bird organises, no wisdom or crowds, no god interferes with it, it is just as it is. It is self-organisation without a self and without organisation.

What is the alternative?

Logically, we can do nothing with self-organization and certainly nothing with self-steering. These are wrong names used for a way of working that is popular nowadays. Which language games do we have to play in order to arrive at a logical concept?

A good description for such a team can therefore no longer contain the words autonomy, self-steering or self-organisation. This requires a bit of linguistic artwork, which I hope will lead to something. Forget the word team, we’re talking about people who work together and where the agile leader, like any good manager, only intervenes when they no longer deliver value.

So we are no longer talking about self-steering or self-organising teams, but about value-driven people working together. As long as they deliver value, there is nothing wrong with them and nobody needs to intervene. As soon as the value stream dries out, someone will intervene, you can be sure of that. If that is not the agile leader, I can guarantee that an old-fashioned manager will pull the plug.

This blog is also in Dutch.

(note: this blog is also in Dutch)

The Agile Manifesto was originally written for software development. It has had a huge impact on the way in which we have started to organise IT work. However, there is a serious flaw if you want to apply it in sectors other than IT. I am going to correct this flaw by rewriting the manifesto. My intention is to reduce the influence of IT thinking on agile development and challenge people from other industries to think along. The agile ideology is too important to leave it to IT professionals alone.

The old Manifesto (for software development)

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

On our way to the new manifesto

The sentences can remain largely intact, I replace ‘working software’ with’ working services/products and finished work’, but this has not yet repaired the flaw. There is still something missing that the authors of the Manifesto have overlooked. Without that, the agile transition in IT would not have been possible.

The missing link is the actor technology (you are indeed reading ‘actor’ and not’ factor’), which has a much greater influence than you would think. It is a different type of actor than a human being who has a will of his own, but that does not alter the fact that technology has a greater influence than we admit. Without technology, it would have been impossible that the agile revolution in the IT would have progressed in the way it has. Automatic testing, devops, does not go without technology. It is technology that has been the engine behind the agile transition, not the Manifesto. It is not agile work that has brought about the digital revolution, but vice versa, because of the digital revolution we have started working agile.

This is the main reason why agile in the way it is promoted is difficult to transfer to other industries than IT. Each industry uses its own technology that determines the way it works. After all, there is little to sprint for a large infrastructural work, and dedicated teams are often not feasible. However, when we consciously opt for innovative technology that supports agile working, then it may well be possible. For example, I’m convinced that 3D printing, AI, automatic cars and augmented reality will make agile work possible in many other sectors.

The new generally applicable agile manifesto

I now come to an updated version of the Manifesto:

• Innovative agile supporting technology above proven technology.
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more. We also consider technology to be the driving force in all attempts to become agile.

This seems to me to work better than the old manifesto.