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.

Team archetypes: basic setups

 "Which kind of team setup should we choose?" - a common question in many organizations with the luxury of having an IT department bigger than a single team. First of all: there's no universal best answer - the choice is often constrained by factors outside the teams' control - such as HR, legal,  company politics and so on. Irrespective of such details, let's explore what the archetypes are.

As long as there are only enough people for a single team, the question "which setup do we choose?" is - fortunately - moot: build a team and get to work. Approaches like Skunkworks, which predate software development, conclude that a single team is always less overhead than multiple teams, and the overhead can become a performance killer - down to the point where a single, effective team can outperform half a dozen teams struggling to get their act together.

This entire article is written under the premise that a single team isn't enough to get the job done, and that we already exhausted all feasible options of doing the same with fewer people - hence: there is an indisputable need to set up a multi-team structure.

Four Team Archetypes

Let's take a look at the team setup chart. For simplicity's sake, let's just assume that the only functional specializations are Analysis, Coding and Testing. The key points of the article don't change if we have further specializations, such as Frontend/Backend/Database development or include Operations. If anything, the problems caused by specialization would be exacerbated.

Component Teams

One of the most common setups for organizations with just a handful of teams is the Component Team: each team consists of the people required to deliver a single component. This works splendidly as long as there are only few components, and they are loosely coupled. In that case, each team can perform their work independently. It becomes an entirely different ballgame when components are tightly coupled, interdependent - or worse: co-dependent.

Key questions to ask when setting up component teams include:

• Will each team have all the skills and means to complete the delivery lifecycle of their component? If the answer is "No," component teams will quickly find themselves blocked and unable to consistently deliver value. Proceed only if the answer is "Yes."
• How close is the coupling between each component? If the answer is, "Tight", component teams will likely find themselves rendered ineffective. Proceed only if the answer is, "Very loose."
• How dependent are the components on each other in delivering end user value? If the answer is anywhere on the scale from "Master-Slave" to "Closely interlinked", at least one component team will be a bottleneck, and overall delivery performance will depend on the constraining team.

Specialist Teams

The staple setup in corporations with hundreds, potentially thousands of IT people is the Specialist team: each team consists of specialists performing a single function in the software development lifecycle. In case of very large organizations, we often see a double specialization - each component having their own specialist teams performing only a single type of task. 

This kind of "industrialized, conveyor-belt delivery" process optimizes resource efficiency over effectiveness, and typically ends up with massive bottlenecks diminishing flow efficiency of value delivery close to Zero: Regardless of how many people are involved, "there are always too few people." The problem is less the amount of work than the immanent optimization favoring workload over results.

Key questions to ask when setting up specialist teams include:

• Where will the bottlenecks be? You will have at least one bottleneck, and if it's not where you want it to be, you won't understand why your organization is so ineffective.
• How do we keep flow across teams balanced? Managing flow in specialist teams requires understanding the intake, throughput and flowback rates of every single team. If these are out of balance across teams, work will get stuck.
• How will people communicate? The classic Waterfall-style "communication by document" is slow, inefficient, ineffective and error-prone. Proceed only when you have a feasible solution for communication flow.

Feature Teams

The key reason for feature teams is to reduce the cross-team friction caused by delivering unusable component work which requires integration efforts at a later point in time. Feature teams minimize the handovers across team boundaries which lead to additional communication and waiting queues. 

Neither component nor skill boundaries will stop the flow of work from demand to delivery in a feature team. The way of working in feature teams is very natural - people sit together, do whatever it takes, and get the job done.

Key questions to ask when setting up feature teams include:

• Which organizational impediments prevent us from setting up feature teams, and how do we overcome them? The barriers are often more centered around management, structure and contracts, not at shop floor level.
• How do we keep team size low and still make sure people know what they're doing? Feature teams require a lot of initial learning as every team member is confronted with a vast amount of things they don't know.
• Which engineering practices will we use to ensure that teams won't constantly step on each others' toes? If you have no solutions, you need to find these before proceeding.

Generalist Teams

The generalist team is often considered the holy grail of Agilists. A generalist team is multi-skilled both in software engineering, and in the product domain: each team consists of individuals who can exercise multiple functions in the development lifecycle, and who are able to work on all relevant components of their product. Generalists hardly find themselves in bottleneck situations, and are always able to contribute value. Setting up generalist teams has a massive learning curve, requiring continuous multi-learning. In return, generalist teams minimize the concern of "truck count," and they are able to flexibly take on any feature that maximizes value.

Key questions to ask when setting up feature teams include:

