Agile feeds on trust and trust does not scale up

an environment of trust is one of the many hidden assumptions of the initial agile movement. corporate environments that are known to breed infighting can only tackle agile transformations if they are happy to face fundamental cultural changes.

Hierarchies enable indirect and/or mediated communication through multiplexed channels. Instead of 100 employees talking to each other, it is more reasonable to divide them in teams of 10 and have 10 team heads talking to each other. Team heads are there to filter information between people who don’t necessarily work together. This keeps information safe and reduces the “talk time”.

Hierarchies are good at scaling up but bad at scaling down. Which is one of the primary observations that lead to the agile movement in the first place. People were thinking that maybe not every single project needs to be a bureaucratic monster, and some projects are actually small enough where bureaucracy is harmful.

The agile principles are there to abolish hierarchies. As a result, getting rid of hierarchical communication leaves us direct and open communication. This makes direct and open communication between coworkers one of the founding assumptions of agile development. This is easier said than done because direct and open communication has to be based on mutual trust. Primarily, trust in people to keep sensitive information safe and communication channels unclogged.
For practical purposes, trust means having confidence that the observed and unobserved behavior of an agent are not too different. This sort of confidence builds up over time as people have a chance to regularly observe the results of the unobserved behavior of their colleagues. Building up a trusting work environment requires mutual personal involvement from all coworkers.

“Mutual personal involvement from all coworkers”, mathematically means a fully connected graph, which has n*(n-1)/2 edges. For 100 coworkers that would be 4950 simultaneous communications. Which circles back to why we have bureaucratic structures to enable many people to work together. When you divide workers into “teams of square root members” the number of communications is ((n⁰.5)*((n⁰.5)-1)/2)*((n⁰.5)+1) (eleven graphs of 10 people each, where eleventh is the leader-team) which generates 495 communications. (original number divided by square root of original population) Which is drastically less.

the “teams and leaders” configuration on the left has fewer concurrent discussions compared to the “flat hierarchy” on the right. (reduced to 9 team members for visual clarity of graphics)

Based ONLY on the given information, selection of a methodology for a given project is trivial. Trust doesn’t scale up and bureaucracy doesn’t scale down. There is a fuzzy grey area in the middle where you have to sit down and think about respective benefits brought by both methodologies, but it is already being discussed much better in other venues. Do a google search.

it sometimes goes horribly wrong

Now I am not claiming that giant organizations can’t have nice things. I am sure we can find ways to utilize agile ideas there. Some proposed agile solutions are explicitly labeled as “works at a scale”. I did not try them and I shouldn’t comment publicly without trying for myself. Instead, I urge you to read up on them and form your own opinion. I will simply propose that the well-established first generation of agile methods (I will not name and shame, but readers will know which ones I am talking about) should be kept out of larger organizations.

What in practicality happens tends to be a mess. Somebody important hears somewhere that agile methods will increase productivity by getting rid of deadweight. “Deadweight” being the bureaucracy that keeps the employees in their endless cubicle farms at least semi-organized. The trust relationships are hard to form because large companies always bring a history of corporate-feudalist-infighting to the table, and people start from a position of grudge which is the exact opposite of trust. Bureaucracy fights its own downsizing tooth and nail because most middle managers are not ready to meet the requirements of an agile work environment, such as skills in facilitating and coaching. And in the end, the pains of bureaucracy downsizing and maybe even reinvention of the existing bureaucracy is blamed on an agile transformation that never took place. Maybe it even never started.

➡️ let us consider two examples of large organizations with trust issues.

Example A

The relationships between companies in the ecosystem are managed by contract negotiations, which cause massive business friction and slow down product development.

The holding company A does not actually care for the software that runs in the sold hardware. It is only there to make hardware units sellable. That’s why they decide to at least cut software costs by introducing agile software development practices in an effort to tear down company silos and unify software employees. The point is to develop a single common software for all hardware and go faster with existing human resources. Manpower from multiple antagonistic companies that are first loyal to their direct employer are pooled to work on the common project and have to talk to each other without supervisors. The antagonistic companies will be forced to adapt to the end result.

the following happens:

  • Management will demand the use of extensive specifications to make sure that none of the subsidiaries are undermining the project to exclusively benefit themselves.
  • Because software employees are incentivized to look out for their local hardware first.
  • Management will be highly suspicious of any deviation from the specifications and will severely hamper any attempt to deviate.

About 75% of the agile manifesto just went through the paper shredder, because people won’t trust each other.

example b

The holding company B decides to jump on the globalization bandwagon and offer geographically continuous services. Analogous organizational silos in subsidiaries are ordered to seamlessly interface with each other, people start mailing in English and quickly realize that every culture has a different way of “parsing reality” and they are all talking past each other.

The following happens:

  • Global management will decide on a fixed toolkit to unify business interactions around their own favorite business practices. The imposed toolkit will not fit geographically remote business practices.
  • Management will demand extensive and overly verbose documentation to make sure that nothing gets lost in translation due to cultural assumptions.
  • Management will be very sensitive to deviations and assume that any deviation is first and foremost a misunderstanding of common documentation

About 75% of the agile manifesto again landed in the shredder bin, because people can’t trust each other.

Discussion of examples

The second example is complicated to explain because language is complicated. On the other hand, humans are evolved to cooperate and figure out language problems, so the solution is more hands-off. Before a transformation project takes place, teams that belong to disparate cultures should set aside time to explain to each other how their respective systems work. Through discussion, a common understanding will eventually be reached. This won’t immediately reveal an optimal solution and a common ground but it will make all subsequent discussions much more fluent.


Also us consultants should probably develop better tools and methods to detect the existence and absence of trust. I, for example, need to work with a project team for some time and observe personal interactions during task distribution and blame assignment to confidently decide if they have a trusting environment or not.

*on cargo cults:

A cargo cult is a religion that develops in a pre-industrialised society when they encounter the misplaced products of an industrialised society and consider this misplaced cargo to be divine or magical. When the cargo cultists eventually discovered the air strips where the planes that carry the cargo landed, they would observe the daily routines of the soldiers/workers there and simulate them in an attempt to attract planes themselves. Eventually, they create rituals that copy observed behaviors of the industrialized societies, but since they don’t understand the reason it looks haphazard and out of place.

Cargo Cult Programming is when programmers exhibit similar behavior by blindly copy-pasting code or use dependencies without properly checking suitability.

By extension, cargo cult agile transformation would be blindly assuming rituals of agile transformation that “worked” for a competitor without properly understanding the reasons or results of agile in the first place.

We set trends and design digitalization through innovation, engineering, knowledge & events. 🔎 get your best ideas with us! 💡