Decision-making in an agile organization

A challenging question in Agile organizations is: "Which decisions should be made where?" - we quickly end up in a heated debate of "team autonomy versus command and control." A red herring - and a false dichotomy that misses the big picture. There is a better way.

Making decisions

Let us first discuss briefly about the three ways that decisions can be made in companies:

Top-Down

Traditional organizations may be most familiar with this type of decision. When something needs to be decided, a manager needs to be informed about what is to be decided, preferably also with some information on the consequences of various decision types. At a convenient moment in time, the manager will decide, and the affected parties will act based on the decision.

Depending on how information is presented to the manager, the manager may decide based on an unknown bias. Managers are often unable to fully understand the consequences of their choices. In turn, teams have to deal with consequences that may not even make sense to them, but they lack the power to change things. The system encourages currying favor over full transparency, and a "making things look good" is worth more than "doing what is right." 

A lot of time is lost in presenting information to management in order to prepare the decision, even when the decision is seemingly obivous. Revising the decision requires significant evidence as well, even after the negative repercissions are already visible. Hence, top-down decision on the work are rarely efficient, effective or even helpful. And that's why they are avoided in leaner organizations wherever possible.

Autonomy

Agile organizations, especially those centered around Scrum, emphasize team autonomy - and thereby, autonomous decision making. Many developers don't like managers interfering with their work, and prefer this way of making decisions. Some get very religious on the "autonomy" part, and will insist on teams getting their way.

Autonomous decisions are both feasible and efficient when the team operates in isolation: As long as it works for the team, we're good. When the team isn't happy with a choice, they can quickly revise it and improve.

Team autonomy sounds great, but isn't a feasible approach when multiple teams interact.

Let's say that team A would like to define a customer as firstName and lastName referenced by customerID, and team B would like to define the customer as fullName and title referenced by customerRefID: Who is right?

If A and B decide autonomously, the system won't integrate, so everyone is "wrong."

Should management decide?

That brings us to the third option, which requires willingness to compromise:

Federation

Let us redefine team boundaries to objective boundaries. People contributing to the same goal, working in the same context, or on the same products, need to collaborate, lest they get stuck dealing with friction rather than making progress.

In larger organizations, we have multiple teams. They might be planning, working and delivering independently - yet, at some level of abstraction, they share the same goal.

As an example, if we're working on an Online Shop, we benefit little if our checkout process is optimized at the expense of user registration: our total revenue might go down if we force people to provide payment data upon registration already. Neither the "Checkout," the "Payment," nor the "Registration" teams can autonomously decide which approach is the best - they need to collaborate!

Thus, a "federation" is born: People whose work overlaps for one reason or another can federate. A federation compromizes on local autonomy to optimize globally. We have some centralization, and some decentralization, and we apply a higher-ordered decision framework to determine both how, and what, we need to centralize.

A federation offers us fast and efficient team-level decisions, as well as sustainable and effective overarching decisions.

Guardrails of federated decision-making

A number of common pitfalls can render a federation ineffective:

1. Not involving people who are affected by outcomes.
2. Involving people in the discussion who aren't involved in the outcome.
3. Forming decision queues.

This happens when we violate the general rule of thumb that any federation should decide as little as possible, and as much as necessary. 

The following decision-making flow can assist us in determining which decisions we would like to keep autonomous, and which are better to federate.

In sequence, we can ask three questions to determine whether we require a central federated decision session:

1. Will the decision affect others?
• We only need to involve those who are affected.
• If we affect nobody outside the team, we don't need others to agree.
2. Will the decision have long-term impact?
• Easily reversible choices can be subjected to experiment, and inspecting outcomes.
  
• Decisions that have a high cost of change require deeper discussions.
  
3. Is the decision highly time-critical?
• If there is a high cost of delay, "it's easier to ask for forgiveness than get permission."
• If cost of delay is lower than cost of change, the decision should be made centrally.

As we know from governments, federation has a cost attached and easily leads to bureaucracy. Hence, with every centralized decision, we should inspect and adapt on, "What are the costs and benefits of centralizing this?" - and, "Are there things we could change so that we could do this autonomously?"