• Where are currently our knowledge constraints? Generalist teams immediately expose where the number of individuals with either product domain expertise or specific lifecycle expertise are too rare to ensure each team has seed knowledge to get started.
• How much specialization is really required? If you're working on teams where lacking deep domain knowledge becomes a life-or-death decision, generalization may not be your primary choice. These cases are rarer than we would think. Based on the Pareto Principle, 80% of the work requires 20% of the knowledge - and generalists can do that.
• What does it take to set up generalist teams? How do we get started? Can we start right away, should we upskill feature teams or component teams? Do we need to re-organize entirely?

The most common concern towards setting up generalist teams is, "Not everyone can do everything." Indeed. It takes time and learning, and not everyone will specialize deeply in everything. There are two key points to ponder: the starting point, and the optimum point. 

At the starting point, we set out with people who may find themselves unable to contribute outside their specialization, and based on where the team's constraint is, that's what they need to learn first.

At the optimum point, team members can offer basic contribution wherever it is needed - and "wherever" isn't "everywhere." A generalist team is effective when there are no skill-related bottlenecks in the team, not when everyone is a master of everything. It could mean that a tester understands some basics of coding and can make simple changes by themselves - not that they need to establish profound coding expertise. 

What's the difference between generalist and feature teams?

Feature teams are a lower standard. We can easily set up a feature by putting an analyst, a developer and a tester into one team and giving them access to all the modules they need to work with.

Generalist teams should be feature teams. Only some feature teams are - or evolve into - generalist teams.

A generalist team consists of coders who can analyze or test, testers who can analyze and maybe write some code, and analysts who can also code or test. People who worked in smaller companies are often used to this way of working - people from a corporate environment are often unable to even grasp this concept as it's too detached from their reality.

How about Generalist Component teams?

Small teams of people, each of whom can do most of the work on their own components. This pattern is very typical in modern organizations opting for microservice architectures.

Dissolving specialization boundaries within teams is desirable to increase "truck count," and definitely useful. We minimize delays, handovers and information gaps within the team. On the other hand, the effectiveness of the overall development organization remains constrained by the lowest performing component team. Component team organizations can't solve this fundamental flow impediment, hence the teams' generalization ends up being a local optimization.

We can even find this local optimization working against us - the highest performing teams might create overload on other teams, further reducing the overall performance of the organization. High-performance generalist component teams might render the entire organization ineffective, despite best intentions.

What to choose?

In other articles on the topic of team archetypes, we will explore a little further what the implications of each archetype are. The topic is complex, hence there is no simple answer. The best answer is: "Caveat emptor." Know what you're opting for and what the consequences of your choices are.

What about Mix-And-Match?

Should every team within an organization have the same setup? Wouldn't it be better to mix-and-match? A few component teams doing bulk haulage, supported by a few specialist teams for Feature Analysis and End-to-End testing, maybe with a Task Force Feature Team for high urgency tasks? 

That's actually what we find in many organizations, so it's definitely a realistic scenario. Our question is less about "Can we do that?" than it's about, "Should we do that?" - and again: there's no simple answer. As a product matures and growth reaches a plateau, that's most likely what we're going to find. For emerging products, the suggested mixed setup is probably not going to provide the necessary performance to succeed. 

Where to start?

Try starting with the simplest setup, and only add complexity when inevitable.

And that simplest possible setup is a small number of Generalist teams. If you can, try that first.

The economy of incentives

People working in bigger companies often do things which don't really seem to make sense when looking at the big picture. And yet, they're often pretty reasonable in their choices. They are intuitively following basic psychological and economical principles. Let's explore.

The economy of needs, wants and incentives

Let's start out at the detail level of the individual. Each person has needs:

The need pyramid

Maslow's hierarchies of Needs, sometimes also called "Maslow's pyramid" is built on the theory that every human being has needs, and these needs follow a hierarchical order. This picture is already a simplification, more comprehensive models are abundant on the Internet. 

While each person has the same types of needs and the pyramid is the same, the level at which these needs are considered "satisfied" widely differ. 

One person might feel basically satisfied with a bowl of rice and a few cups of water, whereas another person requires a more special diet to  sustain. These are the basic needs, which must be met to ensure survival. People whose basic needs aren't met will not have a mind to think about other things, their primary concern will always be meeting these needs.

Once people are satisfied at the basis, they care for psychological needs - family, social ties, being accepted and valued.

With such a firm foundation starts the restless search for meaning in life - developing one's personality,  being creative, pursuing a cause. At this level, people look for transcendency.

