“The best architectures, requirements, and designs
emerge from self-organizing teams”
– Principles Behind the Agile Manifesto
I’ve often had people say to me that we’re not really self-organising because we’re not all taking part in all the decisions made at our organisations, such as how the company is run or what products we should be making. This is a misunderstanding of how self-organisation occurs. The fact is we’re constantly self-organising, it’s just most of the time we’re completely oblivious to the fact it’s happening.
For example, within a group of people (such as a workplace) there are many social sub-groups, such as the early morning runners, the ones that go to lunch together and the after work drinkers. They all naturally self-organise around shared goals & desires. Even within a team where a highly autocratic management approach is in place, members of the team will self-organise around anything they can (such as making the tea or going out to buy some biscuits). The thing with self-organisation is it’s actually harder not to be doing it!
If you define self-organisation as when everyone in a team is able to control everything that affects it where do you stop? Your team? Your department? Organisation? City? Country? See where I’m going?
Self-organisation always occurs within boundaries defined by it’s context. For example, a football team might be a football pitch for 90 minutes, a group of friends on holiday the holiday villa they’re staying in or your department at work by the responsibilities it has. Something or someone always sets these boundaries. If they did not exist self-organisation couldn’t occur.
What causes self-organisation?
A complex system* will always be vulnerable to external events which are outside of it’s control, such as the opposite team, the weather or your customers or stakeholders. Self-organisation emerges when it becomes important to respond to these uncontrollable events in a manner which benefits the system. The ability to do so results in the system being adaptive. We know that software development is complex so we can determine we’re in a complex adaptive system. It’s a huge subject and not the particular focus of this article so I won’t try to go into any more detail, but if it’s a new concept to you I strongly encourage you to investigate further.
How to take advantage of the fact that it occurs
When self-organisation is on your side it can be extremely valuable. If you’re working in a complex adaptive systemÂ it’s shown that by far the most effective way to allow that system to operate is to allow it to self-organise, because that’s what it will naturally try to do.
The problem is it’s not always on your side (if you’re an oppressive Arab dictator, for example) and will often work against your goals and objectives. I’ve often seen self-organisation criticised because this happens. I’ve also seen it criticised because a team is unable to self-organise effectively when allowed to do so. In both cases you may be tempted to blame the individuals in the team. This would be unjust because in reality it is the system to blame (and probably you as the controller of the system).
To enable self-organisation to work in your favour you need to understand and ideally define the system – set it’s boundaries and try to organise it in a manner which will encourage self-organisation to occur in a way which supports your objectives. This is often called Systems Thinking. Again this is a large and well documented subject so there’s no need for me to elaborate further (if you’re looking for a good place to start though I thoroughly recommend Jurgen Appelo‘s excellent book, Management 3.0).
*It’s widely held that software development in general exhibits the properties of being complex (as described in the Cynefin Model).
I’m curious to know how you distinguish between a self-organising team and team that isn’t self-organising. I’m not sure I could provide one that provides makes “self-organising team” a meaningful phrase.
A project team might be able to manage its prioritisation and define its own people’s roles, and thus call itself self-organising. Or it might take note that it has a fixed budget and time, and declare itself not self-organising because it cannot control those factors. Or it might declare the customer representative (the one who prioritises most of the stuff) to be outside the team and so again declare itself not self-organising, because it cannot control that aspect.
Right now I think “self-organising” is actually a scale (fewer controls to more controls) rather than black and white (is or is not self-organising). Yuor piece above appears to imply you think it’s more black and white. I’d welcome your thoughts.
Quite the opposite I don’t think it’s at all black and white. My point is self-organisation will occur regardless, making the question or whether you think you’re self-organising or not rather redundant.
There will always be a limit to what a team can control as your examples show. Understanding the boundaries of the particular context or system (explicit and implicit) will help you better take advantage of that fact self-organisation occurs and therefore determine what would be appropriate for a team to be responsible for and what’s more suited to be organised in a different manner.
Is that more clear?
Great post. This is the way I’ve always thought about it too. One nit-pick:
” This is often called Systems Thinking.”
My understanding is that self organisation in teams fell under the banner of social complexity science, but I appreciate that the terminology in this relatively new area of study is still evolving.
From what I understood Systems Thinking is considered a branch of complexity science, in fact according to Wikipedia the terms “complex systems” and “complexity science” are inter-changeable.
Hi Rob. Yes, that sounds quite sensible!
My name is Roger Zacharczyk, Editor in Chief of Software Developer’s Journal, a new magazine for software developers.
Software Developer’s Journal is a professional magazine, where we try to provide the best knowledge of programming (and much more).
Our idea is to promote software development knowledge at the highest level. Therefore, we are looking for the best authors in the IT industry who could help us in such goal.
Would you be interested in such contribution? I’ll gladly provide you more details.
To familiaraze you with what SDJ is I can send you some free samples of our magazine.
Complex Systems as a sub genre of System Theory/System Thinking makes sense. Not so much the other way round though. For example the study of Ordered (predictable) Systems would fall under System Theory/System Thinking but not under Complexity Theory. Self-organisation is an approach that is associated with complex human systems and hence complexity theory.
There is a whole sea of terminology 🙂 The history is the most interesting bit. System theory is quite old, whilst Complexity theory is a relatively modern offshoot (~1990’s).
This link shows the history and other related fields of study.
And yes I believe you are right that complex systems and complexity science are interchangeable terms (AFAICT).
Not wanting to detract from an excellent blog, but I thought this would help anyone who wanted to do further reading themselves.
Thanks for the clarification. There is indeed quite a lot of terminology to grapple with. I look forward to delving deeper!
Pingback: Mendix Twitter Roundup: Week 19 | Mendix | Agile Business Applications Made Easy
Pingback: rob bowley - adventures in software craftsmanship » Blog Archive » Self-organisation: team size