Agile Manifesto – The Truth Behind Those Principles


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

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!