Dan Pink mentions this in his book, "Drive" - without fully realizing that it's not just that the money must be off the table, but all basic and psychological needs. People who feel threatened for their physiological well-being or social status aren't looking for transcendence, so in order to set up an organization where people go to look for a higher purpose, there's a lot of groundwork to be done in taking care of people first.

From "Need" to "Want"

Unmet needs cause dissatisfaction with the status quo. This is also true for the future, because people think ahead.

We build our needs pyramid from the bottom, and whenever a lower-levelled needs turns to an unmet status, everything on top of that need gets out of focus. A starving person doesn't care for appreciation (many artists can tell that story.) A bullied person won't feel the office aesthetics. And so on. So, when a person has an unmet need, they want something, and action is required to satisfy the need (although it could be a different actor to serve the person in need.)

There are a lot of intermediary Wants - for example, money can be used to meet all kinds of need. When a person is hungry, they want money to buy food. Or drink. Or to pay the rent. Once basic needs are satisfied, they might invest that money to buy a token of wealth that meets their need for social recognition. And so on.

Other intermediary Wants, such as a promotion, could be more complex: Is it about the job title for prestige, is it about the presumed job security, about the additional pay, is it to rise the ranks to improve status? Maybe all - maybe only some. 

Or maybe the idea that the Want satisfies the need is an illusion?

The key takeaway here is - if there's a need, there is a want. Ignoring the underlying need will render attempts to satisfying a Want ineffective.

Incentives

Incentives don't directly affect needs. They work because they trigger (both positive and negative) wants: things the individual wants, in order to meet needs - and things the individual wants to avoid, in order to not have needs unmet.

An incentive always stimulates at least one Want. 

Positive incentives

Positive incentives give people the ability to satisfy their needs if they conduct a certain action. The most common form of positive incentive is, "Do your job, get your paycheck." Even a simple "thumbs up" from a coworker can be an incentive to try and go the extra mile. 

The strength of an incentive depends much less on the nominal amount of incentivization - much rather, it depends on the level of unmet need. For example, you won't entice Donald Trump with a Thumbs Up, but the new team member who's not certain of their position in the team yet may be willing to go great lengths to finally get the lead developer to nod in agreement of something.

Negative incentives

Just like positive incentives, we can find ourselves subject to negative incentives.  For example, the negative incentive "skip dinner"  attached to overtime plays on our Want to not be hungry.

In society, we use negative incentives to deter certain behaviours, such as fines (which affect people differently, depending on their wealth.) 

Explicitly phrasing negative incentives helps people discover which courses of actions are desirable and which are undesirable.

Managers quickly forget that there are almost always some negative incentives attached to their words: Even asking for a trivial thing might leads to the person feeling their status in front of their peers is diminished - a negative incentive, which people try to avoid.

The incentive economy

An economy is defined by wealth - in this case, we define "wealth" as satisfied needs.

In the case of incentives, we're dealing with promises of future wealth, hence, a value proposition to the recipient of the incentive.

Passive incentives

"What could be a passive incentive?" - well, that's an incentive created by doing nothing. Taking an extreme example, when a police officer continues munching donuts while a robber demands cash from the store owner, that's an incentive for the robber to commit further crimes. We see much less extreme examples in everyday's business world as managers fail to acknowledge the successes and contribution of their teams, incentivizing individuals to either cut down on performance (if stress is affecting their basic needs) - or to start hunting for a better job.

The nefarious thing about passive incentives is that you literally don't need to do anything to trigger them.

Ineffective incentives

The next type of incentives we're looking at are ineffective incentives. A positive incentive which doesn't address a real Want is entirely ineffective - as are negative incentives which don't touch a relevant need. This is also the reason why a pay raise for a person who's already fully able to meet their basic and psychological needs is pretty ineffective, as Dan Pink in his work, "Drive" figured out.

The same is true for "fun activity at work" while people are worried about not being able to afford the rent: it affects a higher-levelled need while there are lower-levelled Wants.

We can try to manipulate people by suggesting that they do have a certain Want, a typical marketing strategy. Here we can quote Lincoln, "you can fool some of the people all of the time, and all of the people some of the time, but you can't fool all of the people all of the time." Eventually, people will realize that an incentive doesn't affect their needs, and they will ignore it. That is especially true for  things often called "non-monetary incentives."

Likewise, when a person finds alternative ways of satisfying their Needs, the Want disappears, and the incentive fizzles. For example, new joiners will stop trying to achieve the recognition of their boss when they feel that the recognition of their peers means a lot more. 

