Agile - Rigid or Nimble?

From Dictionary.Com

ag‧ile  /ˈædʒəl, -aɪl/ Pronunciation Key - Show Spelled Pronunciation

1. quick and well-coordinated in movement; lithe: an agile leap.

2. active; lively: an agile person.

3. marked by an ability to think quickly; mentally acute or aware: She's 95 and still very agile.

4. Characterized by quickness, lightness, and ease of movement; nimble.

5.  Mentally quick or alert: an agile mind.

—Synonyms 1. nimble, sprightly. 2. brisk, spry.

I think another Joel agrees with me as well.  All too often I come across teams that truly miss the point of Agile principles and end up constructing an atmosphere of rigidity and absolutism.  The Agile movement presents a set of very important principes, but I think that we need to realize that at its core  is a mindset that allows you and your team to continually adapt to change.

I completely agree that context switching is bad and we should all work to avoid it (you should read Peopleware by Demarco & Lister).  I get a little annoyed when I read articles that pin developers up against sales ("stupid sales people always forcing us genius developers away from our all mighty keyboard") since it fuels a fire that should be quelled.

In the last year I have seen some amazing results when we positioned technical people to work on the same team as the sales people.  Estimates are better.  Requirements are better understood.  Sales rates are much higher.  Trust with the customer increases.  Repeate sales are increased and the overall cost per sale diminishes.  Articles such as this endanger the goodness of a holistic team approach to software development, which includes a sales component (unless you don't like your high salaries and your new laptops).  All too often Sales people are singled out as being the problem, when I argue that its likely the other way around. 

I'm not saying that there is some truth to the Attention Deficit Disorder that can be caused by too much task switching, however, not at the expense of our bread and butter.  Ironically, I'm personally "absolute minded" about the concept of managing change within an iteration (i.e.  change within an iteration needs to be avoided - but not at all costs).  So, with this being said can a single 2 hour disruption of a developer lead to 2 weeks of productivity loss?  Absolutely!!!!  This could completely kill the entire iteration and could have ripple effects across the team.  What we must also understand is the perspective of the organization not just the team.  Agile teams must be agile within the organization they work - not just in their own team.