Key Takeaways
- Learn what self organization is and why it’s important
- 3 key elements that make self-organization in teams tick
- How to use them to get desirable outcomes
- How they are used in agile methods
- How to use self-organization as a management tool
The idea of self-organizing teams is at the core of contemporary approaches to managing complex work. It underpins all agile methods as well as other new approaches to corporate governance like Holacracy.
Self-organization is, however, still frequently misunderstood as something anarchic, that will just happen if we let it, needing no attention nor guidance. In reality productive self-organization within a group, one that supports the purpose for which the group was formed and helps it transform into a team, occurs only if certain conditions are met.
The Triangle of Self Organization identifies three such conditions, that are most important and have to be taken care of in order to successfully use self-organization as a management tool. I have created this model as a teaching tool primarily, hoping to visually reinforce the importance of the triangle’s elements to students. However, it turned out that it could be used in practice when working with a self-organizing team to help ensure all elements are provided and lead to desired outcomes.
Model
The Triangle of Self-organization consists of three key conditions influencing group self-organization. Managing self-organizing teams is done indirectly, mostly by managing the elements of the triangle.
If any one of them is missing the self-organization will not occur (meaning the group will not start to discuss ways of doing the work/activity - the work might not be done at all or it might be one or more of the individuals in the group) or it will occur but not in a desired way (typically people in companies people self-organize to resist the management’s efforts to direct and control them - collectively gaming bonus schemes is a typical example).
The three elements of the triangle are: goal, rules and tension. They are explained in detail below.
Figure 1 The Triangle of Self-organization
First and foremost there must be a clear goal that everyone in the group is aware of. This goal will shape how the group will organize itself – different goals require people to apply different skills and methods. The existence of a shared goal is also the primary difference between a group and a team - if we want our group to become a team we must give it a goal to coalesce around.
Ideally, the goal should be compelling and all in the group should share willingness to achieve it. It can be just implied, but it is easier to make sure all in the group know & embrace it if it is openly stated. If the group shares a physical space it is a good idea to display the goal somewhere to make sure the group stays aware of it.
Shorter, more concise goals usually work better – they are easier to memorize and understand and therefore more compelling.
Second element is a set of rules the group must abide by. They will govern the group as it organizes to achieve the goal. Those are the shared “dos” and “don’ts” of the group. They will wary from case to case and just as the goal they can be just assumed or – better – stated openly. In most cases some of the rules will come from the organizational context the group operates in. Technical standards or rules of a methodology employed by the organization are good examples of such rules that are in effect imposed on the group. The group may then add some additional rules on its own as it works towards achieving the goal.
Rules should be few and simple, just like the goal. Too many rules or rules that are complex are likely to be ignored by some or all members of the group.
Third, final element is tension (I would even sometimes call it pressure) – a short term motivator, reason why the group members should expand energy in the effort to self-organize into a team, engage and achieve the goal rather than remain passive and wait.
Usually the pressure of time is enough to get the group going - a due date creates enough tension. However, sometimes the tension may result from a challenge or a reward.
To summarize, in order for a group to self-organize (and become a team in the process) following three elements have to exist: a clear goal, understood and embraced by all in the group, a set of rules the group will follow and an element of tension, a bit of pressure for the group members to engage now rather than wait.
Finally, I want to remind the reader that providing the elements of the Triangle doesn’t mean there might not be some further process or structure inside, like a guidance from the process or assistance from a coach - someone like a Scrum masters. Neither the process or the coach should make any decision on behalf of the team, they shall just assist the team as it works towards the goal within the rules.
The Triangle in practice
As already mentioned I have first created the triangle as a teaching tool. After realizing that many of my students understood “self-organization” literally, as something almost magical that will appear and resolve problems if only we announce that “we are doing agile now” I was looking for a simple way of conveying what is - in my opinion - the truth about it. The original idea was to visually represent the things I knew had to be taken care of in order to get productive self-organization out of a group or team and hence give students a different perspective. Quickly it turned out, however, that the model is useful in real life practice too.
Directing teams with self-organization is done mainly by applying the elements of the triangle in a conscious way to gently steer the group towards achieving desired goals. This is done either by the group itself, usually when following an agile process, or by manager(s) external to the group.
Let's discuss the first situation more in depth before we consider the second one. It occurs typically with teams working in a process built on the principle of self-organizing teams, the most common of which if of course Scrum.
If you look closely at Scrum you will discover all three elements of the Triangle weaved into the framework. For each sprint during the Sprint Planning the team defines together a Sprint Goal that it strives to achieve. The Scrum framework itself provides a set of rules the team must follow both in how it organizes itself (“cross-functional team of professionals of up to 9 people” etc.) and how it works (Definition of Done, Daily Scrums etc.). The framework calls for teams to abide by preexisting rules - such as company-wide coding standards etc. - and also extend them when the team discovers (perhaps during a Sprint Retrospective) the need to do so. Work is done in short sprints – the looming end of a sprint and the inspection of the outcomes (Sprint Review) that happens then provide the necessary tension. In other words, Scrum provides all three necessary conditions for conscious, productive self-organization and ensures through its events that they are renewed and adapted from sprint to sprint. Their repeated use helps groups change into performing teams.
It works quite differently for teams working with the Kanban Method. There are rules there (in fact the method calls to make “all the rules explicit”) most pronounced of which is of course the WIP limit. However, there are no explicit “sprint goals” (for lack of sprints) or other similar goals the method would call for. The only consistent goal applicable to whole group would be the implicit goal of attaining and optimising flow - pushing work items through as fast as possible while adhering to quality requirements. This goal is made usually more visible by tracking metrics like cycle time and throughput, especially when they are tracked against some kind of agreed or expected performance. It is worth noting, however, that this is a process goal, not a goal related to the product as is the case with Scrum’s “Sprint Goals”.
The tension is also indirect, coming from first the mentioned push to achieve the ideal of “flow” and related metrics as well as daily “Walk the Board” meetings where teams concentrates on items stuck for whatever reason.
When comparing Kanban with Scrum from this perspective it becomes quite clear why it is more difficult to create good, tightly knit teams with Kanban - goals and tension are not as strongly present in this framework. It is of course possible, as those elements can be provided nevertheless, irrespective of the framework (for example, if a team builds a software product then the release goal can become the motivating focal point for the group), but Kanban Method itself doesn’t require that.
A much more complex application of self-organization is Holacracy. In Holacracy people are organized in Circles of Roles (and potentially a person might have multiple Roles belonging to different Circles). Each Circle must have a purpose, which serves as the primary goal for its self-organization. Shorter term goals are set as projects. Work is reviewed at least weekly during Tactical Meetings providing the necessary transparency and pressure (the word tension having a different, defined meaning in Holacracy). Behaviour of each Role and Circle are defined by a whole set of rules - what is unique to a Role, what can be done by anyone etc. - as well as guided by explicit policies set by a Circle. In fact, there is a special role - called a Secretary - devoted to keeping track of all the rules in place. Each of the rules is up for change during special Governance Meetings occurring every month or so providing an additional layer of self-organization - the Circle not only organizes tactically to fulfil its purpose, but can also change its own structure and rules as it goes.
However, the triangle model can also serve as a guide for managers who want to employ self-organization when working with teams (instead of traditional “point and tell”, command & control style).
A good example for this scenario is using self-organization to form smaller teams out of a large group. Usually such a larger group can not define the goal nor provide the necessary rules on its own - they have to be provided to it by an external entity.
In fact this very situation is one of the first practical uses of the triangle. About 6 years ago I was working with a company that was transitioning to agile, with Scrum as the desired team-level process. The challenge the development manager faced was how to divide the group of 28 developers into 4 Scrum teams. Instead of trying to somehow analyze the people available and assign each of them to a team I suggested that we use self-organization. We sat down together and prepared all three elements by briefly discussing them and writing the result down:
- Goal: divide into 4 Scrum teams to work on the X system
- Rules: a) no more than 9 people on the team, b) no testing or other technically focused teams - all teams must be able to deliver features from the backlog, c) “tiger team” members can’t be all in the same team - there must be at least one of them in each team that forms.
- Tension: 30 minutes to perform the division
The goal as stated was clear enough for the circumstances, since all developers have already worked with the system X (an internal system used the by the rest of the organization). All participated in a Scrum training, so they knew - at least in theory - what a Scrum team was. And after that training 7 volunteers have formed a team, that applied Scrum by the book in practice for two sprints working on a side-project. They started to be called “the tiger team” and the development manager was afraid that if this team stays together their knowledge of working in Scrum will not spread to other teams.
We called all developers into a meeting room, presented the goal, the rules and the timebox then asked if they have any questions. The only one they had was how to address/assign people not present in the office (turned out there were 2 such persons on that particular day). We quickly turned the question around (asking “how do you think you will handle that”) and in the end they decided to call them and ask them if they had any preferences, but if that fails they will be assigned by the group but will have the option of changing teams once the are back at work.
With that done we have a set a timer to 30 minutes and together with the development manager left the room. The wait for quite difficult for him, as he was worrying our little experiment will fail and he would be back to his Excel sheet with people’s names trying to resolve this puzzle. Of course, nothing of this kind happened - once we were back we were presented with a list everyone in the room was happy with.
This experience is not unique - most agile practitioners recommend performing team formation in this way (see this article on creating teams). Yet, for many managers it is still a new experience, one that provides them with a vivid experience of self-organization at work - but also of the triangle elements in action. They can see how by selecting the rules and the goal as well as applying an appropriate timebox they can influence the group to avoid risks (like having all “tigers” in one team) and get the desired outcome.
However, the triangle can be used in other contexts as well. I frequently use it when preparing focused workshops, ones on which the group should work on a given topic. Right now I am preparing a workshop for a group of managers to consider why they are implementing agile in their department, how will they know they succeed and how can they measure it. The expected outcome is a set of objective - or at least intersubjective - metrics that will give them an idea whether the department is getting better or not.
- Goal: 2-3 metrics indicating improvement in areas that are key for the dept.
- Rules: a) metrics must address the areas that motivated the department to use agile b) they must be measurable objectively or if based on gathering opinions (surveys etc.) use appropriate methodology
- Tension: 1h30m timebox, if metrics not selected by the group they may be imposed by the management board
The Triangle in context
It is important to notice that self-organization happens usually within a certain organizational context. The basic Triangle of Self-organization concentrates on short term elements, ones that have to be provided to a group to get it to organize in a certain way. It is however worth noting other elements that influence and support (or not) the three basic elements of the triangle.
Short term, concise goals that the group strives to achieve should be rooted in a longer term vision, which group members should of course also know and share. While the pressure of time provides necessary immediate tension, nevertheless longer term motivation is also important. Finally, rules provided to the group (or developed by it) should be in sync with the organizational culture and supported by it.
Vision, culture and overall approach to motivation are longer-term issues each organization must take into consideration when trying to create self-organizing, self-managing team (as well as use agile methods etc.). It is quite frequent to see companies try & fail in implementing agile methods because they are completely incompatible with existing culture & vision.
Recently at a company I was running a retrospective, with a team that was not very enthusiastic, but progressed nevertheless to consider their past (and first) sprint, identified key challenges and then generated the actions that in their judgment would resolve them. We hit an unexpected block when I asked the team who will do the actions - they said that of course those would be the managers. Having worked probably all of their career in hierarchical, command and control cultures it did not occur to them that they themselves could do anything to remedy the problems identified. In fact, one of the team members started arguing that as workers they should have everything organized by the managers, this being a sign of good management in his view. Clearly, the culture of the organization so far was not supportive of agile and getting teams to indeed self-organize in a productive way will be difficult.
Conclusion
Self-organization is a modern management tool that replaces command & control as a method of creating teams and guiding them to deliver desired outcomes (eg. valuable products). To use it productively managers and teams should be aware of three essential components needed to guide this process – goal, rules & tension - and choose them consciously to achieve intended outcomes. Care must be taken to ensure those are in line with existing culture, vision and approach to motivation.
About the Author
Andy Brandt is been in the IT industry for 25 years and he has done many things – he was a programmer, a Unix system administrator, a trainer, a Linux evangelist, an analyst, a project manager (and a PMP) and a line manager, then also a Scrum Master and founder of software development startup. He has started working with agile teams in 2005 and practices Scrum since 2006. In 2010 he joined Ken Schwaber’s Scrum.org and is one of the longest serving Professional Scrum Trainers. He also published two e-books on Agile (“Environment for Agile Teams” and “Agile w Praktyce”) and blogs. Currently Andy is leading Code Sprinters, the software company he founded in 2007 that evolved into Poland's largest provider of agile-related training and consulting.