Why Is Agility Important?

Agile development has virtually exploded onto the software development world, bringing with it a shift in the way that software is developed. Agility makes a lot of sense because it addresses some of the common reasons why projects have failed over the years.

Back in 1995, the Standish Group’s CHAOS Report^[4.] (a commonly cited report focusing on reasons for project successes and failures) showed that the primary reason for project failure was “lack of user input.” The same study also found that the top element that dramatically increases the chance of success is “user involvement.” So it isn’t surprising that user involvement (and, in particular, user feedback, as early in the process as possible) is a hugely important driver behind agility.

Another commonly recognized contributor toward project failure is the “big monolithic project” syndrome, where a project doesn’t get to see the light of day for a year or two. Finally, when this monstrosity rolls out of the programmers’ workshop, the customer grows purple-faced and demands to know what this has to do with his original specification. It’s quite likely that what the customer thought he was specifying was completely different from the way in which the programmers interpreted the spec, or the requirements might simply have changed beyond recognition in those 2 years, and somebody forgot to tell the programmers. It sounds absurd, but it happens—a lot.

Agile development addresses these issues: it cuts down the amount of time before the customer sees working software, and it encourages increased communication among everyone involved in the project (the programmers, the analysts, the customer, the users, the managers, the tea lady, and so on). If business customers are concerned about trusting their millions of dollars to your IT consultancy, you need a pretty good story to convince them that you will deliver what they need, when they need it.

In an ailing software industry in which it is still unacceptably common for projects to fail, the most visible (and probably the most often cited) reason for failure is unstable requirements. In other words, requirements that were thought to be “set in stone” are liable to change midproject, causing code to be hacked and the most insidious and time-consuming bugs to creep into the product. Often the requirements change so much, and the code becomes so hacked about as a result, that many of the bugs are not discovered until the software is released. Projects that follow heavyweight (or high-ceremony) methodologies may also suffer as a result, due to the amount of documentation that must be kept up to date (doubling the amount of work to be done), sent back and forth, reviewed, and signed off on to cover each and every change. Such projects face the danger of collapsing beneath their own weight.

Another problem faced by many different project teams is that the design will warp and evolve over the course of a single project. In other words, the design that you began with will likely not be the same as the finished design; rather, it will change as the team’s understanding of the problem improves. The extent of this problem varies from project to project, depending on a number of factors such as how well understood the problem is, whether a similar project has been written before by anyone on the team, the skill level of the people involved, the quality of the design process and supporting environment and, sometimes, simply whether or not there is a prevailing wind to send the project on its way.

Given this situation, it was inevitable that the industry would begin looking for ways to accommodate changing requirements and evolving designs more easily. A number of agile processes have grown out of this need, each taking a slightly different approach. We describe some of these agile processes in the next section.

^[4.]See www.standishgroup.com/press/article.php?id=2.