Whether you’re manufacturing a car, engineering a spacecraft, or building a house, project-management methodologies are the backbone of any plan, and just like the projects in these fields, software development also requires a solid project-management approach.
There are a number of different methodologies in the software-development industry – some are new takes on old methods and others have adapted a relatively new approach. The two most commonly used methods in this field are the Agile and traditional Waterfall models.
Most software companies that follow these two models will argue that their chosen method is superior in respects, so before we answer the question, “Which one is more successful?”, we should look at their main differences.
Agile Methodologies
Born in the early 1990s, agile methodologies share a lot of the same qualities as their Gen-Y peers – bold, youthful, ambitious, flexible, and forever seeking new challenges. This model is fast becoming the project-management method of choice, largely due to its focus on optimizing development time and producing an operational application in the shortest time possible.
There is an ongoing debate within the software-development industry as to what constitutes agile development.
Perhaps the most accurate definition can be found in a document created by 17 development practitioners known as The Manifesto for Agile Software Development:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
As you can see from the points listed above, agile methodologies center on obtaining the best results possible, rather than following a strict, predefined plan.
A common feature of the agile methodologies is sprints – miniature projects within the main project, usually divided up into two- to four-week increments. Each sprint is designed to produce a new or improved working feature and is centered on developing the most essential parts of the application. This gives a sense of progression and allows you to step back and re-evaluate the state of the product with every increment.
This piece-by-piece approach allows developers to foresee and respond to all major obstacles and to set the project on a straighter course of development, for example, because of user feedback or changes in the target market.
Waterfall Model
Traditionally used in the construction and manufacturing industries, the waterfall model has found its way into software-development projects. Unlike the flexible nature of the agile methodologies, the waterfall model is defined by its strict and linear principles. Projects start at the first phase and only progress to the next when everything in the previous phase has been completed.
Agile vs Waterfall: Project Success and Failure Rates
A number of different studies have been conducted to identify the success and failure rates associated with the agile and waterfall methods across a number of areas, and the results are fairly unanimous:
Ambysoft’s 2013 Project Success Rates Survey concluded that the agile method has a 64% success rate, compared to just 49% for the waterfall model.
Ambysoft’s survey analyzed the main factors that contribute to a project’s success or failure and found the following:
The 2015 CHAOS report from the Standish Group also discovered that the agile method produces a higher success rate than the waterfall model:
The Standish Group originally defined the outcomes based on the degree to which the following critical constraints were met: schedule, cost and scope.
In this way:
- Successful project is one that meets the assumed schedule, cost, and scope.
- Challenged project meets two out of three constraints, and schedule, cost or scope is not met.
- Failed project is one that is canceled before it is completed, or is completed but not used.
Statistics clearly show that, considering the degree to which the constraints are met, the agile methodologies consistently deliver more successful projects than the waterfall model. This is seconded by the 2017 study conducted by PWC, which also indicates that agile projects are 28% more successful than traditional projects.
Agile methodologies also lend well to working with distributed development teams – we’ve explored the subject more extensively in one of our previous posts.
The sources above clearly show that the agile methodologies deliver more successful projects than the waterfall model, but what areas of software development contribute to a project’s success of failure? Well, the truth is that there are many, but here are the three main factors:
1. The Software-Development Process
The software-development process is made up of a number of stages. Within the agile and waterfall models, the stages are the usually the same, but involve different approaches:
Waterfall
Waterfall is considered the traditional method. Due to the linear character of the model, each stage of the development process is considered separately, and thus starts and is completed one by one.
In theory, this approach should produce a working application sooner; however, building an application isn’t that simple and straightforward. Obstacles are a dime a dozen in software development, and all it takes is one small, undetected bug in the beginning of the process to bring the whole project crashing down.
Agile
The interconnected development phases in the agile methodologies allow developers and clients to access and test each part of the application sooner and to make decisions on how the rest of the application should progress. This adds huge benefits to both parties, as the end result contains all the design elements, features, and functions necessary for a working application.
2. Application Testing
Quality assurance and testing are just as important to an application’s success as building its codebase. Bugs, performance issues, and security flaws need to be detected and resolved early on and repeatedly throughout the development process to allow the project to advance.
Agile
Testing and QA are constant, ongoing processes of the agile methodologies. Once a new, working piece of the application is built, it is put through a series of tests (e.g. automated unit tests) to identify bugs and other non-compliant parts. Many teams also choose to incorporate Continuous Integration (CI), which involves adding all developer working copies of the software to a shared mainline several times a day. This ensures all new features will seamlessly integrate with the rest of the application, and contributes to the overall quality of the product.
Waterfall
The testing phase in the waterfall model is a completely separate part of the development process, and is usually carried out once the whole application has been built. As this is the first time software testing is conducted, it is not unusual for it to be full of bugs and other major problems. This results in more time spent in the testing phase – or worse, the phase may be attempted half-heartedly (or partially completed) due to the pressure applied by the client to move the project forward into the next development stage.
3. Value delivery
Each methodology comes with some disadvantages and comparing the agile and waterfall methods using project success may no longer cut the mustard in certain situations. On top of that, there is a lot of controversy around the definition of what makes a successful project. For some people a successful project is one that is delivered on time and meets the budget constraints, and for others it may be more about what value it delivers, and how quickly it offers a return on investment. One thing is certain: value delivery is a solid indicator of a project’s success, and also a tangible differentiator of the two development methods.
Agile
Agile is all about adopting an incremental approach to building software – it shifts the focus away from the software and puts it on the business value behind software. Agile makes business sense as it allows you to deliver part of the value sooner – decreasing the risk of complete failure of the project. It allows more time for testing and provides more control over the features being developed.
Because value is delivered in increments, the product is workable at an early stage, whereas when a waterfall project fails (e.g. when the budget runs out or the deadline is not met), it leaves you only with an unusable half-finished product.
There is still a certain level of risk in the agile project development, but at least the development team and client have the proper controls in place to address problems as they appear and make adjustments to the scope and features of the project; thus decrease the probability of building the wrong product.
Waterfall
In waterfall, value delivery comes at the end of the development process. If the project exceeds the agreed budget – which is very likely in the case of IT contracts, there may be no time and money left to deliver the value that was agreed upon with the client.
It is not to say that waterfall is downright bad; it just requires very careful planning and estimations, which, at the early phases of the development process, may simply be impossible for many projects. We know that in software development not everything can be fully planned in advance and problems should be expected along the way. Initial assumptions are very likely to change, or may turn out completely unrealistic.
3. The Client-Developer Relationship
Another key area in developing a successful application is the client and developer relationship. Without a definite plan, the final product can turn out to be different from what was expected in the beginning. That’s not necessarily bad, Furthermore, documentation can be less detailed, which can sometimes make the onboarding process longer for new team members. Not to mention the fact that the time and cost of a project can’t be predicted with perfect accuracy. They are usually specified as a range of values and that may seem more risky for a client.
Agile
Full cooperation, complete transparency, and strong communication are all vital to an application’s future success. The prerequisite of strong collaboration in the agile methodologies encourages the client and developers to work in unison, and provides the client with a greater feeling of engagement and trust.
Waterfall
Waterfall proves useful when constraints of the project are known, and the client has precise, strict requirements for the final product – unlikely to change radically during development. At the same time, predictable timelines in the waterfall method make it easier to create project documentation and report progress to clients.
Conclusion
The above comparison of the success rates of agile and waterfall projects leaves us with one important takeaway: agile is on the rise as it guarantees higher success rates and is more fit for software development projects.
However, there is more than meets the eye. Waterfall is not inherently bad – the inexorable transition to agile was largely dictated by the expectations of modern businesses, the nature of specific industries, and the way projects are approached nowadays.
Some experts claim agile is a way of thinking rather than a bona fide methodology – it emerged because a change was urgently needed in project management. Behind agile there is no rigid theory – it was founded by flesh-and-bones, down-to-earth software practitioners who analysed their experiences and analysed what works, and what doesn’t work in software development projects. Simply put: agile makes sense because it works.
