Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We always end up with waterfall

amazingcto.com

Post reply on HN
Print view View original

91–100 of 144 posts

Re: We always end up with waterfall

#91

Post by spinningarrow »

leokennis wrote: post #57
spinningarrow wrote: post #46

Earlier quoted context omitted.

> scrum is too much Surely scrum is too little? Most lowercase-a agile people consider it more of a stepping stone into agile.

Just out of curiosity, are there any non-startup non-tiny companies whose core business is self built software (or a service that runs on said software) that _actually_ and _in practice_ follow the agile manifesto?

I'd say yes - I knew of several in the Germany (Berlin/Hamburg) area a few years ago. In my experience, actually doing agile works better in places with less middle management (just a theory).

Re: We always end up with waterfall

#92

Post by oblio »

potatohead00 wrote: post #76
solatic wrote: post #63

At its core, the true underlying problem is that you can't actually fully control another person's output while still holding onto any genuine agility. The design is going to leave out some Product features, the code is going to diverge slightly from the design, QA will find some things the code didn't account for, DevOps, Security, and Legal will each chime in with other things that weren't considered. If the organi…

... and leave ops/ devops / are team to pick up the pieces (or put the pieces together) because now your too busy to iterate because your shipping another new thing?

The standard fix for this is to put the devs on call.

Recurring operational issues get fixed mighty quickly when J. Dev has to wake up a few times at 02:00 on Saturday.

Heck, design and architectural issues suddenly get a lot of scrutiny at the whiteboard phase and people decide they don't really need Kafka or Kubernetes or Mesos or GenAI anymore.

Re: We always end up with waterfall

#94

Post by oblio »

cushychicken wrote: post #72
smugglerFlynn wrote: post #70

Earlier quoted context omitted.

You can iterate on compliance _implementation_ if you keep some tollgate that guarantees all compliance business requirements are eventually met. In my opinion this is not the same as waterfall, and leaves room for experiments and iterative learning. The (very) tricky part, in my experience, is to have these requirements captured in implementation-agnostic way. Even strict accounting reqs require huge amount of work…

The PCI Compliance audit commission would surely have some thoughts about this philosophy.

You can just section off the bits that need to be PCI compliant.

It would be a good architectural decision, actually.

Re: We always end up with waterfall

#95

Post by marcosdumay »

baz00 wrote: post #81

No we don't. Waterfall is probably the only way of managing large quantities of differently skilled people on a software project and actually getting somewhere though. True agile is for very small teams of highly competent people only, which are rare. There are some corrupt organisations out there selling process models which tell you you're getting the latter but actually sell you waterfall again with bits renamed.…

Waterfall always fails, on every kind of project management.

It's a very recent invention, from the late 20th century, and mostly only "used" in theoretical works until a ridiculous small number of decades ago. It actually being used on practice is very likely the main reason why large projects cost so much nowadays.

It is really not "the only way of managing large number of skilled people".

Re: We always end up with waterfall

#96

Post by Ozzie_osman »

Every project needs some time where you decide what to build, and some time where you build it. The idea of agile and other methods wasn't to eliminate that because you can't. The idea was to reduce the chunk size for each batch (ie flesh out a part of the feature instead of the full product), reduce the detail needed in each chunk, and hence create faster cycle times and more room for feedbaxk, which increases learning, improves speed, introduces autonomy, and decreases risk.

"Waterfall" in the broader sense is inevitable. What we moved away from was "let's spend 6 months writing up a 300 page specifications doc for this new Operating System that will be handed off to 100 engs" to "a PM and designer can mockup this feature in a few days with some input from the person who will implement it, then the person who will implement it will build it with input from them along the way".

Re: We always end up with waterfall

#97

Post by abwizz »

alphager wrote: post #80
CuriousSkeptic wrote: post #66

Earlier quoted context omitted.

This is the kind if project where agile can truly shine. “Hey, customer, looks like we burnt through half your budget and it doesn’t look like we’ll be able to complete the full spec on what remains… I could ask you to increase the budget, but I think I have a better suggestion. You tell me which feature is most important to get in and well focus on that exclusively, and iterate on that until you're either happy with…

Look, I paid you your asking price for the /full/ spec; now you're telling me you will only deliver it partially and have the gall to say I get to decide how much money on top I pay you after the deadline for the full spec has passed? Why on earth would I accept this?

Look, we already catered to your "corrections" of the full spec here, here, there and then. surely this is work on our side that comes on top of the work we agreed upon. thing is, we already built the x, y and z features that your current solution is lacking, which already saves you top dollar on your business workflows. that's how good we are.

Re: We always end up with waterfall

#98

Post by [deleted] »

docflabby wrote: post #18

I think problem is product managers are very common and probably unavoidable in most organisations. Can't have product owners without actual ownership - without real equity in the product being developed do they really own anything?

[deleted]

Re: We always end up with waterfall

#99

Post by marcosdumay »

alphager wrote: post #80
CuriousSkeptic wrote: post #66

Earlier quoted context omitted.

This is the kind if project where agile can truly shine. “Hey, customer, looks like we burnt through half your budget and it doesn’t look like we’ll be able to complete the full spec on what remains… I could ask you to increase the budget, but I think I have a better suggestion. You tell me which feature is most important to get in and well focus on that exclusively, and iterate on that until you're either happy with…

Look, I paid you your asking price for the /full/ spec; now you're telling me you will only deliver it partially and have the gall to say I get to decide how much money on top I pay you after the deadline for the full spec has passed? Why on earth would I accept this?

Yeah, if the customer insists on waterfall, the customer will get waterfall.

You can choose to accept this or leave the customer to yell at and sue somebody else.

Re: We always end up with waterfall

#100

Post by jghn »

pc86 wrote: post #82
CharlieDigital wrote: post #79

Earlier quoted context omitted.

> eventually met That might work in some fields, but consider life sciences and pharma where some unmet functional/compliance issue could be injurious to the company, a patient, or both. Waterfall-ish workflows are hard to avoid in such cases. We learned to simply do iterations of waterfall and speed up the validation via automation as much as possible.

Even if that's true - I'm not sure it is, particularly in very early R&D phases with no external impacts - all that means is that non-waterfall doesn't work absolutely 100% of the time, which nobody is saying it does. Any time an engineering methodology is discussed, people come out of the woodwork with their specific example of one time where that methodology won't work.

In my experience at pharma there has been an enormous divide between R&D and production for software development. Precisely for the compliance implications. In cases where it hasn't been a perfect black/white differentiation it was always dirty laundry where some subset of people knew they were sitting in a grey area and hoping that compliance officers/auditors wouldn't notice.
Post reply on HN