Waterfall vs. Agile Software Development
What's the difference between ‘waterfall' and ‘agile' software development? And why should you care if you're thinking about buying or commissioning some bespoke software?
Waterfall means more detailed upfront specification work and longer stretches of development followed by testing at the end. The good thing about waterfall is that it starts with a lengthy period of requirements capture and design (if it's done properly). The downside is that you can end up with complex documentation and if you've got the requirements wrong (or they change), then you've probably got more development work to redo.
Agile development uses shorter cycles of development - sometimes 3 week ‘sprints' - and relies less on upfront documentation. Instead the developers work from short descriptions of the user requirements called ‘user stories'. Development teams tend to be a bit more cross-functional and the team agrees which stories get implemented at the start of each ‘sprint'. Agile development is more iterative and there's more reviewing of work in progress by clients and end-users simply because development cycles are shorter.
Most software developers today appear to prefer agile. Certainly in the web development world it seems to have become the standard way of working; waterfall is almost regarded as something that's old fashioned and to some extent it's associated (perhaps unfairly) with big expensive IT project failures.
But - there are some points around agile that it's good to be aware of, particularly if you're about to commission some software or manage a software development project for the first time:
- How does agile work on a fixed-price project? SkillsLogic build bespoke software for clients, mostly on a fixed-price basis and our customers understandably want to know from the start what they're getting for their money. We need to estimate and plan at the start based on a broad set of requirements - that's more like waterfall. Think about architects and builders - would you let them use agile to extend your house?
- Requirements analysis and solution design is difficult and takes time. A waterfall approach means that the developers and the client (and their stakeholders) have to invest the time upfront is getting the requirements right. On a lot of projects it's the hardest part of the job - harder than writing the code and harder than project management - and there's an argument that says that doing a bigger block of work upfront encourages everyone to take it seriously and invest the time it requires.
- Scope creep - particularly where there are multiple client stakeholders - can be harder to resist on an ‘agile' development. And waterfall shouldn't be about setting things in stone - you can always set aside some time for reviews and changes in later phases.
- How can you estimate with agile on a fixed-price project? Clients want to know what the software is going to cost and the developers (and the project manager) need to know how much effort will be needed across the development. Again that means doing more upfront - digging into requirements and scheduling jobs into development work packages & phases.
The trick of course as always is to take the best of both worlds. We'll plan upfront, divide development jobs into phases and start with a fairly lengthy period of requirements capture (this obviously depends on the size of the job). But within each phase we tend to work in short cycles and somehow we always manage to leave aside enough time to give the client some opportunities to make late breaking requests for tweaks and changes. And the client can review work in progress as often as they want.
Finally, always ask about the how the requirements analysis gets done and who does it - it's the part of the job that is key to everything but it is the hardest part to do well.