The Agile Tragedy of Commons

There's a socioeconomical dilemma called, "Tragedy of the Commons" which effectively means, "In unregulated systems, local optimization may become so extreme that the system becomes unsustainable."
And here's why you need to understand it in order to understand "agility at scale."

Before we get started, though, let me explain the dilemma:

The Tragedy of Commons

Imagine there's a huge, pristine green pasture. The lord of the land has decreed that everyone is free to use this pasture for shepherding their flock.

The first shepherd who arrives finds a vast green pasture, and the flock is happy to graze on the fields.

Soon afterwards, another shepherd arrives, and their sheep graze happily on the lush pasture as well. Both shepherds are happy, as their sheep have ample food to eat.

In the excellent conditions, the flocks multiply.

As the flocks grow, there is no longer an overabundance - the sheep of the two shepherds begin competing for food. The first shepherd's sheep had more time to multiply, and the second shepherd's sheep lack the required conditions to multiply freely.

Both flocks compete over increasingly scarce food: the sheep lack nutrition and are threatened from starvation. The first shepherd feels that the second shepherd's presence has caused this threat to their flock. The second shepherd considers the first to be using their unfair advantage of having a bigger flock to drive them off the pasture. Quarrels arise.

The feudal lord settles the dispute by dividing the once lush green pasture into an allotted segment for each shepherd, based on the size of their flock. Both shepherds now have access to less land than they could access before - but each now has full control over their flock.

Should the lord have settled the dispute in this way? Should the lord have found another solution? Take some time to think. What would have happened - had the lord not intervened?

Tragedy of Agile Commons

There are many, and massive, applications to the Tragedy of Commons in the realm of software systems - moreso in scaled environments. In the land of Agile, they're much more visible than in the land of Waterfalls, where the lots are already divided before they exist: Agile teams incrementally and empirically discover their next best move based on where they are today - perfect preconditions for the Tragedy of Commons.

Common Code

Teams who haven't learnt discipline in code will find it highly irritating to see one developer interfering with another developer's code: "my" coding style is always better than "yours."

Quickly, quality problems begin arising on the Common Codebase: quarrels over style, functionality placement, inconsistencies and many others.

As more and more developers enter the scene, the tendency for code silos built around personal preference, coding style, technologies, or even domains increases.

Whereas one team can often be left to freely roam the green pastures of service implementation, the field quickly turns into a brown quagmire when multiple teams all play their preferences, until the code base becomes entirely unworkable.

Once teams build fences around their codebase, Collective Code Ownership becomes a thing of the past, and Component Teams find themselves entertaining a dreadful nightmare of coordination meetings.

Better approaches could be:

• code conventions
• linting rules
• cross-team Pairing sessions
• Code dojos
• Continuous Integration / Continous Delivery

- but these things are all topics large organizations struggle with after the code has been divided into silos.

Common Innovation

A green field project is often a great way to introduce new, more powerful technologies that allow teams to do less with more.

As the development organization matures, and standards begin to shape the landscape, new ideas becomes exotic and marginal, struggling to overcome inertia.

Imagine - just for example - introducing agent-based logic into an architecture driven by RPC's and SOAP requests: There will be few takers for such an innovation.

The Tragedy of Common Innovation is that new ideas have to find a really small niche when the field is already taken by old ideas. Many good ideas go extinct before they can catch a hold.

With a constant decline of innovative ideas, organizations eventually find themselves investing massive efforts into servicing outdates ways of working and technologies, incapacitating their ability to deliver high value to the customer in the same ways others do.

Better approaches might be:

• innovation allotments
• hackathons
• innovation sessions
• innovation champions
• cross-team collaboration on innovation
• intrapreneurship

Common Meetings

Have you ever been in a 2-hour meeting with 40 people? Did you ever pay attention to how many people actually speak? Hint: it's most likely not an even distribution.

Small organizations find their meetings very effective, but as more and more people appear on the scene, meeting effectiveness quickly declines. And there's a reason.

In an effective 3-people, 1-hour meeting, every person gets to speak roughly 20 minutes. That's a lot of time to voice ideas, offer feedback and draw conclusions. That's a 33% activity ratio. And everyone has pretty much the same understanding afterwards.

When we constrast this with a 30-people, 2-hour meeting: Simply by dividing clock time, we see that every person gets to speak an average of 4 minutes, while being forced to listen for an average of 116 minutes: The ratio of ideas contributed versus passivity is staggering for each individual - the activity ratio has dropped to a mere 3%! In such a scenario, the tragedy of common meetings becomes that some of the more experienced people take the stage, and everyone else becomes decoration.

Solution approaches might be:

• focus sessions
• using a need-to-know principle
• Law of Two Feet
• breakout sessions
• topic ownership

Specialisation also removes the need for everyone to participate in all discussions.

The tradeoff is mainly between not everyone getting firsthand information and people suffering through hours of only marginally relevant meetings. To any solution, there's a downside.

Common Work

A single developer can work on any code at any time, and there will be no unpredicted side effects like merge conflicts caused by others' work. Small teams will usually learn quickly how to coordinate so that they minimize mutual interference.

Without good engineering practice, delivering a larger, integrated piece of software means lots of simultaneous changes in many places. Teams will either get into a Riverdance of constantly stepping on each other's toes, or they will require so much coordination that things get really messy. Of course, the "solution," is - once again - code silos and dependency hell: productivity tanks as risks and delays rise skywards.

Every developer joining an organization that hasn't managed to deal with the Tragedy of Common Work adequately, will make every developer's productivity decline - up to a point where the net productivity gain of hiring additional developers may be negative, i.e. with each new hire, the organization gets less productive overall!

Potential solutions could be:

• visual dependency management
• domain separation
• decoupling
• joint roadmap planning
• cyclical synchronisation points
• communication by code

Now what?

These are just four examples of how the Tragedy of Commons matters a lot in a Scaled Agile setting, and there are a vast number of potential commons.

Regardless of whether an Enterprise is new to agile ways of working or have been doing so for a while: you need to establish overarching rules that mitigate the conflicts, lest you run afoul of the Tragedy of Commons.

The "Tragedy of Commons" is entirely evitable in a holistic system where every participant sees themselves as an integral part of the whole. The solution is coexistence and collaborative conflict resolution rather than competition.

Ground rules address unregulated, harmful growth, a lack of discipline, and myopic actions, but each rule comes with a drawback: it reduces flexibility. While Team Autonomy needs boundaries where these are for the Greater Good, it's important to set these boundaries wisely, and revisiting these where they aren't useful. That can't be done by only one group - in a common system, it has to involve all those whom it concerns.

Which boundaries will you set to prevent your organization from suffering the Tragedy of the Commons, and what is their cost?

The 4 drivers of a holarchy

Concluding the introduction to the basis of a holarchy, let us explore briefly what drives a holarchy:

The 4 drivers of a holarchy

1 - Interaction

Interact with those around you. Build relationships.
It's not enough to interact once. You must continuously interact and communicate.

2 - Inspiration

Give others reasons to want to do what you do - or even more.
Likewise, let yourself be inspired by others.

3 - Participation

It depends on you. If you don't participate in what needs to be done, nothing will change.
Participation is not an individual matter. Align with those who pursue the same goal.

4 - Growth

You're not perfect. Make experiences, learn from others. Seek enlightenment.
Grow as a person and help those around you grow as well.

Act!

You must constantly work on all these drivers. They depend on nobody except yourself. Maybe you will be the person with the most drive in your holon, maybe not - that's not important. Important is that you drive.

10 Principles of a holarchy

How can you make a holarchy happen? First, you need to establish the values of a holarchy to create a foundation, then you must establish the principles to make it "tick". Here are the principles of a functioning holarchy:

The 10 Principles of a holarchy

1 - Care

Care for True North. Care for what you do. Care for people around you.

2 - Leadership

Everyone leads in anything: what they do, how they think and what they believe. Servant leaders never stop to serve, enable or inspire others.

3 - Engagement

Participate. Contribute where you can. Engage others. Take responsibility.

4 - Decentral

Every holon is autonomous. There are no directed dependencies. There is no "HQ".

