What it means to have T-Shaped People

Agile practice advocates a "Whole team approach". This means that not individuals, but the whole team is responsible for results. One of the pillars of this approach is "T-Shaped people", where team members are highly qualified experts in one domain, but at least basically proficient in other domains.
 

T-Shaped People solve Bottlenecks

The main reason for T-Shaped people is resolving bottlenecks within the team.

Eli Goldratt's Theory of Constraints states that the output of a system is limited by the slowest component, the so-called "Bottleneck".

For example, testing and coding often have vastly disproportionate effort: If there are 10 user stories "waiting for test", it makes more sense for a developer to test one of them than developing 2 more stories.

The classic argument, "Hire more testers" is not the solution for dealing with bottlenecks, because bottlenecks may arise and dissolve fluently. For example, your DBA may be sick - or your Frontend Developers take a 2 week's vacation. The duration of the bottleneck is too short termed to onboard a new person, but too long to simply let everyone else idle.

T-Shapedness develops over time

Usually, teams setting out on the Agile Journey are constituted of domain experts with a limited horizon. Coders are unfamiliar with test practices, Analysts are unfamiliar with modern software development frameworks, DBA's don't know how to code, etc.

We can simply accept this at the start: Nobody has been born a master. First, bring together a team where all necessary capacities exist and simply let people collaborate. Encourage pairing for mutual learning, and the necessary "T" will nevolve.

There is no reason to not encourage becoming T-Shaped, because a team of T-Shaped People will always fare better than a team without the "T".

T-Shaped People are not "Master of all Trades"

T-Shaped people are able to help out in times of need. They can grab a task that is stuck to increase the flow within development - but that doesn't mean they are nearly as good as the dedicated expert. This means that they may need significantly more time to achieve the result. Likewise, they may miss elegant solutions. We accept these downsides because a slow result is still better than no result - and refactoring allows us to increase the elegance of a solution if it ever matters.
In the end, it's not about perfection - but about achieving the best possible result with the people available.

Summary

Working towards T-Shaped people is an important way of increasing output and utilization of the team, while minimizing overall cost of development. T-Shaped developers are not supermen, but apt at always taking one step forward, regardless of the domain they are working on.