There is a general consensus in the Agile community on the relevance of cross functional teams and the idea of having generalists and specialists on the team. Dave Gray, in an interesting diagram on his blog, tries to show the relationship between a generalist and a specialist. According to Dave, a generalist has a basic understanding across many disciplines. Generalist may not have a specific skill required to solve the problem, however, he is very good in defining the problem. A specialist on the other hand is a person who has a deep understanding of a specific discipline. He is best used when solving a problem or executing a plan. According to Dave both are required in a project for the successful execution of the project.
JurgenAppelo however, has a strong opinion on the generalist and specialist theory. In his blog he mentioned that, not only specialists are good , he also discourages any team member in his organization from becoming cross functional. According to Jurgen,
Cross-functional teams (in the way they are promoted by some agilists) completely ignore everything society has learned since philosopher and economist Adam Smith pointed out in 1776 (in his landmark book The Wealth of Nations) that specialization leads to higher productivity and prosperity.
He further added
When the design of a web site is being implemented by a developer, it can bring tears to my eyes. Some of them seem not to be able to see the difference between a pixel and a centimeter. I have seen functional designs for web sites, created by software engineers, that would probably have caused physical injuries among our web sites' visitors, if we had followed the designs.
Jurgen added more weight to his argument when he quoted the book by David J. Anderson
In his book Agile Management for Software Engineering David J. Anderson mentioned research done by Capers Jones which showed that a team of specialists will usually outperform a team of generalists (page 272).
According to him, the inefficiencies associated with specialists do not outweigh the much bigger inefficiencies of generalists, who are apparently slower at doing their jobs than the specialists are.
On the other hand, some members of the Agile community strongly believe that specialists should be avoided on the teams at any cost. David Christiansen is of the opinion Generalist first, specialists last. In response to a question on the composition of a well formed team, he suggested
You should avoid specialists if you can. They tend to be grumpy one-trick-ponies that aren't particularly interested in developing a good core team. Besides, they only do certain tasks, eschewing all other work. Specialists spend a lot of time waiting between tasks that are "appropriate" for their skills, so they are either wasting your project's money OR only partially allocated. Both of these situations add risk and invite failure and can cause tricky scheduling dependencies. Generalists, on the other hand, can add value throughout the entire project lifecycle. They can help at all phases, which means scheduling isn't such a big deal. In fact, having a team staffed entirely with generalists can go a long way to eliminating dependencies on your projects critical path.
Scott Ambler takes a middle ground when he suggests that a team should be comprised of generalizing specialists.
One approach is to build a team with some people who are generalists and some who are specialists, the generalists provide the glue within the team and focus on the bigger picture whereas the specialists focus on the detailed complexities of your project. This works well because the strengths of generalists balance the weaknesses of specialists and vice versa, and it is often quite useful for a generalist to pair with a specialist because of this balance. A better approach would be to build a team comprised of people who are generalists with one or two specialties -- generalizing specialists.
According to Scott, a generalizing specialist is someone with a good grasp of how things fit together and as a result of this they tend to have greater understanding of what the team is working on.
On similar lines Jeff Atwood, voiced his opinion in favor of generalizing specialists. According to him too many software developers are burrowing themselves deeper and deeper into the same skill sets and specialties. Coding is a narrow realm and there is a vast universe of engineering skills, which should be cultivated to become a full rounded software developer.
In conclusion, not all members of the Agile community feel that specialists is the way to go. Depending on the people and project either a team can have the desired ratio of generalists and specialists or else can aspire for having generalizing specialists who can work together towards the success of the project.