In the Agile world, we (and I am certainly no exception) talk a lot about Self Organisation, but what does that mean? What is this thing called Self Organisation?

The key to understanding self organisation comes from one of the principles behind the Agile Manifesto –

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

What we want is a project where the teams get the job done by themselves. I don't mean that the team works in isolation, the organisation needs to "give them the environment and support that they need" but the team should not need to be told how to do the job at hand. They should work it out for themselves. They should work out how best to break up the work, who should do each task and how each task should be accomplished. The organisation should trust them to get the job done and give them the freedom to do it.

Why is this a good thing? Think about a regular project. The project manager works out in advance what tasks there are, who should do them and when. Then they hand those tasks out to the team. Or more usually, hands them out to team leads who hand them out to the team, or to managers who hand them to team leads who hand them to the team. As the project manager is several steps removed from doing the actual work, the decisions about what tasks there are, and who should do them, are often made with poor information or require long meetings with dozens of people to work out who will be doing what.

Inevitably, the decisions made up front are not 100% right so plans need to change. Maybe Jim has gone off sick so the tasks he was doing the John was dependent on can't be done. Who can take over Jim's work? The people doing the work have to stop and wait while everything is re-planned then they get back to work... until the next problem arises and the projects stops and re-plans again.

Of course, what often happens is that the team sorts out the problem without telling anyone. The project manager is blissfully unaware that their detailed schedule bears little resemblance to what is actually happening. Until they look at timesheets, or actual hours, or resource allocations and realise that people aren't following the schedule. Of course there are reasons why, so it's no one's fault, but the project has to stop and re-plan to get "back on track".

And so on.

A lot of time on projects is lost in planning and re-planning activities in advance, often by people who are removed from doing the actual work and therefore don't have a full appreciation of what is required.

A self organising team doesn't need that. They plan the work themselves, in small increments, when it needs doing. By concentrating planning and decisions on a short time horizon and by the people who are closest to the actual work, planning and scheduling issues get taken care of with minimal disruption. If Jim is away, Jack can drop his less important task to take over Jim's tasks and unblock John. This is essentially what good teams do anyway, except this time there is no project manager to stress over the fact that their detailed schedule isn't being followed. The team can react to change and navigate around it. All by themselves. They don't need to stop and wait for instruction, they can keep going.

Inspect and adapt is one of the key principles of all agile methodologies. Inspect – notice that there is a problem. Adapt – do something about it. The faster a team can inspect and adapt, the faster they will be able to deliver. Stopping and waiting for direction slows down the inspect/adapt cycle.

But surely, you can't just leave the team alone in a room and expect them to deliver what the business wants, can you? Well no. It's not that simple. The team still needs to know what to build. They need to know what the business wants. This is where the "give them the environment and support that they need" part comes in. They need the infrastructure to develop on and they need to know the needs of the business so that they can deliver solutions to meet those needs. A traditional project does this through the schedule and the requirements – through management. An agile project does this through leadership instead.

In my last post I used a quote from French author Antoine de Saint-Exuprey –

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”

This is what a self organising team needs. They need someone who can give them that longing for the endless sea. They need someone to set out a vision that they can work towards and someone to guide them along the path towards that vision. They need guidance because a longing for the endless sea could be delivered through a ship (what the business needs), or a raft, or even a house on a cliff overlooking the ocean. They need a servant leader to guide them so that they produce the ship the business needs.

Guidance and support, rather than management and control, will set the team free to self organise and strive for the endless sea. Without hitting the rocky shoals and furious gales of endless re-planning.

Cheers

Dave