Specialization is Good

Sure I don't want a nurse taking out my tonsils, but that's not software. And what's wrong with having a developer get the pieces in place on the web site (especially if the guy who's better at window dressing is too busy). I want that person to know how to operate in there... or at least not be afraid of it or worse told they can't.

For me, the better analogy is a SEAL squad. They are heavily cross-trained and can function in any of the team roles, but at the same time like any good team, some people are better at some skills (specializations) than others, but there are of course times when they aren't in the right position or they are just spread too thin. Note they have swim-buddies too, which seems to me similar in ways to pair programming (which help build better generalists).

And with too much specialization, you always have to be aware of your low "truck number".

Your argument is based on two fundamental misconceptions:

First, the term "cross-functional team" doesn't have anything to do with individuals. It describes a team where all the knowledge needed to reach the goal of the team (like developing a product) is present inside the team. This is in contrast to functional teams, where a product needs to be handed around between different teams to get finished. It doesn't say anything about who inside the team has what knowledge.

Second, nobody in the Agile community I know says that everyone should work on everything, no matter what. What we are saying is that a team can be much more effective if team members can fill more than one function, and are able to help out in even more when needed (for example by pair programming with an expert). See http://www.agilemodeling.com/essays/generalizingSpecialists.htm

While I like what is being discussed here, I have to stress that cross-functional teams encourage learning. It's how teams grow. We do a lot of pair programming and it has really helped our team become "cross-functional". We work on a lot of consulting contracts often simultaneously. Sometimes, a specific team member with a set of expertise is not available because he or she is committed to another team on another iteration or release. But, because we've paired in the past and some of those expertise have been "passed on" through the pairing, our team is better equipped to handle the temporary absence of our expert. And our expert is always available for questions if the need arises. But we have found that the more people stretch their knowledge base, especially through pairing, the more flexible and nimble our team can be. Even on iterations where our "expert" is on the team, often we've had "non-experts" take some of his/her tasks and perform very well on them. This allowed our expert to either expand his/her knowledge base or concentrate on more complex or difficult tasks. But this all comes with one caveat: You still do need that single expert (or multiple experts) to spread their goodness around to other team members. This takes a team member with little or no ego who is willing to share and transfer knowledge with the rest of your development team.

"Well, I agree that there's nothing wrong with the intended definition. But what I am talking about, and disagreeing with, is the interpretation in agile circles. Here's a quote from Chris Spagnuolo:

This means anyone on the team can and should work on tasks that may not be within their expertise. Usually there is someone on the team with functional expertise to lead a specific task, but anyone on the team can do the work.

I don't agree with that."

I'm not sure that there is something that you could call "the interpretation in Agile circles" - the Agile community is not as homogeneous as this statement seems to imply.

I'm also not sure that your interpretation of Chris' interpretation is actually correct. I can think of ways to interpret that statement that wouldn't be in conflict with what I wrote at all. On the other hand, I wouldn't be too surprised to learn that Chris and I actually disagree on this - while I find his views to be interesting and valuable, I don't know how much he is actually embedded in the Agile community. From all I know, he might just be a blogger who happens to write about his very personal view of Agile Software Development.