We have 5393 guests and 11 members online
Home > Articles > Columns > Articles > Agile Manifesto – The Truth Behind Those Principles

Agile Manifesto – The Truth Behind Those Principles

E-mail
Written by Dele Sikuade   
Wednesday, 06 July 2011 15:59

truth

The Agile Manifesto lists twelve principles for agile teams to follow. These principles are altruistic and ambitious statements that agile advocates should be proud to follow. But what if those statements were overly ambitious and unachievable, misguided, or just plain wrong?  They did not appear out of thin air and have survived the test of time because they speak of some need that we had or have.  In this third part of my series, I intend to examine the third agile principle to see whether it stands up to close scrutiny, and I shall be asking if it is a principle at all!

Principle #3 – Deliver Frequently
Principle #3 asks us to “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

In my reworking of the first principle, I stated that one of the qualities of truth is that one truth reinforces another. If this is the case, and you state the truth, then you would expect to find that no matter how many ways you try to express a view, you keep coming back to the same principle. My reworded principle #1, based on using only statements that can be regarded as true, is:

“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.”

The result I believe of making a true statement like this, as opposed to one that is only honest, is that saying it again in a different way, as is done by the third principle, is superfluous. Of course, you should deliver working software frequently, as it is the principle based on understanding the gap between what you want and what you get.  Take the words “show them what they are getting as soon as possible” and ask yourself why you would wait any longer. What would you be hoping to achieve? Surprise them with how wide the gap has become?

Is there any need to say any more on this subject? I don’t think so, but I don’t want you to feel short changed. If we restate those superfluous Agile Manifesto “principles” into real principles, then we’re bound to end up with a lot fewer than twelve. This is a good thing because we need principles and not rules. What I can offer as a substitute to agile principle #3 is an insight into how I believe we should define the principles by which we work, and a bit of homespun wisdom that experience tells me is pretty sound.

We should favor an approach that I have borrowed from other scientific disciplines, most notably physics. Physicists have searched for years for what they call the Universal Theory, a model for the theory of everything.  Physics, more than any other subject, is obsessed with the discovery of truth. If truth is self-reinforcing, then it should be possible, no matter how difficult, to arrive at a theory of the universe that explains all other theories. If this Holy Grail is a good enough quest for the likes of Albert Einstein, then it should certainly be good enough for the rest of us.  Since the purpose of a principle is to explain life’s complex processes, nobody could possibly imagine that a valid outcome would be to create twelvesuch explanations and hope that they would somehow hang together in a coherent framework that underpinned everything.

Principles are fundamental and, therefore, simple. Gravity is a principle. Yes, there are smart people who might dispute this. All I have to say to them is “jump, and when you land think about it again.” The thing about gravity is that you know it is true. One could write all sorts of honest equations about gravity, and they could be a load of utter bunkum, but that would not alter the truth of gravity one iota. If you think of how important it is that we understand the truth of gravity, then you will appreciate how important it is that we do not misuse the term “principle.” We design planes and buildings and rockets, and they do what we want them to do because we understand gravity. We understand human principles like “do unto others as you would have them do unto you,” and they guide our morality, regardless of religion, color, race, or creed. Once you start layering honestly held views onto principles, then they no longer hold true, so keep them away and do not distort the original ideal, which is to find a single, simple explanation for complex actions or behavior that we can use to guide us.

I offered you two things in place of a third (artificial) principle and the second of these, which is some homespun wisdom, relates very neatly to the third Agile Manifesto “principle.” My bit of wisdom comes from what I have learned over many years, which is that people like consistency; they like it very much. However, more than consistency, what people want is the quality that is contained in the expression made famous by the Ronseal advertisements: “It does exactly what it says on the tin.” Delivering working software cannot be a goal in itself. Software has a purpose, and it has users, and the users and the developers come together to understand the timing of delivery and in what way the software that will be delivered meets its purpose. Contrary to popular belief, I do not think that people object to software being delivered late. S**t happens, and most of us can deal with it.  What people really object to is software, or the timing of its delivery, not meeting their understanding of what would be delivered. In this respect, the rule that you need to take away is this:

“If you are going to fail to meet any expectation, then fail early and give everybody time to adjust!”

Deliver frequently if you can, but I have to tell you that nobody will be interested in your punctuality if you fail to match the quality that they expect. On the other hand, you can get away with delivering late if what you deliver exceeds or exactly meets their original expectations. If you have to choose between late and quality, choose late.
 

About the Author Dele Sikuade is a technologist, writer, entrepreneur, and chief evangelist for Countersoft. His writing and opinions can be found on the Countersoft blog site, Collectivematters.com and on his personal blog, Gogojaja.com.

Trackback(0)

Comments (0)Add Comment


Write comment

security code
Write the displayed characters


busy
Last Updated on Tuesday, 13 September 2011 15:59
 
Cialis

Agile Marketplace - Announcements and Special Offers

The Business Case for ALM Transformation
Are legacy systems holding your company back?  Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper