The term “agile” is becoming increasingly popular when discussing how software development projects are run. Some may argue (myself amongst them) that it has been used to the point of being abused – a term used more now for marketing purposes and management-speak rather than to actually mean something.

However, it does mean something. A project run using an agile method really does differ from one run using a waterfall method. To my mind it brings many advantages, but it can also raise issues. Chief among these is the issue of price – the answer to the question: “what will it cost me?”

For those of you unfamiliar with agile methods, I’ll give you a quick overview. Feel free to skip ahead if you know the theory. Agile methodologies have been around for many years, with Scrum and DSDM originating back in 1995. In 2001, seventeen of the most experienced and respected people in software engineering circles including Martin Fowler and Kent Beck wrote down twelve principles of agile methods: the “Manifesto for Agile Software Development” (see “http://agilemanifesto.org/”). Out of these twelve principles four values were distilled:

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

These four values summarise all agile methods. To restate them in a different form, agile methods describe how people work together to produce software systems that perform the necessary function, even if that function changes somewhat during the course of development.

Of particular interest to me for the purposes of this article is the third value in that list: “customer collaboration over contract negotiation”. This, for me, is the crux of the differences between waterfall and agile approaches. So often I see a software development project entirely grind to a halt due to its “commercials”.

The first substantial chunk of a waterfall project is the production of the requirements specification. This is a document that attempts to capture in writing everything that the customer wants the final system to do. This document typically acts as an addendum to the contract – the customer is expected to “sign it off”, and once done then it forms the definition of what must be delivered contractually. Any deviation from this specification – any change of mind on the part of the customer – forms the basis of a “change request”.

Even for a small project producing a requirements specification is quite a challenge. Try, for instance, to write down the requirements specification for a simple appliance like an electric coffee maker, and I’ll bet that it will be missing several critical elements. It takes a long time to produce an accurate, unambiguous specification, and it involves a large number of people. Given its contractual status, it normally involves a large number of very expensive people. Sometimes projects fail at this early point due to a lack of remaining funds needed to actually start building the thing!

And, the thing is, the customer typically gains least from the requirements specification. It is almost entirely to the benefit of the supplier. It’s true that the customer may gain a greater insight into the system that they want, but ultimately its primary use (or, at least, the way it is primarily used) is to be able to say at some point later “ah, but you didn’t say you wanted it to do that...”. The sorting of issues between the categories of “fault” and “change request” can become a full-time job in itself, sometimes requiring appreciable input from the very expensive people who put together the requirements specification originally.

Projects run using an agile method don’t try to define a requirements specification upfront. Often an attempt is made to outline the high-level requirements (“features” or “user stories”), but the detail is hammered out just before being built, and the project is broken up into many small build cycles, each one lasting perhaps just a couple of weeks.

This offers great flexibility on the part of the customer. Parts of the system are delivered very frequently, and these can be seen and prodded by the customer. This interaction often prompts ideas – “wouldn’t it be easier if...?” or “that screen could be improved by...” – and these ideas can be fed back into the later build cycles. Ultimately, this leads to the system doing what the customer actually wants rather than doing what the customer thought it wanted (or, more commonly, what the supplier thought the customer thought it wanted). In my experience these are often worlds apart.

However, an agile approach is not for everyone. If a customer wants a fixed price for a fixed functionality then it will have to stick with the inefficiencies of a waterfall approach. It will, however, cost appreciably more – the metric that I typically apply is that building the same system will cost about 20-30% more using a waterfall method as opposed to an agile method. This additional cost is taken up by the production of specifications (requirements, functional, test, etc) and the project management overhead involved.

Whenever I engage with a customer I try to ensure that it receives the best possible value for money. For this reason I will always recommend an agile approach – anything else is simply wasteful. If price is critical then define a time-box that fits into the available budget and then work within that box. The visibility that agile methods offer the customer enables them to track progress very quickly and easily, thus providing early indication of whether the desired functionality can be delivered in the allowed budget. Also, crucially, this visibility provides a basis on which trust can develop between the customer and supplier, and, as we all know, trust is essential in any successful relationship.

Agility at what price? Hard to say – but it will be cheaper than the alternative.