Do Specialists Outperform Generalists on an Agile Team?

Specialists will always be more efficient than a generalist: when they see a big problem in their dedicated field, they are vastly more likely to "remember" the solution from somewhere and apply it directly, as opposed to having to research it.



But you need to link these specialists together somehow. An application or a system IS by definition "cross cutting". If all you have is a bunch of specialists, you'll have situations where the DBA works in a way, the ASP.NET dev works in another, and when you try to tie it up, it doesn't work.



So you need generalist engineers who know enough to understand how the specialists should interact, how a system is made, and obviously, how to replace someone when a specialist is unavailable :)

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.

To make claims about performance of a member of an organization, a generalist, a specialist, a specialized generalist, a generalized specialists and what not, one would define qualitative criteria and provide information on how the survey based on that the conclusions are drawn have been conducted. W/o it it's just hand waving and whoever-shouts-louder-wins.

I wrote about the subject some time ago in my blog:

www.dtsato.com/blog/2008/02/11/generalist-or-sp...

I'm with Ambler and Gray on this one. You need both. A generalist is utterly useless without his/her SWAT team. A SWAT-team without a generalist won't know which door to knock down and who to hit.

Stating that you should always have generalists or specialists as a one-size-fits-all seems a little ridiculous. It depends on the problem space, and my 13 plus years of experience I is seeing tons of real world problems as a result of too many specialists on development projects. Database specialists are brutal, frequently been more concerned with turf. Requirement specialists are equally so, because many have never actually touched any technical components, so the requirements end up being, and need to be rewritten by the technical team. Overly specialized architects can be equally damaging, they're too busy drawing lines and boxes to actually concern themselves with the reality of implementation. Developers often miss the big picture.

Bottom line, as somebody gets more experience, they need to branch out and become at least familiar with other disciplines in order to offer leadership required under development projects. I agree that most developers are horrible at usability, but that doesn't mean your usability expert shouldn't become a little more familiar with requirements, testing, or some other discipline in order to be more useful in a team.

Personally, I am a object-oriented developer/designer/architect/whatever, who has lots of experience with requirements, testing, modeling, build management, etc., and now I'm reading about Web analytics because I don't think we are marketing our web presence properly within our company. Branching out is a good thing, within reason. Think of developing software as the "specialization", rather than building requirements were doing database work and everyone will be happy.

Jeff Anderson
agileconsulting.blogspot.com
innovationsinpublicsector.blogspot.com/

To make claims about performance of a member of an organization, a generalist, a specialist, a specialized generalist, a generalized specialists and what not, one would define qualitative criteria and provide information on how the survey based on that the conclusions are drawn have been conducted. W/o it it's just hand waving and whoever-shouts-louder-wins.

developers who wear red shirts are more productive then developers wearing blue shirts.

Developers who wear white shits are the scariest!

what about the brown shirts?

I love specialists. They work faster than generalists, and they bring expertise.



The problem is when the specialist becomes a bottleneck because everyone else on the team depends on them and they can't keep up. And, I can't stand when I see a specialist "waiting for the team to catch up" or even worse, a team of specialists staring at each other trying to figure out "who's gonna do THAT?". Velocity in agile is greatly dependent on even "flow".



I was a developer, then a usability/analyst/UI person before getting into agile. As a usability person, I was frustrated with the agile teams ignoring usability and building products fast without time for user testing (not sprint reviews, but real user testing). In that environment where user errors could lead to human injury or death (medical software), this was not acceptable.



The solution... have a team of generalists that can take on any work from any direction without a resource bottleneck. Once there is enough work on the team for a specialist to ALWAYS have enough to do, move a specialist onto the team. The hard part for the specialist is then choosing which items require their direct involvement, and which items can be mentored/paired with a generalist on the team. This seemed to work well for usability, UI, and QA types of resources. On some teams, the specialists in these roles would not be dedicated (which created a different agile problem, but was manageable).



Specialists have to recognize that it is their role to mentor the generalists to cover for them and not allow bottlenecks, ever. Some specialists won't "share" their role, so personality and team dynamics must be managed appropriately.



So, I guess I advocate a balance of the two. And I've experienced it in a positive way (for those asking for data).

Someone who is completely a generalist, or completely a specialist, should be considered extremes. In my experience you rarely want to consider an extreme solution, but instead look for the sweet spot in between which is right for your situation.

Quoting Adam Smith is interesting, but we might want to recognize that he was writing about macroeconomics, not the organization of intellectual work. Context counts.

- Scott
Practice Leader Agile Development, IBM Rational

I can't resist .... ;)

I specialize in being a generalist.

As a generalist you need to recognize what you don't know and leverage the people on the team who are experts. As a generalist I can consume massive amounts of information on many subjects and have easy recall. It's just my talent. The thing is you have to know where peoples strengths are and use them.

PS... Scott sorry I will miss lunch with you this year.

I would agree that both are needed on a project.



At the low end, generalists who can hake a little ASP.NET, a little CSS, a little SQL is great as they grind out web pages.




However, at the high end, architectural level, or complex CSS/Design, you really need specialists there. You don't want average HTML designers doing your logo and overall page layout. You need a specialist here.




Similarly for performance, scalability, etc, you need an expert Architect/Developer to do these parts. Putting Joe Average here is not going to cut it. Even worse put your CSS designer doing Database Design!




As far as those who say that specialists are sometimes idle -- that is a perfect usage for consultants. When you need that logo, that web page layout -- get a Consultant!




Having a great Archictect as a Consultant (which is normally how I operate) makes great business sense in that they provide maximum value when they are working yet do not cost anything when they are idling.




You can have both -- specialists and generalists, and you can make it work financially by having the specialists as consultants.




Jordan

Adam Smith favoured specialists for Production processes, indeed most of the reasoned calls for specialisation without generalisation seem to come from production environments rather than from Development environments. The reality is that we value the depth of knowledge that specialisation brings, but we also value the breadth of ability to communicate and the flexibility of working that generalisation brings. In a Production environment where relatively little new knowledge is generated, the need for breadth of communication is less, so specialisation brings fewer problems along with it. Personally, I'd be happy with a generalist provided they were good at everything. Unfortunately it takes 20 years or more experience to get that good at everything... Until then, I need a balance between generalisation and specialisation.

I did some googling on Capers Jones, and found this paper: www.compaid.com/caiinternet/ezine/capersjones-m...

I don't own Anderson's book, so I'm not sure whether that's the referenced paper. Anyway, this one finds that *maintenance specialists* are 6 times more productive at *maintaining software* than "generalists".

I'd argue that, since Agile projects are in "maintenance mode" from iteration two, all members of an Agile team are - or at least quickly become - maintenance specialists...

Ah, but having been a "maintenance specialist" at some times in my career, I have to wonder, what is a "maintenance specialist?" Is it a sort of generalist? Someone who has skills that let them dip in to maintain any part of the code as needed?

From the Capers-Jones report: At the top of the list of maintenance “best practices” is the utilization of full-time, trained maintenance specialists rather than turning over maintenance tasks to untrained generalists." Aha! UNTRAINED generalists?

I scanned the article and couldn't quickly understand the intended distinction between "trained maintenance specialists" and "untrained generalists".