>Instead, what I'm seeing is measures of artificial intelligence use.
Fun fact: this is also how most large companies are measuring their productivity increases from AI usage ;), alongside asking employees to tell them how much faster AI is making them while simultaneously telling them they're expected to go faster with AI.
In my experience, "good management" meant striving to isolate measurements as much as possible to output/productivity.
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.
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.