No, waterfall is not making a comeback

02.07.2019

The honeymoon phase for agile is over. Gone are the days when the process was hailed as the saviour of software delivery.

In recent years, a more considering audience has turned a critical eye to the process and its flaws. Some have even proclaimed that Agile has been failing the companies who choose to adopt it. However, this doesn’t mean that companies still stuck on waterfall can breathe a sigh of relief. In 2019, learning to implement agile properly might just be more important than ever. 

Why waterfall doesn't work
While agile may not be fully suitable for a certain team and company configurations, it stays leagues ahead of waterfall – which cripples long-running projects or projects with vague requirements.

Many agile decriers are suffering nostalgia-induced “waterfall amnesia” – forgetting issues such as high latency between development, delivery and customer feedback. A strict waterfall approach means a solution cannot be adjusted year by year, so by the time a product is finished and delivered, one of the following may have happened:

  • More end-user needs and issues have cropped up that the solution wasn’t created to cover.
  • A change in government regulations related to this product results in the business deciding to get rid of this type of service, rendering completed work useless.
  • The end users might have completely changed the approach they were using to do their job, invalidating your solution.
  • The problem the solution was created for existed a year ago, but no longer does and the solution is no longer relevant.

And of course, the longer the time between deliveries, the bigger the gap between current customers’ needs and what software can actually do.

Good implementation = good agile
Many complaints about agile arise where the process simply wasn’t properly implemented in the first place. Often when the business wants to work applying agile it does not realise how much effort and involvement it needs to keep a project running smoothly.

People think that if they just call a process "Agile" it will immediately bring them value without actually needing to change their approach. But just throwing some requirements at the implementation team and sitting down to wait for great results is where agile “fails”. You need to constantly monitor and participate in the process, providing early feedback, making corrections and adjustments where and when needed. In other words, implementing agile requires agility too.

Another common misconception is that working in an agile environment means things can be changed at a moment’s notice: increasing scope, shortening timelines, adding requirements, increasing team size or rebuilding architecture at the drop of a hat. Agile is not a panacea for poor planning, and in these cases, the project simply cannot keep up with all the changes and stall.

Ultimately, the greatest challenge is to keep the balance between too much and too little involvement.

Agile's small strengths 
With agile, teams have the ability to try new tools for a limited time. In a single sprint, a team can explore and adopt a new tool and then decide if it works or not. If it doesn’t, the team can go back to the proven method or start trialling a new one without too much effort.

At Objective, we’ve found the best support for software developers is to let them decide how to better do their job. The beauty of this freedom means that as long as every participant has a good understanding of the workflow and knows at any point in time what they need to do, agile works. Unlike with a static process such as waterfall, we aren’t forced and limited to existing practices when implementing something new.

I truly believe that it is more important to have a well-defined process rather than one that purely complies with practices, but that no one can understand. So no, waterfall isn’t making a comeback. Keep agile in mind as your macro-framework, and with critical judgement find a micro-solution which works for you.

If you found this piece interesting, feel free to follow Objective for more insights from our team

 


Victor Suvorov, Senior Software Engineer

Read more:
From the author: Victor Suvorov
A similar use case:
The same products: