I attended Rachel Davies' talk at QCON 2008 about Agile Mashups. She made the point that in the real world people take a variety of practices from different Agile methods; as a simple example there are Scrum teams using TDD and XP teams using burndown charts. She pointed out a few practices that seem more optional, such as pair programming and sitting together.
I find there's a very interesting tension. On the one hand I think it's important to know what "good agile" looks like. There is a danger that some teams throw away their documentation, hack and claim to be Agile. So to sort this "cowboy agile" from the real thing, you could use the Nokia Test, which is a checklist: tick the boxes and you are doing Scrum :-)
Particularly, when you start Agile and don't understand all the subtle interrelationships of practices and sometimes unexpected effects of doing certain things, it's useful to try to stick closely to a process and really try it, to find out what works for you and what doesn't.
On the other hand, a central piece of Agile is self-organising teams that inspect and adapt. A good Agile team will have assessed these practices for themselves, tried tweaking them, thrown away the ones that don't work, tried new things. So trying to assess Agility through a checklist runs the risk of constraining a team and stopping them adapting.
I think really good teams find how to get this balance right: you should feel free to try new practices, even quite radical ones, and think of ways to properly assess and modify them; at the same time, you should be serious about really trying the practices from your method of choice
and getting a deep understanding of why those practices are there.