The Agile Manifesto - 25 years later
The Agile Manifesto and why it mattered
25 years ago, back in 2001, the world was a much different one. Work was, in many cases, done on massive scales with long cycles and clear separation of work as inspired by the industries where the work was carried out. Today, we refer to these long forms of projects that turned dysfunctional as processes turned into red-tape bureaucracy as waterfall. This was never a common name, however, but it was later added as a way to recognise dysfunctional process-based work in long cycles.
The fact that these seventeen people sat down and summarised what most of us today would simply call common sense is not surprising. Change had been on the way for a while, as more and more people were looking at the way, especially large organisations, worked as wasteful and dysfunctional, long before that meeting took place. This meeting just happened to become the catalyst that ignited a movement towards a more balanced and human way of working.
It became the match that ignited a desire to change. As the world of the Internet and the digital era formed at an unprecedented pace, the term Agile became synonymous with the way of working for the modern workplace.
4 simple values and 12 principles.
The Agile Manifesto is simple, with just 4 rules and 12 principles. It is expressed as a vision with no practical ways to apply, and as such, it was vague, but it provided the direction that so many wanted. The fact that it can be interpreted pretty much any way a person wants made it the perfect starting point for the inevitable pivot in ways of working.
The 4 rules of the Agile manifesto make perfect sense even today, and they reflect a frustration when stuck in a bureaucracy that focused on strict processes and absurd documentation. Today, I don't think anyone would consider the opposite of these rules to make any sense, which is why I would argue that these 4 rules would be considered common sense today.
These principles are more specific than the 4 rules, and as such, they also display that the Agile manifesto was born out of frustration. These are opinions from people who have a biased focus and a strong need to be seen and given control in a world where they had very little. There is no point of view that represents the business in these principles, and there is more focus on giving the people who came up with the principles control than on what science tells us about group psychology.
It is a document born from frustration and a desire for control more than anything else.
A document created with the best of intentions, but not with the best holistic point of view.
An Agile world turned into greed
Riding on the popularity of Extreme Programming and Scrum, the Agile manifesto ignited the desire for a more human and fast-flowing way of working. Scrum, in particular, became popular as its lightweight process appealed to the many people who wanted something new. It was vague, open for interpretation, and openly stated that it was not a methodology, but a framework. A framework that people could shape anyway they wanted, as long as the process of Scrum was followed. In fact, Scrum demanded that it be followed exactly as specified, or it was no longer Scrum!
As Scrum became more and more popular, it was inevitable that it would become commercialised, and it did not take long before paid certifications started to appear. As a scrummaster, you had to be certified, and with 20 or so pages of information with no defined way on how to actually do Scrum, it was very easy to become certified. Soon the market was flooded with scrummasters with no experience and no clue how to implement Scrum, except to quote the scripture...
Agile becomes a religion
As the digital world and the corporate world evolved, Scrum remained basically the same. As more and more people started to question the value of Scrum, it upset the community of Scrum evangelists. Words like Agile quickly were hollowed out with buzzwords, and evangelists started to use phrases like "Agile is a mindset", but with no explanation of what that meant.
Anyone questioning "Agile", which quickly started to become something mythical no one could actually quantify, would be ridiculed and gaslighted. Just suggesting that there are practical reasons why Agile, as defined in Scrum, does not work in investment projects triggered accusations of being an advocate of Taylorism and red-tape bureaucracy.
Agile was no longer about common sense or about providing a more human and realistic approach to how we work. It became an institution to be followed without question, or you would be branded as evil for even suggesting improvements or changes. Teams began to self-isolate, and mistrust towards any form of management started to create a rift in organisations, causing financial harm as well as damaging collaboration.
The Agile awakening
Then came the pandemic. People no longer interacted the same way, and as isolation had people starting to question how we work as the workforce dramatically shifted. More and more people started to look at Scrum and Agile in general, and soon they started to question things. Just like the little boy in the emperor's clothes, they called out that the emperor was indeed naked. Scrum was not a methodology, and following it to the letter (literally) did not add the value it had been sold to us for decades.
Companies started to abandon Agile, and the roles of Agile coaches and Scrum masters faded quickly. It was clear that Agile was not the magical bullet that would kill all of our problems. In fact, no one could actually define what Agile actually is. There is no definition that is useful in practice, only buzzwords like "Agile is a mindset", which is pointless and does not define anything unless you define the mindset...
Agile was no longer what people were looking for, but without alternatives, strange new alternatives sprouted. Things like SAFe, which is a waterfall with Agile terminology that tries to take the best of Agile and Waterfall, but fails at both. Lean and Flow, Kanban, and many other flavours call themselves Agile, yet no one still knows what Agile is or what problems these frameworks actually solve.
At the core, today we have a problem with Agile, and that is that it is not defined and has never been defined. You can ask anyone around the globe today, and they will have stories of how Agile, in whatever form, has worked for them. You will find the same number of stories of how Agile has turned into chaos and destroyed teams and companies.
This is not because Agile is bad or good, but because it does not exist...
..Or rather, it exists in as many variants as there are people...
The Agile manifesto explored
To understand the Agile manifesto, we must first understand where it came from. At the beginning of this article, I wrote about the meeting that the 17 authors of the Agile Manifesto held and the outcome. To understand why the outcome became what it became, we would have to talk to the authors themselves, but we can make some presumptions based on the outcome itself.
First, we need to consider the world that these people worked in at the time.
The birth of Agile
In the late 90's and early 2000's, many who worked in IT worked in large companies with heavy processes. These were processes that worked well for big engineering projects like building infrastructure. For the growing digital world, however, it was a poor fit. Not only was this a field where every day was a learning experience as we figured out how people interacted with new interfaces, but it was also a time when social advances happened at an unprecedented pace.
Massive 2-3 year plans set in stone with little to no communication or collaboration led to massive failures and a massive loss of money. Developers that was on the cutting edge of the new digital frontier were treated as workers and had little influence over the decisions that were made by managers who had no competence or understanding of the new technologies.
This was an extremely frustrating time for those who worked every day in the new technologies that saw the potential, but were never invited to voice their competence or experience. A sense of working in a dystopian world of incompetence was amplified by silo structures and a lack of access to those who made decisions.
This is where Agile came from.
Communication and involvement with clarity
From this frustration came the desire for rebellion and to take control from those who did not understand.
A desire to be heard and to be involved is a strong theme in the Agile manifesto. They want access and direct communication, and you can see that this is a group of extroverts because the second principle is not true. The most efficient way to convey information is not verbal because it depends on what format the receiver needs. Verbal is the fastest, as you have direct communication, so questions can be asked and answered at the same time.
Information is also a vague term. Instructions are never mentioned, and that is a form of information, but it is handled vastly differently from documentation, which is mentioned. To me, this shows that the group is more frustrated than trying to make a permanent solution to their problems. You can also see this in Scrum and other Agile frameworks, where everything related to communication focuses only on verbal communication.
It is also interesting that the wording is "working together" and not collaborating. If you consider the other principles where the Agile manifesto wants to take control from management and establish control in the teams, this indicates that the wording is not accidental, but deliberate. The teams should lead, and the business should provide what the teams need. In essence, a switch of the control pyramid that was in effect at that time.
I still see these requirements from teams, Agile or not, and what I find is that what they need is not communication or collaboration, but clarity. More often than not, this comes from unclear expectations, and paradoxically, that is often because there are no processes defined. This is a serious side effect of reducing the written and visual instructions as part of these principles, and to some degree, the misinterpretation of the four values.
Control and the freedom to change
The most prominent theme in the Agile Manifesto and its principles is control and the ability to make changes at any time. This is very typical for groups of people who feel that they do not have control, but also for extroverts who don't want to commit and instead have the possibility to rapidly change directions.
This is by far the most damaging aspect of the Agile manifesto, as it has led to self-isolating teams and a culture of chaos and ad-hoc behaviour when used in a dysfunctional way. We have to understand that the intention of these principles was probably not to cause this, but more of a desire to direct power to the people in this meeting who felt powerless at that time.
I believe that the intention was to move away from the dysfunctional way of working that was common in those days. A way of working where changing anything in the development aspect of a project was like pulling teeth and almost never worth the effort. They wanted more influence as they were the people on the cutting edge of technology. They probably wanted fewer stupid decisions by incompetent managers who were acting on yesterday's technology. They also wanted the ability, or the right, to change things often. This is both a sign of the times, as many things during this time were fluctuating heavily, but also a typical need from an extrovert mind.
We know for a fact that development teams do not have the competence or experience to make design decisions. They absolutely should not make any business decisions, and sadly, the outcome from these simple principles is that requirement management more or less has vanished in Agile contexts. While the world of technology still moves fast, it is nowhere as fast as it was when the Agile manifesto was drafted. Managers are far more competent and in some cases even more competent than the people in the teams.
What is even more telling here is that this was written in a time when projects ruled supreme. Not the misnamed assignments most of you work with today, but actual investment projects. As you know, there is a world of difference in how an investment project is managed and run compared to how an assignment or initiative inside an annual operational budget is managed and run. This was never a part of the Agile manifesto, which is also a cause for friction and frustration today.
Rapid change and experimentation befitting the times
This is also very typical for the times. The Internet was changing the way the world worked rapidly, and technology turned everything on its head, often on a daily basis. Code languages evolved seemingly overnight, and hardware doubled in capacity every iteration. Titles and how work was done changed often as technology and science converged, and new discoveries were made in how we interacted with our new technology.
The fact that the people in this meeting felt this way is not surprising. The will to change is their common goal for even having this meeting, and that suggests that they belong to the early adopters category, which is more open to change than most people. While I do not think anyone feels that shorter iterations of deliveries or reflecting on how we work is negative, the principle that focuses on the customer shows a lack of understanding of the business.
The code above business needs
These principles clearly show that there was no consideration for business values. The full focus of the Agile manifesto was clearly focused on technology and the development of code. While this makes sense since the people in the meeting were from the areas of technology and code, it has hurt the way we work, as a big part of how we work was never addressed.
To me, this is the biggest flaw of the Agile manifesto, as it naturally creates a rift between the business side and the technology side. This is by far the biggest problem we have today when it comes to ways of working, as Agile has never included the business side. It is, in fact, considered the anathema of Agile if you even bring that up. Nothing gets you branded as a proponent for Taylorism, or even office slavery, when you go deeper into that rabbit hole.
The Gap and the Ageing of the Agile Manifesto
Over the 25 years since the Agile manifesto was written, the world has changed. The world is no longer the same crazy world of rapid change as it was when it was written. Many will claim that it is and that we have to be fast in how we work, but this is not true. This is just stress talking through the mouths of early adopters who feel the need to jump on everything that changes. What we need today is not to be first, but to be right on time.
The way we work is slowing down. Science has taught us a lot in 25 years, especially in psychology through the fields of UX and CRO. Human-computer interaction is no longer a frontier field, but a field of continuous exploration as design shifts and changes. We know so much more today than we did 25 years ago, but we still try to execute on principles we know are wrong today.
Everything we know about group psychology and everything we know about the different fields related to developing technology says that self-organising teams are a bad idea. Believing that you can have all competence in a single team for organisations at scale is impossible. We invent new words like T-shaped profiles and full-stack developers to gaslight people into believing that a backend developer can also master UX design or that a front-end developer can optimise a database...
I see the gap between developers and management increasing rapidly. I think this is partially the reason why we are seeing mass layoffs of developers and technical people at the moment, and as managers can seize back control that they have been struggling with for decades, they will. Just like developers did when Agile started to take shape. The pendulum always swings back eventually...
The greatest failure is perhaps that the Agile manifesto never aligned with business needs, and as such, always stands as a flawed or limited expression of frustration from a small subset rather than as a whole. While the Agile manifesto does not advocate for the removal of processes or the need for documentation, the end result is that Agile is often experienced as a fragmented and confusing way of working. This fits well with people who want to control things and have a mind that can handle that type of setting, which is surprisingly few. Today we have an epidemic of stress-related illnesses with high cortisol, especially in managers, that is a direct result of a work environment lacking clarity...
Agile and the Agile manifesto were a cry for help and a call for rebellion 25 years ago. It added a lot of good things to the way we work, but it also created a massive gap between developers and the rest of the organisation. It shattered the dysfunction of the massive projects where the most competent people had no voice or influence. As time passed, what was a good thing was turned into a dysfunctional religion, effectively strangling the very solution it was designed to be. Criticism was not just expressed by former practitioners, but even the authors of the Agile manifesto expressed their critique of the state of Agile.
Agile became weaponised as a chaotic and ad-hoc way to avoid accountability and to turn away from the organisation in self-isolation...
Agile is no longer agile.
The future of Agile
I find this quote to fit the current situation very well. While Agile in the form of Scrum and SAFe that we have today is not generally working, there are plenty of examples when they do work. Not because of Scrum of SAFe, but because the people make it work. Through discipline and grit. This is a testament to the people more than to Agile itself. You also have the opposite, where individuals or groups completely destroy things by abusing the term Agile.
They also have several positive aspects that I think we should preserve. Not because of nostalgia or to keep the name Agile, because I think we need to bury the term Agile for good. We should keep them because they make sense and because they add value. In addition to the parts that we should preserve, we should also bridge the gaps and extend these things to reduce the lack of clarity.
Processes are not evil; inventing the wheel over and over is
During the last 25 years, processes and documentation, especially in the form of requirements, have been pushed out and even become vilified. We need to get past such nonsense, as we need to ensure that we have clarity in our ways of working. That does not mean that we should let the pendulum swing all the way back to the old, dysfunctional ways of massive documentations and processes that constrict and strangle work. Having dozens or even hundreds of teams create their own way of working causes fragmentation and dilution of data. It also confuses and hinders collaboration. We need to teach people what processes are and what level of processes are theirs, and how they can adjust them to improve instead of destroying.
We need a balanced approach, and it has to be defined in practice.
We need to break out of self-isolation
Groups of people should not self-isolate in an organisation, so we need to break the mindset that groups should rule supreme. Organisations are made of many people, and collaboration is always the correct way forward. Self-organisation is a myth in any organisation, and in psychology, there are plenty of warnings about what happens when groups self-organise. Groups work to create value for the organisation, not themselves, and not customers. Collaboration must happen so the most qualified voices can provide the best guidance on how to create that value.
What we need is influence and clear structures of communication that are organisation-wide.
We need accountability and clarity
As groups have become less and less competent in how to value their own work, they have also shifted away from accountability by inventing arbitrary values such as story points. We also see group accountability over individual accountability, again avoiding taking responsibility and accountability for their work. This has to stop, and we need to make sure we teach people to make estimations again and why they are important. We need individual accountability, but also to remove cultures of accusations and micromanagement.
We need clarity of who is responsible for what, so we can rebuild a culture of trust.
Agile is not the enemy; abuse of Agile is
I could continue this list with more ways that we need to adjust Agile for a modern workplace, but this article is already long enough as it is. I will end this article by pointing out that Agile is not the enemy, because Agile does not exist. The enemy is when people abuse the term to create ways of working that are harming both people and organisations. This is not done on purpose, but even more dangerously, it is done with the best of intentions by people who do not have the competence or the insight to realise they are very much affected by the Dunning-Kruger syndrome.
The road to hell is paved with good intentions, and without clarity on what Agile is and how it works, it should stay as a vision, not as a way of working.
The Agile manifesto has aged well, and it still has value. You just need to look below the surface and read it as the world was back then. Use what you see provides value to your organisation, not just your group and fill in the gaps where time has made the original intent less valuable today. Find new ways that work better today and share them with the world.
Agile is not a mindset; it is a set of ideals presented for a world we no longer live in.
It is up to us to refine and iterate on those ideals to a reality that we live in today and then to continue to iterate as the world around us changes.
--
Agile is deeply flawed because we are flawed.
That is both its beauty and its curse.
By
💫 Jimi Wikman in Work Methodologies ·
-
- 0 comments 384 views
