Let’s talk about the Agile Manifesto, the most popular description of the values that drive Agile software development.

The Agile Manifesto was written in early 2001. It’s a short statement that describes the values behind Agile. A group of seventeen very opinionated experts specializing in XP, Scrum, DSDM, and several other frameworks got together for a weekend working session at a beautiful ski lodge. While they didn’t agree on much, they did come to agreement on this manifesto.

It describes the fundamental values upon which the principles and practices of Agile rest. If you are effectively delivering software in total harmony with these values and the principles, you are living the Agile philosophy.

So let’s break down and examine this manifesto. It starts with:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

The signatories are saying that these values are empirically derived. They’ve been developing software and helping others for a long time, and based on an honest reflection of that experience, they are now sharing the fundamental values that drive their work.

Individuals and interactions over processes and tools

This is probably the number one reason why Agile transformations struggle. Yes, there are processes and tools included with most Agile frameworks. However, these processes and tools are designed for an Agile structure and culture – the behavior and organization of these individuals and the quality of their interactions with one another. For instance, the story pointing give teams valuable information about how much work they can realistically complete in a sprint. However, if story points are weaponized by a product owner or stakeholders who manipulate them to pressure the team to work at an unsustainable pace, the issue isn’t the process but rather the culture. Similarly, vertically-sliced user-focused stories work great on cross-functional teams who have mastery and autonomy over their work, but they don’t help much if the teams are organized into technology-oriented silos that prevent them from completing features end-to-end for their users. In both these examples, the process tools will feel useless and even counterproductive from the team’s perspective.

Working software over comprehensive documentation

There’s a few different types of documentation (e.g., internal developer documentation, project requirements documentation, customer-facing documentation), but I think this applies to all of them. Yes, documentation is useful. Another developer should be able to look at your code and understand what’s going on. I should be able to easily understand your API, internal or external. Yes, we should agree on what works to be done. And of course users sometimes need an instruction manual. But no amount of internal commenting makes up for poorly implemented code. It’s easy to get trapped into believe that writing a project requirements document is a sign of progress, but customers don’t pay for PRDs, they pay for software. And the only thing better than well-documented software is intuitive software that works so well, it doesn’t need much documentation.

Customer collaboration over contract negotiation

Contracts are a powerful tool: they specifically describe an agreement between two or more parties so they have shared understanding of the scope of work to be done and legal recourse if things don’t go as planned. They’re slow to create—specifying terms in this kind of detail takes a long time—and once signed are rarely referred to. Project requirements documents aren’t all that much different. While it is essential to have contracts in place to support the working relationship, attempting to use such a heavy tool instead of transparent and flexible face-to-face collaboration compromises results.

Responding to change over following a plan

Tim Hartford once said: “No plan survives first contact with the enemy. What matters is how quickly the leader is able to adapt.” Put another way, it is very difficult to create a plan that will not need adaptation, and often the costs of attempting to do so far outweigh the costs of adapting. Agile frameworks are empirical, which means that they highly value knowledge derived from observation and experience. Yes, we can often come up with forecasts at the beginning of a project, but once we’ve started the work we will gain a far better understanding of the work. Perhaps the user experience that tested so well in the lab doesn’t work in real-world scenarios, or there is a performance issue that nobody reasonably expected. Even if we could have planned for this, it would have taken at least as long and there would have been other unplanned issues to deal with.

That is, while there is value in the items on the right, we value the items on the left more.

The authors of the Agile Manifesto were reasonable: they understood that there were times for focusing on processes and tools, writing comprehensive documentation, engaging in contract negotiation, and even rigidly following a plan. Our occasional need for these activities won’t go away, even in a truly Agile environment. When we engage in them, we want to be mindful of why. There may be a somewhat more difficult but far more valuable course of action.

Keep these values and the Agile principles in mind as you inspect and adapt how your team works together. Good luck and have fun!