For years, many project and functional managers have believed they need the "exact right person" in each role on a project. Those exact right people are specialists, and some of them have quite narrow specialties. Here's the story of one specialist and her impact on several projects.

Two project managers needed the same person, a database modeler named Suzanne, on their projects immediately and for weeks at a time over the next two months. Ted needed Suzanne for a week now, then four weeks later for a three-week period. Vu was running an agile team working in two-week iterations and wanted Suzanne for the duration of the next four iterations. In the past, Suzanne had multitasked between the two projects, making both of them late. Neither Ted nor Vu was willing to do that this time, but they thought Suzanne was the only one who could do the database work.

Ted and Vu both were stuck in specialist thinking—convinced that they needed a specialist to finish certain work. And they were right, because the organization had no other database administrators who could do what Suzanne could do.

"Can Suzanne train someone?" I asked.

"But then my project will be late," Ted objected.

"Your project is already going to be late, because I'm not willing to give up Suzanne," Vu said. Ted was about to say something, but Vu continued, "I'm going to ask one of my guys to work with Suzanne during the first iteration. I need to cross-train people, because not having Suzanne will disrupt the timebox. I'll explain to the product owner that we need a bunch of stories in this iteration that Suzanne can lead, and we'll train other people so that we may not need her later. How does that sound?"

When Vu added that Ted could have the following four weeks with Suzanne, Ted reluctantly agreed with the schedule.

Vu's first iteration was not easy. The team's velocity decreased, finishing only about half the user stories they expected to finish. They weren't sure if they'd learned enough from Suzanne to finish the next iteration's user stories. During the second iteration—this time without Suzanne—the team had a few questions. They collected them every other day and arranged time to discuss them with Suzanne, interrupting as little as possible. By the end of the second iteration, the team was more comfortable and had increased the velocity by 10 percent.

With Suzanne helping Ted's team finish tasks no one else could do, the team was on track in terms of time. By the end of their projects, both Ted and Vu believed they had managed the problem.

Fast forward six months to another project. Both teams needed Suzanne again, but this time, Vu's project needed her only briefly as an advisor, and it was Ted's turn to ask her to train his team on some of her modeling approaches. Afterward, Suzanne was no longer a scarce resource shared across many simultaneous projects.

Is Suzanne's specific expertise still needed? Yes. Is she still the only one who can provide some of that expertise? Yes. But, the other developers have learned enough that their generalist capabilities can help the projects and keep Suzanne's schedule from holding up progress.Specialists Create Bottlenecks
Looking at this example, it's clear that specialists create bottlenecks. It's easy to see this in a serial lifecycle. If you're missing any of the analysts in analysis, architects in the architecture phase, developers in the coding phase, or testers in the testing phase, the project slows down. In an agile project, if a specialist is not available for a specific iteration, you may have to change the order of the product backlog, which means you may not finish the most valuable work first.

Fungible Is Not the Answer
I'm not advocating that everyone obtains the same technical skills—that everyone becomes fungible. That's not possible and wouldn't be a good idea even if it were. People like doing certain kinds of work. The more they complete the work they enjoy, the better they become. But, if they loosen the boundaries around that work and learn a little more about related areas of a system, they become more valuable to the project and to the organization. And, the project is not subject to specialization bottlenecks.

Five Ways to Decrease Specialization
Here are five ways to learn more about areas of the system you don't yet comprehend:

1. If you work alone on a component, work with other people on related components.
2. Better yet, work with a team of people on a feature. Discuss what each of you needs to do to create the feature.
3. Work with other people in pairing relationships. Make sure you pair with different people often.
4. Explain to other people what your part of the product does.
5. Conduct a code review of the code or a test review of the tests.

I bet you can think of even more ways that are applicable to your project.

Specialists hold the project hostage to their skills. If you can decrease the number of skills that are theirs alone, your project will progress more smoothly. And, you'll have a more valuable project team.