In agile software development “self-organization” is often referred to as a best practice. This is strange, because it is actually the default practice of complex systems. Self-organization has relationships with anarchy, emergence, evolution, and self-direction. But none of those are the same. Complexity science can teach us what the differences are.

The Darkness Principle and the Conant-Ashby Theorem are two examples of scientific concepts that explain why we do things the way we do in agile teams, and why delegation and empowerment are crucial.

There are different ways of delegating work to a self-organizing team. First of all, people’s level of experience with empowerment is important. Second, there are 7 authority levels that can be selected per task. Third, one can choose between delegating to teams vs. delegating to individuals. Fourth, the order (time dimension) of the delegation of work is important. There is a handy checklist for making sure you’ve properly delegated work to a self-organizing team.

After delegating work to an empowered team, a team leader or development manager is responsible for managing himself, managing top-level management, managing the empowered team members, and managing the environment. All stakeholders may have to change their attitudes to make self-organization work.

Finally, we can distinguish 4 types of trust between a manager/leader and team members. They all have to be in place, or else self-organization may fail.

TOPIC

Self-organization lies at the heart of Agile. Yet, few people really understand what it means, and perhaps even fewer people know what is needed to make self-organization actually work.

OBJECTIVES

What self-organization is from a scientific viewpoint
What the important choices are when delegating work to a self-organizing team
How to manage all stakeholders to make sure that they work with and not against the self-organizing system.