(Originally posted on October 7th, 2010)

One of the main tenets of the Agile methodologies, exemplified in the Agile manifesto, is “people and communication over process and tools”. Thus, one is led to believe that Agility is not a process, but some kind of overarching, magical recipe that has the power, by itself, to guarantee success.

Some who subscribe to this extreme view will then attribute failure to an incorrect, or incomplete, implementation of Agility - a situation sometimes referred to as “Scrum Butt” (which comes from “we are doing Scrum, but…”).

First, I would argue, quite the contrary, Agility is fundamentally a process - one that is markedly different than Waterfall, and one that emphasizes people and communication - yet, nevertheless, a process. The dictionary definition of a process is “a series of actions or operations conducing to an end”. Clearly, in implementing a type of Agility such as Scrum, one imposes a set of rules, such as daily stand-up meetings and regular iteration meetings, which must be followed. Even though people are involved, we have prescribed a process.

Secondly, I would argue that the Agile process is by not a sure way to success. A methodology such as Scrum contains no discussion of good software engineering practices, yet these are arguably fundamental to the delivery of a good implementation. XP Programming provides these, while being less comprehensive on the process aspects.

Similarly, if the team members do not have the adequate technical skills, and if they are unable to acquire them, the execution is compromised. Yet another area concerns the external constraints imposed on the technical team - if the project timeline negotiated by the business side is unrealistic, no matter how high the quality of people, process and engineering, the project will be destined to fail.

We can see therefore that Agile is not a holy grail of software development. Successful companies such as Google have been able to deliver quality software without relying on a religious mantra, but by being able to combine the best of each area and to see the big picture. Failure of any of the essential components (people, business context, technology, process) can compromise the entire project. It is therefore no wonder that the failure rate is so high in software - since there are so many different types of pitfalls to avoid.