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?"

The different definitions of Agility

One reason why getting different people on board in an agile initiative is because they may not understand what's in it - for them. We can put the different perspectives together by looking at the different definitions of agility. This allows us to negotiate better with people who have a different focus in their own work and gain their support for change.

Everyday definition

"Move quickly and easily." - Cambridge Dictionary

Note the two vectors here: Speed and effort. This definition doesn't focus on externally imposed change. Although only implicitly, it is primarily concerned with the ability to reach one's goals.

Managerial definition

Acting according to the current situation - Peter Drucker

“The greatest danger in times of turbulence is not the turbulence: it is to act with yesterday's logic.” 

Change is only a problem when we're not able to think and act in a manner suitable to the new circumstances. We must be sufficiently flexible to adjust when something unexpected happens.

Financial definition

"Turn on a dime for a dime." - Craig Larman 

There are business opportunities every day. Many businesses can't capitalize on opportunities for two reasons: Either, the cost of grasping the opportunity outweighs the gains from the opportunity (i.e., a negative business case). Or, the window of opportunity expires before we can grasp it.

Technical definition

"Minimizing the cost of change for code." - Kyle Griffin Aretae

"Cost of change over the long term is almost the only thing worth paying attention to when working in code. It's more important than doing any individual feature requested most of the time."

The initial creation of code is marginal compared to the cost of maintaining or changing the code. We have high code-level agility if there is a low cost of change for our code, and low code-level agility if we are spending a lot of time, energy and money to change our code.

The different focus

Looking at this diagram, we see that no single definition is all-encompassing - and that there is only a small overlap between them.

Hence, we have to be clear what we are setting out to achieve, and how we would like to achieve it.

• Do we want to increase sustainability and reduce effort? Unless we can tick these boxes, developers most likely won't care.
• Do we want to become more adaptive and faster? That makes our initiative interesting for management.
• Do we want to reduce cost and increase profitability? Otherwise, let's not assume finance will support us.
• If we're not in it to get more done in less time, surrounding stakeholders - like Marketing, Sales or Customer Service, won't care.

We can't dogmatically insist that we want to do only one thing, like increasing adaptability, because we'd struggle to get anyone to support this. Instead, we can use these different perspectives to have deeper conversations as to what people need from a change initiative, and how they would like to become part of this change.

And - the Customer?

Frankly - as a customer, I don't care about your agility. 

I care that I get what I want, how I want it, when I want it. How you do it - your call.

The importance of Retrospectives

"Can't we just skip the Retrospectives when we don't have the time?"

While I am myself not a big fan of the Retropective events that I see in many Scrum teams - when considering skipping Retrospectives, we solve the wrong problem: Retrospectives are Scrum's engine of Continuous Improvment. What matters is not the event, but that the team is constantly taking active steps of improvment. Retrospectives just kick-start the mindset of improvement.

The case for Retrospectives

• The purpose of the Retrospective is finding significant improvement potential. 
•  Significant, from a statistical point of view, is 5% or above. 
•  "5% or above" means, "Something worth at least 2 hours a week" 
• Investing 2 hours every 2 weeks to find something worth 2 hours per week already paid off within a single Sprint. 
•  A team improving by 5%, 25 times a year, will operate at over 300% of their original performance after a year - yes, they will be three times as effective as when they started!
•  A team skipping half of their Retrospectives, doing only 10 a year, will have improved to 150% of their original performance after a year - give or take variation, it will appear as if this team hasn't improved and is almost at their original level.
• A team having effective Retros every Sprint will visibly outperform a team skipping half of their Retros - to the point where they deliver twice the value per time. 
• Or, stated differently - a year down the line, a team doing effective Retros will be worth as much as two teams skimping Retros, and as much as three teams without any effective Retros.

The Bang for the Buck

A team investing into effective Retrospectives is worth twice as much to the company as a team which values delivery over improvement.

Teams taking Retroespectives seriously lead to an organization needing fewer people to deliver the same value. Hence, less coordination. Hence, teams get more autonomy, because they don't need to fit into a management corset.

Hence, developers can spend more of their time doing what they like best: writing code, not sitting in meetings. That makes them happier. And happy brains are more productive.

Also, since developers in such teams are worth so much more to the company, they are worth every cent - a great argument for negotiating higher pay.

Effective Continuous Improvement makes everyone a winner: Customers, getting better products quicker. The company, getting more value without hiring extra people. Developers, who get better working conditions, and deserve higher pay.

Retrospective Antipatterns

