Hacker News Reader

Comment by affinepplan | Hacker News Reader

this smells very much like selection bias, in that it seems pretty plausible that

* if you have a project that is Very Important To Succeed, a team might be more likely to adopt waterfall

* if you have a project you just want to trial and don't care if it fails, maybe agile practices are more likely

I like to think about it like this. If you are building a skyscraper in Manhattan you need a plan. It has to be engineered. The materials must be specified and ordered long before construction starts. There are engineering practices and building codes that create a measure of safety. There is an order to the construction process. The project plan would likely be called “waterfall”. If you attempted an agile approach of dropping off a team and saying for our first sprint let’s just dig for two weeks, then we’ll plan what’s next is not going to cut it. Agile on the other hand is great for smaller, less complex efforts where the desired outcome is “fluid”. Different methodologies work best for different things.

All I can say is the big waterfall projects I was on pre-agile had excellent planning for the wrong things, and took up most of the time allocated for the project. So we were out of time, the quality and people suffered. Another project was cancelled because we took so long planning, the company lost interest.

    > if you have a project that is Very Important To Succeed, a team might be more likely to adopt waterfall

Yes, but that is directly in contrast with what Agile promises to do, namely helping teams to succeed.

Not if the project succeeds because it was important enough for more resources and time to be allotted.

I don't think that's what a selection bias is. If I have two cars, and electric for getting around locally, and a guzzler for road trips, you wouldn't call it selection bias if I always chose the guzzler for the road trips.

You'd just recognize that they are better for that task.

There is choosing the right tool for the job, and then there is evaluating the tools against each other on the properties specific to the job.

If after making your tool selection you went on to author a study about how gas cars result in more frequent bathroom breaks while driving, without controlling for the length of the trip, you’d be doing what these folks did, and that’s selection bias.

Also, how is success vs failure defined? Whether you implemented what you intended to on time and on budget?

That's a reasonable definition, but it doesn't capture whether the project actually achieved the business goals it set out to achieve. For many projects, it's better to fail quickly than to succeed and then discover afterwards that it wasn't worth doing the project.

There are more direct selection biases in the study: "projects which had clear requirements before starting development were 97% more likely to succeed" because hitting a moving target is more difficult, with all methodologies.

Reply on news.ycombinator.com