As you know, the Agile movement was formulated as a response to the perceived need for an approach to software development that could easily accommodate change. It was presented as an improvement to the so-called waterfall model, which was predicated on an extensive design cycle that defined fairly unchanging requirements and designs. Because of this, waterfall models tended to deliver software that was out of sync with the user's needs due to the evolution of the latter during the development cycle.
At its inception, the Agile movement was not about techniques, but about principles. However, extreme programming (XP) was one of the most established set of Agile practices at the time and so it provided the body of practices with which Agile came into incarnation. For many years, XP practices and Agile approaches shared a great deal of overlap. Later they would become more differentiated, but early on they were essentially the same.
XP, as the P implies, is focused on low-level work. It consists of 12 practices, seven of which are exclusively about coding-related work: pair programming, test-driven development (TDD), refactoring, small releases, coding standards, collective code ownership, and system metaphor. The remaining five practices barely hover above this level: planning game (weekly iteration planning), whole team, continuous integration (building the code trunk repeatedly), simple design, and sustainable pace. This makes XP a great solution if only your coding or implementation pipeline need remediation. But experience tells me that sites with faulty downstream processes often suffer from problems further up the line than what can be addressed by practices such as TDD and CI.
For these challenges, you need to go to a different branch of Agility the one that focuses on process, design, and team interaction. This higher branch comprises lean development, kanban, and to some extent, scrum. (Scrum is sort of a hybrid, it can be viewed as high level or low level; while lean development is a true systematic attempt to bring Agility to the larger processes where development teams first become tangled up.) Lean development derives from a just-in-time manufacturing approach, and it was adapted to software development in the classic Lean Software Development by Mary and Tom Poppendieck. It relies on seven precepts, not one of which deals directly with code, although being true guiding principles, they can be applied to coding.
While this higher level is undeniably agile, the term "Agile" refers largely to the coding practices that are low-level and stay down at the bits and bytes. The best summary of them, in my opinion, is Robert Martin's Agile Software Development from 2003.
The book perfectly illustrates the "in the small" aspect of Agile development. The subtitle is "principles, patterns, and practices," but the book is mostly filled with diagrams and code. The Poppendiecks' book, in contrast, does not contain a single line of code.
The problem caused by these two divergent paths is that there are key issues that fall through the gap between them. I am talking about a level that should ride between lean development and Agile coding: architecture and design. "Agile design" are two words you rarely see together. Even more rarely read is: "Agile architecture." Go to the proceedings of almost any Agile conference and you'll be hard-pressed to find a single session with architecture in its title. Yet, as Mary Poppendieck affirms: "[project] architecture must support incremental development." How is this architecture developed? It's not easy to know. The Poppendiecks' book has no entry for architecture in its index. And Martin's 500-page work has a short 10-page section in an appendix, most of it dedicated to explaining UML notation. Clearly, architecture is a significant omission of the Agile approach.
Many enterprises don't buy into the entire Agile prescription. Despite my high esteem for Agility, there is a certain prudence to this restraint. Even after these many years, Agile still has gaps. It does not account sufficiently for architecture and only minimally understands design two practices crucial to enterprises. Because of these unaddressed needs, enterprises are better off weaving Agile practices with other familiar methodologies and finding a blend that works for them rather than transforming their processes to adopt an approach that, while commendably good at many tasks, remains distressingly incomplete.