Hence, long-term incentives that have alternatives tend to be ineffective. 

Perverse incentives

The final category of incentives are perverse incentives - these are different from the other categories.

When we try to incentivize an action, we usually try to do that to get a benefit from what they do. The term, "perverse incentive" comes into play when people have the Want, but the intended incentivized action isn't actually what people to in order to meet their need, and so they go to do undesirable things. "Cobra Farming" is a notorious example of a perverse incentive.

The problem with perverse incentives is that they work extremely well - just not in the way that the incentive-giver intended. 

And there's another problem: Perverse incentives are extremely common in complex organizations where the relationship between cause and effect isn't clear.

Setting incentives without connecting to the recipient's reality often leads to perverted incentives.  

Top managers coming up with broad-brushed incentivization schemes for people at shop floor level often realize this only when it's already too late.

Summary

Bringing it all together - we have to understand the real needs and how they can be met. We must learn to go beyond merely talking about our Wants.

From there, we must learn how to take care of each other's needs in effective ways.

That allows us to become explicit on the incentives that let us build "Win-Win" scenarios.

The Agile Tragedy of Commons

There's a socioeconomical dilemma called, "Tragedy of the Commons" which effectively means, "In unregulated systems, local optimization may become so extreme that the system becomes unsustainable."
And here's why you need to understand it in order to understand "agility at scale."

Before we get started, though, let me explain the dilemma:

The Tragedy of Commons

Imagine there's a huge, pristine green pasture. The lord of the land has decreed that everyone is free to use this pasture for shepherding their flock.

The first shepherd who arrives finds a vast green pasture, and the flock is happy to graze on the fields.

Soon afterwards, another shepherd arrives, and their sheep graze happily on the lush pasture as well. Both shepherds are happy, as their sheep have ample food to eat.

In the excellent conditions, the flocks multiply.

As the flocks grow, there is no longer an overabundance - the sheep of the two shepherds begin competing for food. The first shepherd's sheep had more time to multiply, and the second shepherd's sheep lack the required conditions to multiply freely.

Both flocks compete over increasingly scarce food: the sheep lack nutrition and are threatened from starvation. The first shepherd feels that the second shepherd's presence has caused this threat to their flock. The second shepherd considers the first to be using their unfair advantage of having a bigger flock to drive them off the pasture. Quarrels arise.

The feudal lord settles the dispute by dividing the once lush green pasture into an allotted segment for each shepherd, based on the size of their flock. Both shepherds now have access to less land than they could access before - but each now has full control over their flock.

Should the lord have settled the dispute in this way? Should the lord have found another solution? Take some time to think. What would have happened - had the lord not intervened?

Tragedy of Agile Commons

There are many, and massive, applications to the Tragedy of Commons in the realm of software systems - moreso in scaled environments. In the land of Agile, they're much more visible than in the land of Waterfalls, where the lots are already divided before they exist: Agile teams incrementally and empirically discover their next best move based on where they are today - perfect preconditions for the Tragedy of Commons.

Common Code

Teams who haven't learnt discipline in code will find it highly irritating to see one developer interfering with another developer's code: "my" coding style is always better than "yours."

Quickly, quality problems begin arising on the Common Codebase: quarrels over style, functionality placement, inconsistencies and many others.

As more and more developers enter the scene, the tendency for code silos built around personal preference, coding style, technologies, or even domains increases.

Whereas one team can often be left to freely roam the green pastures of service implementation, the field quickly turns into a brown quagmire when multiple teams all play their preferences, until the code base becomes entirely unworkable.

Once teams build fences around their codebase, Collective Code Ownership becomes a thing of the past, and Component Teams find themselves entertaining a dreadful nightmare of coordination meetings.

Better approaches could be:

• code conventions
• linting rules
• cross-team Pairing sessions
• Code dojos
• Continuous Integration / Continous Delivery

- but these things are all topics large organizations struggle with after the code has been divided into silos.

Common Innovation

A green field project is often a great way to introduce new, more powerful technologies that allow teams to do less with more.

As the development organization matures, and standards begin to shape the landscape, new ideas becomes exotic and marginal, struggling to overcome inertia.

Imagine - just for example - introducing agent-based logic into an architecture driven by RPC's and SOAP requests: There will be few takers for such an innovation.

The Tragedy of Common Innovation is that new ideas have to find a really small niche when the field is already taken by old ideas. Many good ideas go extinct before they can catch a hold.

