Generalizing Specialist

Agile teams are formed (mostly) of generalizing specialists.  A generalizing specialist, sometimes called a crafts person, is someone who has one or more technical specialties and can contribute something of direct value to the team, has at least a general knowledge of software development and the business domain in which they work, and most importantly actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas. Generalizing specialists are the sweet spot between the two extremes of specialists, people who know a lot about a narrow domain, and generalists who know a little about a wide range of topics.

Why Generalizing Specialists?

There are several reasons why you should prefer to build teams from generalizing specialists:

Improved communication and collaboration:

 A generalizing specialist is someone with a good grasp of how everything fits together. As a result they will typically have a greater understanding and appreciation of what their teammates are working on. They are willing to listen to and work with their teammates because they know that they’ll likely learn something new. Specialists, on the other hand, often don’t have the background to appreciate what other specialists are doing, often look down on that other work, and often aren’t as willing to cooperate. Specialists, by their very nature, can become a barrier to communication within your team. Another challenge with specialists is that they have difficulty working together effectively with others because they don’t have the background to understand the issues that the others are trying to deal with.

Less documentation:

 Specialists are often motivated to create far more documentation than is required, when all you can do is write use cases then those use cases will end up including information that could be better recorded elsewhere, and very likely require reviews of said documentation when they provide it to other specialists. The implication is that the same piece of information will often be captured by several specialists because they’re afraid that they’ll lose that information.  A generalizing specialist will write less documentation than a specialist because they have a greater range of options available to them.  The implication is that a team composed of generalizing specialists will be more effective than one composed of specialists.

Improved flexibility:

 In his discussion of integrating usability specialists onto an agile team, Paul Hodgetts discusses several practices which result in productivity loss which are motivated by having specialists on your team. Specializations forces the team to pre-assign tasks to individuals, thereby hindering the team’s ability to dynamically allocate tasks as new circumstances emerge.

Reduced risk:

Specialization drives teams to break down their iteration tasks to accommodate each person’s specialty, resulting in finer-grained tasks and more points of hand-off between people.  The problem is that every time there is a hand-off between people there is information loss, documentation is the worst option for communicating information between people , thereby increasing overall project risk. Generalizing Specialists lower overall risk because there is less information, greater knowledge of the system among individual team members, and growing skills among team members.
Fewer bottlenecks: 

Specialists become bottlenecks, reducing overall team efficiency, when work queues up for them. For example, a single database administrator (DBA) is assigned to support four development teams due to lack of database expertise amongst other people. This would be perfectly fine if the four teams generated less than one person’s worth of data work in total, but in most organizations as soon as it was recognized that the DBA had slack time available to them they’d likely be assigned to one or more other teams until they finally had no more slack time available to them. So, because work load isn’t consistent work will queue up for them sometimes, which means that the teams which they’re supporting need to wait for them to get the work done, reducing overall team efficiency as a result. The specialist in effect becomes a bottleneck. Sadly, assigning experts to multiple teams is perceived by traditionalists as efficient because they look at it from the point of view of resource allocation instead of the point of view of overall team effectiveness.

For more information on Generalizing Specialists please refer this post from Agile Modelling