How Do We Get All the Work Addressed When Our Specialists Cannot Be Everywhere?

Work in progress. Basically just a brain dump atm


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.


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 T-shaped people: Reduce bottlenecks (WIP), enable swarming for faster problem resolution, enable learning and growth of individuals, team empowerment increased - able to take on anything, less single point of failure / improved resiliency of the team (and organization), improved communication and collaboration, less documentation required to hand off information.
  • Defining / Example: 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% of the specific area
  • Doesn't this mean I become less effective as a “developer” for example? 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. Or 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). Lets 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:

Use the following URL for manually sending trackbacks:
what_is_pair_programming, 2016/06/20 14:09 (Trackback)
What is Pair Programming? Or “what are the benefits of pair programming?” Or “how should I get started with pair programming?” Basics I've recently has a number of discussions about the benefits of pair programming. Some of the thinking was that the main use of pair programming was as a learning tool, to help break down our specializations. This is the result of the emphasis we made in answering the question of breaking down specialization on a team (see
what_should_we_consider_when_forming_a_new_team, 2017/03/02 06:33 (Trackback)
What Should We Consider When Forming a New Team? Premise When you first bring Scrum into an organization you need to set up teams. Sounds easy, doesn't it until you starting thinking through the problem. That's when you start to understand that this may not be as easy as you thought.
You could leave a comment if you were logged in.
  • /home/hpsamios/
  • Last modified: 2018/12/03 19:26
  • by Hans Samios