Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I started working prior to Agile becoming a thing but wasn't around for the entirety of the 1990s. I have seen both waterfall and agile products fail or succeed. I don't think the process is ever to blame when they failed or deserves much credit when they succeeded.

My take on it is both processes have their strengths and weaknesses and perhaps a product needs to start Agile and slowly morph towards Waterfall as it matures.

Agile is great for the pre-1.0 phase when no one is sure what exactly the market needs yet and you're working on a software product with low cost to acquire customers. If you're iterating over different ideas trying to triangulate what is going to sell, and you don't need to scale yet before you figure out if you can sell it, then Agile has a great role to play. This is kind of risky startup time for sure though.

But when your product has become huge, mature, and you're signing $1M+ annual contracts with enterprise customers and your new features are getting very complex Agile doesn't work as well at that point as the tech debt it creates become more and more punishing as the project size grows, and the complex features become more and more difficult to fit into sprints without causing disasters. If a feature takes 6 months it can be a disaster to force it into 2 week sprints that just build tech debt in the name of being able to demo.

I've been on the current product I work on for about 8 years and have watched it morph from a pre-1.0 Agile product to a $500M+/yr complex product. We've been lucky to have good management and the process has gradually changed as the needs of the product have changed.

My career has mostly been enterprise B2B software... the best process for B2C, B2B, aerospace, military, etc.. is not necessarily going to be the same.

One thing for sure though is Agile has largely become a religion and less so of a pragmatic process as time has gone on.



Fully agree with this despite a much shorter career. Waterfalling a young project still in its exploratory phase leads to wasted work. Forcing agile onto a very mature project leads to tech debt and shoddy work.

A big part of the problem is when people have been indoctrinated into one of the various denominations of the Agile cult and try to force it upon every organization, product, project, or team they encounter. And of course it goes without being said that almost nobody follows “real agile” since in most companies it’s just a way for management to micromanage and randomize the tasks of individual engineers so middle management can look at pretty burn down charts.


What I've found while working in defense is that when your customer issues a statement of work with clear high level requirements then you're going to need waterfall (even if just at a high level).


Yeah, I think this is uncontroversial. If your problem domain generates strict, well-defined requirements, agile has less to offer.

https://www.fastcompany.com/28121/they-write-right-stuff

There might still be some useful agile practices, and you could have the less defined work (eg internal tooling?) be more agile.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: