Waterfall v Agile: How Should I Approach My Software Development Project?
Published on under Best Practice
Software development projects are usually approached using one of two methods: waterfall or agile. Both have pros and cons, and each method has its advocates who espouse the value of their chosen approach. In this article, I'll look at both methods to understand the circumstances in which to use either a waterfall or agile approach. I'll answer the question, How should I approach my software development project?
Waterfall Method
The waterfall method has been around since the 1970s and remains in everyday use. It follows a distinct set of steps through the lifecycle of a project. Here is a typical set of waterfall stages:
- Requirements Analysis
- Design
- Implementation
- Testing
- Installation
- Maintenance
Figure 1: Waterfall Method.
The reason this approach is called the waterfall method is that each stage follows on from the previous one after completion, cascading down like a waterfall. Like a waterfall, it flows down and never flows up. Often, this method is seen as 'safer'.
The waterfall method works well for commercial arrangements where contracts are signed, and money paid. However, when working with internal customers, it can be difficult to refuse last-minute changes when the people asking already have the backing of your senior management.
| Pros | Cons |
|---|---|
| Detailed documentation | Perceived slow start |
| Agreed and fully signed off requirements | Fixed requirements difficult to change |
| Can be delivered using developers with a lower skill set | No customer visibility of software until most development work is complete |
| Reduced number of defects through more rigorous design and planning stages | Lacks flexibility making it difficult to change direction quickly |
| Defined start and end point for each stage, allowing progress to be easily measured | Customers can be unclear about their requirements at the beginning of a project |
Agile Method
The agile method refers to an iterative approach to projects. The requirements and solutions evolve through collaboration between the customer and development team. The term emerged in 2001 with the publication of the 'Agile Manifesto'.
If your manager is worried about you making 'perceived' mistakes in front of your customer, this method may not be for you. The agile method creates deliverables early in a project and refines them through an iterative approach involving the customer. However, you may find that some stakeholders view this approach negatively.
During a project to deliver a video homepage for a customer's website, the first iteration we produced was close to the example provided by the digital design agency. The testing of this iteration revealed some errors that needed fixing. These errors were trivial in respect of development effort required to fix them.
My line manager saw this as failure to deliver the customers' expectations and an embarrassment for the team. In my view, our delivery was ninety percent right, and the errors only needed a few days of development effort to fix. This first iteration had allowed us to understand the customer requirements fully and for the customer to communicate their expectations clearly.
After being suitably rebuked, I was left with no doubt of my managers feelings. I wasn't to allow this to happen again. In future, all work would have a fully agreed and signed off-specification before writing a single line of code.
Interestingly, the customer seemed happy with the agile approach as it enabled them to see work in progress and make comments during development.
So does the agile method lead to a faster delivery?
That's debatable. Just because you start coding early doesn't necessarily mean you'll finish sooner. However, it can ensure the final deliverable better meets the customers' needs through the provision of their insights during the project.
| Pros | Cons |
|---|---|
| Quick start, incremental releases with regular customer reviews and feedback | Misinterpreted as unplanned or undisciplined |
| Evolution of customer requirements over time | Needs a high-quality, customer facing development team |
| Provides the ability to respond to change quickly | Needs a high-level of customer commitment to stay involved throughout the project |
| Less rework achieved through continual testing, customer involvement and feedback | Lack of detailed long-term plans |
| Real-time communication with the development team and customer | A lower level of documentation produced |
Conclusion
So which method is best for your project, waterfall or agile?
Neither, there is no right or wrong - better or worse.
The method you use depends on several factors:
- Type of work: is there a clearly defined outcome? Website development is creative and, therefore, lends itself to the agile method. Transactional system development, where there is a clearly defined outcome, is better suited to the waterfall method.
- Type of customer: are they willing to work in an iterative way? Do they have enough time to review and comment on successive iterations?
- View of your manager: does he or she prefer one method over another? How adaptable is he or she?
- View of IT within the organisation: is IT seen as a valued partner or a necessary evil? If the latter is true, then use the waterfall method.
- Internal or external customer: is your customer internal or external? The waterfall method works well with external customers where you can hold them to a signed contract.
It's important as project manager to select the method that best satisfies your customers' needs. The problem comes when there's a difference of opinion. In these cases choose the method that will deliver the best result. Carefully manage anyone who disagrees.
In the end, both methods can deliver your project. It's about managing the expectations of your customer and providing a quality product. After all, once you reach journey's end, nobody worries about how you got there.