Most agile transformations start in the same place. Somebody in technology leadership decides the developers need to get better at delivery, so a coach gets hired, and the coach goes to work on the people writing the code: stand-ups, retros, story slicing, the whole kit. The developers mostly get it and adopt it in good faith, and then the next request shows up from the business the same way it always has, a big fixed-scope requirement with the date already attached and a note that says, more or less, "We don't need it in pieces, we need all of it."
The work arrives already shaped
So the team runs its ceremonies on top of work that was never designed to be delivered in increments, and we get the thing everybody in this field has seen: agile vocabulary wrapped around a waterfall project, and a coach who keeps getting asked why adoption isn't sticking. The usual answer is more coaching for the same team. Better retros, a refresher on estimation, maybe a new tool. None of it touches the reason the practice keeps breaking, because the reason isn't on the development team at all.
Nobody on the development team is resisting anything. They were taught one way of working and then handed work shaped for another, and the work wins.
Where I actually spent the hours
When I went into a Fortune 100 financial institution as an agile coach, the Technology side was paying for my time. I spent most of that time with the product team anyway. That wasn't a side project and it wasn't on my own time; the people paying knew where my hours were going, and they were satisfied with what came out of it.
The reasoning was simple enough. It was more effective to teach the people where the work originated how to organize it so it could be delivered in an agile way than it was to teach developers agile principles while product kept handing them work that wasn't structured for it. Once the work started flowing in under that design, the development teams needed very little coaching to adopt the practices. Not zero (that would be overstating it), but close enough that the difference was obvious to everyone involved.
The downstream team adopts whatever the upstream work makes possible.
Built to be taken apart
The obvious pushback is that this makes the whole thing fragile. If the developers only work this way because product hands them work in this shape, then a new head of product who wants big fixed-scope requests again can undo it in a quarter.
That's true, and I'm fine with it. If the people who own the work decide to run it differently, they should be able to, and the delivery teams will follow the new shape the same way they followed the old one. I'd be more worried about the reverse, a practice so locked in that nobody can change it even when they have a good reason to. The version I want to leave behind lasts because the people shaping the work understand why it works and keep choosing it, not because it's too tangled up to remove.
AI rollouts are repeating it
Most AI rollouts make the same mistake in a new form. The licenses and the training go to the people doing the work, the analysts and engineers and support staff who'll actually use the tool, and everything upstream of them stays the same: the same request formats, the same tickets, the same handoffs. So the tool receives work in whatever shape it always arrived in, which for AI usually means without the information it needs to be useful.
That missing information is the part AI changes. Someone who's done a job for years fills in the gaps on every request without thinking about it: they know the customer, they know which system is quirky, they know what "the usual fix" means. An AI tool knows none of that unless someone gives it to it. You can hand it that background with every single request, which eats most of the time you were trying to save, or you can make it available once, by connecting the tool to the systems and records where that knowledge already lives. The second one is where the return is, and it's a decision about how the work gets set up, which the person using the tool can't make on their own.
Look at the intake first
If adoption isn't sticking, look at the intake before you schedule another workshop. Who decides what shape the work takes when it shows up, and when was the last time anyone coached them?
There's a catch I haven't solved here. A lot of the knowledge an AI tool needs was never written down anywhere. It lives in the heads of the people doing the work, and they're the ones with the most reason to distrust an AI program. Asking them to write it all down for a system that might replace them goes about how you'd expect. What I'd do instead is give them a tool that helps with their own work, tell them plainly that what they teach it gets shared so everyone else benefits too, and let the knowledge build up as they use it. Whether that's a fair trade for the people doing the teaching is its own question, and it deserves more than a paragraph.