A frequent complaint we hear from Agile teams is that their self-organization is not respected and their manager routinely overrules their decisions. If you talk to the manager, he or she complains that the team doesn’t respect company policies anymore and makes decisions it's not entitled to make. What seems to be a battle about power in many cases and like a confusion of self-organization with autonomy turns out to be an unfinished Agile integration into the organization.
Last December, we discussed this topic at a workshop of the “Supporting Agile Adoption” program of the Agile Alliance from the perspective of decision making. Decision making has been a topic of management literature since at least the middle of the 20th century, so there’s probably not much new the Agile community can contribute, but it has a lot to learn.
Most large organizations try to optimize on decision making. If a major decision needs to be made, troops of consultants analyze the problem back and forth, preparing a “decision memo” for the board. Often, this is a standardized structure of five to seven PowerPoint slides. The board then walks through these slides in a 30- or 60-minute presentation, decides for one of the options, and delegates the “execution” of this decision to their staff. This is considered to be extremely efficient decision making, because it only take about 60 minutes of the board members’ time until the “right” option is chosen. If you look at middle management, you find similar patterns, often less ritualized.
However, what seems to be very efficient decision making is rarely effective. It optimizes one single aspect of the decision making (“level of executive’s attention”) at the expense of both quality and effectiveness of the decision-making process. Even worse, it confuses making a decision with the board communicating an opinion.
If you look at the full value chain of a decision, it starts when a specific problem is recognized, and it ends once a working solution to the problem has become part of the organization’s actual way of working. So it includes implementation, validation, and correction of the decision. It also includes alignment on the decision (not to be confused with compliance!). A good decision-making system optimizes on this whole value chain, rather than just on the first few steps of it.
One way to categorize decision-making systems is by the order of the decision making itself and the alignment. In the traditional hierarchical way, the decision is made by an authority (a priest, a king, an executive) first, and then we care about alignment. These authorities derive their power from some higher authority (e.g., God or stakeholders). Since those who have to execute the decision have not been part of its finding, and it cannot be adapted to their needs, we need other mechanisms to come to alignment. Loyality to the authorities due to higher beliefs or contractual bindings is the most common mechanism. Enforcement — threatening to give a bad annual review, to fire someone, or to put someone to jail — doesn’t lead to alignment but to compliance. This is often enough, accompanied by attempts to not execute the decision while circumventing the downsides of enforcement. Hence, organizations built upon autocratic decision making need to put a lot of effort into rules, compliance, and enforcement. It takes a lot of time from the decision being made until the decision is “rolled out.”
In collaborative decision-making systems, the order is reversed: first the organization creates alignment, then the already-aligned decision is made. In this case, the decision does not take its power from the authority of the decision maker, but from the “consent with the governed,” as the American “Declaration of Independence” puts it. Coming to a decision in these organizations takes far more time and effort than in an autocratic organization, but their execution comes immediately once the decision is made. So participatory decision making enables the organization to react much faster.
In these organizations, self-organization and management decisions are not in conflict but consistently support each other. And in most cases, a decision made by a group is better than a decision made by an individual — no matter how skilled the individual is.
Making decisions as a group is a craft that needs to be learned. You need to develop facilitation skills, listening skills, and train appreciative discussion. It is also important to understand that a majority vote is not the only way to make group decisions, and for most small groups in the business context, it is probably one of the worst options.
You don’t need to use collaborative decision making on all decisions. A single individual can easily make most of the daily decisions. However, when setting the policies, alignment is crucial and collaborative decision making is far superior to autocratic approaches.
In an Agile context, the policies are set during retrospectives on different levels. There’s a myth that managers should not participate in retrospectives. If you maintain an Agile bubble in an autocratic sea, this is probably good advice. In more mature organizations, retrospectives (and planning or replenishment meetings) are the core alignment meetings and should be run as collaborative decision-making meetings including the managers. Norman Kerth’s book, Project Retrospectives, offers good advice on how to set up retrospectives with several hierarchy levels involved.
One point of particular interest is the interface between an autocratic organization and a participatory decision-making suborganization, such as an Agile suborganization. By explicitly negotiating policies on these boundaries that respect the needs of both parts of the organization, many conflicts at these boundaries can be mitigated. Using a consent mechanism here, which means decisions are made if no one of the involved units has a “predominant objection” against it, allows a bridge between the need for control of autocratic leaders and the benefits of participatory decision making. And a discussion about decision-making systems is far more natural to most traditionally educated managers than value-centric discussion.
[Acknowledgements: Thanks to Anders Ivarsson, Hendrik Esser, and Pieter van der Mechè, who contributed a lot of the insights I used in this Advisor and to the Agile Alliance for making this possible.]
