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.
I personally like to reduce or remove hierarchies when and where possible, because hierarchies have a natural tendency to expand themselves in positive feedback loops. Any given hierarchy is more likely to be bloated than not. On the other hand, it is prudent to understand what a tool does before getting rid of it. Here I will focus on what hierarchies add to communication.
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 behaviour 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 unobserved behaviour 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^0.5)*((n^0.5)-1)/2)*((n^0.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 much less concurrent discussions compared to the “flat hierarchy” on the right. (reduced to 9 team members for visual clarity of graphics)
(An aside: Trust relationships and bureaucratic relationships are mutually exclusive.They simply have very different modes of communication. That is one of the reasons why agile teams and bureaucratic teams are hard to synchronize. They simply can’t fetch information in a way that is comfortable for one another.)
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
Instead of the selection between agile and bureaucratic methods, I am more interested in people who smuggle trust relationships into leviathan sized organisations that are better off with byzantine bureaucracies. “HOW? WHY would anyone trust unmotivated bored seat-filler employees? Let alone the sharks in the boardroom?” I can imagine you ponder in horror. “Trust relationships are embedded into Agile processes.” is how and “They actually don’t know any better, agile adoption is mostly a cargo cult* at this point.” is why.
Now I am not claiming that giant organisations can’t have nice things. I am sure we can find ways to utilise 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 organisations.
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-organised. 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 organisations with trust issues.
Example A
Hypothetical holding company A mass manufactures and sells hardware. They own many smaller companies in the same sector. Hardware processes are hard to transform and unify, so many of the subsidiary companies are basically independent and pretty much in competition with each other and company 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 unified tooling to achieve comprehensive oversight of all transactions to accurately assign credit/blame to units. This is because the real budgets of companies are separate and losses are not “socialised”.
- Management will demand 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
Hypothetical holding company B manages infrastructure and had to grow by buying minor infrastructure companies from different regions. They own multiple geographically distributed subsidiaries. That is a lot of people who nominally belong to the same ecosystem but probably don’t even speak a common language.
The holding company B decides to jump on the globalisation bandwagon and offer geographically continuous services. Analogous organisational silos in subsidiaries are ordered to seamlessly interface with each other, people start mailing in English and quickly realise 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 favourite 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 first example is straightforward to discuss. There is open illwill in the project. There will be finger pointing independent from the success and failure of the project. Everyone will be more concerned with CYA than collective results. The conversion project is doomed to fail as long as the business transactions between companies are not first modified to make sure everyone fails or succeeds together. If a change in social business practices is not possible, it is best to leave the existing methods alone.
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.
Solutions
One obvious solution is to divide large organizations into multiple loosely coupled teams with independent budgets and schedules. Microservices as such, is a good way of creating an environment that is conducive to trust building. If your large hierarchy is maintaining a monolith, breaking the monolith up into microservices will allow you to also break up your hierarchy into smaller self contained groups. Groups can then build up trust within themselves and move towards agility while maintaining their microservices. Assuming that the loose coupling is somehow done just right, the individual teams won’t even need to have a common methodology between them. Some of them can even choose to internally continue the waterfall ethos. Naturally you will need consultants and coaches to guide you during the transition *nudge nudge* *wink wink*
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:
You might be better off reading about cargo cults in Wikipedia but I will write a short primer by grossly simplifying some very complex phenomena.
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 which copy observed behaviours of the industrialised 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.
