Last week in the blog, The Agile Team as Organism: Part I, 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 can make them vulnerable to changes in the broader ecosystem. As we all know, software companies and software operations within other types of companies both operate in notoriously changeable business and technological environments. If a Scrum Team[1] becomes comfortable, complacent even, with its current skill levels and dispersion of knowledge, disaster can be lurking just around the corner.
Two Problems Caused By Specialization
In my experience, there are two problem areas that revolve around specialization.
1. Stagnant Domain and Technology Knowledge
The first problem area involves Teams that know their domain and technology inside-and-out, but have stopped learning new things. Some Teams have even stopped learning how to improve their collaboration and interactions, making them stagnant and vulnerable to any changes — whether internal to the Team or in the external ecosystem.
2. Lack of Cross-Functionality
The other problem area is internal to the Team: we expect individuals have specialized skills, but sometimes 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.
Two Solutions to Solve Specialization Problems
1. Plan Slack
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 5-10% 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 on a Spike to provide a report to the Team that lays out their findings. As formal Stories, 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.
2. Set Pair-Programming Goals
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 Goals, 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.
Ready for your Team to gain the skills it needs to adapt seamlessly?
As Always, Stay Agile.
Notes and Sources
- “The Well-Formed Team Scrum White paper.” 3Back. Accessed May 04, 2017. https://3back.com/well-formed-team-scrum-white-paper/.