Do Specialists Outperform Generalists on an Agile Team?

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.

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.

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.

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.

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.

Shouldn't the point be to measure the performance of the team rather than the performance of the individual? Both specialists and generalists are required. I see the real question as what is the proper ratio and when can sufficiently talented generalists make up for the lack of appropriate specialists.

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.

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.

Both are Best, Consultants make great Specialists as well
by
Jordan Bortz

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.

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 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".

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.