The Agile Manifesto – How Well Did It Age?

Agile? Isn’t it dead?

There is a lot of talk these days (actually already since years) about agile being dead or close to kicking the bucket. We believe it is not (we covered this in a separate article). But maybe in some places it is starting to smell funny. This could be due to the way its real-life implementations went, how competent its average practitioners have become over time. Or it could be a result of its very core ideas having fallen out of touch with what today’s tech businesses actually need to stay on top of things and generate value. The state of agile as such warrants a separate discussion, and we will not dive more deeply into it. Instead, we will focus on where it all started back in the days: the Agile Manifesto. This will also provide a better context and starting point for the discussion about agile’s survival in the future.

How relevant is the Agile Manifesto today?

Using the opportunity of the Agile Manifesto’s recent 23rd anniversary (writing this in March 2024) let’s take a look at how relevant it still is today.

How well did the Agile Manifesto age over the years since its creation in February 2001 looking at it now from 20+ years later? Which parts of it are still valuable and what should perhaps be revisited, updated or – with all due respect – discarded?

Let’s dive right into the preamble and value statements!

In the form of a line-by-line commentary:

  1. We are uncovering better ways …
  2. … by doing it and helping others do it
  3. Individuals and interactions
  4. Working software
  5. Customer collaboration
  6. Responding to change

“We are uncovering better ways …

… of developing software by doing it and helping others do it.”1

Software is definitely too narrow now. Not because agile did not deliver on its promise of uncovering better ways of developing it – but because it went far beyond and overdelivered.

Agile methods started in software development where they revolutionized the way developers went about their daily work. It helped those engineers who, after the boom of the dotcom era, were stuck with antiquated ways of a naively plan-driven “waterfall” project management that was not fit for the complex knowledge work involved in designing and producing innovative software products.

It was the battle against the infamous “waterfall” which – one can argue now, looking back from a distance – even came short of what good classical project management should be. Waterfall project management was kind of a scapegoat – but a useful one.

From software, agile spread first to other areas of information technology (IT), then to technology in general, then to areas outside of tech. Since at least the 2010s there are movements such as “agile hardware development”, “agile administration”, “agile HR”, “agile strategy”, agile everything. Now even if you visit a conference on traditional (waterfall) project management e.g. by the “Project Management Institute” (PMI) you are likely to find more than half of the agenda filled with sessions relating in some way or another to “agile” (or “adaptive” methodologies as they sometimes call it).

This is why the “software” part of agile is today of rather historical interest. Agile is no longer restricted to coding or software. It came back full circle to its “Lean” origins rooted in a much more general and universal perspective on how organizations should run from end to end. It has become a mindset and a philosophy.

Programming, Motherf*cker!

However, looking at the devs today, there are worrying signs that they are starting to revolt against what has become of agile over the years. Not against the spirit – as we will argue – but against what exorbitant popularity has made of it in the hands of people who obviously often did not “get it” despite its simplicity. Take the following outburst of devs being annoyed by agile as an example:

Exhibit 1: “Programming Motherf*cker Manifesto”2

I let this stand on its own here without comment and for the reader’s shock or enjoyment.

Let’s just say: The self-ascribed programming mofos definitely have a point looking at what sails under the flag of agile these days, and their good intention of getting back to f*cking programming can only be applauded!

“… by doing it and helping others do it”

The second part of the Agile Manifesto’s preamble is as pragmatic as it gets. Both the word and spirit speak to the practitioner, not the theoretician. How important is this aspect today and how well has it been translated into practice?

The manifesto came from people working – getting their hands dirty! – in the concrete domain of software development, not as academics or management consultants taking an outside view on an interesting phenomenon like, say, an entomologist dissecting a bee or a investment banker calculating the profit to be made from reselling your grandma’s mortgage.

The “programming mofo” manifesto (see above) speaks volumes about a big problem facing agile in practice. In many places it has turned into a caricature of the simple, down to earth practical approach it once was.

The reasons for this are manifold: “Agile coaches” (NOT mentioned anywhere in the Agile Manifesto), “agile masters”, paid consultants of all flavors who failed to convey the original simplicity of just doing stuff and doing it better, or who – even worse! – had a vested interest in making things complicated to sell their services. Managers and leaders who did not receive the right guidance or support to understand the basics and allow their teams to apply them.

The focus on “doing the work” and improving things through doing them stands firm and has maybe never been as timely as now where the abstraction levels of data and AI are taking over and even knowledge work is being hijacked by data analytics and machines making it easy to see human work and practice as optional parameters.3

Let’s take a look at the four (relative) value statements of the manifesto, introduced also with a practical vibe “through this work we have come to value:”

Individuals and interactions

… over processes and tools. Oh the tools! Agile these days seems to be dominated especially in the corporate sphere by a few digital tools that have become so widespread that sometimes they are confused with the thing that they are supposedly built to support.

