Project Delivery Methods: Agile versus Waterfall
Before starting any new project, the decision needs to be made as to which delivery method will be used. It is often a subject that results in differing opinions and heated debate. It is vital, however, that the software development work is organized and that the team is working in a unified way. The two principal methodologies for project delivery are agile and waterfall, both of which have been used in software development projects for a long time and come with their own strengths and weaknesses.
The Waterfall Method
This linear approach to project delivery is the more traditional of the two methods. It involves each stage being defined, carried out and finished before the next can begin. The stages within the waterfall form a logical pattern to follow, along the lines of plan, build, test and release. To ensure each phase has been completed there is usually a stage gate where a review takes place. For example, after requirements have been gathered the customer must review and approve them before design can begin.The waterfall method has become less popular in recent years due to its lack of flexibility. That said, the more rigid structure does have its advantages:
The planning and design process is more straightforward as developers and customers agree early on what will be delivered in each development lifecycle.
Clients can find the method reassuring as their expectations are clear and the structured plan gives them a more certain delivery date.
Development costs can be determined up front.
Early planning ensures components are designed to integrate with external systems.
As the full extent of the work is known in advance progress can be measured more easily.
Team members can be involved in other projects, returning to the project when needed according to the active phase.
The customer is not required to be present the whole way through the development process, although status meetings, reviews and approvals will, of course, be included.
Software is designed with a complete understanding of all deliverables. The project is design-focused, and there is less chance of pieces of code being added at later stages when they may not fit well.
However, as mentioned above, many teams have moved away from the waterfall approach. It’s main disadvantages include:
The effectiveness of requirements gathering and documenting can fall short. The details can be difficult to digest to early on, and customers can struggle to visualize what they will end up getting. They also need to be very sure about what they want in the first place.
As the customer doesn’t see the software product until delivery, there is a chance, especially if they didn’t fully visualize what they were getting, that they will be dissatisfied.
Time to release is very long for large and complex projects, and there is always a chance that they will be cancelled before completion if, for example, something else takes place which renders the project obsolete.
Changes aren’t particularly welcome as once testing begins its very expensive to return to the development or design phases.
There is no working software available until late in the project.
Bugs may be written in early code but won’t be found until testing begins, making bug fixing expensive and time-consuming.
Testing can sometimes be less thorough than required to keep on schedule, meaning that bugs go unnoticed until project delivery.
The Agile Method
This iterative, team-based approach to software development focuses on rapid delivery in complete functional components. Instead of time being split into a schedule of activities it is time-boxed into phases known as sprints. Sprints are usually a week long and have a defined list of deliverables which are determined at the start. Priorities are defined by the business value and needs of the customer.The agile method has become a prevalent tool for software development due to its flexible nature and ability to prioritize work. It’s key strengths include:
The customer is highly involved with the project team and gains a strong sense of ownership, on these grounds development is more user-focused.
The customer can see work being delivered and make changes throughout the project’s development. Requirements can emerge as understanding develops.
The time-boxed approach means that new features are frequently delivered, giving more opportunity for testing.
The agile nature of the approach means that features can be removed to ensure a working version is released within a necessary time frame.
The collaborative nature reduces the silos that often exist in software development projects.
The cost of each sprint is predictable allowing clients to prioritise features.
There is an opportunity to continually refine the finished project and make changes.
The approach focuses on the business value of each feature as well as user stories to create business-focused acceptance criteria.
As the project is worked on in manageable units, the team can ensure high-quality development, testing and collaboration.
The agile approach does, of course, also have some disadvantages which need to be considered before adopting the methodology:
It requires a high level of customer involvement which, although being one of its benefits, does require availability and commitment from the customer.
Team members need to be entirely dedicated to the project to deliver the related benefits; it is a very intensive process for both developers and customers.
The overall time of the project can creep as new features are added in, and items are not completed during initial sprints. This also has a knock-on effect on cost.
Team members ideally need to be located in the same working space in order to achieve a collaborative working environment.
It is much less predictable at the outset what will be delivered at the end; this can make it harder to get stakeholder commitment.
How to Choose Between Agile and Waterfall
As we’ve covered, both methodologies have their strengths and weaknesses; the difficulty is deciding which one will best suit your project or indeed if you would be better off using a hybrid approach. It’s worth asking yourself the following questions to give you a steer in the right direction:
How much availability does the customer have?
Is the full scope known up front?
Do you need an ‘all or nothing’ approach or could the business accept a more basic version of the finished product?
Do you have enough resource within the development team for them to focus solely on one project?
Is it a fixed price contract?
In summary, agile and waterfall are very different and choosing between them can be difficult. The waterfall approach may reduce risk in the face of certain constraints, but it often won’t produce the best product for the business. Agile, on the other hand, focuses primarily on product development and large-scale projects are made up of many other elements that need to be factored in. However, each project and their related circumstances needs to be assessed separately, and the common pitfalls of cost, schedule predictability and scope creep reviewed. The best plan is to try to educate customers on the benefits of the agile methodology and the best ways in which software development can be managed and funded to give them the best possible product.