The Elusive T-Shaped Team Member

A T-shaped Agile team member is someone who has broad experience (the horizontal bar of the “T”) who also possesses subject matter expertise in one area (the vertical bar of the “T”).

What is a T-shaped Team Member?

A T-shaped Agile team member is someone who has broad experience (the horizontal bar of the “T”) who also possesses subject matter expertise in one area (the vertical bar of the “T”).

An example might be a developer who has deep experience in coding and who also has broad experience in banking – e.g. knowledge of how equities and bonds are traded and has good knowledge about trading systems etc.

What are the benefits of T-shaped Agile team members?

The main benefit of a T-shaped person is they can not only deliver against User Stories in their domain, but can also contribute during Sprints to help others who may lack bandwidth or expertise in other areas. For example the developer could help a PM write an RFQ.

What are the drawbacks of Agile teams comprising T-shaped team members?

The main problem with building an Agile team comprising T-shaped people occurs when the majority of work in a Sprint or across a series of Sprints falls to one area of expertise.

Imagine a team of six where everyone is T-shaped and their subject matter expertise is;

Developer

Business Analyst

Lawyer

HR

Technical Author

Marketing

Imagine that the team has a huge amount of legal work where the lawyer has to read, evaluate and revert to external counsel in preparation to meet a regulatory body.

Now imagine that the Management Team has prioritised the legal work over everything else, so this Agile team gets 40 User Stories for the next Sprint, knowing that the team members are T-shaped.

The problem is, the team only has one lawyer. That person may be able to hand over proof-reading etc to other team members, but it would not generally be possible for the other team members to do the specific work of a lawyer to the standard required especially when sharing materials with 3rd parties.

This is were cracks can form in Agile teams.

When is it better to silo expertise into a single Agile team?

An organisation should build generalist Agile teams as well as building teams of excellence – e.g. in fields such as IT development, law and marketing.

The important thing to realise here is, that when work is transferred between Agile teams or even between T-shaped members in the same team, there is a cost associated with the handover – depending on the gap in skill-set between the team members.

Agile Team Health-Check

Please contact Agile Unpacked if you think you could benefit from an Agile health-check, whether it be in the Agile Framework as a whole or with your teams, processes or materials.

Got a Question? Ask Agile Unpacked…