Agile Team Composition: Generalists versus Specialists

In a previous post, I described several of the shortcomings with planning poker, particularly when the tool is used in a context that includes more than just the developer’s shop. Estimating levels of effort for a set of tasks by a close knit group of individuals well qualified to complete those tasks can efficiently and reliable be cast with a tool like planning poker. Once the set of tasks starts to include items that fall outside the expertise of the group, or the group begins to include cross functional team mates, or both, the method becomes increasingly less reliable.

The issue is a mismatch between relative scales when the team includes an increasingly diverse set of project specialties. A content editor is likely to have very little insight into the effort required to modify a production database schema and therefore offer an effort estimation that is little more than a guess based on what they think it “should” be. Similarly for a coder faced with estimating the effort needed to translate 5,000 words of text from English to Latvian. The answer is to add a second dimension to the estimation: a weight factor to the estimator’s level of expertise relative to the nature of the card being considered.

A similar effect is in play when organizing teams according to Agile principles. When implementing Agile methodologies at the organizational level it is important to consider the impact of forming teams of generalists versus specialists. According to Scrum, for example, it is preferable to have a good measure of skill overlap – that is, generalized skills that allow for any one team mate to work on a variety of tasks during a sprint. This is very efficient for highly technical and coherent domains. Differences in preferred coding language among team mates is less an issue when all team mates understand advanced coding practices and the underlying architecture for the solution. In this case, it is easier to measure sprint velocity when a set of complimentary technical skills allow for cross functional participation and re-balancing when needed (vacations, illness, uncommon feature requests, etc.) As with planning poker,however, efficiency degrades as domain expertise on the team becomes more incoherent.

In cases where the knowledge and solution domains have a great deal of overlap, generalization allows for a lot of high quality collaboration. However, when an Agile team is formed to address larger organizational problems, specialization rather than generalization has a greater influence on team velocity. The risk is that with very little overlap specialized team expertise can result in either shallow solutions or wasteful speculation – waste that isn’t discovered until much later. Moreover, re-balancing the team becomes problematic and most often results in delays and missed commitments due to the limited ability for cross functional participation among team mates.

The challenge, then, for cases where knowledge and solution domains have minimal overlap is to find a way to manage the specialized expertise domains in a way that is useful (reliable, predictable, actionable). Success becomes increasingly dependent on how good an organization is at estimating levels of effort when the team is composed of specialists. The answer is to add a second dimension to the estimation: a weight factor to the estimator’s level of expertise relative to the nature of the card being considered.

With a weighted expertise factor calibrated to the problem and solution contexts a more reliable velocity emerges over time. With this enhanced velocity reliability comes an increased reliability in level of effort estimates, greater accuracy in resource planning, and less waste.