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.
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.
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.
Have you considered calling it Rapids development? You will sell a million books or whatever, just on the name.
A variation of this exists with one more word thrown in for good measure: https://en.wikipedia.org/wiki/Rapid_application_development
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…