Many agile teams suffer from the mismatch of agile and organizational leadership with the latter being reflected by the organizational hierarchy. Based on self-organization and iterative processes the teams run into trouble with the top-down steering of their environment. Consequently, very often agile proponents believe that a supportive agile organization should be structured without hierarchies. This is the reason why several companies in the agile field experiment with different organizational structures. Yet, this is not an option for all organizations.
Especially large corporations that exist for many years will not be easily turned into a hierarchy-free organization. Maybe there are only a few agile teams or projects and maybe there is only one department affected by the agile transition. And although over time an agile transition will affect other areas, like finance or sales, it is not very likely that corporations like GE or Siemens will as a whole adhere to agility if it implies they should get rid of their hierarchies. Although there are already several great examples for agile organizations, those neither have a long-lasting history like GE nor are they of a comparable size. This leaves –at least at first sight– the following options:
- Ignore the large corporations or implement agile in such an environment only at the team, project, or program level. Because only an agile organization allows the nowadays requested flexibility and innovative power, just wait till all of these large corporations have died off.
- Found your own organization or rather work only for small organizations without hierarchies.
- Reconsider the idea that an agile organization has to be one without hierarchies.
For a pragmatic approach we will concentrate on the latter. In this article we are suggesting to use sociocracy as a solution that leaves the hierarchies in place yet still allows acting in an agile way.
Leadership in Hierarchies
Managers in general and particularly middle managers in hierarchies often suffer from being sandwiched: On the one hand they want (and have) to ensure that the decisions made in their rank are implemented and accepted on the subsequent levels. On the other hand they want (and have) to be a spokesperson for the level they’re responsible for. This leads to the following consequences:
- The manager has to ensure information and decisions flow both top-down and bottom-up. This isn’t problematic as long as these messages don’t contradict each other.
- Typically the respective manager decides (unconsciously) how to balance these two sides – so either ensuring the top-down or the bottom-up flow. Thus, either the manager acts more in a command-and-control style (typical for top-down) or more in a participatory style, where the latter has often the consequences that the boss of that manager overrules. In an agile setting this can often be experienced if the product owner isn’t empowered, yet does make decisions (as it is expected), and then somebody else up the hierarchy outvotes that decision.
The situation gets worse –actually both for the manager and the team– if the team is supposed to self-organize. Obviously it’s hard, impossible, or at least frustrating to self-organize in a command-and-control setting (because there isn’t much freedom for the team to decide upon) and as well in a situation where the team (including its participative leader) is often overruled.
Thus in summary, leadership in hierarchies faces often two major problems:
- The always-wrong position, being forced to choose between a top-down or bottom-up decision making approach which will make the manager being perceived as either too harsh of too soft.
- Their decisions are overruled at the next higher level and/or the people they lead do not buy-into the decisions.
These problems are independent of an agile transition, yet they become transparent and are seriously in the way if teams are working in an agile manner.
Shared Decision Making and Double-Linking
The key for enabling hierarchies for agile development is sociocracy – especially the two principles shared decision making and double-linking (see also Using Sociocracy for Decision Making and Learning in Agile).
Double-linking allows for a better alignment between the bottom-up and top-down decision making. In “regular” hierarchies there is a person (often called manager) assigned who ensures that information flows top-down. This also means that the manager has to take care that decisions made at the next higher management level get executed in the department or team he or she leads. In an agile team this could be the product owner (depending on the context this might as well be a project manager or some other kind of manager) who will steer the team and who is responsible for e.g. the budget of that team. The product owner will have to ensure that what is decided at the team level is synchronized with the decisions taken at the next higher level.
For the information flowing bottom-up the team elects a representative. This can be anyone appointed from the team (it could be the Scrum master, but doesn’t have to be). What makes sociocracy different is the following: this representative is not only a regular team member in his own team, but also a regular member (with all decision-making authority) of the group one level above.
So this is why it is called double-linking – at the level above are always two persons on behalf of a team below: the manager and the representative. Or in other words from every level of the hierarchy there is a person who is appointed to the next level down (as a kind of manager) and a person to the next level above (as a representative).
With the red arrows representing the bottom-up decision making through the representative and the blue arrows the top-down decision making through the leadership
This solves the sandwich dilemma leaders often find themselves in. Distinguishing the function of top-down information from bottom-up and double-linking the two is actually a structured implementation of good ol’ XP’s request for differentiating business from technical considerations (people-wise) and to quote from the first edition of Extreme Programming Explained: “Neither business considerations nor technical considerations should be paramount.”
Supporting Self-organization
For sociocratic shared decision making it is required that everyone takes a position. This is different from other ways of making decisions, where sometimes the decisions are made without being asked or only cast of votes is required (and the votes in minority are ignored altogether). If a team decides sociocratically, everyone has to share his or her opinion and if it were only by stating to be in favor of that decision – yet even this has to be verbally announced. I, Jutta – can speak from my own experience that it makes a big difference if you just silently agree with something e.g. by not saying anything against the topic at hand, by raising your hand in support, or by giving a thumbs up – or if you have to say loud that you support this decision. As soon as a person says so, the person takes the responsibility for that decision and is no longer a follower only. Consequently, because every team member has to state his or her position, every individual on the team takes the responsibility for that decision.
Thus, no matter which hierarchy level we are talking about – shared decision making supports the buy-in from everyone. Because everyone influences the joint decision by taking a position and by agreeing based on consent: no paramount and reasoned objection. Don’t confuse decisions based on consensus with those on consent. For the former the typical question is if everyone is in favor of the decision, whereas for the latter if everyone “is able and willing to execute the decision” – this doesn’t necessarily imply being in favor, yet being ok with the decision. In case I can’t live with a decision, I will have to explain my reason. Different to what is experienced in traditional decision making – the consequence is not that the rest of the team tries to convince me, but rather works jointly on solving the issue I raised. Thus, as soon as a paramount objection has been brought up it belongs to the whole group – and the whole group uses this information in order to come up with a better decision. Thus, due to the participation of everyone it is also ensured that nothing substantial is overlooked because all relevant arguments of all parties involved are considered and therefore an effective decision is made –in contrast to autocratic decision making or decisions made by majority where not everyone involved will get heard.
Every objection is a sign that something has been overlooked earlier and the objection provides now the possibility to correct this. And yes, this asks for a different attitude in decision making. This attitude is actually comparable to the one a retrospective asks for. According to Norm Kerth’s prime directive, in a retrospective it is believed that everyone did the best job he or she could. In shared decision making it is a pre-condition that everyone adheres to the common goal, for example to deliver a certain service or product. This goal is also explicitly decided upon by the team, using the consent principle. So in both cases it is believed that everyone always acts in the interest of the common goal at hand –be it that of the project, the system, the team, the company, etc. – and that nobody just objects or works against the rest of the team just for the fun of it or for incomprehensible reasons. This could also mean that sometimes objections will lead to changes of the common goal. Or cooperation stops because of a lack for a common goal.
Moreover, for really tough decisions it helps to put a timestamp on the decision and get back to it after the time is up.
Other ways to make decisions, like e.g. majority vote, throwing up a dice or leaving it to the leadership, still remain possible if the group decides to do so with consent. So the consent principle does not replace other decision making principles in use but governs them. In general, consent is used to make the overall agreements like e.g. goals, budget, timelines, or working methods. Their execution is then delegated to one or more team members that can make their own decisions regarding the execution of the policy.
The double link in practice
The difference between working with a double link or not became very clear in a company that had to decide on the same issue within two years. The first time this was done with a single link, the second time after implementation of sociocracy, with a double link.
Traditional: dualism and distrust
The management of a fast growing placement agency decided, regarding the financial situation of the company, to compensate employees for inflation with 1% that year. This was a compromise between the government’s advice of 0% and the union’s advice of 3%. Employees were upset that management did not act on the unions’ suggestion. During the weeks that follow many complained and uttered their frustration and suspicion that management enriches itself at their cost. The managing director saw this as yet another symptom of the existing us versus them culture within the company. This passive aggressiveness made the managing director insecure.
Sociocratic: connected and creative
The Top Circle of the agency decided on a compensation for inflation of 0%. This happened with the consent of the representatives of the next lower General Circle after being informed on the current financial situation of the company. This was actually less than the 1% that management had proposed. Understanding the harsh financial situation of the company the representatives had a paramount objection to handing out money when this might possibly lead to a deficit in the following year.
The decision was announced a week later in the General Circle. The representatives explained why they consented to the decision knowing the tight financial situation. Some General Circle members wanted more information on the financial situation, especially the remuneration of management. When it turned out that their salary wasn’t outrageous and management wasn’t compensated for inflation also, employees accepted the decision. After the decision had been communicated down the hierarchy no complaints were heard, on the contrary there was a shared understanding for the need to get the company in a better shape.
Shared decision making in practice
The power of shared decision making is illustrated in the following example. Deciding by consent helped this group in the health sector to overcome prejudices and trying an experiment that led to a collaboration.
A partnership of obstetricians and seven midwife practices, which are using sociocracy as their governance model, had to decide whether they accept the hospital in their region as a partner. Therefore they gathered with their General Circle containing the double links of each of the current partners and the board of the partnership. If they accepted the hospital as a member it would join their General Circle and make policy decisions with the other partners by consent.
After one round of picture forming, explaining the request of the hospital, several rounds of opinion forming followed. The first of these showed that some of the midwife practices feared that the hospital would dominate the partnership because of its size and financial power. They suspected the hospital wanting to take control of the clients, driving the midwife practices out of business, and imposing all kinds of regulations upon them. This was fueled by a recent incident in which the hospital had placed several billboards in the region to attract pregnant women to come for care to the hospital. After a severe talk between representatives of the midwives and the hospital board the case was settled and apologies had been made.
There were also midwife practices that favored the membership of the hospital because this could prevent these kinds of uncoordinated activities. The same held true for the obstetricians who expected that the consent principle will warrant the equivalence in decision making and make it impossible for the hospital to overrule other members. Furthermore it could help to make the hospital to become more transparent i.e. on how they calculate the cost of their services which they provide to the partners.
After the second round of opinion forming it became clear that the midwife practices that feared the dominance of the hospital doubted the hospital’s good intentions. It seemed difficult to overcome their paramount objections. Tension in the group rose which pushed circle members to think about more creative solutions than simply agreeing or disagreeing to the membership. During the exchange of opinions in the third round suddenly a proposal emerged to invite the hospital for a discussion with a group of representatives of the existing partners. This group consisted also of midwives with strong doubts about the (good) intentions of the hospital. The group was assigned to find out whether the hospital accepts the vision, mission and aim of the partnership, and the sociocratic way of decision making.
It was decided that if this group is positive about the hospital after the discussion, the hospital will be allowed to join for a trial period of half a year. After this period a final decision about the membership will be made. This proposal was consented. In one of the following weeks the group met with hospital board members. The hospital accepted their conditions and was allowed (provisional) membership of the circle.
Effect on Agile Roles
Using a sociocratic structure for embedding agile teams will have some effect on the agile roles. The decision can be made for other roles or people, yet in most cases it will be the Product Owner and the Scrum master ensuring the double-linking. Typically it is the Product Owner who will steer the team on what it is working on, so the person in the role of the Product Owner will be assigned top-down by the hierarchical level above. Subsequently, the Product Owner will participate in the steering meetings of next higher level (this is above the team level). Both – the assignment and the necessary presence is already happening in most organizations who apply agile development. Yet, using a sociocratic structure will require more differences for the Scrum master:
- If the Scrum master should represent the team, then in a sociocratic structure, the Scrum master will be elected by the team he or she is representing. So the Scrum master will be neither assigned (e.g. top-down) nor will he/she volunteer for the role. In this election, every member of the team will provide a suggestion and rationale of a person for that role. Then the team will decide jointly (based on consent) who will take that role.
- Additionally to the Product Owner, the Scrum master will participate in the steering meetings of the next higher level. In these meetings the Scrum master is equivalent in decision making (based on the consent principle) as is every other member of that level.
As mentioned before, it will be most likely that the Product Owner and Scrum master will ensure the double-linking. However, the team can as well decide on any team member as a representative. It doesn’t have to be the Scrum master, just anyone who is trusted by the team to represent it best at the next higher hierarchy level.
Conclusion and Outlook
The two principles presented could be used as well to connect different Scrum teams when scaling up. For example, if your product consists of several product areas and many teams work on each of these areas then these two principles allow to interconnect the teams and product areas without a complicated framework or/and without putting the agile principles and values at stake.
Both double-linking and deciding based on consent secure the equivalence in decision making between agile teams and the organization. This way traditional linear hierarchies can become cyclical hierarchies: (formally) integrating top-down and bottom-up decision making. By double-linking organizational levels through leadership and representative(s), who together set the policy at their respective organizational levels, also a hierarchy supports agility. When this policy setting in the cyclical hierarchy is combined with a delegation of the execution of policy to individual organizational members, it will increase its agility even more.
Further Reading
- Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley
- John Buck, We the People: Consenting to a Deeper Democracy, Sociocracy.info
- Gerard Endenburg, Sociocracy, the organization of decision-making, Sociocratisch Centrum
- Norm Kerth, Project Retrospectives: A Handbook for Team Reviews, Dorset House
- The Sociocracy Group (Homepage of Sociocracy)
About the Authors
As a certified sociocratic management consultant Pieter van der Meché increases commitment and fosters effectiveness and cooperation within organizations and teams. Over the years he has trained and counseled in different sectors of the economy, from the shop floor level up to the board room mainly in The Netherlands and the German speaking countries.
Employed at the Dutch Sociocratic Center since 1995 he is currently responsible for the Northern and Eastern Europe Division of The Sociocracy Group and the education of sociocratic experts towards certification.
Jutta Eckstein works as an independent coach, consultant, and trainer. She holds a M.A. in Business Coaching & Change Management, a Dipl.Eng. in Product-Engineering, and a B.A. in Education. She has helped many teams and organizations worldwide to make an agile transition. She has a unique experience in applying Agile processes within medium-sized to large distributed mission-critical projects. She has published her experience in her books 'Agile Software Development in the Large', 'Agile Software Development with Distributed Teams', 'Retrospectives for Organizational Change', and together with Johanna Rothman 'Diving for Hidden Treasures: Finding the Real Value in your Project Portfolio'. She is a member of the Agile Alliance and a member of the program committee of many different European and American conferences in the area of agile development, object-orientation and patterns.