The people we work with usually fall into one of two categories: generalists and specialists. How do they differ?

• Generalist – a person with a broad knowledge that can work in a number of different areas

• Specialist – a person who has a deep and unique knowledge of a particular area of focus

Many agile methodologies advocate for all team members to become generalists (for more on why, see our article on agile teams). Sometimes, though, it makes sense for a team to enlist the help of a specialist for the following reasons:

• a particular skill set is not required on the team full-time

• the company has a limited number of people with a particular skill set, who are shared across teams

• specific authorization is required for working in an area the general team doesn't have access to

In these cases, it makes sense to have a specialist join the team for a specific period of time. Adding a specialist to the team, though, comes with a few challenges.

Because specialists are with a team for only a specific period of time, they can quickly become a "critical path", sometimes blocking the progress of the entire team. For example, if a team is relying on a database administrator to make changes to the database to deploy new code, team progress becomes blocked by the database administrator. When the team can’t move forward because they need input from that specialist, that work stream stops. Since the specialist is the only one on the team who has the skills, the team has no choice but to wait it out until the speicalist un-blocks them.

Specialists engage in lots of context switching: ramping down on one project and ramping up on another. And shuffling between projects is costly. Specialists almost never have the intimate knowledge of a project that core team members do. As a result, specialists can miss important details. To mitigate this, the core team has to exert extra energy keeping the specialist up-to-date.

Let's walk through three tips to limit the stumbling blocks when working with a specialist. 

1. Clearly define what is needed from the specialist

Once you realize you need to engage a specialist, spend some time thinking about exactly what your needs are. Understand the type of work and depth of knowledge required. Doing so will ensure that the team gets the right specialist, and that the specialist has enough time with the team to be successful. Not being realistic with time and skills needed from a specialist sets both your team and the specialist up for failure. 

2. Transfer knowledge from the specialist to the core team

Agile teams are all about overlapping skill sets. As a specialist works with a team, build in time for the specialist to train the core team to whatever extent possible so that the knowledge they bring in isn't entirely lost when they leave. Some effective ways to do this include:

• Pair programming – Pair programming involves two or more team members working together in real time on a specific area of the project. Both people can ask questions and engage in the work.

• Code review – In code review, a core team member will review work completed by the specialist to understand all changes. Code reviews focus more on why then how, making them less effective than pair programming for training.

• Brown bags – Brown bags are informal sessions were specialists share knowledge to a group of people. It's an efficient way to educate the entire team.

The goal is to ensure the team becomes more autonomous. Knowledge transfer will give the core team more context for managing areas formerly owned by the specialist, reducing their dependence on that specialist in the future.

3. Minimize ongoing need from the specialist

As specialists wind down their engagement with a team, it's important to set service level agreements between the team and the specialists. Determine when or in what circumstances the team may need to reengage a specialist. Creating support guides that outline common scenarios in the specialist’s area can empower the team to have greater control of their own destiny by solving their own challenges.