5 - Informal

Everything is subject to the current need. There is no prescribed form for anything.

6 - Practical

Do what works, don't what doesn't. What works in your holon may not work in another.

7 - Respect

Everyone has something to contribute. You may need to discover what that is.

8 - Non-judgmental

Just because you disagree doesn't mean they are wrong.

9 - Openness

Everybody's perspective is limited. You grow by seeing through other's eyes.

10 - Voluntary

Everything you do is your choice. Nobody must agree to anything.

Conclusion

These principles are not open to customization or "adjustment for pragmatic purposes". If a single principle of holarchy is broken, the entire structure is threatened. Holarchies are fragile and require continuous attention.

Establishing these principles takes years. There will be a lot of setbacks. Failure, getting up and improving are the normal. Regardless of what you see or what happens - never abandon these principles and do your best to keep them.

The 8 core values of a holarchy

In a recent post, I introduced the holarchy as an alternative organizational structure.
Let's look at the core values required to build and sustain a holarchy:

8 Core Values of a holarchy

A holarchy requires shared values. They need to be applied and maintaned without compromize, both on an individual and a corporate level.
If you do not share these values, your holarchy is already set out to fail:

1 - Clarity

First, you need a "true north".
This true north is a transparent, shared set of beliefs and a compelling vision. Everyone must be clear and aligned on the vision and these beliefs. As the vision grows out of sight just by time passing by and life taking it's course, you must continuously invest time on recalibrating yourself.
Shared beliefs need to be clearly articulated and should be as free from ambiguity as possible.

Constantly communicating these beliefs and the vision in clear and simple terms is essential to keep the holarchy going.

2 - Humility

Nobody is better than anyone else, we all are where we are. We do have different responsibilities and different perception, but that doesn't mean mine is more or less valuable than yours.
We all always lack some piece of the puzzle - and we're seeking out more pieces instead of insisting that we got it right. Be willing to be corrected at any time, by anyone, through anything.

3 - Scrutiny

Everything is up to scrutiny. Everyone should be free and willing to say "I could be wrong", or even "We could be wrong" at any time. Nothing and nobody is exempt from being questioned, by nobody, at no point in time.
That doesn't mean we need to have all the answers: It can be that we simply don't know. New information or evidence may imply that our past understanding is no longer adequate or appropriate. When this happens, we must be swift and willing to update ourselves.

4 - Purity

A holarchy relies on following the vision without compromize and being consistent in what you do.
Scrutiny should expose inconsistency, and purity means that you consequently deal with inconsistencies by resolving them to the best of your ability.
True North guides the measurement of the direction you should take. Deviation from True North is an inconsistency that you need to deal with.

5 - Equality

"Rank has its privileges" - and that creates problems. Therefore, there are no ranks and no privileges. Discrimination of people based on any factor beside their actions creates inconsistency and must be subjected to scrutiny.
Roles are transient and subject to need and may change at any time. There are only functions and responsibilities. Not even "leadership" is a role - it is something you either do or don't. It is not a label attached to a person.

6 - Unity

Seek harmony with all those who are willing to move towards your goals, regardless of who, where or when. The rules and practices of the holarchy should be inclusive, yet without compromizing on the vision.
Tolerate no form of division, not even with those who are just at peripheral touchpoints, such as customers, relatives, or friends. Divisions create inconsistency, and inconsistency breaks the holarchy.

7 - Sincerity

Take a stand. Act on what you believe is right. Do what you mean and mean what you do. At the same time, be willing to be adjusted by those around you. You can't refer to "the system" or "the situation" as a reason for doing something you don't believe in, as both are shaped by your own influence.

8- Responsibility

Responsibility can only be taken, not given. If you don't take it, nobody might. You yourself are responsible, so do something. You have no excuse to point at anyone for saying "They should have ..." or "But they didn't ..." , but you do have the right to lead the change by yourself.

Conclusion

Nobody said Holarchy is easy. These core values are essential, yet incredibly difficult to maintain. and even more difficult to establish in the first place. They are the "magnet field" for your moral compass.

