I signed the Agile Manifesto.  Some of you may ask why did I do that?  After developing software for over 15 years, meeting some of the original signatories, and reflecting on the values, I realized that what it stands for really hit home.

I've been in environments where processes and tools are paramount.
I've worked under comprehensive documentation requirements.
I've done consulting where contract negotiation is painful and long.
I've done work where following a plan was the most important thing, spending 6 months in "analysis", 6 months in "development", 1 month in "testing" and 1 month in "support".

I can really relate to the things the manifesto says, where we value individuals and team interaction, working software, collaborating with customers, and responding quickly to change more than those things.

I've worked on a few powerful agile development teams.  I've seen how just modifying what you're shooting for improves the process, involving customers more often, getting working software out to customers.

Recently in one of my MBA classes at University of Phoenix, a classmate who is a software developer for Hewlett Packard told me that on their team the management decided they wanted to "do a study" on "whether or not agile works in our environment".   They tried an experimental team using XP.  A team worked on that for one month, doing pair programming, user stories, rapid releases, and the core components of the methodology.  At the end of the month, the management looked at pair programming and came to the conclusion that "we can't justify the cost of the resources of two developers working on one featureset".  So they rejected agile, determining that "it isn't a good fit for our environment".

After hearing this story, I just wanted to scream "YOU JUST DON"T GET IT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
Agile is not some fad diet that you can go on to cause your development team to lose 60 ugly pounds in a 2 month period.   It's a concept, an idea!!!!  I know that is a foreign thing sometimes to middle management, as the training they have for ideas and concepts is if-it-conforms-take-the-credit-if-it-doesn't-conform-attack-it.    Agile is about changing who you are and what you value.  It's about getting past the old waterfall methodologies that don't work and leave failing projects, careers, and death marches in their wakes and moving on to something that helps both developers and customers be happy!

If you absorb these ideas into your core belief system you can see that with a concept you adapt it to the flow of your situation.  No it doesn't work for me to sit in on a bench seat chair and imitate the movie "Stuck On You" 8-5/M-F to do development work.  But, some of the greatest concept ideas I've had have come out of pair programming.   This is just intuitive, really.  How many coders can't see their own mistakes, yet a colleague could spot it in 5 seconds?  I used to think this was due to semi-godly-like development characteristics until I happened to walk by 2 people's desks in 15 minutes and do it twice in one day.   It's just because the concept works!

So agile, and that includes all brands, XP, Scrum, Agile Modeling, ASD, Crystal Clear, DSDM, FDD, AUP, d3, are all based upon CONCEPTS.  So if it doesn't directly work, refactor it a little bit.  You're developers! 

I've found personally, for me, a blend of working by myself on certain aspects of code, and pair programming work best.   Similarly, I've found that releasing software every 1 week to 2 months as a cycle makes for happier customers, and what do you know, if those customers get to describe how they work to you on "feature cards" or in "user stories" and then they see those stories coming to pass in the order of what's most important to them on a monthly basis, they magically become happy!

Sometimes technical people, and tech managers included, get too hung up in PROCESSES AND TOOLS, even in Agile.  They forget that although these are valuable, if you forget about what's more valuable, like individuals, interaction, working software, and customer collaboration, you just have one big new PROCESS that doesn't work, or "just isn't the right fit for our environment". 

Adapt the environment to the value system, and the process will work itself out.  I promise!