Examining the Agile Manifesto: A Critical Evaluation

To address the challenges faced by software developers an initial group of 17 methodologists formed the Agile Alliance, in February of 2001. An interesting thing about this group is that they all came from different backgrounds, yet were able to come to an agreement on issues that methodologists typically don’t agree upon. This group of people defined The Manifesto for Agile Software Development, better known as the Agile Manifesto, for encouraging better ways of developing software, and then based on that manifesto formulated a collection of principles which defines the criteria for agile software development processes. The manifesto defines four values and twelve principles which form the foundation of the agile movement.

The Values of the Agile Manifesto

The important thing to understand about the four value statements is that while you should value the concepts on the right hand side you should value the things on the left hand side (presented in bold) even more. A good way to think about the manifesto is that it defines preferences, not alternatives, encouraging a focus on certain areas but not eliminating others. The values of the Agile Manifesto are:

Individuals and interactions over processes and tools. Teams of people build software systems, and to do that they need to work together effectively – including but not limited to programmers, testers, project managers, modelers, and your customers. Who do you think would develop a better system: five software developers and with their own tools working together in a single room or five low-skilled “hamburger flippers” with a well-defined process, the most sophisticated tools available, and the best offices money could buy? If the initiative was reasonably complex my money would be on the software developers, wouldn’t yours? The point is that the most important factors that you need to consider are the people and how they work together because if you don’t get that right the best tools and processes won’t be of any use. Tools and processes are important, don’t get me wrong, it’s just that they’re not as important as working together effectively. Remember the old adage, a fool with a tool is still a fool. As Fred Brooks points out in The Mythical Man Month, this can be difficult for management to accept because they often want to believe that people and time, or men and months, are interchangeable.
Working software over comprehensive documentation. When you ask a user whether they would want a fifty page document describing what you intend to build or the actual software itself, what do you think they’ll pick? My guess is that 99 times out of 100 they’ll choose working software. If that is the case, doesn’t it make more sense to work in such a manner that you produce software quickly and often, giving your users what they prefer? Furthermore, I suspect that users will have a significantly easier time understanding any software that you produce than complex technical diagrams describing its internal workings or describing an abstraction of its usage, don’t you? Documentation has its place, written properly it is a valuable guide for people’s understanding of how and why a system is built and how to work with the system. However, never forget that the primary goal of software development is to create software, not documents – otherwise it would be called documentation development wouldn’t it?
Customer collaboration over contract negotiation. Only your customer can tell you what they want. Yes, they likely do not have the skills to exactly specify the system. They likely won’t get it right the first time either. And, they’ll likely change their minds. Working together with your customers is hard, but that’s the reality of the job. Having a contract with your customers is important, having an understanding of everyone’s rights and responsibilities may form the foundation of that contract, but a contract isn’t a substitute for communication. Successful developers work closely with their customers, they invest the effort to discover what their customers need, and they educate their customers along the way.
Responding to change over following a plan. People change their priorities for a variety of reasons. As work progresses on your system your stakeholder’s understanding of the problem domain and of what you are building changes. The business environment changes. Technology changes over time, although not always for the better. Change is a reality of software development, a reality that your software process must reflect. There is nothing wrong with having a plan, in fact I would be worried about any team that didn’t have one. However, a plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.

The interesting thing about these value statements is there are something that almost everyone will instantly agree to, yet will rarely adhere to in practice:

Senior management will always claim that its employees are the most important aspect of your organization, yet insist they follow ISO-9000 compliant processes and treat their staff as replaceable assets.
Management often refuses to provide sufficient resources to comply to the processes that they insist teams follow.
Everyone will readily agree that the creation of software is the fundamental goal of software development, yet insist on spending months producing documentation describing what the software is and how it is going to be built instead of simply rolling up their sleeves and building it.

You get the idea – people say one thing and do another. This has to stop now. Agile developers do what they say and say what they do.

The Principles of the Agile Manifesto