With a constant decline of innovative ideas, organizations eventually find themselves investing massive efforts into servicing outdates ways of working and technologies, incapacitating their ability to deliver high value to the customer in the same ways others do.

Better approaches might be:

• innovation allotments
• hackathons
• innovation sessions
• innovation champions
• cross-team collaboration on innovation
• intrapreneurship

Common Meetings

Have you ever been in a 2-hour meeting with 40 people? Did you ever pay attention to how many people actually speak? Hint: it's most likely not an even distribution.

Small organizations find their meetings very effective, but as more and more people appear on the scene, meeting effectiveness quickly declines. And there's a reason.

In an effective 3-people, 1-hour meeting, every person gets to speak roughly 20 minutes. That's a lot of time to voice ideas, offer feedback and draw conclusions. That's a 33% activity ratio. And everyone has pretty much the same understanding afterwards.

When we constrast this with a 30-people, 2-hour meeting: Simply by dividing clock time, we see that every person gets to speak an average of 4 minutes, while being forced to listen for an average of 116 minutes: The ratio of ideas contributed versus passivity is staggering for each individual - the activity ratio has dropped to a mere 3%! In such a scenario, the tragedy of common meetings becomes that some of the more experienced people take the stage, and everyone else becomes decoration.

Solution approaches might be:

• focus sessions
• using a need-to-know principle
• Law of Two Feet
• breakout sessions
• topic ownership

Specialisation also removes the need for everyone to participate in all discussions.

The tradeoff is mainly between not everyone getting firsthand information and people suffering through hours of only marginally relevant meetings. To any solution, there's a downside.

Common Work

A single developer can work on any code at any time, and there will be no unpredicted side effects like merge conflicts caused by others' work. Small teams will usually learn quickly how to coordinate so that they minimize mutual interference.

Without good engineering practice, delivering a larger, integrated piece of software means lots of simultaneous changes in many places. Teams will either get into a Riverdance of constantly stepping on each other's toes, or they will require so much coordination that things get really messy. Of course, the "solution," is - once again - code silos and dependency hell: productivity tanks as risks and delays rise skywards.

Every developer joining an organization that hasn't managed to deal with the Tragedy of Common Work adequately, will make every developer's productivity decline - up to a point where the net productivity gain of hiring additional developers may be negative, i.e. with each new hire, the organization gets less productive overall!

Potential solutions could be:

• visual dependency management
• domain separation
• decoupling
• joint roadmap planning
• cyclical synchronisation points
• communication by code

Now what?

These are just four examples of how the Tragedy of Commons matters a lot in a Scaled Agile setting, and there are a vast number of potential commons.

Regardless of whether an Enterprise is new to agile ways of working or have been doing so for a while: you need to establish overarching rules that mitigate the conflicts, lest you run afoul of the Tragedy of Commons.

The "Tragedy of Commons" is entirely evitable in a holistic system where every participant sees themselves as an integral part of the whole. The solution is coexistence and collaborative conflict resolution rather than competition.

Ground rules address unregulated, harmful growth, a lack of discipline, and myopic actions, but each rule comes with a drawback: it reduces flexibility. While Team Autonomy needs boundaries where these are for the Greater Good, it's important to set these boundaries wisely, and revisiting these where they aren't useful. That can't be done by only one group - in a common system, it has to involve all those whom it concerns.

Which boundaries will you set to prevent your organization from suffering the Tragedy of the Commons, and what is their cost?

The "Planning Tetris" Antipattern

 "We need to utilize all of our Story Points" - that's a common dysfunction in many Scrum teams, and especially in SAFe's Agile Release Trains where teams operate on a Planning horizon of 3-5 Sprints. It results in an antipattern often called "Planning Tetris." It's extremely harmful, and here's why.

Although the above feature plan appears to be perfectly optimized, reality often looks different: all items generate value later than they potentially could - at a higher cost, in longer time and with lower efficiency!

Accumulating Work in Process

Planning Tetris often leads to people starting work on multiple topics in one Sprint, and then finishing it in a later Sprint. It is resource-efficient (i.e. maximizing the utilization of available time), not throughput-efficient (i.e., maximizing the rate at which value is generated.)

That leads to increased Work in Process, which is a problem for multiple reasons:

Value Denial

Just like in the sample diagram above, "Feature 1" and "Feature 2" could each be finished in a single Sprint. And still, Feature 1 doesn't provide any value in Sprint 1, and Feature 2 has no value in Sprint 2. So, we lose 1 Sprint of marketability on Feature 1 (our highest priority) - and on Feature 2 as well:

A perfect example how utilizing the team makes the value come later!

