Highly specialized teams and the software ecosystem

Winter has definitely arrived -- for the moment -- along the northern Front Range. Before the wind came up, there was a solid 16 inches of snow on the ground here. Now there are bare patches interspersed with deep drifts. Unlike a true winter storm, however, the follow-on was not a deep, bone-chilling cold. It's already just above freezing and the forecast calls for rapidly increasing temperatures beginning tomorrow. By next week it should be downright fall-like again. Wintry weather is so much easier to take when it is doled out in discrete parcels.

But now back to Scrum teams....

Last time I wrote about Scrum teams operating as organisms within an ecosystem. Some teams find their environmental niche very cozy, so much so that they specialize to a degree that makes them vulnerable to changes in the broader ecosystem. Software companies and software operations within other types of companies both operate in notoriously changeable business and technological environments. If a Scrum team becomes comfortable, complacent even, with its current skill levels and dispersion of knowledge, disaster can be lurking just around the corner.

In my experience, there are two problem areas that revolve around specialization. The first involves teams that know their domain and technology inside and out, but have stopped learning. Some teams have even stopped learning about how to improve their processes and interactions, making them stagnant and vulnerable to any changes, whether internal to the team or in the external ecosystem.

The other problem area is internal to the team: individuals have specialized skills, as we expect, but there is very little cross-functionality. The team does not practice pair programming, does not engage in code reviews, does not engage in collective design or shared refactoring -- in short, lacks the generalizing specialists that are key to keeping teams alive and growing. Teams in this state are also highly vulnerable to changes in their ecosystem, but they are even more exposed to changes in team composition. If any member of the team leaves the company or simply moves to a different team, the overly specialized team will suffer as a result. If they have been complacent for a long time, they may not remember how to adapt to changed internal or external circumstances.

So, what's a coach to do? For the first type of specialization, that of stagnant domain and technology knowledge, a good coaching technique is to plan a small amount of slack, say five to ten percent of the team's Velocity, into every Sprint which team members can use to broaden their knowledge. A good tactic is to use Spikes to keep research projects time-boxed and to encourage team members who take a Spike task to provide a report to the team that lays out their findings. As formal tasks, Spikes are also more likely to be taken on during a Sprint. Another way to help a team broaden its knowledge is to place stories or tasks on the team's improvement backlog, which the team plans out during Sprint planning and updates at every Sprint retrospective.

For the second type of specialization, use each Sprint retrospective to encourage team members to set pair-programming rules or goals, schedule shared code reviews, and perhaps also lunch-and-learn sessions taught by each team member on a rotating basis. These ideas for improvement should also be added to the team's improvement backlog, prioritized, and planned out during Sprint planning. Teams that lack adequate cross functionality generally have difficulty meeting their Sprint commitments, making these types of improvements even more vital.

What happens to teams that continue along their path of excessive specialization? As organisms occupying a specific environmental niche, they may suffer irreparable damage if anything about their ecosystem changes, including internal team modifications. In the natural world, organisms that are unable to adapt to a changing ecosystem become extinct. Teams can suffer a similar fate, metaphorically speaking, if they lack the versatility, skills, and tool sets needed to adapt to an ever-changing business, corporate, and technological environment.

All for now.

...-.-