To help people to gain a better understanding of what agile software development is all about, the members of the Agile Alliance refined the philosophies captured in their manifesto into a collection of twelve principles. These principles are:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. For some reason many people within IT have seem to have forgotten that the goal of software development should be the development of software. Or, perhaps the problem is that they think that they need to define everything up front before they can start building software, whereas an evolutionary approach to development seems to work much better.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Like it or not, requirements will change throughout a software development initiative. Traditional software developers will often adopt change management processes which are designed to prevent/reduce scope creep, but when you think about it these are really change prevention processes, not change management processes. Agilists embrace change and instead follow an agile change management approach which treats requirements as a prioritized stack which is allowed to vary over time.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. Frequent delivery of working software provides stakeholders with concrete feedback, making the current status of your initiative transparent while at the same time providing an opportunity for stakeholders to provide improved direction for the development team.
Business people and developers must work together daily throughout the initiative. Your team is in serious trouble if you don’t have regular access to your stakeholders. Agile developers adopt practices such as on-site customer and active stakeholder participation, and adopt inclusive tools and techniques which enable stakeholders to be actively involved with software development.
Build teams around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Too many organizations have a vision that they can hire hordes of relatively unskilled people, provide them with a CMMI/ISO/…-compliant process description, and that they will successfully develop software. This doesn’t seem to work all that well in practice. Agile teams, on the other hand, realize that you need build teams from people who are willing to work together collaboratively and learn from each other. They have the humility to respect one another and realize that people are a primary success factor in software development.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. For a software development team to succeed its members must communicate and collaborate effectively. There are many ways which people can communicate together, and as you can see face-to-face communication at a shared drawing environment (such as paper or a whiteboard) is the most effective way to do so.
Working software is the primary measure of progress. The primary measure of software development should be the delivery of working software which meets the changing needs of its stakeholders, not some form of “earned value” measure based on the delivery of documentation of the holding of meetings.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Just like you can’t sprint for an entire marathon, you can’t successfully develop software by forcing people to work overtime for months at a time. My experience is that you can only do high-quality, intellectual work for 5-6 hours a day before burning yourself out. Yes, the rest of the day can be filled up with email, meetings, water cooler discussions, and so on, but people’s ability to do “real work” is limited. Yes, you might be able to do high-quality work for 12 hours a day, and do so for a few days straight, but after awhile you become exhausted and all you accomplish is 12 hours of mediocre work a day.
Continuous attention to technical excellence and good design enhances agility. It’s much easier to understand, maintain, and evolve high-quality source code than it is to work with low-quality code. Therefore, agilists know that they need to start with good code, to keep it good via refactoring, and take a test-driven approach so that they know at all times that their software works. We also adopt and follow development guidelines, in particular coding guidelines and sometimes even modeling guidelines.
Simplicity – the art of maximizing the amount of work not done – is essential. Agile developers focus on high value activities, we strive to maximize our stakeholder’s return on investment in IT, and we either cut out or automate the drudge work.
The best architectures, requirements, and designs emerge from self-organizing teams. This is one of the most radical principles of the agile movement, one which I would love to see researched thoroughly by the academic community. The Agile Model Driven Development (AMDD) and test-driven design (TDD) methods are the primary approaches within the agile community for ensure the emergence of effective architectures, requirements, and designs.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Software process improvement (SPI) is a continual effort, and techniques such as retrospectives should be adopted to enable you to improve your approach to software development.

Stop for a moment and think about these principles. Is this the way that your software teams actually work? Is this the way that you think teams should work? Re-read the principles once again. Are they radical and impossible goals as some people would claim, are they meaningless motherhood and apple pie statements, or are they simply common sense? My belief is that these principles form a foundation of common sense upon which you can base successful software development efforts.

Why is the Agile Manifesto Important?

The Agile Manifesto provides a philosophical foundation for effective software development. Contrary to some of the criticisms you may have heard from the traditional community, the fact is that the agile movement is based on some very solid concepts and the methodologies clearly reflect that. Unfortunately the agile community currently suffers from low-end hackers claiming to be agile (e.g. the “we don’t document therefore we’re agile” crowd) and many traditionalists jump on that and say that agile is a bad idea. Yes, the “code-and-fix” approach to development is a bad idea, but code-and-fix isn’t agile regardless of what these clowns claim. You might find my article The Criteria for Determining Whether a Team is Agile of interest because it describes how to determine if a team is truly agile or not.

Going Beyond the Agile Manifesto

I truly believe that the Agile Manifesto is one of the most important things ever written by the software development community. In fact, word for word, it has clearly had the greatest impact of any writing within that space. But, it is time to recognize that it has several clear challenges:

It is out of date. It was written in 2001, over twenty years ago. We’ve learned a few things since then.
It worked. The focus of the manifesto was to address the challenges faced by software teams in the 1990s, not the 2020s. For example, step back and consider the actual text, in particular the principles. For example, deliver working software every few weeks to months? Many teams now deliver working software several times a day. A focus on working software when we should really be talking about consumable solutions instead? In short, the Agile Manifesto had a huge impact on the software industry, so much so that we’ve moved past many of the challenges that it calls out. Minimally it needs to be updated to reflect this.
It’s limited to software development. The manifesto authors were crystal clear about this, and it’s right there in the name. While this is perfectly fine, the reality is that agile concepts are clearly being applied outside of the realm of software development. As a result, much of the advice of the manifesto doesn’t directly apply to non-software teams.
It’s team centric. While this is a very good thing, many of the problems that team face in practice come from outside of thier team. Your team can be working together incredibly well, but you may be getting hampered by HR, procurement, or finance (to name but a few) processes that are misaligned with your way of working (WoW). We also need to consider collaboration between teams.

It is clear that the Agile Manifesto needs an update. Unfortunately, the original authors agreed amongst themselves that they would only update it if all of them agreed to any changes. It is their right to do so and I support their decision even though I do not agree with it. Luckily myself and others were not limited to that decision. Over the years many people have published their own extensions to the Agile Manifesto, and in fact I believe the very first one was the Disciplined Agile Manifesto in 2009, captured in print within the book Disciplined Agile Delivery in 2012. But efforts like that inevitably proved to fall short due to the overwhelming popularity of the original manifesto and in many cases the choice to not address all of the challenges listed above.

In 2019, myself, Mark Lines, Alan Shalloway, and several others decided to step back from the Agile Manifesto. We asked ourselves the question “Given what we know now, almost 20 years later, given that our real scope is enterprise agility, and refusing to be limited by the format of the original manifesto, how would we capture the mindset for enterprise agility?” After a lot of hard work, and getting feedback from many people, we eventually developed The Disciplined Agile (DA) Mindset. It is an enlightening read, I highly suggest that you take the time to investigate it.

Acknowledgements

I’d like to thank Stan James, Lasse Koskela, and Ilja Preuss for their feedback regarding this article.