Agile is a King in the IT project world. But the most important question sounds like this: if agile is adequate to manage every IT project? Why are most IT Project Managers using Agile every day, and why in some projects they should use Waterfall? Many questions, big controversies, but in this post, I will try to explain to you why, the waterfall is better in some IT projects, and how to decide which methodology is used in a new project.
When use agile model
Most IT projects are like never-ending stories. The client comes with some ideas and wants from an IT team to build applications that help him achieve his goals. The biggest problem is that he doesn’t know how it should be like. So, the IT team will build version 1.0 of these applications. Then the client will give some feedback, and Developers will build version 1.1, and so on so far.
These journeys probably never end. It’s a high possibility that after some time, the client will demand new functions in the application, or ask to rebuild something that works fine now.
For these kinds of projects Agile model is super useful. It helps to reduce costs and gives clients a chance to have a big impact on the application. In the beginning nor the Client or the IT team don’t know, what they build exactly. But these no problem, because every iteration they will speak each other’s, and they will set the next step.
Why waterfall model fails in these type of projects
We can consider: why the waterfall model is called waterfall? The conclusion is simple: the waterfall model is called waterfall because there is no way to turn back projects managed according to the waterfall methodology. In the waterfall model, each step should be set and well described before we start the project. This causes that we need to know exactly what kind of product we will have at the end of the project. Of course, we can make some changes to the final product, but we aren’t able to start the project if we don’t know the final product.
So, you now know why not waterfall model in most IT projects, and why the waterfall model will fail. But there is also a lot of IT projects, where we exactly know, what how the result should look like. In these kinds of projects, the agile model will fail. There is no sense, to use agile when we know the result. What will we improve in the next iteration? Nothing, so in these kinds of projects waterfall is better than agile.
Waterfall when use
Ok, so now you can be curious, which kind of project is good for the waterfall model. What type of product exactly do I have on my mind when I said that the waterfall model is best?
Let’s look closer at website projects. Most of these projects start with graphics models. When we work on these models, of course, the agile model will be best. Usually, we barely know, how the final model will look like. But this is only the first step in the project. What’s more, each stage in the project could be driven in agile, when the whole project is in waterfall methodology. It’s funny because it doesn’t work in opposite direction.
After we get the graphics model, then there are three next steps: get graphics and text, build website code, and test the website. That’s all. In most cases after these steps, the project ends. We release the product, and never come back to it.
Here waterfall is much better than agile. Of course, if the client wants to improve the webpage, after some time, in this case, agile will be better than waterfall, because we have again situation when we don’t know how the final product should look like.
Where waterfall is better than agile
After you read this post, I think it is obviously for you, but let’s made some summary. If you can define the product very well before the project will start, then waterfall methodology is better, than agile. But, if you don’t know exactly how the final product should look like, then agile methodology will be better.
There is no reason to use agile methodology in every IT project. Sometimes, the old waterfall fits better.