Agile vs. Waterfall (Part 1 of 5). What is the Waterfall methodology?Digital Project Management
As agile methodologies have started garnering widespread adoption, an ongoing debate has sparked on whether agile really is the best methodology to follow to maximize product development e.g. features, ROI, stability.
After many organizations have started to embrace the agile movement, we are more and more often asked about whether it is always the right approach.
In this 5 part post series I will describe the differences between a sequential e.g. Waterfall and agile e.g. Scrum development methodology and why each have their own merits.
The first part (this one) will concentrate on describing the Waterfall approach. In the following parts I will describe the agile approach and why both methodologies are not mutually exclusive for an organization. I will touch upon project constraints such as cost, time and functionality. Furthermore, I will focus on why agile is not always a silver bullet and why a sequential model like Waterfall might, in some cases, be the much better and more reliable solution. Finally, I will give some pointers on choosing the right approach.
Are you ready to go into the trenches and view it from both sides?
To level the field first of all, agile and Waterfall can be described as two different approaches for managing the project and development lifecycle process. Agile is favored by its supporters as being more flexible, collaborative, embracing change and often suited for smaller projects where a minimum viable product (MVP) is crucial. On the other hand, Waterfall is more controlled and stringent, with progress measured by clearly defined sequential milestones and goals. Both methodologies are proven to both work and fail for different types of projects. So which one to choose?
To simplify things a bit, I will from now on refer to a sequential model as Waterfall and an agile model as Scrum.
First some clarifications about the two types of methodology. Let us dig in!
Waterfall development model
The traditional mindset of developing software is usually what is called the Waterfall model. Using the Waterfall model a project should not move from one phase to the next until the preceding phase is completely fulfilled and perfected. It is not possible to jump back to an earlier concluded phase. This development model is displayed in the figure below. One problem with this approach is that risk is pushed back into the development process and can, if the software is of any significant size, cause problems later in the process. This can lead to increased cost in the project or and may result in project termination (Kruchten, 2003).
For any non-trivial project it is hard to get one phase of a software product's life cycle perfected before moving on to the next phases and learning from them. For example, clients may not be aware of exactly what requirements they want before they see a working prototype and can comment upon it. They may change their requirements constantly, and program designers and implementers may have little control over this. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements that most likely will invalidate a part of the effort if overly large amounts of time have already been invested.
The figure below gives an overview of the typical Waterfall development model.
Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. It may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and that does not account for the newly discovered problem areas.
Unless those who specify requirements and those who design the software system in question are highly knowledgeable of the problem to solve, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase following it.
If you do not actively attack the risks in your project, they will actively attack you (Tom Gilb, 1988).
Feedback from following phases is usually needed to complete preceding phases satisfactorily. It can be difficult to estimate time and cost for each phase of the development process without doing some sort of "proof of concept" in that phase, unless those estimating time and cost are highly experienced with the type of software product in question. It is worth mentioning that, with experience and learning from previous projects, it can be done with high accuracy though!
When thinking about Waterfall it is often seen as a heavy-weight approach to project management with Big Design Up Front (BDUF) that does not have any checkpoints on the way, carried through without taking changing conditions into consideration. This is not necessarily how it must work and it does not mean you cannot assess your progress and change your course along the way. It does not mean you cannot measure where exactly you are or compare that against expectations which were set up front.
Waterfall can be far superior when the customer knows exactly what they want and nothing changes substantially, other than bug fixes. The Waterfall methodology gets a lot of discredit because the majority of customers do not know what they want (which is completely fine, as long as there is someone to guide them).
This is the end of part 1. I hope it was enlightening.
Come back to read part 2: Agile vs. Waterfall. What is an agile methodology?
Photo by The Chef!