Specialists Are Overrated

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” – Agile Manifesto

“Watch the baton, not the runner.” – D. Reinertsen, 2007^[1]

Traditionally, notions of efficiency have been to minimize cost by utilizing experts (i.e. expensive people) only on the most difficult problems and having cheaper workers do the other work. This approach is effectively the underpinning of a matrixed organization. The problem is, as soon as we create a special role to solve a problem, the expert who fills that role has every incentive to ensure the problem never goes away. Agile is different —its focus is to find ways to deliver the best product possible that fits the customer’s need in the shortest possible time using a team that works collaboratively to tackle both the difficult problems and the more mundane tasks.

Scrum, and Agile generally, work by forming stable teams, which operate cohesively and focus on one feature at a time. Because they’re stable, Scrum teams can grow and become better equipped to deal with both bottlenecks and changes in demand. They do this by developing “T-shaped” team members, effectively distributing “expensive expertise” across multiple team members, rather than consolidating it in singular experts.

What is T-Shaped?

A specialist (i.e. an expert) is someone who has the skills and knowledge to work highly effectively at one station or one type of work. The drawback to having many specialists, and the downfall of matrixed organizations, is that, in any system, they are often just piling up inventory^[2]. If they keep producing when their work isn’t in immediate demand, such an unused specialized work product becomes a source of risk for the business. It might contain defects or represent a misunderstanding of the customer need, but because the work is not in demand, it is unlikely to be checked for errors. This is a waste and does nothing for efficiency.

Some Examples

• A Senior Developer writes server-side code only. If the team currently has a bottleneck in testing work (i.e. there is more work than can be tested soon), then any new server-side code the developer writes becomes a form of unused inventory.
• A marketing department has a clear separation between writers and editors. If editing of work is currently backed up, any new writing work contributes to the backlog, becomes stale, and increases team frustration because they aren’t seeing any meaningful results from their work.

We often call specialists “I-shaped” people. At the other end of the spectrum, we also have generalists, the infamous Jack-of-All-Trades.

In Scrum, we have discovered something in the middle is far more effective: “T-shaped” people, aka the “Generalizing Specialist”. That’s a mouthful. A generalizing specialist is very good at one or two skills areas, but can also possess working knowledge to help out in some others.

Why Have Generalizing Specialists?

There are many advantages and rewards to developing T-shaped individuals in the team. These include:

Benefits for the Organization

• They reduce how often the organization is constrained by bottlenecks. (Example: Toyota trains employees to handle multiple stations, so they can contribute where the workload requires.)
• They are stuck less often waiting for other teams (aka external dependencies).
• They are predisposed to share knowledge across the team, increasing the lottery/bus number (i.e. The number of team members we would have to lose – they win the lottery or get hit by a bus – before our project stalls due to lack of knowledge ^[3]).
• They are better able to adapt to changing demands, instead of only being able to work on features that fit their narrow skillset.
• The team is better able to complete work in the Product Owner’s priority order instead of having high priority work wait for specialist skills.

Benefits for the Customer

• By reducing bottlenecks, the customer gets the work they asked for sooner (in Kanban this is measured as Lead Time^[4]).
• Quality is higher because more people have the skill (and flexibility) to review the work for errors or bugs.

Benefits for the Team Member

• T-shaped people have a greater number of marketable skills and proven adaptability than I-shaped people, which makes job opportunities more plentiful.
• Since it’s human nature to enjoy novelty and variety, being T-shaped makes it easier to find satisfaction inside a project since they are not restricted to certain tasks because of skill limitations.

Where are the Limitations of T-Shaped People?

• Testing or editing your own work often leads to blind spots. To avoid this, try swapping with someone else so you can review each other’s work for errors.
• With some knowledge areas (e.g. Hardware Development, User Interface Design, or foreign language translation) there are limitations as to how far any non-expert can develop functional expertise. Realistically, while having T-shaped team members can minimize the need for specialists, in some cases it will be impossible to eliminate the need for them entirely.

How to Become T-Shaped

You become T-Shaped by cross-skilling (also known as cross-training or multi-skilling). This involves learning and practicing skills relevant to delivering the product. Examples of this could be a marketing writer, learning the basics of copyediting, or in the case of web development, having a back-end developer learning to read and write CSS (normally the work of a designer or UX specialist).

To be effective, cross-skilling requires an organization committed to supporting its teams in this endeavour. Ideally, this would be accomplished by establishing a plan for cross-skilling that is created collaboratively with the team. This plan should include the reasons why the team is learning to cross-skill, set out sufficient time and resources to accomplish this, acknowledge the additional workload required for a person to learn until they are proficient in new skills, and some kind of recognition mechanism for team members that successfully cross-skill. It also should outline where the team will focus on developing cross-skill strengths.

So, How Do We Decide Where to Cross-Skill?

There are two major ways to discover opportunities for cross-skilling:

Kanban/Scrum Board
Skills Matrix

We’ll explain how to use both in our next post.