Hacker News Reader

Comment by pjmlp | Hacker News Reader

Easy, as somehow discussed on the article.

Beyond the IT department everyone else has very to low incentives to adopt "those crazy ideas from computer guys", they care about deadlines, roadmaps, when marketing campaigns can be organised, with what content, what should be on the contracts with business partners,...

Ever since we got those ideas around 2000, the best outcome if agile is adopted at all, is scrumfall as the article describes.

However I have also seen many companies go back to classical requirements documents, and all related processes, as if agile had never been in the building.

View on HN

I think here is the common misunderstanding:

No one says Agile can't have full blown requirements or the respective documents.

To the contrary, you can't expect your dev to understand what he has to write without giving him a goal he is working on - Agile won't fix that.

Agile just means you build in small steps from what you have and review your steps ASAP, instead of working multiple months based on some detailed documents, derived from other documents, written by some other department months ago, building stuff no one wanted in the first place.

It seems the majority of comments miss what you are saying. We are an Agile Shop. We design things. We have to at scale. We review schema designs, query patterns, error handling strategies, monitoring, etc. Without that review, you get people doing silly things because most devs have less than 5 years experience. Deliver a minimal viable product and use customer feedback to iterate. The goal is to provide customer value as quickly and regularly as possible. This can include all the Excellence in Engineering standards you want.

Yeah, because waterfall with iterations is better than SCRUM/AGILE/WHATEVER.

God intended water to run from the TOP to the BOTTOM. Don't fight gravity.

The best results I have ever seen have been projects that people on the bottom did themselves, because they needed it without the people on the top ever knowing about it.

The worst results I have ever seen have been projects where the people on the bottom stopped caring because the people on the top tried to make them ignore the laws of nature.

Also: God is dead

I'm not really sure what you are arguing. Of course if its a one man job (or a couple) and the .. product or whatever isn't system/safety critical even having a PM is probably overkill and the overhead of "any" process likely just wrecks the output.

But if you need to organize 50+ engineers and actually produce a ... product? That people/agencies/customers expect things of you sure as shit is going to need a definable goal, verifiable output and a somewhat chronological way of achieveing that. Waterfall it is (with reasonable iterations).

Good luck building a chronology for 50+ engineers ahead of time that isn't either horrifically over estimated or instantly wrong.

Waterfall is a pacifier for people who would rather have lies than uncertainty.

Sure time estimation in developmentprojects is hard (impossible?), but thats hard in both waterfall and agile or whatever.

But the often used CER -> PDR -> CDR -> TRR etc. is damn useful.

>Waterfall is a pacifier for people who would rather have lies than uncertainty.

This is the truth. It's painful to see, but some people would prefer to light millions of dollars on fire than admit they don't know.

It's not just about "admitting they don't know." It's about giving up the control that they've used to define their entire professional lives as "managers." Thank you Frederick Winslow Taylor for your outdated ideas.

Reply on news.ycombinator.com