Agile Principles: Why You Need Self-Organizing Teams

Agile Doctor

I have often argued that the founders of Agile did not provide reasons why their approaches worked just that they did. Their was empirical evidence, proven by doing the work, or, as they state in the beginning of the manifesto – uncovering better ways of developing software by doing it and helping others do it. From their very pragmatic approach, they figured out that better software was created by following the values and principles. One of those discoveries was that better software was created by self-organizing teams.

One of the things I speak of during my talk on Complexity Theory and Cynefin (Complexity Theory and Why Waterfall Development Works (Sometimes)) is that most software development is complex and that is the reason that Agile works well and is generally preferable to Waterfall. Those projects that might benefit from Waterfall are those that are complicated, those where all the answers can be known up front and experts are effective.

Agile works better when projects are complex, those where all the answers cannot be known upfront and big upfront expert analysis is a liability. Also, according to George Rzevski, one of the seven criteria for complexity is Self-Organization in which complex systems are capable of self-organization in response to disruptive events. While this addresses the fact that a complex system will self-organize and does not address self-organizing teams in particular, I believe it does inform us that in response to complex systems the best use of people is to allow them to self organize around the work.

In addition to the relationship with complexity theory, this principle also relates to the fact that it is the people who do the work that are the best to make decisions with regards to architectures, requirements and designs. While to most people this would be common sense, in the world of corporate IT, with its fetish for top down, command and control hierarchy I have found this to be the exception.

In some cases I have found organizations so tied to the misunderstanding that software development is complicated (as opposed to complex), that work can be identified, analyzed and designed at one level (the world of architects, Bas, team “leads”, so on) and simply passed down to a “lower” level (usually to offshore), that they really have no conception of what Agile means when it talks about a team.

Even if they can be convinced that they need to think of teams as the people who actually do the work, it is usually too radical to expect people to actually know their jobs and be able to organize their own work. These organizations are stuck in the world of Taylor, but all the evidence shows us that knowledge workers are squarely in the world of Deming.

Pink, in his wonderful book Drive: The Surprising Truth About What Motivates Us, tells us that people are motivated by AMP (autonomy, mastery and purpose) and not surprising, self-organizing teams provide a healthy dose of all of these while receiving piecemeal work from “experts” is not at all motivating. No wonder that the best architectures, requirements, and designs emerge from self-organizing teams.

What are your thoughts?

– Larry Apke