What Agile Challenges
Examining the values of bureaucratic organizations
Agile is a new and different concept, radical even. It arose recently, from within an existing tradition of organizing complex work. Since the inception of the Agile movement, Agile principles have been clearly and explicitly expressed, for instance in the Agile Manifesto. Similarly, the Scrum Values are all well described in the Scrum Guide. All of these principles and values are widely discussed in the Agile communities today. Everybody knows them.
Unfortunately, I haven’t found a document as concise as the Agile Manifesto describing our established (traditional, prevalent) values and principles, which have been shaping our organizations for so long. What should your traditional bureaucratic manager friends tell you, if you asked them for the ‘rules of the game’ and its underlying values?
Our current tradition of building organizations started centuries ago. It culminates in today’s corporate, bureaucratically organized enterprises. We have been raised in the bureaucratic tradition for so many generations that we cannot even see its underlying values anymore. Like we cannot see our own eyes, because we look with them. That’s culture.
In order to better understand our pre-Agile value system (for lack of a better name), let us examine a few areas where the tradition is challenged or contradicted most strongly by these new Agile principles. This is where the main battles are fought in the conflict zone as seen in the picture above.
Battle # 1: Transparency vs Secrecy
Why is not everyone embracing values like Transparency or Openness with ease? Because Transparency is not for free. It conflicts with Secrecy and other forms of information manipulation. Transparency threatens to expose information manipulation, a powerful, well understood, and widely deployed tool in today’s bureaucratic environments. The bureaucracy’s information flow, up and down the hierarchy, can easily be gamed by the players, and therefore it is often gamed. Brian Martin describes an all too common example:
Making things ‘inspectable’ in order to adapt requires transparency. Scrum’s insistence on Transparency is a clear challenge to the usefulness of Secrecy in today’s bureaucracies. In the meantime, issues like trust, psychological safety, and so on are being fought out in this arena.
Could it be that losing the power of secrecy is too big an offer for those used to having it? If this is so, then insisting on transparency for transparency’s sake may not persuade an entrenched corporate bureaucrat to hand over their battle-scarred weapon of Secrecy. Then what do Scrum or Agile offer in return for giving up this very useful Secrecy? Well, maybe Transparency is a necessary ingredient for an even bigger change: towards empiricism. This brings us to the next battle.
Battle #2: Empiricism vs Dogma
Remarkably, the organization designing world has somehow ‘managed’ to ignore the scientific (empirical) method for a very long time. Then, suddenly something very old (empiricism) comes along, for example in the guise of Scrum, and finds a new audience. Scrum helps organizations to get started with the empirical method. It could very well be a scientific starter-kit for business kids. (Possibly a disappointing one, since it only has empty containers and a very thin instruction booklet 😊).
Empiricism challenges the long-held belief in ‘plannability’. In Cynefin terms, we traditionally plan and operate as if in a complicated (static, plannable, mechanizable) environment, while actually, our environments have become complex. Mechanization and formalization of complicated work is an old and extremely well-developed field, which gave us factories, assembly lines, and Taylorism.
This is still very much the current vibe. Part of this planning fallacy, as I will call it, is the belief that there has to be The One Plan. It’s created by an individual with authority. The Plan shall be perfect. Adherence to the plan becomes more important than the results achieved. One can easily recognize the many planning and reporting charades across organizations that are victims of this planning fallacy. As project plans are increasingly colliding with fast-changing reality, the delusions of the mad ruler are sustained by his many sycophantic courtiers.
The planning fallacy, together with the separation of ‘plan makers’ (management) vs ‘plan executers’ (factory workers, software developers) established a culture where management’s plans are infallible. They become Dogma. In this situation, you need workers who are (merely) paid to work as instructed (individually, of course) and who are not to think for themselves.
Bureaucratic organizations then are the epitome of the belief in plannable, designable, unchanging organizational machines, made up of individual workers’ ‘jobs’ and their formally designed interactions. The focus on individuals is very much a tenet of such bureaucratic designs. It may not be surprising then that Individuals are next up in our clash of the value systems.
Battle #3: Team vs Individual
As a thought experiment, imagine what our current organizations would look like if we had always designed them with org-charts where all the boxes were teams instead of individuals.
Taylorism and its reliance on individual performance have taught us that the individual is the ‘unit’ of work delivery and that it is management who should design, build, and maintain the machine around these individuals. Larger organizations then evolve into complicated schematics, consisting of interchangeable individuals formally interacting in a bureaucratic, hierarchical (information) system.
Performance appraisals and other curses of the modern enterprise have always been arranged around the individual. Consequently, the team (a group of people) as the natural vehicle of work (or any human endeavor) has never been fully explored nor appreciated in modern times. Until fairly recently, that is.
As a concept, ‘team’ has been around in organizational lore for a while now. It usually is interpreted as a smaller-than-department group of individuals; a means of scaling the hierarchical information-passing game to a larger organization. Often the manager of the team is concerned with optimizing each individuals’ task performance and ensuring their ‘utilization’ to prevent wasteful idleness.
This utilization thinking is old. It has been the default for a very long time. So much so that we didn’t even question it until Agile came proclaiming that (at least in software development for starters), we should have cross-functional, self-organizing teams, slack, flow, mob programming, swarming, etc. This is quite a departure from ‘optimizing’ individual assembly line workers for maximum parts hammered per hour.
The current culture is always used as a lens, through which new (Agile) ideas are first interpreted. Many Scrum teams today use the Sprint Planning to ensure that every individual has ‘enough to do’ (to appear busy or fully utilized) at all times. They try to pack each sprint with tasks for each individual member accordingly. Scrum teams are told by their managers that this is the goal of the Sprint Planning. This is a clear example of how Scrum teams fail in organizations that do not embrace the Scrum Values but continue to operate under the traditional value system.
Teams as envisioned in the Scrum guide are nothing like this. They are supposed to be self-organized, cross-functional, and working as a group on each bit of work that comes their way, once they decide to do so. They are to be excellent improvisers since novel situations or requirements are expected to arise each sprint. They both make the plans and implement them. The workers are the planners and they redesign their own ‘assembly line’ constantly. Or as someone put it: Scrum is the game where you play both the scientists and the lab rats.
If all of human history cannot convince you that teams perform better than individuals, you could approach it analytically, do some empirical research on teams, and still come to the same conclusions:
Bureaucracies must narrow down the activity (‘job’) of each individual in order to better compose complicated processes from those individual workers’ tasks. For the workers, these conditions are often profoundly unnatural, and even psychologically or physically harmful. Human needs such as purpose, mastery, and autonomy were seemingly not a concern before today, in organization design.
Today, many ‘jobs’ do not entail the hammering of a specific car part all day long. We have returned to more interesting and complex ‘jobs’, which are now at the level of problem-solving. And it is here where the reliance on individuals and their narrow ‘jobs’ fails us. We perform much better in groups than as individuals when it comes to problem-solving. It’s how we were made to be: smart and social.
Only as late as the 1800s, at the time of the industrial revolution, the approach to organizing work changed from being largely family or guild based. During that period, organizations were invented to produce large quantities of goods more efficiently. A very successful approach was found, one where individuals served as highly specialized human resources in a larger mechanized system.
Unfortunately, today’s complexity and rate of change can no longer be successfully addressed by big static machines comprised of individuals and their narrow jobs. Groups are the new minimum unit of work (problem-solving) in our complex environments. Luckily, groups of people are ultimately fit for this purpose. Our new Agile principles tell us to start appreciating and harnessing the power of teams. But this means letting go of the bureaucratic machines built from individuals in an information manipulating hierarchy.
Agile Manifesto for the rest of us
If the Agile Manifesto For Software Development needs an update, why not remove the ‘For Software Development’ bit and see what a more generic version would look like. Instead of merely upsetting the entire software industry, why not aim higher and upset all the (complex) product development environments? The software industry is not alone in its suffering from bureaucratic traditions. The Agile Manifesto only scratched the surface of the underlying value system of all bureaucracy with its disapproval of ‘tools and processes’.
Let’s brainstorm some statements that oppose the key features of bureaucratic organizations and see where that takes us:
we value teams over individuals
we value transparency over secrecy
we value empiricism over dogma
we value emergence over designs/plans
we value learning over task performance
we value creativity over compliance
we value autonomy over control
I could go on but at this point, it may be clear that by directly opposing the value system of bureaucracy, Agile values appear almost automatically. Likely, you will find a strong similarity to the Scrum values and other concepts from the Scrum guide.
We cannot fully embrace the Agile principles without also giving up on the ‘old’ ones, as they are often directly in opposition. Agile is the new tenant in the ancient house of Organization, and it demands a complete renovation.
Do you want to write for Serious Scrum or seriously discuss Scrum?
