What is the term for a team member who is t-shaped in agile

It’s about “T-shaped” teams too!

One of the challenges for organisations when they move to Agile ways of working is the often mentioned need to build teams made up of “T-shaped” people. This can also be described as a cross-functionality. The Scrum Guide describes cross-functionality as:

“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”

The “T-shaped” metaphor comes from the idea that an individual can possess deep skills in a few areas as well as a broader range of shallower skills.

The Challenge

For many people this concept can be a challenge because:

• Historically organisations are built around teams of similarly skilled individuals or components of the system, e.g. QA team or “Backend” Team
• Management lines follow these organisational structures too, e.g. Development Manager
• Entire careers are built by specialising in highly sought after skill sets, e.g. Front end developers
• There is a common misunderstanding that because each person should be T-shaped each person must possess every skill needed to deliver.

The Problem

The traditional approach of building teams around common skills and components has a number of problems in the complex world we now inhabit:

• There is a large coordination cost in order to move a piece of work though all the required areas, it is traditionally the role of project management to manage the dependencies that this causes
• Knowledge will be lost during the handoffs between various specialisations, decisions made up the chain will be lost as work moves through various teams
• Individuals become highly siloed in skill set and product knowledge, the motivation to expand skills and knowledge becomes more difficult
• The “it’s not my job” attitude can become prevalent where individuals have no motivation to be responsible for anything more than their specific component

A Common Misunderstanding

The common misunderstanding within many organisations that a specific person has to possess every skill is a challenge. In reality,  an individual person within a team doesn’t have to possess every skill in order to be T-shaped, the whole team does. The following diagram illustrates this point. Each “T” represents a different team member with a slightly different set of skills:

The concept is not a new one, in fact the idea was documented in the seminal paper from  Takeuchi and Nonaka, The New New Product Development Game back in 1986:

“They [team members] also acquire broad knowledge and diverse skills, which help them create a versatile team capable of solving an array of problems fast.

Such learning by doing manifests itself along two dimensions: across multiple levels (individual, group, and corporate) and across multiple functions.”

The Benefits

By building a team with a mix of skills rather than around a specific skill set, the organisation will be able to:

• Minimise dependencies between teams, resulting in fewer challenges with coordination and differing priorities
• Reduce handoffs between knowledge silos, avoiding information loss
• Broaden and deepen the individual team members skills over time through collaboration
• Foster team ownership of the whole solution rather than specific slices

The same model applies to larger organisations that have many teams. The analogy scales nicely; you can’t expect every team to have all the skills from day one, but across all the teams you will have the blend of skills needed.

Now this could conceivably cause problems where a small number of teams (maybe even a single team) possess a very specific set of skills. Such teams will essentially become a dependency to the other teams, going against the idea of cross functionality.

There are three options which can mitigate this problem:

• If the skill set is highly specialised, expensive or regulated then you will probably have to live with this dependency. Prioritisation will be a challenge and requires careful consideration, over time you should look to uncouple this dependency but it may not be possible
• If the skill set is less specialist but it’s still difficult for the wider group of teams to be totally proficient then their are a couple of approaches you could take:
  • apply a model where the specialist team supports and enables the development in other teams; this is the approach that Spotify take for their client apps teams
  • in Large Scale Scrum it suggests the concept of a traveller developer who rotates teams every couple of sprints with the aim of sharing skills and knowledge.
• The last and most desirable option for the long term would be to reorganise the teams so these skills silos no longer exist, either by training or a better distribution of skills in the teams. A warning on this, frequent changing of teams is highly destabilising and changes should not be a considered lightly.

Summary

The types of changes described here will be difficult to overcome for many organisations. However, with careful planning, consideration and understanding of what makes a successful high-performing teams will result in an organisation that will be better placed to deliver value to their customers.

If the challenges talked about in this article resonates with you and you’re curious how Adventures with Agile can help your organisation, please talk to the AWA Team today.

I’m an Agile Coach and a former a software architect. Outside of work my interests are travel, snowboarding, video games and cooking.

What is a T

What is T

What is a T skilled team member?

What is the term for a team member who is T