For a business stakeholder to understand, and clearly state business requirements, roadmaps to IT. That's a big ask in many organizations, in some cases where

For a business stakeholder to understand, and clearly state business requirements, roadmaps to IT. That's a big ask in many organizations, in some cases where the business is evolving in response to customers/economy/random changes (pandemic for example), and given the average business stakeholder who's probably just trying to get thru some crises etc. As I type this, it makes me realize what a shit-show it is, and justifiably so - i.e. welcome to real life. Its messy in its natural state, because you don't control your customer, can't dictate to your customer or the economy or anyone outside your company for that matter - that's almost an invariant.. and is legit the dog that should wag the tail. One thought that comes up is messy is ideally suited for agile, maybe if everyone pulls together , i.e. sees things the same way (without things being rammed down ). I've had an experience recently when I emerged from the mess, switched jobs, and went into a much more 'orderly' (read large/glacial) organization, I realized how effective messy agile is : No scrum masters, almost no managers, your Kanban and sprint board is the only work record (plus confluence), No word documents, absolutely no PPTs. It just worked .. I did hate some parts when I was in it but those were some social aspects. Taken by itself we shipped, as a flat team, and everyone knew everything, we were agile. This was what it took to ship. In those uncomfortable 18 months, I'd made the transition from waterfall to agile. Work items have to be brutally meaningful and direct.. self-organized, without any of "lets do an AI project or neat dashboard". So you need capable business leadership, and capable tech leadership - both of whom should be able to cut thru jargon, frameworks, bleeding edge tech toys etc.. and just set priorities. The engineering team executes on those in a self organized way. As for scrum, safe-agile - if it has a certification for it, that's self serving with some vested interest, causing much overhead, you either need technical engineering people or product owners.. otherwise it just leads to org bloat.