When I first started out with Agile software development I went looking for an agile analogue of the “Joel Test.” I wanted some kind of check-list I could run through to ensure that what we were doing included all the “essential” elements of agile development. Although I didn’t realise it at the time, this was because I wasn’t Doing It Right, because I had misunderstood Agile.

The Part I Missed

The Agile Manifesto is surprisingly brief, and the brevity is significant. Right up front we can see that the manifesto is a statement of values:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

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

Note that the manifesto does not say that there is no value in the items on the right. What it does assert though is that the values on the left are given priority over the ones on the right.

Most software engineers are familiar with the need to make trade-offs. It’s one of the things that can make development so difficult. An example of a trade-off is the tension between user-friendliness and security (no, usability is not the same thing as user-friendliness. But I digress…). Generally speaking, the more secure we make a system, the more barriers we place around it, and the less user-friendly it becomes. This is probably what you want in a banking system, but is not so good for your mailing list sign-up page.

The important point in considering such trade-offs is that neither is more important in isolation. The two need to be considered in context and then one explicitly chosen as being more appropriate in that particular situation. We can never truly say “security is always more important than ease of use” because it’s the context, the specific application, that determines importance.

Of course in software development you’re never trading-off just two factors. There can be dozens of considerations that you need to balance. These include robustness, performance (speed), resource utilisation, simplicity, and resilience. Where there is tension between developers on the Right Way to do things, explicitly stating the priority order of these things from the business perspective can help resolve the issue.

But back to the agile values. All values are important (because that’s why we call them “values”), but we often need to prefer one over another. Consider for example the values of honesty and compassion. If a friend gave you a present that you hated, would you choose honesty, and tell them that? Or would you “prioritise” compassion, spare their feelings, and thank them? What if they did it all the time, to everyone? What if it was your partner, and you thought the poor choice reflected their level of care for you?

In any non-trivial project there are considerations, values if you will, that can conflict in this way. In the Agile Manifesto, the authors made this conflict explicit, and stated a preference for certain values over others. And one of those statements places individuals over processes and tools. That’s why there’s no check-list. When you start to become obsessed with the artefacts of agile, you stop being agile.

What I Know Now

The Agile Principles follow directly from its values. For me, the first is the most important:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

(Emphasis added)

Often (not always, but often), conflict within a team, or between teams, is because values are not aligned. The classic example is Development and Operations. Development is all about change — because change is how they create business value. New features, better performance, better customer service. Operations meanwhile is all about stability. That’s how they create business value. That means minimising change. I was once in a meeting with Dave Thomas and the CIO of a company. Dave was there to talk about his experiences introducing Agile to large companies. During the meeting Dave made a comment about change and the CIO said: “Indeed. In fact it’s better to not make any technology changes at all.” Which is not what Dave was saying. But the CIO was filtering through a different list of prioritised values, in an environment where the worst thing ever is to make a change and have it break something.

DevOps is one response to this conflict over values, although I can’t see it helping really if the values question is not addressed up front by the two teams. This can be difficult. I once tried to get a group of managers and researchers to do pair-wise comparisons of values in order to prioritise a list. It didn’t work. They couldn’t see the point, did not accept that there are trade-offs to be made, and so did not want to choose between “Excellent Research” and “Benefit Industry.” Only later, much later, did they start to engage with that trade-off.

Lessons Learned

The “so what” of all this is that Agile is not a methodology. It’s not a process, or a set of tools, or prescribed practices (that’s what “Scrum” is). Agile is a set of values. Making those values explicit is part of the process of achieving genuine management agreement with how the team will work. And if your teams are experiencing conflict internally, or with other teams, look for a possible divergence in the prioritisation of values. Discussing which values are more important in your particular circumstance can go a long way to resolving such conflicts, even if you don’t end up agreeing on the ones that should be preferred.

PS: The Joel Test is perfectly applicable to all development styles, there doesn’t need to be an “agile equivalent.” Go ahead and use it if it will help you make useful software.