It’s been 18 years since the members of “The Agile Alliance” wrote this manifesto. Since then, Agile has dominated the software industry’s mindset for how to manage software development. We have abandoned the “Old Way” of trying to fit software into the frameworks developed for other disciplines. We have recognized that change is both a fundamental part of all software development and that embracing change is the only way to create great software. We have reduced our dependence on the heroism of key employees and set reasonable expectations for long-term effort levels.

On the other hand, much has changed since 2001. We now expect that we will develop software with teams that span multiple continents. New technology, like machine learning and open-source frameworks, have changed the nature of software development.

The Agile Manifesto has achieved a reverence equivalent to the tablets that Moses brought down from Sinai. Though we may not feel empowered to question the Ten Commandments, it’s time to question the value statements of the Agile Manifesto. Each of the four value statements contrasts two aspects of software development. In most cases, the items on the left and right aren’t even related. These statements are like saying I value apple pie over sunshine because that sunburn I got last summer was nasty.

The statements devalue the aspect on the right without providing criteria to evaluate how much. They are reactions against the Old Way more than they are a vision for the future. In reality, you can only get the ‘items on the left’ with a good portion of ‘items on the right’.

History moves in extremes. The Old Way needed to end. While moving away from the Old Way, Agile moved too far in the direction of anarchy, so that any attempt to use documentation, planning or processes often meets with the objection: “That’s not Agile!” Let’s look at the value statements with a critical eye.

Individuals and interactions over processes and tools

This statement reacts against the Old Way’s focus on process. The problem with processes in the Old Way was that there were too many unproductive processes and processes that were inappropriately rigid. Processes that required writing specifications that no one would read, or that required following steps that delayed the work needed to solve a problem, sapped productivity and removed creativity from software development.

Not all processes are bad. Common low-level processes standardize mundane tasks so developers don’t have to think about them. They let developers concentrate on solving the problem at hand. Tools like source control systems and processes like continuous integration remove burdens from developers and let them concentrate on writing better code. A code review process or a project status process, like a daily standup meeting, encourage interactions. Good processes improve the results of low-skilled developers’ efforts while enabling high-skilled developers to contribute at peak efficiency.

This value statement has led many to believe that any process is bad. Standardizing common processes is a necessary part of software development. Individuals, if left to themselves, will create a hundred different processes that change every day. We need a development philosophy that encourages common processes, and encourages the development team to periodically review processes to ensure that they continue to promote creativity, productivity and quality.

The left side of this statement, “individuals and interactions”, is diminished by binding it to the right side. People are the engine that drive software development. The statement makes us think of people primarily as executors of processes, but they are much more than that.

Working software over comprehensive documentation

This statement reacts against the Old Way’s mandate to specify everything up front. Written specifications are always incomplete and quickly out of date. I agree that working software is the best specification, but some documentation is necessary, and the statement doesn’t provide criteria to judge how much. Today’s global development puts such a burden on communication that a lot needs to be written to avoid misunderstandings and incomplete communication.

Like the previous statement, the left side is diminished by the right. The statement focuses on software’s role as the canonical documentation of the system rather than on its broad role as the goal of software development. The many aspects of software, such as quality, maintainability and evolvability, are hidden in the word ‘working’.

Customer collaboration over contract negotiation

This statement also reacts against specifying too much up front. Contract negotiation can commit you to things that don’t make sense by the time they arrive. But if you are developing or customizing software for the Department of Defense, you may have no choice but to commit to deliverables in writing.

Customer interaction is critical to creating high-quality software. But collaboration is often inappropriate and sometimes impossible. If you are developing a product that will have a million customers, which ones do you collaborate with? Getting input from customers is essential to good software development, but how you do that depends on the nature of the customers. Collaboration is only one of the ways to achieve that.

Responding to change over following a plan

The final value statement is a reaction to over-constrained projects. The Old Way tried to plan projects without having all the information, and then tried to stick to the plan even as new information became available. It’s like planning a trip from Boston to New York by first planning to go south for 115 miles and then west for 150 miles – it works in theory, but in practice it requires a lot of swimming.

The solution is not to devalue planning, but instead to encourage a different type of planning. No software gets done without a plan. A project without a plan will never be funded. Even a plan based on incomplete information can guide you on the first steps.

Responding to change and new information is the core tenet of Agile. The key to agility is to change the plan when more information is available.