Many years of experience with it across orgs of various sizes and ages. One-size-fits-all software management and metrics about planning and velocity are things that exist to give middle management surface area to tell whatever political blame/credit stories they want, and have not got shit to do with productivity, adjusting to change, or delivering anything.
And don’t even get me started on why Agile is emphatically and unequivocally not a different thing than Scrum itself.
No single methodology is right for everyone, but lean principles tend to be a better fit for most. And that's really what Agile and Scrum are.
The most important thing for teams is to establish a rapid feedback loop, and make sure someone is tasked with handling that data. Once you know your customers' needs, you can act to resolve them. If you're using a waterfall approach, you can miss the window, which delays your ability to get changes in front of customers, which delays feedback and increases the chance that you're wasting time.
Before we adopted an Agile-inspired process, we had several projects get scrapped after weeks or months of work because we misunderstood the customer's problem. When we adopted a new process, we built smaller MVPs (took days instead of weeks) and got customer feedback that indicated we needed to make a shift. Many of our features got smaller because we didn't get time to over-engineer them.
The major flaw, IMO, is technical debt. Our product is released on a schedule, but we get feedback from users with alpha products, so we have time to clean up the implementation once we get hands-on feedback from customers.
If we adopted Agile 100%, we likely would rack up more technical debt, and I've actually seen this happen in that same company as management made changes (I became trainer and technical lead instead of project manager).
If you drink too much of the kool aid, you'll get a stomach ache.
I've seen scrum work and not work. My biggest beef with scrum is that people think its a batteries included thing, and its not. I've also seen a lot of things called scrum, which were not scrum. That batteries not included part is the thing scrum calls a product owner, which is just an idealization of whatever requirements process is in place. If that requirements process does not deliver decent requirements in a prioritized manner, then good luck.
I've had much more success with feature driven development (Coad).
