The question which methodology is better: agile or waterfall – is as old as the methodologies themselves. And it doesn’t look like the discussion is coming to its end. We decided to explain all pros and cons of them once and forever. So meet in the left corner – Agile Methodology with its most popular type SCRUM and in the right corner – Waterfall! Let’s see who wins this time!
OK, why people fight about methodologies?
Before we begin out battle of the century, let’s answer a question you probably have on your mind: why there’s so much fuss around it? Choosing Methodology is closely connected with choosing a pricing model, so it influences the final cost as well.
Less than 20 years ago Waterfall was the dominant methodology used for software development. But not everybody was happy about it (we will get back to reasons why a bit later). So in 2001 Agile Manifesto was proclaimed, which gave the birth to all modern Agile methodologies. So as you see, Agile isn’t a methodology itself, it is a code a bunch methodologies are based, but for the matters of convenience let’s pretend you don’t know that 😉
Keeping in mind that Agile was created as opposition to Waterfall, it’s not hard to guess why there are never-ending discussions about them. But let’s get down to details and have a closer look at both camps.
Waterfall methodology Pros and Cons
Development via Waterfall methodology first and foremost means that the whole development process is strictly phased.
- First, there Phase 0, at which business analysis is done, scope is drawn and specification is created for the whole project.
- Only after Phase 0 is completed, estimates are given and the agreement featuring the deadline and final cost is signed
- Next development is done
- Only after the whole project is developed, it is demonstrated to the client
- In case there are any change requests, they are logged and charged separately
Looks pretty smooth, doesn’t it? In reality it is not so pink-coloured. It’s a common thing, when during development some business logic conflicts appear or situation at market changes. Or simply the way the system looks like and works in reality doesn’t look as good as you imagined in your head. This is especially a big problem with big projects that take a year or even more. It is impossible to foresee all the minor changes and details, which eventually turns into endless stream of change requests and plenty work is redone. Besides, this adds a lot of stress and pressure on all participants of development process from product owner to developers. Since each mistake costs a lot.
On the bright side of Waterfall is that it tells you when exactly the product will be delivered and how much it costs, which is probably the only thing you really want to know about the whole development process. But you should keep in mind that every change requests adds chaos to this structure, so if you choose Waterfall methodology, you should avoid them as much as you can.
Let’s have a look at the grid with all major pros and cons of Waterfall organized.
Agile methodology Pros and Cons
Agile methodology is a fancy and light-hearted way of software development. One of its main aims was to make the development process fun and easy and remove pressure Waterfall is known for. Here’s how it works for Agile on example of SCRUM:
- There’s little Phase 0 at which vision and general scope is determined. Understanding of how the final product should look like is required, but it is very vague and might change during development. AT this stage tickets for the sprint or two created. Sprint is usually 2 weeks.
- Planning session for the sprint defines what would be developed during the next 2 weeks, which means that only part of tickets are estimated.
- Product is reviewed each sprint, so that the changes can be introduced.
- While developers are working on the sprint, requirements for the next one are prepared.
- There can be endless amount of sprints. The product owner defines himself, when it is time to deliver the project.
Among the evident advantages of Agile is the ability to start development quickly, little pressure and of course ability to change requirements and vision of the product with little effort and money loss.
On the negative side, you can never tell how much the final product would cost and when it is ready. This happens not because providing estimates and following them is a lot of pressure, but since the scope is vague and can change any moment, so there’s not much to estimate basically.
Have another look at Agile pros and cons.
What should I use?
Choosing methodology first and foremost depends on the size of the project and how well you understand what you need. For small projects that are easy to estimate waterfall will be a perfect choice. But for medium and big ones the margin of error increases, which makes Agile a better choice.
And some more good news for you: in fact, it’s not always you really have to choose between these two variants. You always have an option of hybrid methodology, which takes best of the ones mentioned above. There are no standards on it, it is basically mixing techniques and seeing what works best for you.
No, you are ready fight on what is the best methodology in either camps. Good luck with that!
Questions? Comments? Let’s talk about them in the comments section below.
2 Comments
I am very sorry to see how shallow this comparison is. When you cited Scrum, you don’t even talk about dailies, burn down charts and retrospectives. You don’t say nothing about the product backlog, like there would be no planning whatsoever. You say Scrum has little predicability on the final product, but in fact Waterfall does this. Iin Agile teams, this view of the product is constructed in the process of development, and in fact can provide a better predicability of the final product. Also it allow us to change this view at any time, as well as to keep this view aligned with market and strategies movements. There are several other ways that Waterfall differs from Scrum that you don’t mention. The main difference is that in Waterfall we are thinking about a project, that starts and ends at a given time. In Scrum, we are thinking about product, that is being continuously developed and evolving, thus maximizing innovation.
Thank you for your additions. Thay really make sense!