If you listen to the buzz in software development circles, you will know that the waterfall software development process is very last year and that Agile is quite the thing. Read on and I will translate:
The waterfall process of software development sees progress as something that flows steadily downwards, like a waterfall. Broadly speaking, any software development project involves the same sequential stages: specification of requirements, design, implementation, testing and maintenance. Each stage must be complete before the development process can move forward.
Agile software development is modular and iterative. Agile is used to describe a number of different methodologies which share common themes set out in the Agile Manifesto of 2001. Under that Manifesto: individuals and interactions are to be preferred to processes and tools; working software is preferred to comprehensive documentation; customer collaboration is preferred to contract negotiation; and, responding to a challenge is better than following a plan. In each instance, there is value in both aspects but there is more value in the former and less value in the latter.
You can see why Agile is popular. Customers get to influence the process and can see demonstrable progress as working software is delivered as the project moves forward. There is less paperwork and less scope for the project to be bogged down by legalese. Developers have more freedom to suggest ideas and discuss options with the customer and are not forced to follow rigid contractual guidelines. Presumably, this means they have more fun.
And you can see the drawbacks to the waterfall process. It is rigidly linear. Making changes during the process is difficult and expensive, a reflection of the fact that, historically, the waterfall process has its roots in the project management systems used in the construction industry – an industry where changing the plan once it has been started is troublesome. The customer must have a clear idea of their requirements at the outset. There is little scope to deal with “wouldn’t it be nice if….”.
But I think that a place remains for the waterfall process.
True, Agile suits big projects where it can be difficult to provide as detailed scope at the outset. In fact, if you provide a full scope and then pass it over to the developer it is more or less inevitable that the situation will have changed by the time the development process is complete and the software risks being out of date even before it is installed. Agile has the flexibility to cope with evolving needs. But this flexibility comes at a cost to the customer who is required to commit a great deal of time and resource in terms of working with the developer throughout the life of the project.
Waterfall, on the other hand, is suitable where the customer knows what they want and can provide a clear specification. The rigidity that is so constricting to big projects probably won’t worry the customer as their requirements are less likely to change. In fact, rigidity brings certainty. The customer knows what they are going to get at the end of the project and knows what the cost will be. I’m always a little suspicious that Agile projects must be difficult to accurately cost upfront. There is no upper limit to the number of iterations that will be involved nor to the number of different approaches or tweaks that can be suggested, tried and rejected. In comparison, the rigidity and predictability of waterfall is comforting.
I also think that waterfall can, without too much trouble, offer at least some of the perceived advantages of Agile. It isn’t difficult to draft a contract to require the developer to deliver functioning modules at stages during the project nor to require the developer to report regularly and in detail.
Agile is certainly a Good Thing and is a Really Good Thing when it comes to big contracts. But waterfall still has a role to play and in some cases will be a better bet than Agile. It isn’t the out-dated dinosaur it is sometimes described as being.