Background: The Pune vodQA 2012, where I was involved, but not entirely committed(A frivolous reference to Scrum lore, about commitment, chicken and pigs) in more ways than one, was interesting instructive and illuminating! Read about it here.
Mr Chaitanya Nadkarny, a senior member of Thoughtworks consulting gave an opening talk, covering among other things which factors are going to affect the lives and careers of testers. One point he made was with regard to how testers can be generalizing specialists, or specialising generalists. It took some time for the audience (at least I did take time) to get it’s collective head around this. Mr Nadkarny’s point here was that
One could be a performance tester (specialist), but also interested in expanding capabilities (therefore generalising) to do general functional testing, manual etc.
OR
A tester (generalist) now wants to be more skilled and focus on an area of testing, for example usability (specializing).
MAIN POST:
Since I see the world through Scrum tinted glasses, I’ve been struck by how Nadkarny has put in a nutshell the possibilities of how people develop, become more valuable and competent. Many years ago a programmer was doing most if not all activities in relation to developing systems/applications, including testing. As the field developed people became more and more specialized. Eventually in the noughties, we have extremes of specialisation. Even being a tester isn’t enough of specialisation, one is now a manual tester or an automation tester, or a performance tester. The side effect of the industry moving in this direction is that people are squeezed into ever narrower roles, even though this isn’t required and actually creates inefficiencies. Finally we have the equivalent of a striker who can only play on the right wing, kick with his left foot, but will not head the ball into the net, even if the ball is at eye level, straight ahead and the keeper is out of position!
This attitude is so entrenched and pervasive in some places that even managers have often fallen into the trap. People are type-cast and given no opportunity to learn new things. The Scrum team, essentially being cross-functional, would struggle to succeed if a group of super-specialists have to work together, even if they are initially willing to collaborate. Why so?
Firstly: There is little understanding of what the other person does and needs.
Secondly: Load balancing at different points in a sprint is a nightmare, as work of a given type isn’t evenly loaded throughout the duration of the sprint.
Thirdly: Majority of work in any organisation is done by generalists, because much of the work doesn’t need a too much of specialization. How often have you visited a general practitioner vs a specialist?
Lastly and very importantly: it encourages the continuation of waterfall habits.
Time to generalize. A cross functional team would need generalizing specialists.
On the other hand, once they get there, they might then need to be specialising generalists, as well… and so it goes.
Chaordic Commentary 
Mar 29, 2012 @ 23:27:16
As a general theory of HRD, a hard reality one cannot escape is that individuals gravitate towards specialisation or generalisation. This is how the whole idea of the pyramid structure of management came into being and we cannot run away from it. It is rare that the specialist becomes a generalist and that is why there is always only one boss.
May 11, 2012 @ 20:40:34
Almost all the scrum teams I have worked with have these problems where specialized “resources” actually make it difficult to take up commitments that a team of generalists could, quality of the integrated/delivered s/w is poor even when the individual pieces are developed by the specialists and the dependencies on the specialized team members lead to inefficient load balancing and spill-over of commitments. All these are against the spirit of scrum and the team ends up pretending to be following scrum (as you rightly said, it encourages the continuation of waterfall habits). Most of the times, in such teams, there is a reluctance (sometimes resistance too), to follow scrum practices.
I have been thinking of ways to address these factors but have not been able to come up with a satisfactory one. I think it would take readiness to learn new things (languages, technologies) and some time before the specialists in the teams could start contributing as scrum team members.