Exploring trends and developments in project management today

Waterfall v Agile: How Should I Approach My Software Development Project?

Duncan Haughey

Signpost saying who, what, where, why, when and how

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:

  1. Requirements Analysis
  2. Design
  3. Implementation
  4. Testing
  5. Installation
  6. Maintenance

Diagram showing the Waterfall Method

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 and cons of the waterfall method.
Detailed documentationPerceived slow start
Agreed and fully signed off requirementsFixed requirements difficult to change
Can be delivered using developers with a lower skill setNo customer visibility of software until most development work is complete
Reduced number of defects through more rigorous design and planning stagesLacks flexibility making it difficult to change direction quickly
Defined start and end point for each stage, allowing progress to be easily measuredCustomers 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 and cons of the agile method.
Quick start, incremental releases with regular customer reviews and feedbackMisinterpreted as unplanned or undisciplined
Evolution of customer requirements over timeNeeds a high-quality, customer facing development team
Provides the ability to respond to change quicklyNeeds a high-level of customer commitment to stay involved throughout the project
Less rework achieved through continual testing, customer involvement and feedbackLack of detailed long-term plans
Real-time communication with the development team and customerA lower level of documentation produced


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.