One Australian company stands out in particular. Without blaming them for their success (they seem to be fairly agile in their internal organization), the creators of Jira should at least have mixed feelings when they see job postings describing an agile practitioner like a Scrum Master as someone whose main job is configuring projects in the digital toolchain or enforcing that every developer regularly updates their ticket status.

It seems that processes and tools have become stronger, not weaker since the manifesto was written. This is not to say that the part of individuals and interactions did not make any progress. It has. In many places communication on more or less equal levels between devs, non-devs, management – the whole idea of cross-functionality has taken hold successfully. Still the tools – and the processes that come with them – are too tempting. Agilists falling for this temptation are in danger of becoming tool monkeys in the short run … and obsolete and unemployed in the long run.

What does this say about the relevance of the manifesto in this regard? I think the answer is easy. Everyone who takes the idea of agile seriously should of course use all kinds of tools – the digital and the analog – but do so with a grain of skepticism.

First understand what is needed to get things done in a way that those who are involved in doing it can agree on. Only then define (if necessary) initial processes, standards, templates etc. Keep these processes as simple and lightweight as possible. Use tools only as elements in a changeable, lean process that is built on interactions between individuals and doesn’t try to replace them.

The important thing here is: tools and processes are great for a team that wants to build stuff quickly and with high quality. There are enough cases where we would be stupid not to use them. But always allow the people who work with them to have a maximum degree of freedom in choosing, setting up – and changing (!) – everything about them. This also goes for “good” or “best” practices including those originating from the agile bubble (XP, pair programming, code reviews, etc.). The manifesto can still teach us something here.

“Working software

… over comprehensive documentation. We already discussed the “software” part. Today instead of “working software” one would say something more general like “working product”, “realized value” or even “feedback from reality”. The bottom line is: produce stuff that works (for you). Which means: that is ready to be shipped, to be closed, concluded, used as stepping stone for the next step … or simply: something that is “done” according to your definition! Some would say that this point – getting to done, ideally delivering done increments to an end customer, is the most important thing about agile. And they have a point. Agile without the fanatical drive to “get to done” is a rather lame exercise and falls short of its potential.

The documentation part has has been a thing in the earlier days of software development. Documentation requirements are of course still inevtiable in highly regulated areas such as pharmaceuticals, healthcare, finance, domains where there is a legal obligation to be able to trace even small changes back to their origin for accountability. On the other hand, one may say that e.g. in web or app development the age of the baroque documentation is over. Not least because documentation can be now automated to a large degree – but also because the value of agility and speed over diligent tracking, tracing and blaming has become more or less obvious. Documentation can now also be built into an agile working mode due to a large number of proven practices from user stories to behavior-driven development (document functionality as code) that make it less of a hassle.

Therefore, this value statement is still very relevant if you abstract from “software” to something more general, interpret “working” according to context and take into account what the options and requirements of documentation are in your specific domain.

The right side of the comparison could be extended to many other domains apart from documentation that add activities without adding value. The message of the Manifesto is: focus on the outcome over things that are not laser-focused on producing it! Getting to done is what defines agile as the core of its value proposition.

Customer collaboration

… over contract negotiation. The statement starts with an elusive entity: the customer. It took many man/woman years of project work and even more books and articles to get from this simple statement to the point where we are now where we can distinguish between e.g.:

  • Customer vs user
  • Internal customer vs end customer
  • Direct vs indirect customers and stakeholders

In short, agile had an impact here. Now you rarely find a company that does not claim to be “customer centric”. However, interpreting the manifesto within its context, it is clear that it refers to a more narrow definition of “customer”. This customer is someone who has a contractual relationship to developers or to a dev team, i.e. not so much an end user but closer to what we would call a “sponsor” or “principal” – in terms of Scrum not so different from the role of a Product Owner.

Reading between the lines there is a strange disconnect between (unmentioned) agile team and “customer” underlying the statement. You think of a setting where a team is hired by someone to build software based on a contract, apparently (on the right side) with a fixed scope and budget.

The idea of the original agilists was to get away from negotiating price and scope upfront to a more ongoing, flexible and also trust-based way of collaboration. However, the overall framing was one of an external contractor being hired to deliver something for a client.

While still relevant in some cases (outsourcing, offshore, nearshore), agile has moved on far beyond these kind of settings. Now agile teams work with all the other types of customers listed above and there is not always a contractual basis in the more narrow sense.

What remains is: don’t fix requirements too tightly up-front. Leave decisions open for the time of development. And during development collaborate based on trust towards a common vision rather than enforcing pre-defined (in the worst case contractually determined) restrictions. These are still things to take away for today whenever there is someone who has a requirement working with someone else or a group of people that build and deliver it.

Responding to change

