Has everyone forgotten about Waterfall? It’s a classic of IT, and it’s a good methodology that has its advantages and disadvantages, like any other. It once ruled the world of software development when teams were stable for years, if not decades. And now that everything has changed, with teams fluctuating continuously, it has become forgotten and neglected. Let’s look and compare Waterfall and Agile, deciding whether Waterfall still has a place in IT.
One of the reasons Waterfall was overshadowed is the dynamic nature of modern IT teams. In the past, they were stable for many years, which is perfect for Waterfall. Also, there were fewer software development projects in the world in general, fewer programmers and fewer opportunities to use communications for projects while IT specialists weren’t dispersed all over the world and were concentrated in one office, which made the scope of work more manageable. Waterfall worked great in those circumstances.
The general global trend today is that anyone in any country can begin a startup using IT specialists from any country or company, and those specialists can move form project to project all the time. Now people change jobs quickly and freely; they are less tied down by social benefits and pension funds so they move from company to company, or go freelance. So now projects are carried out by teams less experienced in working together because they change all the time; therefore, specialists need to adjust how they work within these teams. In Waterfall, you have to do a project assessment in terms of money and time, and now when what team will work for the project is unclear it is impossible to make the correct predictions based on those criteria.
Agile is more flexible, and allows for less specifics and more uncertainty, with risks managed better. When Waterfall ruled, information wasn’t traveling as fast and the markets didn’t change as fast. Today, depending on the industry, weekly or monthly changes happen, so tweaks and alterations to the development process are inevitable, and the end product can turn out to be absolutely different from what it was planned as. In a year, changes to the industry can be drastic; flexibility becomes paramount, especially with longer projects. Agile is perfect for that.
Agile is best for projects developed for products where change happens all the time. For example, if a social network is planned for guitar players, in two years it may be developed for vocalists, who will be more popular in that time. But obviously not all industries are affected by such uncertainty – some global industries that don’t depend on mass marketing for success are still really stable with no market fluctuations. Examples include such industries as oil and gas, steel, space, etc. In such projects, there is more time to understand what is needed and the changes aren’t global or critical. The project of sending a satellite off to space, for example, will have the same goals in two years than it does now. After all, Waterfall was born in construction and manufacturing, where changes to the initial plans would be catastrophically expensive, if not impossible. Waterfall still works well in those projects, and it should be used more.
Waterfall is also perfect in projects where the initial product vision doesn’t change during the life cycle because these spheres are strictly regulated (by government, for instance). In health, for example, the project of creating databases for medical clinics will most definitely have stable requirements because the industry doesn’t change in essence. In that case, Waterfall fits the mold. But if a medical institution were to develop a mobile app for its clients to look up services and book appointments, Agile would be the path for the developers to take. The nature of the product can therefore affect the choice of methodology.
Because in Waterfall a working model is not available until late in the project, using it is impossible in projects where the client wants a working prototype of the product early in the development either to still gather requirements or to make changes to the initial plan. Also, it is almost impossible to go back and correct something in Waterfall. If a stage has gone wrong, there will be problems in the next stage. Therefore, longer, more complex, object-oriented projects work better using Agile.
The world has changed. Measuring effectiveness of teams, cultivating motivation and responsibility is very important, and Agile works better to meet these new needs. But it is clear that Waterfall is here to stay and will be implemented in a number of projects, where the methodology is perfectly suited for its core philosophy. At the same time, it is predictable that Agile will be used more in environments where business values, product vision and markets change quickly.
As some IT experts like to say, there is a little Waterfall in every Agile.