productivity is such a nebulous concept in knowledge work - an amalgamation of mostly-qualitative measures that get baked into quantitative measures that are mostly just bad data
https://ourworldindata.org/grapher/labor-productivity-per-ho...
When you try and break it down to various products and cost centers is where it comes unstuck. It’s hard to impossible to measure the productivity of various teams contributing to one product, let alone a range of different products.
Moving fast and breaking things, agile.
On the other hand. When you know what you want to build but it’s a very large endeavor that takes careful planning and coordination across departments, traditional waterfall method still works best.
You can break that down into an agile-fall process with SAFe and Scrum of Scrums and all that PM mumbo jumbo if you need to. Or just kanban it.
In the end it’s just a mode of working.
In general, delaying infrastructure decisions as much as possible in process usually yields better infrastructure because the farther you are the more knowledge you have about the problem.
...that being said I do dislike how agile gets used as excuse for not doing any planning where you really should and have enough information to at least pick direction.
This is obviously satire but there's a clear ask, some features, from there you know what you need to have to even achieve those features, what project management process would you employ? Agile? Waterfall? Agile-fall? Kanban? Call me in 6 months?
Replacing existing system (and especially one you didn't write) is pretty much always the hardest case.