James O. Coplien

Robert Heinlein has a great quote on the topic of specialization:

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight effectively, die gallantly. Specialization is for insects.

One of our favorite Scrum patterns is “Cross-Functional Team”, but there is much confusion about its meaning. Folks commonly assume it means that everyone should be able to do everything. This is probably ideal for minimizing talent blockages, but folks discount it as unrealistic and too costly from a training perspective. The intent behind cross-functional teams is that they should offer all competencies necessary to complete their work, and in particular, that developers collectively have all skills necessary to efficiently build product.

Why does Scrum call us to this kind of work community? First, to handle variance. You can’t staff a team with exactly the right number of UX designers, testers, programmers, and database people to match the workload ideally. The demand for each specialization changes both during the Sprint and from Sprint to Sprint. Over-engineer a bit to reduce the risk. Second, we want to make sure the team isn’t blocked if one uniquely skilled person is overloaded or on sick leave during a particular Sprint; another team member should be able to pick up the slack. Third, times change. The market calls for one set of expertise today and may call for another tomorrow. Don’t hire team members for what they know today or for how they have applied their knowledge in the past, but rather for their ability to acquire and apply emerging knowledge in the future.

In his book, Drive: The Amazing Truth About What Motivates Us (Riverhead Books, 2011), Daniel Pink reminds us that people love to grow in their area of specialization (Mastery), so these calls to cross-functionality elicit a visceral, negative reaction. The usual claim is that you can’t have an expert in every field within the team’s endeavors. The more sober perspective is that you don’t need world-class excellence—just competence. If necessary, use kaizen to grow from there.

Scrum emphasizes learning as a team. Let’s say that, again and again, you find you are missing some specialized skill set, or that you need more knowledgeable testing people than you have. Fix it—with cross-training (which is cheap and adds value) or hiring (which adds both short- and long-term cost and risks more rapidly bringing your team to a point of diminishing returns on capacity as a function of size). The sooner you fix it, the sooner you’ll be improving again. You’ll suck in the meantime, but that’s OK. Good kaizen bears a bit of reflective regret.

And it’s great to belong to a team where people can learn as individuals. Pink’s admonition about growing in knowledge doesn’t imply a limited number of specializations; it is just as rewarding, or more so, to grow in mastery of a new area. Great team members learn, grow, and diversify their skills.