Loss of money

Imagine now that every feature costs less than it's worth (which it should, otherwise it wouldn't be worth developing) - and you see that the "saved" efficiency of having worked on features 3 and 4 before finishing feature 1 costs the company more money than the added benefit .

Efficiency loss

You may argue, "different people are working on the features, so there's no multitasking."

Yes - and no. What is happening?

Sprint Planning for Sprint 1 has to discuss 3 features: 1,3 and 4. This means that the whole team is discussing three different topics, (none of which will be delivered in that Sprint.) The same happens in Dailies and Review. And, potentially at a source code level as well. The feature interference may also bloat up the complexity of technical configuration, deployment processes and the like.

The team becomes slower, hence less efficient.

Adding needless risk

In statistics, there's a phenomenon called "the high probability of low probability events." Let me explain briefly:  There's an infinite amount of almost infinitely-unlikely events, but unfortunately, high infinity divided by low infinitiy is still a number close to one: Something will happen. You just don't know what, and when, so you can't prepare or mitigate. Since you don't know which aspect of your plan will be affected when a risk hits, you'll always be caught by surprise.

How is that a bigger problem in Planning Tetris than in sequentialized delivery?

Massive ripple effect

When you're working on one topic, and an event hits that affects your entire team, you have one problem to communicate. When the same happens as you're working on multiple topics, all of them are impacted, and you're generating a much stronger ripple effect.

Complex mitigation

As multiple topics are in process, you suddenly find yourself mitigating multiple topics. And that means multiplicative mitigation effort - less time to work, and at the same time a higher risk that not all mitigations are successful. You end up with a higher probability of not being able to get back on track!

Chaotic consequences

Both the ripple effect into the organization and the mitigating actions could lead to unpredicted consequences which are even harder to predict than the triggering event. In many cases, the only feasible solution is to surrender and mark all started topics as delayed, and try to clean up the shards from there.

Prepare to Fail

There's Parkinson's Law - "work always extends to fill the amount of time available." That's often used as an argument to start another topic, because it stops gold-plating and keeps people focused.

But there's also the (F)Law of Averages: "Plans based on averages fail half the time."

The latter makes planning tetris a suicidal approach from a business perspective: it starts a vicious circle.

Predictable failure

Because there's no slack built into planned tetris, the mid-term plan will automatically fail as soon as a single feature turns out more complex than planned. The more features are part of our tetris stack, the more likely at least one of them will fail. And the team will usually get blamed for it. Because of that, we end up with

Conservative estimates

Teams must allocate the slack buffers into their feature estimates to reduce the probability of failure. When a Tetris plan spans multiple Sprints, some feature content may not be "Ready" for implementation during the Sprint when slack would be available - so we end up with Parkinson's Law, the buffered estimates don't reduce failure probabilities. 

Declining throughput

At this point, Parkinson's Law tag-teams with the Flaw of Averages to KO the team: Regardless of how conservative the estimates, the team will still end up failing half the time. The consequence is that business throughput continues to decline (there's an interesting bottom: when a Sprint only contains one feature!) 

Strangulating the team

Let's take a look at the psychological impact of Planning Tetris now as well:

No space for Creativity

I have never seen an organization where Product Management was happy that developers would add "creative spaces" into a Tetris Plan. It's all about churning out feature, after feature, after feature, without a pause, without a break. When one feature is done, another is already in progress. There is no room to be creative.

No space for Growth

The only relevant business outcome in Tetris Plans is usually business value delivered. It ignores that developers are the human capital of the organization, and growing them is growing the organization's ability to deliver value. Especially in the rapidly changing tech industry, not growing equals falling back until eventually, the team is no longer competitive.

No space for Improvement

I often advise that developers should take some time to look at "Done" work to reflect how it could have been done better, and turning that better way into action. With Planning Tetris, that opportunity doesn't exist - another feature is waiting, and improving something that exists is always less important than delivering the next big thing. That often ends in terrible products which are no joy to deal with - for developers and customers alike!

Now ... what then?

The point that Planning Tetris is a terrible idea should be blatantly obvious.

"Now what's the better way then?" - you may ask.

It sounds incredibly simplistic, because it is actually that simple.

1.  Reduce the amount of features the team is working on in parallel to an absolute minimum. This minimizes blast radius.
2.  Instead of having people parallelize multiple topics, let "inefficient", "not-skilled" people take easier parts of the work to step up their game. That reduces the impact of low-probability events and gives everyone air to breathe.
3.  Put slack into the Sprints. The gained resilience can absorb impact. It also reduces the need for buffered estimates, countering Parkinson's Law and the Flaw of Averages. It also gives people air to breathe.
4.  Agree on Pull-Forward. When the team feels idle, they can always pull future topics into unused idle time. Nobody complains when a topic is finished ahead of time, everyone complains when something turns late. Pull Forward has no ripple effects or chaotic consequences.

