Related posts
11 thoughts on “Sometimes it’s OK to “Waterfall””
Leave a Reply to Julya van Berkel Cancel reply
Sometimes it’s OK to “Waterfall”
Select your location
English | EN
Agree with your point of view
I will add that rather than completely adopting a Agile way of working (and here I specifically mean using Scrum or similar methodology), we can adopt some agile principles and apply to the traditional waterfall or RUP way of working. So in RUP, we can make the iterations small, involve periodic milestones to get customer involved etc..
Tried that at the Port of Rotterdam (HAMIS project), didn’t work. Don’t take it the easy way. Going agile is difficult but you should stick to it, because it will really pay of.
Definitely pays off when the right effort is applied.
Agreed … a lot of organizations have to adopt “hybrid” agile principles because other departments do not/ can not change. For example, IT has to define the entire project upfront in order to get budget from finance.
Do what works and always improve …
Once the project plan is defined and all things are known, then the scope of the project cannot change.
Ok and since when this ever happened in real life ?
Still i agree with you, some projects could benefit from the waterfall approach. You shouldn’t go Agile just blindly and see it as a “silver bullet” or the sollution to every thing. Mostly what it does is make it clearly where the “hurt”is in the organisation. If you dont want that dont use Agile
Knowing all the facts upfront might have happened once in recorded history … maybe the pyramid builders? 🙂
Agile should be implemented when it makes sense … and implemented seriously as opposed to just doing it because it is cool.
I agree that Agile should be implemented when it makes sense. The choice to transform your organisation to Agile should not be taken lightly and I usually explain why Agile exists by going into the origins of agile based on sequential methodologies like waterfall. Waterfall worked for a long time because we didn’t use it religiously until it was institutionalised by organisations and governmental processes.
Agile, Scrum, Waterfall all suffer from using it as a goal.
That being said. It is an illusion to think you can hold on to “all or the majority of major requirements are known” situation. Therefore I would like to stipulate that Waterfall works best on short projects and not year long projects without adding on procedures and changes processes. Which is what we did in the past.
If you look at what Dave Snowden says based on his Cynefin framework you need to make the decision on what to use not by categorising your situation but you need to figure out if your situation is Simple (standard work, simple, use best practices), Complicated (analytical, use good practice, Waterfall fits well here), Complex (there is no causality to what happens, you work by safely failing, emergent order, Scrum fits well here) or Chaotic (try to stabilize the situation) – see: http://cognitive-edge.com
Thanks for your thought 😉
I agree with not using if for infrastructure projects. Agile is more suited for software and than hardware. I don’t agree with application migrations. In all of my working live (25 years now) I never encountered an application migration that was just a technical migration without any change on functionality. In most of the cases a migration is also used to (radically) change functionality. What is also different is the technology. And one of the assumptions of agile is that every situation is unique and that a developer doesn’t now upfront how to built it, but has to discover it. That’s why agile is certainly recommended for application migration.
Agreed that most application migrations require enhancements/functionality changes, but if the app is a known quantity then a lot of the requirements could be known upfront. So, scoping a waterfall project for that kind of migration could be done.
Agile is great for new development, so it could also be used in an app migration. But if the team must gives estimates up front, waterfall would work as well.
Are there really times when it is OK to do waterfall?
There are a fair number of assumptions here:
1) Anyone actually does a strict waterfall for non-trivial problems. Not true, and even the construction industry is moving away from a waterfall process: http://www.gregerwikstrand.com/agile-waterfall-and-the-construction-industry/
2) Change can be limited. Not true, change is ever accellerating and only short short time frames can be kept stable: http://www.gregerwikstrand.com/change-agile/
3) There are successful companies doing non-agile. Of course you can find some examples, but statistically that is not a significant cluster, at least not in this major study from Brazil: http://www.gregerwikstrand.com/software-development-success/
Hi Greger.
Agreed that Agile is gaining ground in several industries (thankfully!).
I don’t think change can be limited in new software development or even in enhancements, but mature organizations who have been supporting the same processes and systems for a long time can perform work just as efficiently in waterfall. Now, they will have trouble breaking out of their “tried and true” ways, but that’s where experienced Agile professionals can help them.
Found this article recently that I think is interesting … it speaks to how Agile is becoming a bit of a brand and should get back to its roots. A company trying to become agile and adopt the principles could get steered or scared away by some of the issues listed in the article:
http://blog.toolshed.com/2015/05/the-failure-of-agile.html