We have already touched the first antipattern: Skimping Retrospectives. Every lost opportunity of a Retrospective is an improvement not happening, putting the team behind on their potential, sacrificing a lot in the future to gain very little right now.

Skipping Retrospectives usually happens because teams have ineffective Retros. Each Retrospective that didn't deliver a significant improvement outcome was a waste. Hence, teams need to figure out how to get more value out of their Retro. Hint for Scrum Masters - There's a surprisingly low correlation between form and effectiveness of a Retro.

The third antipattern is giving up too early on improvement: If there are impediments towards improvenent, these need to be resolved, rather than taken as a reason to not improve.

If you feel that Retrospectives don't make you better, then improving that is your highest priority.

True story

I don't like formal Retrospective events all that much, but I do like a good continuous improvement process (CIP). Retrospectives are just one way to do it. CIP can be done totally informal. I just want to tell you this story to see how Retrospectives can transform a team.

One of my teams had a 2-hour lunch break every day. This "break" included having a walk, and talking about improvements. 

After 2 months, we delivered in a week what others would do in a month.

Within 3 months, we finished a project we had forecasted to take roughly half a year. 

Spending only 6 hours a day at our desks.

That's the power of Continuous Improvement done right.

Notice:

In the Post-Scrum Manifesto, I explain why active, continuous improvement is better than Retrospectives - and also, what you might be getting wrong about your Retrospectives at the moment.

SAFe Values - no real value!

Transparency, Built-in Quality, Alignment. Program Execution.

These are the four "SAFe Core Values." But - are they actually, "values?"

What are SAFe Values?

According to the official SAFe website, the SAFe Core Values are:

The four Core Values of alignment, built-in quality, transparency, and program execution represent the fundamental beliefs that are key to SAFe’s effectiveness. These guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.

I would like to focus your attention to the highlighted terms:

1. Fundamental beliefs: In order for "SAFe Values" to make any sense, you must buy into this belief system. If you don't share one or more of the underlying beliefs, the cookie crumbles and the "Value System" of SAFe becomes meaningless. Let's also mention that the idea of "fundamental beliefs" originates from religion - it doesn't coincide well with science.
2. Guiding principles: What is a guiding principle? Let's examine the meaning of a principle: "a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning." Here, we're pretty close to circular reasoning: SAFe Core Values are fundamental - because they are fundamental. A foundation isn't negotiable, because everything built on it collapses without that foundation. But - are these "fundamental truths" axiomatically true - or are they based on perspective?
3. Dictate behaviour and action - "Dictate" is a much stronger term than, for example, "orient" or even "inform." Based on the fundamentals, you have only one course of action, and it's not open to negotiation or discussion: it's mandatory.

From a linguistic perspective, the SAFe values are beyond scrutiny and would be considered a totalitarian rule: You must believe them, and you must do what they say.

Fundamental beliefs dictating behaviours coincide neither with science - nor agility.

Without getting any further into this matter, let me first clarify that I have never, ever experienced a SAFe fanatic. I have seen my share in the Scrum community, but SAFe practitioners - by and large - tend to be very pragmatic. "Doing what makes sense" is high on the list, and hence, I would give both the idea of "fundamental" beliefs and the idea of "dictating" behaviour a break.

That's just half the matter, though.

The other half is - how these terms tend to be understood in a larger corporation.

Much of an enterprise system is built around the idea that transparency is a one-way street, alignment equals incorporating others' opinions, quality a matter of governance. "Program execution" - well, it requires setting up programmes. With a separation between coordination and execution.

Not-so-fundamental beliefs

A problem of SAFe's core values is that these very underlying beliefs aren't defined from an agile point of view - when a company introduces SAFe, they are taken as "fundamental." Management understands these terms in a certain way, and discussing a "fundamental truth" seems to be a waste of time, because - they're fundamental, and we already understand them. Hence, the crucial discussion, "What do these terms mean?" won't happen. Instead, the terms become a projection of status quo onto an agile organization.

If you start with these four key premises:

1. Transparency: We require a chain of command giving clear orders, and we rely on detailed reports.
2. Alignment: We must ask for the opinions of people not doing a specific piece work, and only do things they agreed to.
3. Built-in Quality: We need some kind of governance telling people what their job is, and how to do it properly.
4. Program Execution: We must set up large programmes which bind a lot of time, money and manpower.

... then congratulations: the core idea of "Agile" is already dead and buried.

Hence, we first need to discuss how we want to understand these terms before we can build an agile organization where these terms even make sense.

What's (a) Value

Unlike beliefs, values aren't "fundamental," "truths," or "principles."

Value, as defined in Oxford dictionary, is:

Value - how much something is worth in money or other goods for which it can be exchanged.

Note again, that there are two critical statements here: worth and exchange.

A value is about the "worth" of something, not a boolean attribute. 

When asking, "What's the value of this car?", you wouldn't expect "Yes" as an answer.

Value only exists when there is a metric and a conversion rate towards another entity, so that people can decide what kinds of trades they would make - and which they would not.

For example, let's assume we measure quality on a scale of 1-10, and you have a quality level of 5. That's merely a measurement: It's not a cross-referenced metric. If you want quality to have value, you would need to relate it to something else, such as "1 quality is worth 3 time."

The statement, "we must have all of built-in quality, alignment, transparency and program execution" would not define "core values." To have an actual value system, we must be able to make trades between quality, alignment, transparency and execution - and we must be able to determine which trade-offs are advantageous, and which aren't.

How much execution are you willing to invest into alignment instead? How much quality would you give for transparency?
These aren't values, unless you can answer those questions.

And for the record - if you'd answer, "None," then you have just discarded the value entirely.

You only have a "value" if you can trade for it.

Considering a SAFe value system

In order to turn "beliefs" into values, we need to be able to make trade-offs based on something. We need to state how much we are willing to give, in order to gain some of what we believe in.

The easiest way to make trade-offs is by investing more or less time or money.

Quality

makes a formidable value, since we can immediately relate it to money: We can determine the cost of poor quality (i.e., the failure to produce high quality) based on projected cost of failure and/or rework. This cost is so staggeringly high that quality has an extremely high value, and the price of reducing it is extremely high. Although the numbers for reducing quality rarely add up, we can do it, and clearly quantify cost, benefit, exchange rate and margins.

Alignment

converts formidably to time - we could do something now, and show the outcomes. Or we could first align, which would mean that we will have no results until alignment is done. It also means that we're not earning money in the meantime. Plus, we're spending effort. Hence, we can assign a financial cost to alignment.

When we can say how many days an improvement / reduction of 1 point on our alignment scale will gain or cost, and how much money we gain / lose during that time, then alignment might become a value.

Transparency

is very hard to turn into a value, because it's extremely hard to define.

What is transparency even - and how would the gain or loss of one point on our transparency scale convert into time or money? We could measure the cost of information inavailability, which in itself is only visible via second-degree indirection - we must peek at the delays incurred by waiting for information to become available, and at the cost of that time. We could also measure the cost of evitable, wrong decisions that were made because people made choices in the absence of existing information. We then also need to reverse the calculation, computing the cost and time required for producing information not required for decision-making ("information waste").

Companies capturing this kind of data are so rare that the measurement of transparency remains elusive.

 

Execution

simply doesn't make sense as a "value." How much time or money is one unit of "not doing anything" worth? How many would we want? Is there ever even a potentially valid scenario where having a plan, and not acting upon it, has a positive value attached? If so - we should immediately ditch that plan! 

And that's not even digging into the question whethere there's value in a "program," that is, a large-scale initiative. Skunkworks has already shown two generations ago that programmes are often more of a problem than a solution.

SAFe Core Values - a wishlist for Santa!

When we're talking about "SAFe Core Values", we're not talking about values at all, since we're not even discussing potential trade-offs.

Quality is the only "value" of SAFe that managers would actually consider trading off, despite being so ridiculously expensive that this isn't economical: The best quality has the lowest cost - "less costs more and brings less." It's absolutely something an economical thinker would want to maximize.

Alignment, as commonly understood, comes with a negative net benefit - "more costs more and brings less." So, it's not something of value. Why would we want it, besides clinging to a belief that it's somehow important?

Transparency is too elusive to be considered a value: Everyone wants it, but nobody can really say what, or how much, we'd want to trade for it.

Program Execution doesn't make sense as a value. It's boolean: If we want to do something, just do it. If we don't want to do it - why is it relevant?

Hence, SAFe's "core values" are nothing more than a wishlist for Santa - something that almost every manager in the world will say they want, and nothing they'd be willing to pay a price for. 

Anything for which you're unwilling to pay a price, has no value. It therefore can't be considered a value.

SAFe has only one real value: built-in quality. And that's the first ones most organizations kick out of the window.

If you want SAFe "Values", you'll need to do a lot of groundwork and figure out what it is that you actually want: You're not done with simply accepting them.