Time to discard the "T-Shaping" model!

 A common concept in the "Agile" community is that of T-Shaping. Regardless in which form or fashion it is promoted, the narrative is basically this: People have certain skills, and if they are one-trick ponies or are too generalist, they need to form a so-called "T-Shape." Nonsense!

The concept of the T-Shape

A specialist is a person with a very narrow skillset (making that person an "I"-Shape) while a generalist has a broad skillset (making that person a "dash"-Shape). 

A broad set of skills plus one deep expertise is a "T", multiple deep expertises are "Pi." And then, no model couldn't be "improved" by adding complexity, so we get variations like "M" Shapes, i.e. non-generalists with multiple expertises, and "E" shapes who aren't only experts, who also have "experience, exploration and execution." - although that's clearly buzzword bingo terrain, because what kind of an expert doesn't also have these?

Even I have blogged about T-Shaping, for example, here.

With the model, we were moving the burden onto people: "You must form a T/Pi/E-Shape." Thats nonsense, because it's not like people wouldn't do that on their own volition. In fact, most people who find that they can't use their skills at work will spend their time acquiring off-work skills, such as, for example, learning an instrument: everyone is Pi-Shaped, the only question is if it helps the company.

And now, I announce the time to ditch this model in favor of another model that already predates the Agile Manifesto - "Psychological Flow", by Mihály Csíkszentmihályi.

Psychological Flow

Let's take a look at the model Csíkszentmihályi proposes: He uses the dimensions of "Challenge Level" and "Skill". The very assumption that people have "one" or even a very limited number of skills is already absurd. Consider, for example: breathing. Do you know anyone who doesn't have this skill? Depending on what would qualify as a "skill," people are experts in thousands of them.

Instead of thinking about skills as discrete variables with a discrete set of values (e.g., "none", "basic", "advanced", "expert" ...) - we could think of "skill" as a continuum of different, integrated topics on a continuum spectrum.

Most importantly, the psychological flow proposes a second dimension: the level of challenge, in relation to the skill. For example, asking a Chess Grandmaster to state how a pawn moves is like a relaxation exercise. On the other hand, someone who never cared about Chess won't even take an interest in this question, "why should I care?"

If you'd ask a senior project manager to take care of large, critical programme, that brings out excitement and a sense of, "I am the right person for this job, and I can do it." Their brain would immediately sort through potential approaches and how to make it a success.

A college fresher, on the other hand, might be anxious about where to start and what to do.

That's the basic concept.

Notice that neither the "challenge level" nor the "skill level" are measured on an absolute scale - they can be considered from the perspective of the person who is doing the work: Is this work "low challenge" or "high challenge," does it require "low skills" or "high skills?"

How is Flow related to T-Shapes?

Well, it is - and it isn't. Instead of asserting that a person has a certain skillset required to do the job, we reframe the skilling challenge:

1. Is a task adequate to a person's skill level?
1. We should not under-challenge people, lest they bore out.
2. We should not over-challenge people, lest they become become worried or anxious.
2. How do we ensure that people receive challenges which allow them to use high skill?
1. High challenge, medium-skill tasks get people to become interested in what they do and that's how they grow.
2. High challenge, high skill tasks bring the best out of people.

The challenge, hence, is to identify meaningful, highly challenging work which is at least within grasp of people: medium skills get people excited, high skills get people to perform at their best.

Failure in "T-Shaping" isn't on the individual - it's team management not ensuring people have sufficient challenge to grow and show their performance.

(note based on feedback: in a self-managed team, "team management" isn't top-down - it's what teams decide to do)

T-Shaping ignores Flow

The T-Shaping model makes an implicit assumption: that all the work in the expertise domain is of interest to a person, and that it's a good use of their skills. This isn't always the case. Part of the work may make a very advanced person fall asleep, while being quite challenging for someone new to the domain. Hence, the best way to distribute work in a team isn't based on a certain "T-Shape," but to ensure that people reach a flow state - that is:

A team as a whole performs best not when people exercise a certain "T", but when the work provides everyone with sufficient, yet not overwhelming, challenge.

We shouldn't upskill with the goal of acquiring an abstract "T-Shape" - that's a weird framing already. 

Instead, we should distribute work in a team so that everyone is excited to do what they do, while ensuring nobody is overchallenged and anxious or underchallenged and bored.

Whether the result is something like a "T-Shape," doesn't even matter - because the primary result is a highly qualified team whose members are comfortable taking on slightly bigger challenges every day. 

Let's forget the T-Shape.

Let's refocus on the question, 

"How can we distribute work within our team, so that everyone gets to spend the highest amount of time possible in a flow state?"

Three things a good Scrum developer brings

It's usually not about how many years you have worked in Software Development, not about how excellent you are in a specific discipline - although it certainly helps, it may occasionally be detrimental. That is the case when a developer's history makes it impossible for them to move forward.

Here are the three things which make a good Scrum developer:

