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…
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…