In the recent years, the agile development approaches have been gaining more and more interest and acceptance in software development organisations. This has been a rapid adoption for ideas that were formalised in 2001 with the signature of the Agile Manifesto by a group of software development thinkers.
The basic value of agile approaches is to put back some emphasis on the importance of people collaboration, both developers and customers, in software development projects. This position was taken at a time where the software development world was under the influence of “process-centred” visions that could be exemplified by approaches like the Capability Maturity Model (CMM) or the Rational Unified Process (RUP). These visions provide an enormous amount of valuable material on how to develop software in a well-structured framework. Even if the goal of these approaches was to provide a global framework that has to be adapted to the specific situation of each project, the natural tendency of people was to perform every activity proposed, often for fear of missing something important. The basis of the agile movement is what I would call a “bottom-up” approach. You have to do just the minimal set of activities to produce quality software that satisfies the customer needs. They are also appealing for people who are ready to trade the sometimes false security of planning for the added flexibility of an always changing context.
Agile approaches are not the silver bullet of software development. One could argue for instance that “constant customer collaboration” is not so easy to realise in the real life. Tom Gilb also argues that agile approaches are soft on requirements quantification and many thinks that “you cannot manage what you cannot measure”. Although agile approaches are strong on project status (especially with Scrum), their overall reluctance to spend initial time in analysis and design make them use a “soft” approach to requirements definition and prioritization. Agile ideas could not be considered as new. Prioritising requirements for short iterations could be seen as rebirth of evolutionary development or of the “time boxing” principle of RAD. We will have to see how applications developed using an agile method will evolve during their maintenance phase, even if we cannot say that applications developed using other approaches are necessarily easy to maintain. Finally, agile approaches will have also to face the “mass adoption barrier”. Early adopters of new approaches are often motivated and intelligent people trying to improve their current situation. With this kind of people, it is easier for projects to succeed. It is when the “average” developer starts to use a new approach in the “average” organisation that its value can be fully acknowledged.
It should be recognised that agile approaches have brought a balancing influence to the “process is the king” attitude and that many projects could benefits from this “good enough” software development processes that need a strong customer-developer collaboration. You should also consider that agile development is not a weak approach. Individuals have a strong individual responsibility to produce quality code with a strong emphasis on unit testing and short iterations provide improved visibility on the project status and achievements. You cannot hide failure very long if you deliver every two weeks.
Finally, the conclusion is that there is nothing right or wrong with agile approaches. Each project has its own context: development teams, customer requirements and organisational environment. You have to adopt the process that gives your project the most chances to succeed under the current circumstances, taking valuable tools from every approach.