Waterfall v Agile: How Should I Approach My Software Development Project?
2009
Software development projects are usually approached using one of two methods, Waterfall or Agile. Both have pros and cons and each have their exponents who espouse the value of their chosen approach. In this article, I look at both methods and try to understand which is best and under what circumstances answering the question, "How should I approach my software development project?"
Waterfall Method
The waterfall method has been around since the 1970's and remains in common use. It says you should follow a distinct set of steps through the lifecycle of your project. The structure is usually similar to this:
- Requirements Analysis
- Design
- Implementation
- Testing
- Installation
- Maintenance
The reason it is called the waterfall method is that each stage follows on from the previous one when it has been completed, cascading down like a waterfall. Like a waterfall it flows down and never up. This method is often seen as 'safer.'
The Waterfall method works very well with commercial arrangements where contracts are signed and money is being paid. However, when working for internal customers it's more difficult to be hard nosed about last minute changes when it's people in your own organisation asking who often have backing from senior management.
| Pros | Cons |
|---|---|
| Detailed documentation. | Slow start. |
| Agreed and signed off requirements. | Fixed requirements difficult to change. |
| Can be delivered using developers with a lower skill set. | No customer visibility of software until the development has been completed. |
| Reduced number of defects through thorough upfront design planning. | Lack of flexibility making it difficult to change direction. |
| Defined start and end point for each phase allowing progress to be easily measured. | Customers often unclear about their requirements upfront. |
Agile Method
The Agile method refers to an iterative approach to projects, where requirements and solutions evolve through collaboration between customers and development teams. The term was coined in 2001 when the "Agile Manifesto" was put together.
If your manager is worried about you making mistakes in front of the customer, this method may not be for you. The Agile method means that you create deliverables early and refine them through a number of iterations with the customer. However, you may find that some stakeholders view this negatively.
During a recent project to deliver a video homepage for a customers' website, the first iteration was close to the example provided by the design agency. The testing of this iteration threw up some items that needed attention, most fairly trivial in terms of development effort required to fix them.
My manager saw this as having failed to deliver the customers' requirements and an embarrassment for the team. My view was that our delivery was 90 percent right and the final 10 percent would only take a few days of development effort. This first iteration allowed us to fully understand the customer requirements and for the customer to be clear about their expectations.
After being suitably admonished I was left with no doubt as to my managers feelings. I wasn't to allow this to happen again and all future work should have a fully agreed and signed off specification before a single line of code is written.
Interestingly enough, the customer was happy with the Agile approach as it enabled them to see work in progress and comment on it during development.
So does the Agile method lead to a faster delivery? Well that's debatable. Just because you start coding early doesn't necessarily mean you'll finish sooner. However, it does ensure that the final deliverable meets the customers' needs, primarily because they provide useful input throughout the development phase.
| Pros | Cons |
|---|---|
| Quick start, incremental releases and regular customer reviews and feedback. | Can be misinterpreted as unplanned or undisciplined. |
| Agreed and signed off requirements. | Fixed requirements difficult to change. |
| Evolution of requirements over time. | Needs a high quality, customer facing development team. |
| Ability to respond to change quickly. | Needs a high level of customer involvement. |
| Less rework through continuous testing and customer involvement. | Lack of long-term detailed plans. |
| Real time communication between the development team and customer. | Produces a lower level of documentation. |
Conclusion
So which method is best, Waterfall or Agile?
Neither...
The method you use depends on a number of factors, some of which are:
- Type of work: is there a clearly defined outcome? Website development tends to be fairly 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 regular iterations?
- View of your manager: does he/she favour one method over the other. How adaptable is he/she?
- View of IT within the organisation: is IT seen as a valued partner or a necessary evil? If the latter 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, as opposed to internal customers who can force you into changes by gaining the backing of senior management.
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 and manage anyone who disagrees.
In the end both methods can deliver your project. It's all about managing the expectations of your customer and delivering a quality product. Let's face it, once you reach journey's end, nobody worries how you got there.