Blog Post

Software Development - How Do You Choose Between Waterfall and Agile?

Waterfall and agile are two different ways organising and managing software development projects. They tend to be presented as opposites - you either choose one or the other - but in reality it usually makes sense not to be too purist and instead go for a hybrid approach that takes the best from each.

What are the differences between the two approaches? In waterfall:

  1. A lot of planning, requirements capture and solution design happens up front.

  2. More documentation tends to get written - requirements specifications, design documents etc. One of the things said about waterfall is that these documents are often difficult to read, poorly understood by the wider team (including the client) and they often miss or misinterpret key requirements.

  3. There are longer phases of coding followed by testing and then user acceptance.

Agile looks a bit more like this:

  1. The project is organised into short ‘sprints’. A sprint might be three weeks long.

  2. Requirements are presented as ‘user stories’. Short statements that describe what the solution needs to do from a user’s point of view.

  3. The development team has input into what user stories go into a development sprint. Time spent on development is tracked and the team’s ‘velocity’ is taken into account when user stories are selected for the next sprint.

  4. The customer - internal or external - is more involved and gets to see working software at the end of each three week sprint.

Our experience has always been that:

  1. Agile fits a product world better - where there’s an internal development team working on a company product. It makes more sense in a time & materials world (or an employee world) where there is some flexibility around what goes into the final deliverable.

  2. In a fixed price world - where an external client comes with a deadline and a reasonably fixed list of requirements - there often needs to but more upfront focus on requirements analysis and design and a ‘sign off’ some kind of specification before development starts.

  3. Clients struggle with big specifications (they don’t always read them).

  4. Regular but managed client/user input through regular reviews of software during the development is a good thing.

A hybrid approach makes a lot of sense. A project manager on a fixed price project has to manage the budget and deliver what the client wants. The development team wants the right requirements, plenty of client engagement and positive feedback from the client when they see the software. A successful hybrid approach looks something like:

  1. A project plan with development organised into 3 week sprints. The client has input into the plan.

  2. An initial requirements/design sprint that produces a short requirements specification (a table of user stories) and some design mockups. There are several meetings with the client in this part of the project.

  3. Each 3 week coding sprint ends with a client review of the software - reviews of work in progress. The project manager is smart enough to aside some time and budget for small tweaks and changes that come out of client feedback.

  4. One or two testing sprints after the coding is largely complete.

  5. A week or two of client acceptance testing - with more time and budget set aside for some inevitable last minute tweaks.

The pragmatic approach takes the best of both worlds and makes them fit the project - a plan with deliverables, requirements as user stories, plenty of client input and that smart management of the budget to enable flexibility during the development.

Related Posts