Ok, too many words, so TL;DR:

1. Sequentialize.
2. Slack.
3. Pull.

All problems mentioned in this article = solved.

From Standards to Baselines

Many - especially large - organizations are looking for standards that they want everyone to adhere to. The idea is that "standards reduce complexity." Yes and no. Unfortunately, there's a risk that standards create more complexity than they are intended to reduce. 

Let's take a look at the issue by using Scrum as a showcase. Whatever I say about Scrum will also apply to Kanban, DevOps, CI/CD - and many other topics.

The Standard

There's no argument that Scrum is a de-facto standard in the industry for many teams. Many organizations mandate that development teams must use Scrum, and rigorously enforce adherence to a company standard of Scrum. While it's entirely possible to use Scrum in this manner, this entirely misses the point of Scrum: as the mechanics of Scrum are honed to perfection, the core ideas of flexibility and continuous improvement are lost. Teams lose ownership as their way of working is externally imposed.

Teams using Scrum as a standard lose the ability to evolve beyond Scrum. Scrum becomes their mental shutter - they become unable to think in a different way.

Broken Scrum

Teams confined by Standard Scrum often feel that it is far too restrictive. Especially inexperienced teams often suffer from poorly implemented practices, which seem to have no value and just generate overhead for the team. Not being aware of the actual intent, and being unable to discern intent and practice, they proverbially throw out the baby with the bathtub: "Scrum is broken," Scrum is discarded.

Such teams fall below the baseline of Scrum, and they think that Scrum is the problem.

The Baseline

Instead of considering Scrum as the confines within which development must be organized, a team can also perceive Scrum as their baseline. Understanding Scrum as a Baseline means that there's no prescription what you must do or how to do it: it doesn't even tell you that you need to use Scrum. What it tells you is what you must have to be at least as good as a Scrum team could be.

For example - everyone should be able to tell at any point in time what the team's highest priority is.

And there should be closed feedback loops both for decisions and execution.

And the team shoud apply double-loop learning at least in monthly cycles.

And so on.

Now: what's the difference?

From Standard to Baseline

What may sound like a game of semantics makes a massive difference in practice:

Standards create restrictions. Baselines foster growth.

Standard Scrum teams often find themselves rendered ineffective, not because of Scrum, but because the standard stops Continuous Improvement as soon as it touches the rules of Scrum. Baseline Scrum teams aren't concerned with the rules of Scrum - they're concerend with being "at least as good" as Scrum would have them be. A team on a Baseline of Scrum can do whatever they want. There is no rule that the team must use Scrum. Instead, Scrum becomes a list of things that help the team inspect and adapt.

For example, there is no rule such as "we must have Retrospectives." But there is a benchmark - the team should frequently re-examine their ways of working, and actively work on improving their effectiveness. There are other means than a Sprint-end Retrospective to achive this: for example,  extended coffee breaks with deep discussion.

Standards can be measured and assessed based on adherence to a fixed set of rules and practices: it's all about checking the boxes.

Baselines can't be measured in this way. They must be measured based on outcomes: What is the value we're trying to get out of a standard?  And: are we getting at least that?

Measuring adherence to standard leads to improvements primarily focued on compliance. At full compliance, the journey of change ends. Measuring baseline performance is much more complicated. There is no "true/false" answer such as for compliance, and there's an open-ended scale that knows no "perfect" - there's always room for improvement.

 

Now what?

I would advise everyone to look at everything in the Agile domain - Values, Principles, Practices, Frameworks and even tools - as Baselines: "How far do we go beyond that?" 

If the answer is "Not even there," then have a discussion of how you can up your game. Maybe adopting that thing is a simple, easy way to improve?

However, if the answer is, "Already far beyond," then compliance is off your list of worries. Even if you don't have that thing, you most likely won't need it.

Four key metrics for transformation effectiveness

What matters for a company in an "Agile Transformation?" Well, let me give you my perspective. Here are four key metrics which I would advise to track and improve:

Customer satisfaction

Customer Satisfaction can be both a leading and a lagging indicator. It's leading, because it informs us how likely our next move will grow our business - and it's lagging, because it tells us how well we did in the past.

