I share your scepticism, Rachel, and the pitfalls you mention are important to be aware of. Nevertheless I do think scaling, within certain conditions, is possible. The main one that I find is mentioned seldom, is architecture: with a loosely coupled large system your teams can be related one-to-one to one component, and have clear (and minimal!) dependencies with other teams/components. Check my blog post http://www.robvens.com/en/scaling-agile-means-scalable-architecture/ Do you think this could be a mitigating strategy?

Very much agree. It is important to reflect on the "questions" (quoted because the first one is indeed too much of a generalisation) because any effort to work on a framework or a standards body will elicit these responses. A problem with any body of knowledge is the path to mastery. This is a human cognitive process which requires not only deep knowledge but also a lot of feedback from practice. In the meanwhile the framework evolves and we always feel as if we are running behind a snowball rolling down a mountain slope deep in snow. The developers of the framework need to be aware of this, and "pause" from time to time, to give heuristics time to catch up, and to give practitioners time to "ingrain" the knowledge and master it. Mastery shows more in knowing what *not* to apply from a framework. It is the novice's mark to attempt to use it all, or as much as might be needed. We need more "masters" exemplifying this.