During my teams transition to become an agile team we have reached a point where we actually have to talk about self-organization. We have been talking about it before but maybe in vague terms. My vision have been to try to sneak it in, but it doesn’t seem to work. People tends to break my intent, stop self-organizing and just go back to what they have done before, relying on managers to organize, working in silos and asking for decisions from outside the team. And there is an emergent call from my Scrum Master to start to talking about self-organization.
So then, what is self-organization?
In complexity science self-organization is something that emerges from any complex adaptive system (CAS). If the system manage to balance itself between order and chaos self-organization will just evolve. The self-organization should be oriented around the team itself, self-organization means that no one outside the system (i.e. team) should decide how the team should be organized.
My experience of self-organization is just a team organizing itself to create something while at the same time handling structure and order within the team. What to organize around and how to organize should not be transfered from one team to another, each team is unique. What have you must have (unless you found a team with similar contributing team members) is someone that makes sure that the team doesn’t end up in equilibrium but maintains the balance between order and chaos. There must be drama, discussions, temper… and a balance with silence, dialogue, and understanding. In complexity theory there is an analogue using the annealing process where you raise the temperature to move towards chaos and the lower the temperature to move towards order. This must also be present in the self-organizing team, raise temperature and explore, lower temperature and exploit (focus on current tasks and accept current reality).
Just to break it down a bit, an agile team is a CAS. A CAS consist of agents (team members) that have the following four properties
- They are interconnected
- They are dependent of each other
- They are diverse – i.e. there are different personalities, backgrounds, mental models
- They adapt to their environment
They are also robust, that is, removing one agent doesn’t fail the system. The system survives.
So, an Agile Team consists of team members that are connected, are dependent of each other, have different inputs and ways of viewing (diverse) and they adapt to the current environment. Removing one Team member should not break the team, the team should be able to continue doing what it is supposed to do.
My own thought on this is: when you have interconnectedness and interdependency you have something that brings your team closer together. You will as a team create something together. Diversity and adaptability is the part that will create discussions and conflicts in your team, diversity will bring different views and solutions on the same problem, different priorities. While adaptability will allow members to comply and adapt to the current situation no matter if it is not doing it his/her way or introducing new team member, or a new requirement that turns everything upside down.
For Complex Adaptive Systems all these four properties must exist, but they should be “lagom” (Swedish word for “in-between”). If there is none of one of the properties the system is too stable and is now an Ordered system and if there is too much of each there is Chaos. Somewhere in between, at the edge of Order and Chaos lies Complexity.
For example too much interconnectedness results in Chaos and too little interconnectedness there will be Equilibrium, and nothing emerges.
So, to avoid Equilibrium where nothing emerges, we want a balance complexity where emergence is possible.
This doesn’t mean that an Agile Team can not work in Equilibrium, it is just that nothing emerges. Without emergence no innovation. Just people working beside each other with whatever comes up.
So what is self-organization? According to Complexity Theory and Complex Systems, self-organization emerges when you have agents (Team members) in the system (Team) that have the four properties mentioned above: So when you have a Team where each one in the team depends on each other, where we have diversity and where each member of the team is adaptable. This sounds very much like Scrum and Agility right? Well there is a reason for this, CAS have been in the mind of Scrum creator and Agile Manifesto signee Jeff Sutherland from the very start. Emergence is a property of any Agile Team, or Scrum Team.
But for a Team to self-organize around it’s work it have to know what it is supposed to do: a backlog, and the Team also needs to know boundaries in which it has freedom of choice, e.g. government rules, etc. When you have these boundaries in place the Team now knows what they can decide by themselves (usually the How, in “What, When, How“).
Then how should they self-organize? Now this is the tricky part, which can be really hard depending on experiences within the Team. They need to self-organize around everything which is on their list of Tasks (or To do:s). What this means is that they need to sit down and list their Tasks. What are we doing, what are our responsibilities? Then they need to discuss how to manage accountability of these Tasks in the Team. This can be done in several different ways, but it should be decided by the Team. And they have to explore and try different ways. There is no recipe for this, or at least there shouldn’t be. Best practices emerge from within the Team and can not be inherited from another Team. It could be, I mean it could work out and the Team can try to use experiences from other Teams, but it should be explored and evaluated as everything else. What is really important when you inherit something from another Team is that you have to be careful not organize the Team around a borrowed practice, but instead find you own practice. Each team is different. Each team have another set of members with their own background and experiences. Their own mindset. So just because a practice worked great in another team doesn’t automatically mean that it will work in this team. Always challenge inherited, borrowed and emerged practices and processes, the world is in constant change and the Team members are in constant change. Don’t stick to a practice or process that emerged some years ago, challenge it!
In addition to organizing around Tasks you need to organize around Values. For example, in my Team we work in pairs, or in crowd if there is something really new. I would say that working in pairs is something we Value a lot. It removes the need for knowledge transfer and Code Reviews. The training, Code Review and Feedback is immediate when you work together and this is why working in pair is a core practice in e.g. Extreme Programming. The efficiency however, when you haven’t been working in pairs before is not immediate. This will take some time, but the benefits is immediate in other ways, e.g. knowledge transfer and reviews will lead to better collective understanding and better quality. This is also something that need to be considered during self-organization.
So to self-organize, my take on it:
- Define boundaries in which the Team has freedom of choice
- Define which Tasks is the Teams Responsibility for which the Team has a collective Accountability
- Define the Teams Values, by which I mean is the Practices that gives a value for this Team
- Give the Team space and time to self-organize, it will take some time
In Management 3.0 the author mentions something like my own list above, it is more dense and I really like it. To give a team the possibility to self-organize you have to give it:
- Boundaries
- Direction
- Purpose
Boundaries is the space in which the team are free to make decisions without checking with management first. IMO this space should be huge. Management should just help the team with restrictions and obstacles within the organization, everything else should be managed by the team itself.
Direction is what the team should focus on, and in Scrum this is the backlog.
Purpose is something people rarely talk about. What are we actually doing? What is our purpose? Why do our system exist?
A pretty interesting “mind-game” is to consider a team where everyone is new, the product is unknown, and you have no manager. Now give the team a Backlog and a customer, and get to work. In one sprint you should deliver something. That is the task, just the backlog. Think about what could happen. Then imaging that one of the team members introduce some practices, like pair-programming and test-driven design and everyone needs to give feedback on everyones work. Think about that for while. Can you imagine how the self-organization might change when introducing practices? What more practices could be added? And more tasks? When do you think things get overwhelming for the team?
These things needs to be considered by any manager och Scrum Master, and team member. It is just as important for the team member to understand it’s environment and current reality as it is for any manager.