… over following a plan. Here we go. This is what most consultants or consulting service salespeople of the VUCA (recently, BANI4) variety are offering agile for as a remedy to their hyper-nervous clients. Everything always changes, the world out there is dangerous, so we have to be prepared for the worst and therefore dump all kinds of predictions and plans in favor of being totally flexible, adaptive, responsive to change. VUCA VUCA eh eh! Of course agile can cover VUCA and it is not just marketing fad. At least it doesn’t have to be.

Agile as a metaphor and in terms of its original inspiration refers to being flexible, adaptive, open to change. Thinking e.g. of an agile dog – its agility lies in changing direction quickly, reacting to things that are thrown at it randomly and without warning. For today’s agile, this gymnastic metaphor may now appear a bit overstretched.

Take as an example Scrum as the most popular agile framework. A team that follows the Scrum guide has to do a LOT of planning and plan-following. Every day the Scrum team makes a plan for the day in their daily Scrum meeting. Every few weeks (depending on Sprint length) they explicitly plan a Sprint complete with Sprint goal and Sprint backlog. Additionally they may add more meta-layers of planning such as (if they are part of a SAFe Release Train) PI Plannings for the next few months, stage / cycle plannings, or release / roadmap plannings. Some have criticized this as way too much planning just in terms of time spent on it – and of course, if you make a plan you usually want to follow it. Now the proponent of Scrum will say “Nooot quite, because the way planning happens in Scrum leaves many things open by design. The Sprint plan is continuously adapted towards the Sprint goal, daily plans are mainly daily objectives, longer term planning happens only on high / Epic level … etc.” – Fair enough. Still, there is habit, human psychology, maybe human weakness, that makes people treat even the ideally most flexible, lightweight plans as something that they try to follow closely.

Is this what the Agile Manifesto intended? Surely not. They wanted to have an approach to planning that gives precedence to change not only in times of over-dramatized VUCA but as a general strategy for all circumstances. Planning is a thing that on the one hand we as humans are notoriously bad at – messing it up all the time seeing our plans crushed by reality, and on the other hand, we cannot completely go without. As a wise man said: “If it hurts, do it more often”. This is also true of good, agile planning. But do it in an intelligent way, i.e. without falling in love too much with in the plan you created and don’t believe will can get anywhere without a plan.

The Agile Manifesto is still very relevant in stressing the importance of an approach to planning that is realistic, flexible, open to change, and acknowledges uncertainty.

Conclusion and take-aways. tl;dr

Where is the Agile Manifesto outdated, where should it be amended, where does it stand as a timeless monument of eternal truth?

Where the Agile Manifesto is not as fresh as it was

  • The restriction to software. Agile is now a much broader and cross-domain movement.
  • Criticism of up-front specifications, detailed documentation etc. Also here the manifesto has become a victim to its own success and these practices have become less common.
  • Fighting against the waterfall. Today when all notable project management institutions are competing over who is the most agile or at least “hybrid”, there is not much left to fight against.

Overall it is dated in aspects where it was successful in changing the way things are done. Not too bad for an old manifesto.

Where the Agile Manifesto is still relevant

There are things in the Manifesto that are still relevant and will likely remain so in the future. Call these aspects candidates for becoming “Lindy” in the sense of the “Lindy effect”.5 These are:

  • The pragmatic spirit: The people who do the work are the ones learning from how they do it and improving their ways based on their own experience: Learning by doing. In this sense, agile still marks a radical departure from top-down, prescriptive, theoretical, process-heavy methodologies.
  • The “getting sh*t done” attitude: Agile is about building, about creating, about delivering: early, regularly, with minimum overhead. It goes agains all forms of bureaucracy and unnecessary complication. Agile, left off the leash, remains dangerous to wasteful complication, process over-engineering and slowdown.
  • The interaction and people part: The Agile Manifesto is one of the clearest statements supporting the core idea of “New Work”: that work is about people. Not just as resources, not as legal entities agreeing on contracts but as individuals with dreams and aspirations who engage in social interactions that deserve to be fair, productive and fulfilling.

In conclusion: The agile manifesto is not a teenager any more. But for what it is, it did age well enough. It may retire some day, but for now its ideas will remain here to stay.

PS: In case you are missing a deep dive into the “12 principles behind the agile manifesto” here: I will provide a followup article on those to discuss them all in depth. Stay tuned.

Take care. Get sh*t done, build and run!

  1. For references see https://pragmatic-agility.com/agile/#agile-manifesto ↩︎
  2. See http://programming-motherfucker.com/ ↩︎
  3. For a uniquely different approach to data and AI see our concept of Data-Driven Agility ↩︎
  4. BANI = “brittle, anxious, nonlinear, incomprehensible”, see Facing the Age of Chaos https://medium.com/@cascio/facing-the-age-of-chaos-b00687b1f51d ↩︎
  5. On the Lindy effect (Mandelbrot / Taleb): see https://www.researchgate.net/publication/373245971_The_Lindy_Effect ↩︎