We can measure it asynchronously with tools like the Net Promoter Score or observing Google ratings. Softer metrics include customer interviews. Modern, technological means include A/B tests, conversion and resubscription rates.

Regardless of which of these you measure: if you see this indicator going down, you're most likely doing something wrong.

A proper change initiative relies on being able to track user satisfaction in some way and use that to inspect and adapt accordingly.

Employee happiness

Employee happiness is a pretty strong leading indicator for potential success: happy staff tend to do everything in their power to help the company succeed, because they like being part of this success. In reverse, unhappy staff are a leading indicator for many other problems that only become visible once they hit.

I'm not a huge fan of employee morale surveys, as depending on the organizational culture, it's weaponized against management, so people always give scores of 100% and bolt for the door at the next opportunity. 

The minimum you can do is measure staff attrition - if your attrition rates are above industry, you're doing something wrong. If you're significantly below, you're probably doing something right.

At a more detailed level, it does indeed help to look at factors like psychological flow, change fatigue, diversity and compensation fairness, although we need to be careful that these are used as indicators for inspection and adaptation, not as the next management KPI to be gamed.

 

Throughput rate

Throughput rate is a leading indicator for capability and capacity: when you know your throughput rate and the amount of work ahead, you can well predict what happens when.

The effectiveness of an organization can be tracked by looking at end-to-end throughput rates of the core value streams. Some examples are the duration from lead to conversion, from demand to delivery, or from order to cash.

Take a look at queues, lack of priority, overburdened employees and unavailable resources. By tweaking these levers, throughput rate can often be doubled or more, without any additional effort or expense.

Although it may seem counter-intuitive: the key is not to get people to "work harder," it is to eliminate wait time by having some people do less work. For that, we must understand where wait time accumulates and why it does so.

Financial Throughput

The proof in the pudding is financial throughput, a lagging indicator. Be wary - it can't be measured by department, and it can't be measured by unit. It also can't be measured exclusively by looking at the cost sheet and the amount of work done.

Financial throughput is the one key metric that determines business success: it's the rate at which we're earning money!

We have two significant levers for financial throughput: speeding up the rate at which we turn investment into returns, and reducing the size of the investments such as to bind less capital. Ultimately, combining both of these is the sweet spot.

How to improve

Customer and Employee satisfaction

These metrics depend mainly on the managerial system of the company: how goals are set, how people are treated. Usually, there's a strong correlation: happy employees make customers happy, and happy customers give positive feedback to employees.

Deming noted in his 14 points that management must work to "remove barriers that rob people of their right to pride of workmanship." 

Transparency is one factor, getting out of the way is another. Removing policies that reduce people's ability to do the right thing is yet another. A management committed to quality, that is, fixing things that lead to poor outcomes, is vital here.

And, of course, the ultimate key here is letting people own their process.

Throughput rate

This third metric depends on flow efficiency. 

Note that "flow efficiency" is not "resource efficiency:" A process where people and/or resources operate without slack is usually dysfunctional and will falter at the slightest hiccup. Process flow requires resilience. 

Queues are a universal killer of throughput rate, so avoid queues wherever and whenever possible.

In software engineering, process efficiency is mainly determined by engineering practice: Software Craftsmanship and Continuous Delivery (CD). The prior requires people to know how to develop software using the most appropriate techniques, such as Clean Code practice. The latter requires some tooling, a product architected for CD, a high commitment to quality as well as policies and practices consistent with the intent of CD.

Financial Throughput

The final metric depends on how aligned decision-makers are with their customer base and their organization.

While financial throughput relies on the organization's operative throughput rate, we have to look at which things affect our financial throughput and enable our organization to do more of these - and quicker. And in many cases, that means doing less of the things that have sub-optimal financial throughput. For example, eliminating "failure demand." (work that's only required because something else went wrong.) Or "null objectives." (targets which do not affect these four metrics.)

And how about Agile Frameworks?

Nowhere does this article mention a specific "Agile Framework." This is not an oversight - frameworks are irrelevant, or potentially even harmful, in the discussion of business relevant metrics. They could be a tool in the solution space. That depends on where we come from and which challenges we face.

For example, if we're challenged on engineering practice - we can't solve that with Scrum or SAFe.  Likewise, if we have customer satisfaction issues: Kanban doesn't even consider the topic.

Not even "Agile" is either a relevant means, nor a relevant outcome. Working "Agile" is merely one possible approach that tends to be consistent with these metrics. Where agile values, principles, practices and mindset help us improve on these metrics, they are valuable. But when that is not the case, they aren't worth pursuing.