The 4 Core Principles of Agile Programming

Author: Joe Winchester, JDJ's Desktop Technologies Editor, is a software developer working on development tools for IBM in Hursley, UK.

One of the things I really enjoy at the moment is the recognition and adoption of agile programming as a fully fledged powerful way to deliver quality software projects. As its figurehead is a group of very talented individuals who have created the agile manifesto http://agilemanifesto.org/. At its core are four simple principles that, when followed and applied to software projects, generally will ensure a great flexibility and hence higher agility.

Leaving aside how great agile projects are, what worries me at the moment is that more and more people seem to be buying into this idea that agile programming is a noun rather than a verb, and that to do it correctly you have to follow a certain process to the letter.

Point 1: the manifesto for agile developemt states that it puts "Individuals and interactions" over process and tools. In other words, you adapt the process and tools to the team and not vice-versa.

A colleague of mine recently attended a lecture on how their company was going to roll out a company wide agile methodology. They'd given it a silly in-house acronym and appointed a team of people to help projects adopt this new methodology. At the lecture attendees were given a 97 page ring bound handout explaining agile programming that, on page 85, warned people to "beware of powerpoint architects". Forget having a black fly in your chardonnay folks, this is like having a herd of dinosaurs squash your PC and replace it with a punch card mailbox.

Point 2: the manifesto for agile development states that it puts: "Working software over comprehensive documentation".

In the same week a friend of mine e-mailed me to complain that at her company they'd decided to become agile and renamed all of their meetings to scrums. Folks, if it smells like a pointless meeting, if it looks like a pointless meeting, if it tastes like a pointless meeting, then it probably is a pointless meeting. Calling it a scrum isn't going to change that. What was even more ironic was that at said meeting my friend, who was the only person there who'd written any code in the last ten years, yet had to suffer watching six colleagues stare at PowerPoint charts of dates and endlessly argue about which documents had to be signed off at which points in the next few months to obtain the right sizing to get the right approval to go ahead with the project that had the right marketing messages, blah blah, and so forth. The thought of actually coding something and showing it to customers to see what they thought and repeating this process to create an iterative feedback loop was clearly beyond their comprehension. Forget having ten thousand spoons when all you need is a fork; it's like having ten thousand planners when all you need is a developer.

Point 3: the manifesto for agile development state that it puts: "Responding to change over following a plan."

Legal departments can be a huge obstacle to agile development. I've heard so many stories of projects that want to reach customers early to get feedback yet find immovable hurdles thrown up by lawyers who insist that documents must be signed by the customer that their legal departments refuse to do so, creating a deadlock that keeps both sets of lawyers happily engaged, yet drives a massive wedge between the developer and their potential future user ,thereby destroying the whole feedback loop that is essential to the "perpetual beta" concept. When pressed most of the arguments given by lawyers, often pseudo lawyers because they don't actually have law degrees, are usually ridiculous and involve extrapolating things ad absurdum; "What if Foo does Boo and Moo sues us and we all get crushed by a falling comet ?", or recounting quondam horror stories, "Remember when Foo messed up and we all got sued and had to save the day and you're just about to do the same, etc...". Unfortunately legal departments hold a huge amount of power at corporations and love nothing more than to remind other groups of just how big and important they are.

Point 4: the manifesto for agile development state that it puts "Customer collaboration over contract negotiation".

If companies refuse to actually change themselves, even if means changing the core and fabric of all that prevents the projects from becoming agile, then they'll just end up about as flexible as an elephant with two left feet. Being agile is not a buzzword; it is not a religion; it is not a methodology; it is about taking a few core principles and applying them to everything related to the entire development process. It is about taking risks, getting customers more involved with the development cycles, and reaping the rewards at the end when higher quality, better functioning, and more thoroughly tested code is delivered.
[source: http://xml.sys-con.com/read/522904_1.htm]