≡ Menu

Control of Error for Self-Organizing Teams

One of the holy grails of agile software development is the concept of “Self-Organizing teams.” This can be seen in the principles of the Agile Manifesto which says “The best architectures, requirements, and designs emerge from self-organizing teams.”

While much has been said about the misconceptions of self-organizing teams as well as the role of leaders, there is one principle in particular which is vital to the success of a self-organizing team.

To get there, we need to start by defining just what is meant by a self-organizing team. One of my favorite terms comes from the book Facilitating Organization Change: Lessons from Complexity Science. It says:

Self-organization is the tendency of an open system to generate new structures and patterns based on its own internal dynamics. Organization design is not imposed from above or outside; it emerges from the interactions of the agents in the system.

When we attempt to bring change to an organization, we often reach for certain patterns that have worked before. But every team is different, primarily because they are made up of people. Individuals interacting together form certain patterns, which influence the whole of the organization. Likewise, patterns that have emerged previously impact the interactions of individuals. It’s this system of behaviors which create the “culture” of a company.

Cockburn's Communication Effectiveness ChartHowever, as noted in Esther’s article above, you can’t just turn a group of people loose and hope for the best. There are three key factors which influence the placement, shape and power of the emergent organizational patterns:

  1. Container – Sets the bounds for the self-organizing system. It defines the “self” that organizes. However, it is important that the boundary of the container be semi-permeable – there should be some interactions outside of the container
  2. Significant Differences – This determines the value that will come from the created system. For example, if we put all of the developers on one team, and all of the testers on another, the organizational patterns that will emerge will evolve around those containers (see Conway’s Law). But if we include a mix of talents, genders, races, etc, the patterns will emerge differently.
  3. Transforming Exchanges – This is where the real power of self-organization comes into play. This simply refers to the contact the people have with each other. As you can see in Alistair Cockburn’s communication effectiveness diagram above (from his website and his book Agile Software Development: The Cooperative Game) face-to-face communication is going to produce much better patterns that emailing the team.

However, transforming exchanges aren’t just limited to interactions between two people in a team. In fact, it is possible to have a transforming exchange between a person and the very system they are a part of. This notion of the system providing actionable information is a key tenant of Lean Thinking, and one of the important principles of self-organizing teams.

But Lean Systems turn out not to be the only place that understands this. My daughters attend a Montessori school. The other night, we were at a parent education meeting, and one of the topics that came up was “Control of Error“. The idea behind Montessori education is that it is a self-directed learning environment. Therefore, the activities the children do must be designed in a way to provide them feedback about if they are succeeding – in short, it has to be able to show someone who is learning how to do something that they are doing it wrong – without teacher intervention.

Montessori materialsFor example, in the picture to the right, the teacher is demonstrating two “works” which provide this feedback, or control of error. The pink block tower gives feedback by showing that the next block in the stack should be smaller than the last. In the other work – the red rods – The smallest piece fits exactly at the end of the pieces above it, and the length of both pieces equals the next largest.

It’s such a simple concept, but vitally important in our thinking of building teams and organizations. As a manager or leader, you should ask yourself how people learn about how their actions affect the system, the people within it, or the organization. If I’m deciding whether to spend more time optimizing an algorithm, do I have the feedback from the system to know when I should stop (both from a necessary performance perspective, and a ‘You need to do other stuff’ perspective)? Does the team know how often they are getting stuck, or when others need help, without resorting to simply asking everyone all the time? Do the business leaders have the tools necessary to make business decsions based on feedback from the teams – and do the teams understand the impact of those decisions?

Too often we see organizations wanting agility, but maintaining the traditional management thinking. If the best designs truly come from self-organizing teams, then are we giving them the containers, the diversity and the feedback from the systems they need – without relying on the right people always being at the right meeting to hear the right thing?

If you are interested in reading more about these interactions, I’d highly recommend picking up the book Facilitating Organization Change: Lessons from Complexity Science. It goes into the science of Complex Adaptive Systems and how you can tailor your organization to facilitate self-organization – and achieve the culture of agility you strive for.