3 ms·

Wagile brother. It's a mix between agile and waterfall. Waterfall is great for high level governance (such as specifying high level milestones). Agile is gr

Wagile brother. It's a mix between agile and waterfall. Waterfall is great for high level governance (such as specifying high level milestones). Agile is great for executing on the deliverables. It is jus my experience. You're miles may vary.

randcraw 2y ago
Of course there's a range of transitional states between waterfall and [whatever miracle cure is in vogue today]. Like all historical revisionists, today's techies like to impugn the old and laud the new. ('How could they have been so clueless?') Fact is, long-lived products, esp. from BigCorps, and esp. those in heavily regulated spaces like medicine and transportation always have and always will spend a lot more time and effort on design and process than will ephemeral products and services from startups. My software career started ca. 1990 just as waterfall was evolving into the 'Spiral' iterative software model, which since has been rebadged and remorphed several times into today's 'agile' and 'test-driven' gift from god. However in the real world, makers of every S/W product inevitably must adapt their actual development process to suit the lifecycle needs of their product and customer, in ways that scrum can't serve. Often the best way to reduce technical debt is to increase investment design and testing. And taken to NASA-like limits of fault-tolerance and reliability, that can take you all the way back to waterfall.
minkles 2y ago
We use extreme waterfall. All the disadvantages of agile and waterfall in one process. Nothing gets to production due to meetings so the customers are happy we aren’t fucking anything up.
dehrmann 2y ago
The whole strawman/dichotomy you see with Agile and Waterfall boils down to needing both flexibility and vision for large projects, and each fails at one of these.
kermatt 2y ago
Agilefall.
bee_rider 2y ago
So like a waterfall, but the day to day is connected by little bits of agile? You end up at the bottom of the waterfall, but by taking a bunch of much smaller falls instead? Have you considered calling it Rapids development? You will sell a million books or whatever, just on the name.
- wheelinsupial 2y ago
  > Have you considered calling it Rapids development? A variation of this exists with one more word thrown in for good measure: https://en.wikipedia.org/wiki/Rapid_application_development https://en.wikipedia.org/wiki/Rapid_application_development
freetanga 2y ago
This. Some products are platforms with thousands of functionalities all interlinked in a uniform data model, with similar but specific behavior expected for all modules of the platform.For instance, a Core Banking System, or OMS in Telcos. And since we all get paychecks, it seems to work. Building such an product in agile was often tried and failed in the past decade. You need common data structures and routines that a few thousand developers can all expect to find ready further down the line. Like the Oregon Trail game, you launch all workstreams in different moments and expect them to converge at the finish line. I think “100% waterfall” was ditched in the early 90s, for all the known reasons, with smaller cycles of releases becoming the norm. But still the hard thinking, laying down the key mechanisms of a platform was heavily thought out early on. I think all criticism is a bit unfair, as agile is also an infinite source of cock ups, mediocrity and dead ends just as waterfall. There is a space for each approach, and bottom line, the right people will make all the difference. But that’s also why it’s important to learn and respect both approaches…

randcraw 2y ago

Of course there's a range of transitional states between waterfall and [whatever miracle cure is in vogue today]. Like all historical revisionists, today's techies like to impugn the old and laud the new. ('How could they have been so clueless?') Fact is, long-lived products, esp. from BigCorps, and esp. those in heavily regulated spaces like medicine and transportation always have and always will spend a lot more time and effort on design and process than will ephemeral products and services from startups. My software career started ca. 1990 just as waterfall was evolving into the 'Spiral' iterative software model, which since has been rebadged and remorphed several times into today's 'agile' and 'test-driven' gift from god. However in the real world, makers of every S/W product inevitably must adapt their actual development process to suit the lifecycle needs of their product and customer, in ways that scrum can't serve. Often the best way to reduce technical debt is to increase investment design and testing. And taken to NASA-like limits of fault-tolerance and reliability, that can take you all the way back to waterfall.

minkles 2y ago

We use extreme waterfall. All the disadvantages of agile and waterfall in one process. Nothing gets to production due to meetings so the customers are happy we aren’t fucking anything up.

dehrmann 2y ago

The whole strawman/dichotomy you see with Agile and Waterfall boils down to needing both flexibility and vision for large projects, and each fails at one of these.

kermatt 2y ago

Agilefall.

bee_rider 2y ago

So like a waterfall, but the day to day is connected by little bits of agile? You end up at the bottom of the waterfall, but by taking a bunch of much smaller falls instead? Have you considered calling it Rapids development? You will sell a million books or whatever, just on the name.

wheelinsupial 2y ago
> Have you considered calling it Rapids development? A variation of this exists with one more word thrown in for good measure: https://en.wikipedia.org/wiki/Rapid_application_development https://en.wikipedia.org/wiki/Rapid_application_development

freetanga 2y ago

This. Some products are platforms with thousands of functionalities all interlinked in a uniform data model, with similar but specific behavior expected for all modules of the platform.For instance, a Core Banking System, or OMS in Telcos. And since we all get paychecks, it seems to work. Building such an product in agile was often tried and failed in the past decade. You need common data structures and routines that a few thousand developers can all expect to find ready further down the line. Like the Oregon Trail game, you launch all workstreams in different moments and expect them to converge at the finish line. I think “100% waterfall” was ditched in the early 90s, for all the known reasons, with smaller cycles of releases becoming the norm. But still the hard thinking, laying down the key mechanisms of a platform was heavily thought out early on. I think all criticism is a bit unfair, as agile is also an infinite source of cock ups, mediocrity and dead ends just as waterfall. There is a space for each approach, and bottom line, the right people will make all the difference. But that’s also why it’s important to learn and respect both approaches…