Agile Manifesto – The Truth Behind Those Principles

Principle #1 – Our highest priority

Before I deal with the first principle I should declare that I don’t see any of the twelve tenets in the Agile Manifesto as principles at all. A principle is something that can be held up as true and not merely honest. A statement like ‘it is impossible to gauge the worth of an idea until you have seen the initiatives that flow from it’, is true. A statement like ‘we need to collect ideas from our colleagues because ideas are the most valuable currency of our business’, is only honest. The latter statement simply reflects an honestly held view but you only have to point to a foolish idea or one that is impossible to implement to start to have your doubts. So, for the last time, there is nothing wrong with Honesty, it is a very admirable quality in people, I simply find that having read the manifesto I cannot accept a word of it as True.

Principle #1 states that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Okay, so nobody believes that right? You shouldn’t, because although it might be expressed as a principle, it is in fact a rule and as a rule it will be broken recklessly everywhere. I cannot imagine for one second that in the majority of Agile workplaces people are walking about believing that their HIGHEST priority is someone else’s satisfaction. People are far more concerned about their pay checks, their kids, whether they have a seat by the window and thousands of more mundane and human things than customer satisfaction through early delivery of blah, blah, blah.

It is clear that the founding fathers of the Agile Manifesto did not understand the simple difference between Truth and Honesty. You can honestly believe something, but you should not go around trying to persuade others that your honestly held beliefs are true. Truth is something that you will know as soon as you are told it. Gravity is True, regardless of whether an equation that describes it is accurate or not.

If the first principle is not True then how can it have derived so much support from so many smart people over all these years? The answer, I believe, is that it has its basis in truth and so for most people it is true enough. True enough is not good enough for everybody though and if you do not have the experience and knowledge to supplement the words of the manifesto then those words are not as useful as they should be.

Let us unravel how we might express the first principle of the manifesto, not as an aspiration but as something that is fundamentally true. The first thing to say is that one Truth reinforces another and the first Truth that we must rely on is that all of the principles by which we live in the workplace are in some way self-serving. If they were not self-serving then they would not long survive. Therefore, when we read a statement like the first manifesto principle, that defines us as being naturally altruistic for no good reason, we should become immediately suspicious that this is not in fact a principle, it is something else. Okay, it is nice to satisfy the customer, but what if in satisfying the customer you ended up being unprofitable and so ended up bankrupt? It makes no sense for this to be a principle, it doesn’t survive five minutes of scrutiny.

If we forget about describing ourselves as nice, altruistic people and define the ways we should behave from an understanding of what better helps us to survive, we stand a much better chance of being able to state our ideal behaviour as a principle. I believe, though I cannot prove, that the causal basis of the first ‘principle’ is that to date, the final output of all software development is a still-life that needs to work in abstract organizations. Programs do what the programmer coded, not what the user thought. That being the case, not only is the output sometimes imperfect for its pre-defined use, it is impossible to ever definitively correct this anomaly. The reason for this is that software development can only deliver what people ask for and what the developers understood the request to mean, which is sometimes not want the people wanted.

I have had people argue this point with me and it is usually because they have not understood this gap. Let us be clear that it does not necessarily arise because the software developer was wrong in the implementation of the request. It arises because until the consumer sees the output they do not realise what it was they wanted all along. Sometimes, it is only after they see the output that issues with it, or enhancements they feel it needs, come to mind. It is possible that the problem or the enhancement was impossible to envision without the output that was delivered in the first place! What was wanted was never stated! This is why it is impossible to envision a perfect software development environment with producer and consumer in perfect harmony all the time. The gap thus created has costly consequences both financially and in terms of credibility. The software development community, which lives with this problem on a daily basis, has naturally developed a way to bridge the gap as indeed it should.

With this thought behind us, we can say that the first principle should read thus:

“You can only give people what they ask for, not what they want. The solution is to show them what they are getting as soon as possible so that they can help you bridge any gap between the actual and the ideal.”

If you engage the consumer in an Agile environment they are complicit in the production of the product, however imperfect it may be. The Agile methodology fundamentally accepts the delivery of imperfect software. This is why it is such a brilliant methodology, because it is based on what is fundamentally True. If the consumer can be persuaded to accept this then many painful battles need never be fought.

Why do I think it is necessary to expose this founding ‘principle’ in the manifesto as flawed? Why can’t I just accept that they are just words and I can have an interpretation of those words that is different to another man’s? It is because I believe that the flawed wording masks crucial elements critical to the successful working of an Agile environment. With regard to the first of these so-called principles –

if the consumer does not, for whatever reason, engage in the Agile world as a committed participant and believer in the values it espouses, then the Agile methodology doesn’t work as it should.

The Truth is the existence of the gap between ‘asked for’ and ‘wanted’, not in what you can do about it. You can do many different things about the gap, rightly or wrongly, and therefore how you should react is not a principle in itself. Agile is simply one method of sharing the responsibility for what happens when this gap arises. Anybody who says that consumers always get what they want in Agile environments is lying. As an old and trusted mentor used to say to me, s**t happens, it is how you deal with it that defines you.

Having a ScrumMaster and creating time-boxed iterations and burndown charts is an approach to software development and it cannot be proven to be any more or any less efficient than other approaches to building robust software. There are enough successful exponents of this approach however to demonstrate that it can be extremely effective. However, if the consumer is not part of the Agile environment or does not understand the true purpose of the Agile methodology and the way it is rooted as a solution to the real life truth about the gap, then all you have taken are elements of a methodology and not the methodology itself. There is nothing wrong with what you are doing but you are only being honest.