It's much easier to say there are considerable gains than it is to show it, as yet I've never actually seen it measured, just some gut feely stuff where the team says they do or, as I hear almost as often, don't like how the new system is working.

Obviously, with any severely dysfunctional team---I mean some teams still don't even use a VCS---any sort of productivity oriented training should arguably result in significant gains. But these improvements are often looked at in isolation. Being more productive at building the wrong product is still not going to add value. So it really depends what you are measuring and Agilists constantly focus on measuring completely meaningless things, like developer velocity, while expecting the rest of the organization actually knows what it's doing when it prioritizes backlogs or says things are ready to be worked on.

I was in a Scrum training session where the head of product management was concerned when the trainer explained that velocity was largely an arbitrary internal team barometer and couldn't be used to measure the relative performance of teams. He asked "then how can we [use Scrum to] measure their relative performance?" The irony of this was that the biggest productivity issue I could see was the lack of a clear and effective product development process. This meant that iteration after iteration we were constantly building in circles and with only a vague plan for the product. Scrum was not even beginning to address this.

Of course Scrumistas, always claim that these failures are just the result of cargo culting, "doing it wrong(tm)", or just not understanding "Agile". The problem is that these organizations are paying those same people to teach them and are still apparently not getting it, so who is really at fault? It's clear to me both Scrum and XP processes fail at teaching organizations how to learn and improve as a whole. They fail because they focus way too much on explaining the process and pay only minimal lip service to larger organization issues like continuous improvement, product development, customer validation and even basic planning (unless you want to count planning poker, ugh).

Bottom line is, they are oversimplifications at best but at worse are blatantly misleading organizations and software development teams.

That isn't to say there are no good ideas in agile. I still feel a learned lots trying to be a proponent of agile and even Scrum and XP. But after repeatedly going through the painful process of failing, I eventually learned there was more to this and am finally moving on. I should also state I'm still a big fan of the principles of the manifesto, but in the end I no longer see the relationship between the manifesto and the manifestations of agile, particularly in Scrum and XP.