1 - Engineering Practice
Mastery in Engineering Practice is very hard to achieve - but if you don't even have these as basics, everything you produce will most likely cause more problems than it helps: Technical debt is much harder to manage than avoiding.
Getting the basics down on these only takes a couple days - getting the practices on a value adding level takes a fairly long time.
Think, among others, of:
Emergent Design - The art of designing your code so that you are never maneuvered into a corner where you can't meet a reasonable customer request due to technical constraints.
Sustainable Test - Moving from simply writing unit or behaviour tests to the level of testing the right thing, the right way, to get meaningful feedback at minimal cost - while equally avoiding the pitfalls of flaky tests and constant test rework.
Clean Code - Applying SOLID principles "just enough" to end up with easy-to-understand, well-tested, robust code that does not rely on heavy documentation and is easy to work with.
Refactoring - Tweaking the code just at the right time to make it fit for the current purpose without breaking anything.

2 - Lean Thinking
Your horizon must extend far beyond the Software level, Keep Lean's "Optimize the Whole" in your head. You must grow your product, avoid waste, eliminate "work to do", simplify processes, keep customers happy and your organization profitable. At the same time, you don't want to get stressed - and to focus: Quite a feat. Can you properly apply these to your work?
Value - Discriminating "what is asked" from "what is useful".
Value Streams - Discerning the easiest way to get from customer need to customer satisfaction.
Flow - Slicing down the work, avoiding BUFDs and Big Bangs.
Pull - Leaving the tiresome treadmill of featuritis, moving towards sustainable pace without losing business opportunities.
Perfection - Never being content with "good enough", while at the same time avoiding the waste of "gold plating".

3 - Agile mindset
A key pillar of agility is the Inspect and Adapt mechanism. Regardless of how professional you are, you're probably not a prestidigitator. How well do you do in this arena?
We don't know - There are many things we don't know. Some things we know that we don't know, and other things we don't know that we don't know.
We must learn -  We must continually strive to learn and incorporate our learning into our approach and behaviour. We must accept that yesterday's "right" may be today's "wrong".
We must collaborate - No one person can know or do it all. Only by collaboration can we attain the best possible outcome. This collaboration includes developers, business people and customers alike.

Summary

Being a good Scrum developer requires much more than being a good programmer. The mindset change and learning required to grow into this role may require quite some time, but it's a road definitely worth taking.
Of course, understanding your delivery framework, such as in this case, Scrum, is also advised, but that's probably the easiest part to pick up.

T-Shaped People: What and How

T-Shaped People in a cross-functional team will solve capacity problems much easier than limited domain experts. In general, agile methodology calls for T-Shaped People. Unfortunately, there may be cases where the basic approach may not work, or worse: be counterproductive.

Skill can be learned

Developers learn each of their domains, such as Java, C++, Python, PL/SQL etc. Picking up basics in a skill usually doesn't take more than a couple of days - mastery will take long, however. The more frequent a skill is utilized, the more fluent developers become. For example, simply confronting a front-end developer with the Unix Shell will permit them to pick up enough bash to get basic stuff done. Over the months, the developer will gain sufficient expertise and confidence to do even more intricate tasks in the new domain without relying on help.

Not everything is worth knowing

Certain skills may simply require a high level of expertise before they are actually valuable. For example, basically knowing Testing is not valuable in and of itself - if you don't understand what you must look for to catch the hidden bugs, your test may provide a false sense of confidence and cause more harm than good - so the team actually has to decide whether this specific skill is actually worth distributing in the required depth.

It is good to have more than one test expert on the team, but whether everyone should be able to pass the ISTQB Foundation Level without studying - is a completely different question.

For T-Shaped growth, apply the simplicity principle: Acquire as much skill as necessary to resolve potential bottlenecks, but do not revel in domains that are not your own.

Maintain Diversity

Do not confuse "T-Shaped People" with an anonymous mass of developers where everyone is equal. People still have individual strengths, individual focus and personal goals. One developer may really dig numbers, while another digs performance. Diversity is good. A Cross-Functional team should celebrate diversity rather than blending towards equality.

Again, the goal for T-Shaping is not to make everyone equal, but to resolve bottlenecks.

Not everything needs to be T-Shaped

One lesson of T-Shaping that is difficult to understand: Some people are simply not fit for certain tasks.
While our environment can force us to be more or less plan-oriented or more or less creative, the inherent brain-orientation will limit our performance in a specific domain. For example, a Left-brainer can learn how to use a drawing tool or a Right-brainer how to use a planning tool - but their approach will still be different, and - consequently, the result.
In some cases, this is actually desirable. In other cases, it is a clear reason for that person not to take on a specific task. In these cases, it's still viable to consider passing the buck on that one.

When "good enough" is too high

In rare cases, the limit for "good enough" is so high that only domain experts should take on a task. A specific case here would be the design of graphics and sound. Such artwork is either "good" or completely unacceptable. There is not much middle ground.

While you can train a Java developer to use a paint tool, the result of taking on a "paint a landscape" task will most likely be underwhelming. In such a case, it is definitely not worth considering shaping a "T".
The benchmark definition of "acceptable" set in the specific domain may occasionally turn the business value of T-Shaping so negative that it is simply not worth considering.
In this case, the organization must find different alternatives.

Summary

The simplest approach towards T-Shaping is simply picking up what you need on the go. However, you must ask the question "Will we need it?" and "Will the output actually be valuable?". If the answer to either of these questions is "No", then the organization must find different ways of ensuring that the specific skill does not become a bottleneck.

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.