Explaining Agile, Part 3

Continuing my short series of blog posts intended to provide some context for what I'm talking about when I refer to "Agile project delivery"... In the first two parts, I covered the traditional Waterfall style - in contrast to Agile - and then drilled down into one aspect of Agile: the use of automated tests. Now's probably a good time to step back and talk about the Agile framework, since I've neglected to provide that background up to now (proving that I'm making this up as I go along here, folks!)

The Agile Manifesto came into being in early 2001, and it provides four value statements that form the basis of all Agile principles and practices:

"We value:

• individuals and interactions over processes and tools;
• working software over comprehensive documentation;
• customer collaboration over contract negotiation;
• responding to change over following a plan."
  

In each case, the Manifesto explains, the items on the right side of the statement have value, but the items on the left are simply considered more valuable.

When you consider that list in light of how most traditional Waterfall software projects go, you can see some startling results. The most striking, perhaps, is the notion of favouring a responsiveness to change over following a plan. If you allow a plan to change as it's being executed, the argument often goes, how can you ever know how you're doing, when you'll finish or even whether you actually succeeded at the end of it all? After all, the customer will just keep asking for more and more and more!

That train of thought brings in the point about the importance of customer collaboration versus treating the process like an inflexible set of contract terms. In many things in Life, having a contract makes sense, in order to ensure that all parties are treated fairly; when you're trying to innovate and in the process give the customer something that he or she may not even fully understand at the start, though? Not so much! Having the customer involved throughout, and adapting to their feedback and discoveries as you go along, allows for a much greater possibility of them being happy with the results. Implicit in that approach is the use of iterative development, since only in that way can the customer provide meaningful feedback in time for you to react to it.

The emphasis on people and their interactions, rather than relying on pre-defined processes or tools, speaks to several Agile topics, including empowerment, responsibility and adaptability. In software development, at least of the sort that my current company does, a fair amount of creativity is required. Placing your faith in people, though, instead of building up complex structures of rules and mandates within which - the story goes - "nothing can ever go wrong," is a huge paradigm shift. Making that leap is a crucial part of "going Agile," and one that I imagine most organizations struggle mightily with at first (mine certainly has).

Finally, the Manifesto attempts to deal with the historic problem of companies expending great amounts of time and energy to produce verbose, detailed documentation to be delivered alongside buggy software. Is that really what most customers want? Wouldn't they prefer that the features work well and are so intuitive that only the most basic Help screens or manuals are needed? That's certainly the goal of Agile.

From those crucial four statements of value, most of what Agile is, follows.