Early agilists agreed on a set of principles enshrined in the Agile Manifesto, and many practices were shared across multiple agile approaches. However, there was fierce debate about whether a team should start by understanding the principles of agile software development or whether they should begin by performing the practices even before developing a deep understanding of why.
Proponents of starting with practices took a wax-on/wax-off view of the world. If a team were to act agile, they would be agile. By going through the motions of being agile—pair programming, automating tests and builds, using iterations, working closely with a key stakeholder, and so on—a team would gradually develop an understanding of the principles of agile.
Proponents of starting with principles, on the other hand, contended that practices without principles were hollow. Going through the motions without understanding why did not lead to agility. Agility was (and still is) a focus on continuous improvement. The argument went that a team could not improve continuously if they didn’t understand why they were doing the things they were doing.
In Learning Agile, Andrew Stellman and Jennifer Greene do the best job I’ve encountered of stressing the principles of agile without de-emphasizing its practices. They point out that following practices without knowing why is likely to lead only to what they call a “better-than-not-doing-it” level of success. That is, implementing practices alone is helpful, but it falls far short of the true promise of what becoming agile can truly deliver.
The second question is, how to find the right extent of following agile principles? For example, it's surely true that working software has greater value than rigorous documentation, but I can't imagine omitting it at all (especially in enviroments similar to mine, where there is no substitution of developers).