It doesn't matter what you're making, it goes without saying that having a plan for how you're going to make it is crucial. Fundamental to that plan is an understanding of the project management methodology you're going to use to deliver your plan, and which approach is going to work best for you, your organisation and your stakeholders.
Whilst there are countless variations of project methodologies, most companies offering bespoke software development will either work with an Agile or a Waterfall model. Both have their pros and cons, and companies offering either approach will argue their approach is favourable. To help us explore which method works best, we should first understand the differences in the approaches.
Agile (and Agile Derivatives)
Agile methodologies were first used in the early 1990's and have since that time become the project management methodology of choice for many software delivery firms, due in part to the mantra of producing useable applications in the shortest time possible, and in part due to the transparency of the approach.
There are many different flavours of Agile development, however, core to any Agile methodology is the principle of obtaining the best result possible, rather than strict adherence to a predefined plan.
Core principles agreed by The Manifesto for Agile Software Development list the following priorities of Agile:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
To deliver against these principles projects are divided into sprints. A sprint typically lasts between two and four weeks and the focus of each sprint is to deliver or improve on a working feature, starting at the most critical functionality and working down toward the least crucial. Breaking the sprint down into smaller tasks or user stories and ticking these off as they are completed helps to get a genuine picture of the project health. Other artefacts, such as the Vision and definition of 'done' need to be produced and clearly understood by all the team members and the stakeholders; and there must be a common understanding that these definitions may be modified during later sprints.
Taking this approach enables developers to foresee and respond to all major obstacles and keep the project on course as user feedback evolves or business needs develop. This methodology is best applied when there is ambiguity on exactly what the product will need to do, and how it will work or integrate with other business tools.
The waterfall model is defined by strict and linear principles and only progress to the next phase once the entire previous phase has been delivered. This delivery approach is commonly used in manufacturing and construction industries, or on projects which require key milestones to be hit before progress can continue. An example being that you cannot build the walls of a house until the foundations are set. Waterfall methods usually have a number of phases of completion:
- System and software requirements - captured as a product requirements document
- Analysis - delivering models, schema and business rules
- Design - delivering a software architecture
- Coding - delivering the development, proving and integration of software
- Testing - discovery and resolution of defects
- Operations - the installation, migration, support and maintenance of completed systems
Typically a waterfall project schedule will see 20-40% of time invested in the first two phases, 30-40% of the time in coding, and the rest utilised with testing and implementation. The project organisation requires a high degree of structure and a detailed set of procedures and controls that regulate every process within the project. Emphasis is placed on documentation which can help new team members to familiarise themselves with the project by reading the documents. It's widely acknowledged this model is best applied when the requirements and scope are fixed, the product itself is firm and stable and the technology is clearly understood.
Agile vs Waterfall Delivery Success Rates
There have been numerous studies into the effectiveness of Agile vs Waterfall delivery and the results fall fairly unanimously in favour of Agile delivery.
The 2018 Standish Group Chaos Study results concluded that "Agile projects are statistically 2x more likely to succeed and 1/3 less likely to fail than Waterfall projects". Their study found that just 8% of Agile projects were deemed to have failed compared to 21% of Waterfall projects, and that the failure rate was higher for larger projects. Breaking these down into smaller projects increased their likelihood of success and reduced the risk of failure.
This backs up their findings from their 2015 report which indicated that Agile projects were 28% more successful than traditional projects.
Ambysoft's 2013 study measuring the main factors that contribute to a project's success or failure found that Agile out-performed Waterfall on every category:
- Product quality - Agile Outperformed by over 100%
- Stakeholder value - Agile outperformed by 200%
- ROI - Agile outperformed by 500%
- Time/schedule - Agile outperformed by over 500%
They found that Waterfall projects failed 10% more often than Agile, and that they were successful 15% less often.
A recent survey conducted by HP revealed that Agile delivery was now the norm for software development. Researchers asked agile adopters to describe their beliefs about its adoption and consequences. These can be summarised as:
- Agile enhances collaboration between teams that don't usually work together (54% of respondents)
- Agile increases the level of software quality in organisations (52% of respondents)
- Agile results in increased customer satisfaction (49% of respondents)
- Agile shortens time to market (43% of respondents)
- Agile reduces cost of development (42% of respondents)
Whilst both methodologies have their advantages, based on the available evidence Agile delivery works best. Agile guarantees better success rates and the flexibility of the methodology allows for the unknowns that bespoke software projects will contain. This is not to say that the Waterfall methodology is inherently bad, it's just that as businesses have moved on, and business systems have become increasingly complex and integrated, understanding everything that you could possibly need to know at the outset of a project has become prohibitively onerous. Allowing stakeholders to make informed decisions at critical points mitigates many of the risks, and better decisions lead to better delivery.