Or “How do we keep everyone busy on the team when some team members have specialized skills that cannot be used based on the current priority of backlog work?”

Most organizations, when they move to an agile approach, see a real problem when they understand that agile suggests that teams are stood up to do the work (in fact, the unit of execution becomes the team), that the teams are relatively small (7 people plus or minus 2 - or 5-9 people), they are long lived (so they can get better at delivering value) and they are meant to be wholly responsible for delivering value (new request for value comes in and 2 weeks later we have something that is potentially shippable).

The argument is “while I can see how this works for a small product or a startup, how can we make this work in the context of our solution / product where we have 100 people working on a single release?

There are two basic ideas that make this possible:

1. The development over time of T-shaped people (or generalizing specialists)
2. The creation of teams that can do most of the work of delivery in most cases.

This note is about the development of “T-shaped people” or the “generalizing specialist”.

Page needs to cover:

• Where do the specialists we have come from - they didn't start that way. Basically the result of traditional (resource) management approach - we have this problem, George knows about this area, we will give the problem to George (and most importantly, no one else will get it)
• What are the benefits of having a team with some T-shaped / generalizing specialists people:
  • Reduce bottlenecks (WIP)
  • Enable swarming for faster problem resolution
  • Enable learning and growth of individuals
  • Increase team empowerment - able to take on anything
  • Less “single point of failure” if specialist is not available. This means improved resiliency of the team (and organization)
  • Improved communication and collaboration across the team
  • Less need for documentation required to hand off information between people
• Defining the term: 1) has on or more technical specialties 2) has a general knowledge of software development 3) has a general knowledge of the domain they are working in 4) actively seeks to gain new skills and knowledge in both their existing specializations as well as others in both the technical and domain areas in which they work
  • Perhaps add to this 5) has a general understanding of the psychology of the people they are working with.
• Does everyone have to be expert at everything - no. Pareto principle applies - with 20% of the knowledge of the true expert can deal with 80% tasks associated with a specific area. Plus they can reach out for help if they get stuck.
• Doesn't pairing mean we lose capacity because two people are doing the work of one? “Pairing is shared thinking; not shared typing.” Expect to lose some, but probably less than you think, especially if you use “strong sided pairing” - see below
  • Note: this is probably the fastest way to develop new skill
  • Besides isn't it more important to be developing skills related high priority work for which we don't have enough people, than to keep people busy on low priority work because they are limited by the skills they have?
• Doesn't this mean I become less effective as a “developer” for example, if I also now take on “testing” skill? Expansion of knowledge means you become better at your job - if you are a developer and understand how testing thinks / works, you will be a better developer. If you are a developer and understand a bit of psychology, you will be a better developer in a team oriented area. If you are a developer and understand the domain better, you will be able to provide better solutions and suggestions.
• How do you create T-shaped people? Incrementally. Take opportunity to pair as you do work.
  • One practical approach is to use “strong side pairing” where pair consists of “expert” and “novice”. The novice has the keyboard, and responds to “commands” from the expert of what to type and do. The expert explains the “why” she is doing what he is doing and “intent” as she commands.
  • Another practical approach is to have the team actively figure out ways to work together on things - eg design session includes all roles, not just developer / architect - and so increases ability / understanding of all.
• Does this mean that everyone is a generalist? No. Teams with specialization will out-perform a team of generalists (Anderson 2004:271). Let's face it the world is increasingly specialized and for good reason. Problem is that we have gone too far where “specialization” now means “only able to do one thing”. We need specialists but we also need more than a group of “one trick ponies.”
• From HR perspective, look to widen people's job descriptions so they see their role in a wider context.

Additional information can be found at:

• Swiss Army Knife or Generalizing Specialist - Jeff Atwood addresses some common concerns about building T-Shaped people.
• Generalizing Specialist - Scott Ambler
• Cross-finctional Doesn't Mean Everyone Can Do Anything - A note by Mike Cohn. We are not trying to create a team where everyone is a generalist.
• How Do We Establish Skills Development in the Team?