You can't just transform an existing system into a functioning holarchy without first defining "True North". Not everyone will join you in your pursuit of a holarchy, and many will find it too challenging to continue on this pursuit in the long term. A holarchy must be willing and able to continue towards their goals, even if their former leaders forsake these values course and it must be ready to leave those behind who choose to become impediments towards making these values happen. A holarchy can only persist with the people who are willing to share these values. Finding the right people is the first problem you need to solve.

Significant change is required to get a holarchy to work. For those who are not willing to work on themselves to live out these values, participating in a holarchy will remain a dream - insubstantial and intangible.

Hierarchy or Anarchy? - A false dichotomy!

"We need a hierarchy, otherwise there would be anarchy!" - have you heard this claim, or similar claims? How can an organization function without a hierarchy? We have been taught from an early childhood to believe that the absence of hierarchy leads to anarchy, which - in turn, is utter chaos and it's impossible to achieve anything. Is that true? Having experienced a different model, I claim: No. The absence of hierarchy is not necessarily anarchy. Let me explain ...

Hierarchy - the need for prescription

A classic example of a hierarchy

What is hierarchy? Based on the original meaning of the word, it means "sacred order" - or, an order that must be maintained at all costs. A hierarchy is implicitly optimized to remain a hierarchy. This is about status, but also about achievement.

In a hierarchy, the highest person defines the goals for the entire organization. With their direct subordinates, they extract subgoals for those people - and so on. Everyone contributes to the common goal by following the prescibed personal goal and making those below them achieve their goals. The hierarchy would fail to achieve it's overall goal if anyone would deviate from their prescribed goal.

The main purpose of leaders in a hierarchy is to ensure goal alignment and goal achievement within their sphere of control.

Without this kind of prescription, the hierarchy would achieve nothing.

Anarchy - the absence of structure

Let's look at the alternative to hierarchy: anarchy.

Anarchy: The nightmare of every manager

What is anarchy? Based on the original meaning, it means "no order" - or, the absence of order. Anarchy is a highly unstable condition and implies local optimization. Achievement in an anarchy depends only on the individual.

In anarchy, everyone has their own goals and pursues them as they see fit. The outcome of an anarchy depends on the outcome of the individual. There may be common goals or common directions, but they don't mean anything. Failure to achieve personal goals doesn't affect others, so the (not existing) organization in anarchy is unaffected by individual failure or changes to individual goals.

In an anarchy, there is no leadership and no control. Goals are not aligned, achieving a goal depends on the individual alone.



Is that what we have to choose between? If it were so, human society could indeed not function without hierarchy.
But wait ... this is the false dichotomy. There is an alternative:

Holarchy - Integral parts of the Whole

In a holarchy, there is no "up and down" and no permanent structure.

Holarchy is a different model. The term means "The part and the whole are the order" - or: the order is implicit rather than explicit.

What is holarchy? It's quite difficult to understand if you haven't seen it in action. At first glance, the self-similar (fractal) structure may be considered a hierarchy, but it isn't. In a holarchy, there is nobody giving orders. There is also nobody listening to orders, and yet, people pursue a common goal. Nobody prescribes that goal, they take the goal and align around it.
A holarchy is much more effective than a hierarchy, because nobody wastes time defining goals for others and checking their accomplishment - everyone is fully focused on achieving the one, common goal.
People are not "managed" to achieve a pre-defined objective that partially contributes to an organizational goal, much rather they find others around them with whom they are better at achieving their common goal: people with whom they can share labour to achieve something better, something more, something higher than they could alone.

As activities and focus change and steps are accomplished, people's collaboration circles (holons) change dynamically. Every holon is transient and people may be part of more than one holon. Holons themselves may be part of holons. It all depends on what makes sense.

In a holarchy, leadership is different - it's as transient as the holons themselves. Holons aren't "managed", yet there are people forming holons and keeping them together, helping them move forward and joining them with one another. These people are leaders. They have no title and you may not even recognize them.

Summary

Holarchies avoid the problems of anarchy and solve the problems that are endemic to a hierarchy, making them a viable alternative to both. They have other problems, but that's a different story to be told at another time.