Scaling Agile ...
A couple of months ago Rachel Davies, an Agile friend, wrote a blog post called "The Folly of Scaling Agile". It was, as you'd expect from Rachel, very well written and very well thought out. Only problem, for me, is that I disagree with her conclusion. I thought I'd share my comment here, since Scaling Agile is not only possible, but vital.
I agree with a lot of your thoughts, but I have a different conclusion and - I suspect - a slightly different view of what Agile is. I don't think scaling Agile is folly, I think it's HARDER because of all the things you've described but I think (I know, actually) it can be done. Agile in big organisations is different to Agile in smaller teams. I think (know) it's worth trying to do it though because it makes the working lives of people who work in software development businesses happier (though not necessarily easier).
The starting point for me is that scaling Agile usually involves teaching all sorts of people in all sorts of roles who are unfamiliar with - and often very hostile to - Agile to work in what is a very counterintuitive, to them, way. Small-scale Agile, with a team of converts is easier for all the reasons you've described.
So, part of the solution, is to adopt agile in a way which doesn't cause push-back from the adoptees.
I do use some new Agile words, but I try to use old words as much as I can.
I start at the high-level and try to get the customers and project management to chop 1 big project - how they'd normally do it - as, say, 2 or 3 or 4 smaller releases. I trick - in a nice way - the teams into collaborating, by getting the testers to sit down with the developers and analysts before any code is written and discuss what and how and when they're going to test it. I get the analysts to work with the developers and testers and PMs to slice and dice the functionality and then think about how they can build those slices up bit by bit. A get vendors to ship their work in, say, 4 or 5 drops, rather than 1 big drop, and I ensure we test the arse off each of those drops as we go.
When I work this way I try real hard to ensure that I'm always removing pain for people - but sometimes I have to let them realize they are feeling pain first.
We've launched a brand-new product this way (with a team of about 80) in the last 2 years and also a brand new business. If you look at the way the teams work with your XP eyes you'll see tonnes of things the teams could do differently, but for me it's a step by step process which takes considerable time, but it's worth it.