Hans Samios' Knowledge Base

... absolutely #noabsolutes ...

User Tools

Site Tools


how_do_we_get_all_the_work_addressed_when_our_specialists_cannot_be_everywhere

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.

Background

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.

Want to Know More?

Additional information can be found at:

/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_do_we_get_all_the_work_addressed_when_our_specialists_cannot_be_everywhere.txt · Last modified: 2020/06/17 07:55 by hans