How Equivocation destroys Agile

"Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed" - What does that even mean?

This is just a door-opener for one of many equivocation fallacies which are destroying the entire "Agile" space. Let's dig into it.

Equivocation

We're talking about "equivocation" when a term is used in multiple inconsistent ways, which thereby invokes false images in the minds of the audience. A simple example of how quickly this can get out of hand: "White Supremacy is racism. Since the White House is also White, it's also a sign of insitutional racism." - it's clear that the term "White" means two different things (in one case, a mindset - in the other, a description), but it's already hard to get the thought out of our heads.

Equivocations in the "Agile" space are much more subtle, thus harder to spot, but potentially no less damaging. So, let's get into some of the equivocations that are permeating "Agile." (and I purposefully don't dig into how "Agile" itself doesn't have a single definition people would agree on)

Customer

Based on Investopedia, "A customer is an individual or business that purchases another company's goods or services. Customers are important because they drive revenues; without them, businesses cannot continue to exist."

And yet, we have this concept of "internal customers" popping up left and right.

The first Agile Principle reads, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." So, every Agile team needs a customer - and who's that customer for most agile teams? Well, they deliver Business Support Systems, so they say that "Business is our customer!" - circular logic based on the Investopedia definition: the business is important, because without it, the business can't continue to exist. Does that make sense?

It doesn't even end there: Modern software is complex. In larger companies, we often see platform teams building platforms that other teams work on. These say, "The other development teams are our customer!" - how much more profit would we make when we get more and more development teams asking for services from our platform team while nothing in our company's relationship with the open market changes?

To quote Wikipedia, "Leading authors in management and marketing, like Peter Drucker, Philip Kotler, W. Edwards Deming, etc., have not used the term "internal customer" in their works. They consider the "customer" as a very specific role in society which represents a crucial part in the relationship between the demand and the supply. Some of the most important characteristics of any customer are that: any customer is never in a subordination line with any supplier; any customer has equal positions with the supplier within negotiations, and any customer can accept or reject any offer for a service or a product."

The equivocation fallacy is a dual use of the word "customer," in one sense meaning "entity on whom a business depends as a source of revenue" - and in another sense meaning "entity consuming the outcomes of the work done by a group of people." 

Why is that a problem? Demand.

When interacting with the open market, we would like to maximize demand - that is, we would like to have more customers constantly requesting more of our product, and more features from our product - to get them addicted for more, more and more. That enables growth, and makes our company sustainable.

On the other hand, internal demand is undesirable, because it diverts resources away from serving the real customer: internal entity A doing work for internal entity B means that B must spend time with A, which B doesn't have for the customer - and A must spend time to do something for B. That costs money. This money isn't profit any more, and the time B spends with A is profit not generated: internal demand costs twice. We therefore would like to minimize internal demand.

Equivocating "customers" to include both internal and external people opens the doors for a destructive game: maximizing internal demand. It makes internal service teams feel good about themselves and their work, while the inner proceedings bleed the company dry of critical resources.

By clearly differentiating between "customers" as "those who will determine whether they will pay for what we do" and "consumers" as "those who need what we do," we avoid this pitfall.

We won't go as deeply into other equivocation fallacies - just teasing what they are, and the damage that they're doing.

Experts

I chose that little quote from the Scrum Guide as an opener on purpose, because we hear very often that "developers are the experts, trust them."

The equivocation fallacy: Scrum requires developers to be experts in order to function properly. Many Scrum folks argue that being a developer means they're an expert.

This harms the developers when they don't get the support they would sorely need, and it harms the company when the team doesn't perform properly.

Owner

Actual Owners, according to Investopedia, are "a person or entity that receives the benefits of ownership." (emphasis added)

However, when you look at Scrum's Product Owner - how often are these individuals the real beneficiaries of the stuff they allegedly "own?" They have a bunch of accountabilities and responsibilities, but rarely own anything.

The equivocation? "Being a beneficiary of" and "Being accountable for."

The consequence?

While on the one hand, an owner can do whatever they please with their property, they tend to have a self-interest in maximizing their benefits. Without this self-interest, an Owner can merely minimize the effort they have to put into whatever they are supposed to "own."

 

Similar things apply to other forms of "Ownership" - process ownership, code ownership, system ownership or anything else: let people reap the benefits of whatever they're supposed to own, or it's going to backfire.

Value

Investopedia defines "Value" as "the monetary, material, or assessed worth of an asset, good, or service." In the "Agile" space, however, there's a notion that a Product Increment is the value produced by the team. 

That's a confusion of cause and effect: If the Product Increment has value, then the team has produced value. But merely because the team has produced an increment, it doesn't mean it is value - it could be that it actually has a negative value.

Value-Add

Not specifically an issue of "Agile," more a confusion in the entire IT industry - "value added activity" is an activity that increases the value of a product or service. Analysis, design, documentation, testing and support do not create any assets. They are therefore "non-value-added activity."

The equivocation in software development is that all these activities are also value-adding, since they're contributing to the creation of value.

Careful: Just because an activity is non-value-adding, that doesn't mean it's not required. It just means it's not increasing the value. 

Think of it like this: If you do more of activity X, does the company's total value go up? If not, then X is a non-value adding activity.

The issue?

We would like to maximize our share of value-added activity, and minimize our share of non-value-added activity. By equivocating, for example, testing, to be a value-added activity, we paint a picture that testing is something we should do more of, because hey, it creates value. No. It doesn't: It's an activity necessary to create and maintain value, but all other things equal, more testing doesn't mean we're delivering more value.

Value Stream

One of the latest fads that came up with SAFe is the "value stream." It's been around since the early days of Lean (although the concept was already used by Henry Ford around a century ago.)

Yet, if you'd ask how SAFe's "Development Value Stream" is different from a Software Development Lifecycle Process, people might not know how to answer - "Isn't a value stream just a high level process?"

That's the equivocation fallacy of value streams: Whereas a value stream is defined as "the set of value-added activities between customer need and realization of value by the customer"- when we modify the meaning of "customer," "value" and "value-add," then it is nothing other than a process.

The problem?
Clearly optimized value streams are make-or-break for the success of any business. Everything is subject to an organization's core value streams. Processes need to optimize around them. When we can't discriminate the two any more and locally optimize a support process at the expense of our actual value stream, we endanger the whole company.

Closing remarks

Equivocations make improvement difficult, because the thing we're talking about may not be the thing we're talking about. Let's get clear first what we really mean when we're talking about something, remove the equivocation, find a proper label that means what it says - and improve on the things that are hidden in plain sight by using the wrong words.

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.

The wrong professionals

Sometimes, I struggle with teams failing to understand the engineers' responsibility in quality: "I have asked the Product Owner whether we should apply Clean Code practices, and she said, she doesn't need it."

This is already not a conversation that should happen.

Here's a little metaphor I like to use:

 

And that has a number of consequences:

• Professionals do not negotiate the standards of professionalism with their customer. 
• Customers expect that the professional brings and adheres to professional standards, which is why they get hired. 
• Customers are not in a position to judge whether a professional standard is applicable in their context, and asking them to do so shifts responsibility to someone who can't bear it. That itself is un-professional.

So, what does that mean for your Agile team?

• Be as professional as you can, and continuously improve.
• Do not ask the customer to tell you what "professional" is.
• Instead, ask them whether your standards of professionalism satisfy their needs.
• You can't delegate the responsibility for the quality of your work to anyone else.
  The attempt is already un-professional.

Philosophy in Organizational Change

Yes, I'm opening a can of worms here. "We are here to work, not to philosophize!" - is that really so?
Before exploring this question, let me start by clearing up the common misgiving people have about "philosophy": this isn't idle chatter. Philosophy is all about "knowledge" - how we arrive at the conclusions we do, and what leads us to do the things we do. For example: We talk a lot about vision, strategy and values. But: How do we interpret our vision? What makes a good strategy? And how do we turn our values into behaviour? We need philosophy to move beyond the bla-bla!

I'm not exploring the entire domain of philosophy, only a few things that are really important when dealing with organizational change. And I'm just going to touch "What's in it - for you? Why should you care?" rather than explaining any details. All I'm trying to achieve is get your interest in the topic sparked. You'll have to do your reading by yourself.

Ethics

Every organization has its own set of implicit and explicit values and norms. Which ones do we have, why do we have them, and do they serve us in the way they should? How do they inform our choices?
What does it take to arrive at a different set of values and/or norms?

For example: If our organization values "being busy" - how could we move to "producing value" instead?

Logic

There are tons of illogical things going on around us every day, and nobody seems to care.

The majority could be wrong. And might doesn't make right. Just because something is right, doesn't mean it's true and vice versa. When something doesn't follow from the premise: can you spot it, and where would that lead you?

Sound reasoning leads us to make better decisions. How good is our organization at reasoning?

For example: Just because there's an unspoken consensus in your organization that you "don't deploy on a Friday", doesn't mean it's an indisputable fact: Why can't we deploy every day?

Knowledge

Did you ever "know" something was the right way to do things, only to find someone did the opposite - and got better results? Most of what we know is little more than contextual snapshots of momentary experiences, turned by our brains into immutable "facts". And while there are definitely some things where scrutiny just leads us off a wild goose hunt, there are other so-called "facts" that we must discard in order to grow. But how can you discern?

For example: We know for certain that there's a legal reason to archive every contract in written form. But ... how does a paperless, totally virtual company do business in compliance with the law?

Ontology

"What is ..." - the way we define things informs how we think about them. What is "value", what is "performance", what is "success?" - Do you have the necessary means to ask the right questions that allow you to align people around a common understanding, weed out misunderstandings, and provide a more focused definition that allows people to overcome their own mental barriers?

For example: As long as everyone has a different understanding of "Value", it becomes pretty hard to maximize value creation. How would you - properly - define it?

Philosophy of Language

Our lanugage affects our thinking, which affects our reality. The words we use have the power to unite, divide, shape or reform. The subconscious effect of our lanugage is that simple things could become possible or impossible, easy or hard. Our lanugage can create insurmountable barriers or build inviting bridges. How much of what we consider "real" in our organization is just so because we choose to use words the way we do?

For example: The most nefarious element we see in many organizations is calling people, "resources". It's not merely de-humanizing - it has practical impact: "Resources" are assumed to be interchangeable for one of equal type. That leads us to move people across projects in an attempt to optimize "utilization" - which significantly reduces performance, and thereby, drives cost and risk through the roof! 

Philosophy of Law

Ethics informs our norms and values. And what happens when we transgress those? Which one are we willing to sacrifice when two norms are in conflict? Based on what reasoning can we trade off one value for the other? 

For example: Who can decide whether it's okay to put a risky feature live that could either increase value or make customers unhappy? Can I, as an individual, place the value of learning above the risk? What consequences will my choices and actions have? 

Philosophy of Politics

Power rests where it does. We can choose to re-distribute it, but would that even be a good idea?
What's the relationship between a company and its employees or between "manager" and "worker"? What does security and individual freedom mean? How do we trade off between these, and what consequences do that have?

For example: By giving people a corset of processes, we offer a sense of security by working in accordance with known, explicit regulations - while stealing their freedom to do the right thing for the benefit of the organization. 

Game Theory

Every day, in every one of our actions, we weigh off alternatives. The course of action we choose is ultimately that which benefits us most. How do we set up systems where individual, group and organizational goals align with each other - and how do we ensure that everyone benefits most from actually pursuing these goals? Every system can be gamed, then how do we ensure that when it's gamed, we still end up where we want to?

For example: By measuring "Velocity", we might end up rewarding doing a lot of useless work, or by inflating the actual effort. None of that helps us. Then - what should we measure instead?

Conclusion

I hope that this teaser is enough to get you interested in learning more about the domain of philosophy, spend time on equipping yourself with understanding and methods to approach each of these topics, and begin leading the important discussions that will improve clarity, transparency and mutual understanding within your organization.

Stop asking Why!

 The quest for reason and understanding, for change and improvement, always starts by figuring out the "Why". And now I'm suggesting to "stop asking Why?" - Why? [pun intended!]

The problems with "Why" questions

Let me start with an illustration. 

Jenny and Ahmad struggle with major issue in an untested segment of Legacy code. Ray, our coach, joins the conversation by asking, "Why are there no tests available?" - "Because", Jenny snaps, "the guy who coded this didn't write any." How was Ray helping? His question wasn't helping, it heated the mood further - and it didn't generate any new insight.

So was it even worth asking? No. It was the wrong question.

And like this, many times, when we ask "Why", we're not doing that which we intend to achieve: generate insight into reasons and root causes. 

A second problem with "Why" questions is that all parties engaged in the conversation must be interested in exploring. When people are under duress, they are interested in solutions, but not long winded discussions. Hence, they may disengage from the conversation and claim you're "wasting time".

Why that's a problem

There are numerous other problems with "Why" questions that you may have encountered yourself, so I'll list them here as types of "Problematic Why" questions:

Why?	Example	Problem
Nosy	Why did you just put that document there?	When you dig into matters that others feel is none of your business, you will get deflection, not closer to the root.
Suggestive	Why don't you put the document in the Archive folder?	You're implying the solution, and the answer will usually be "Okay" - you're not exploring!
Inquisitive	Why did you put the document into the Archive folder?	It puts people on trial, and the response is often justification rather than inspection.
Accusatory	Why didn't you put the document in the Archive folder?	This immediately poisons the conversation, provoking a "fight or flight" response. Any sentence starting with, "Why didn't you..." is easy to interpret as personal attack.
Condescending	Why can't you just put that document into the Archive folder?	When your question hints at perceived superiority, you're not going anywhere with exploration - it becomes personal!
Commanding	Why isn't the document in the Archive folder yet?	Just like a parent asking, "Why are you not in bed yet?", this isn't an invitation to a conversation - the only socially acceptable response is: "I'm on it".
Rhethorical	Why don't we go grab a coffee?	The expected answer is "Yes".
Distracting	Why do you want to store your document?	Although this question could be interesting, it's taking the conversation on a tangent. I can un-proudly claim to have torpedoed an entire workshop with such a misaimed "Why" question.

While there may indeed be legitimate reasons to use these types of "Why" questions, please remember: If you want to explore and generate insight, these aren't the questions you may want to ask.

Why that doesn't help

"Why" questions become stronger and stronger as means of making people uncomfortable and less open to actual exploration as they contain, in descending order:

1. "You"
2. modals ("do", "can", "should", "must" etc.) 
3. negations ("don't", "can't" ...)
4. Past tense ("did")
5. Judgmental terms ("even", "bad")
6. Temporal adverbs ("yet", "still", "already")

And here is a full double bingo: "Why haven't you even pondered yet that your questions could be the problem?" - How happy does that make you to start a conversation with me on the topic?

 

With the above list in mind, when you begin analyzing the conversations around you, you may indeed start to feel that "Why" questions are often more reason for people to avoid exploring further than to generate valuable insights.

Why Blanks are also bad

Someone just made a statement, and all you're asking is, "Why?" - one word. What could go wrong? How could that be a problem? It can be.

Imagine you're in the middle of a conversation. Jenny says, "We didn't write enough tests." The insight is there. Now you just intercede with a probing "Why?" - and although you never said it, you have just accused Jenny of not writing enough tests, against better knowledge: her mind will auto-complete your one word question into, "Why didn't you write enough tests?"

What to ask instead?

Try re-framing "Why" questions, as to keep out of the solution space and to make people interested in actually having an exploratory conversation. The easiest way to do this is very often to avoid the term "Why" altogether.

When we take the table above, all of the "Why" questions could be replaced with an open conversation during the Retrospective, such as: "I sometimes have a hard time finding ourt documentation. What could we do about it?"

Almost all "Why" questions can be replaced with a "What" or "How" question that serves the same purpose, without being loaded in any direction. 

For example, the question "Why do we have this project?" sounds like, "I think this project is pointless!" whereas, "What is the intended outcome of this project?" assumes "There is a good reason for this project, and I may not understand it."

Likewise, the question "Why didn't we find those defects during testing?" sounds like, "Our testing sucks!", whereas, "How do those defects get into production?" assumes that "I don't know where the root cause is, and we have to locate it."

Summary

Take a look at when you use "Why" questions. Ponder when you didn't get the clarification that you intended. A truly open "Why" question can be re-framed as a "What", "Where" or "How" question that achieves the same purpose.

Experiment with alternative ways of framing questions that avoid pressing hot buttons, such as implied blame or command. 

In doing so, stick only to the facts which have been established already and do not add any extra assumptions or suggestions.

Be slow on "Why": Avoid the "Why" question until you have pondered at least one alternative that doesn't rely on a "Why".

How Agilists betray the very nature of Agility

Almost two decades ago, a handful of people started a joint journey of "uncovering better ways of developing software and helping others do it". The first value was "People and Interactions over Processes and tools". 

Scrum emphasizes the values of Openness and Respect. Coaches are expected to both exhibit and nurture a Growth Mindset.

And what to we do? The opposite!

Trigger Alert - this post will push a lot of hot buttons!

What have we become?

A large number of agilists get triggered really fast, really strong and really bad as soon as they read or hear certain terms. Why have the very people who proudly bear the labels of openness and respect, become so narrow-minded and show almost hostile reactions as soon as a few trigger words are uttered?

People who even dare to use certain words get stigmatized as "unenlightened" and "anti-agile" and are being told to "defend themselves" or apologize. This is neither open nor respectful towards the individual, much less towards their ideas.  Is this the type of interaction with people that agilists looking for?

When have we stopped thinking or asking, "What does the other person mean?" Why do agilists go into full confrontation mode as soon as these words are uttered? How is that behaviour different from a fascist regime where everyone who thinks different must either be converted or eliminated?

Creating taboos and instituting thought crimes fosters an environment where true agility becomes impossible. 

Trigger, trigger, trigger ...

It can be that you had bad experiences a hundred times and think you understand the antipatterns, but isn't it exactly what agile practitioners are trying to teach organizations - that past experiences  are not necessarily indicative of what is the most appropriate thing to do in the current situation?

Each person has their own understanding of reality, which is why communication is needed to collaborate better. Presumption doesn't get us anywhere. How about listening, before arguing? Why is it so hard to keep those guns down until the other person made their point? 

Now, let's see how much I can trigger you ...

Agile Project

Where do we start with an agile transformation? Let's start an Agile Project!

Ohh, I hear you shouting immediately, "There's no such thing as Agile Projects! You must do Product Development!" - can you even smell how dogmatic and close-minded this is? You're not inviting a discussion, you're ending it!

When an organization is operating in project mode, you must start somewhere, and starting with a single, decoupled project is significantly easier than starting by changing the entire organization's structure, management and process landscape. Starting with a single Agile Project allows you to separate concerns.

Fixed Scope

We need to fix the scope for our Agile Project.

Your answer is clear: "We're Agile! That's Big Upfront Design, Waterfall!" Proposing to make the scope known upfront is met with arrogance and disdain. You wouldn't even bother to ask,  "what do you mean by fixed scope", because fixed scope indicates that this person just doesn't get it.

Have you ever considered that self-organization happens within a context, and clear boundaries help teams to reach excellence?

Fixed scope doesn't mean writing a Detailed Specification Document. A team's scope is already fixed when the team is supposed to build spacecraft and not washing machines. Scope can be re-negotiated when it becomes a blocker, but operating within a fixed boundary enables teams to focus ... do you remember someplace where focus was acually considered a virtue? What do you focus on, when everything goes?

Milestone Date

Investors want to know when they can see something and want a roadmap with milestone dates. They expect a Return on Invest at some point. Within a corporation, senior management acts as an investor.

I know that you're going ballistic, "We can't know what or when!" - calling the request unreasonable and insisting on a free pass for the team. 

Oddly enough, I have never seen any agilist who would invest their own money into a business unwilling to commit to results, dates or ROI - everyone buys stock from companies that announce fiscal targets and product release dates ahead of time. Where does that hypocrisy come from?

Investors pay all the bills, including the team's salary. The answer, "We do frequent Reviews" is not helpful without a specific date when it's possible to make a decision on whether to pull the plug or to proceed.

Running this decision multiple times per month would put a tremendous amount of stress on the team and promote unsustainable behaviours. Quarterly milestones give the team sufficient room to breathe and allow the business to make wise investment decisions. 

After all, the business also wants to be agile - being able to spend the money on the most important initiatives, and not just let your team locally optimize what they build!

Product Roadmap

Our stakeholders want to know our product roadmap - what they can expect in the next year or two.

A roadmap instills confidence that you know what you're doing and aren't getting tossed about by every wind.

 "That's not Agile", I hear you scream!

We have a product vision and a product backlog. Some items in the backlog are keys to business growth, others are just work. Take the keys and arrange them on a probable timeline. There is your roadmap: Was that so hard?

Being agile doesn't mean you stop caring about where you're going- it means that you're ready to change direction as needed. And guess what - nobody cares whether or how often a roadmap changes, as long as the current version makes sense and points towards valuable goals!

Progress Report

The next "Agile Antipattern" is the Progress Report. "We have Reviews, and thus, progress reports are a waste". The mere suggestion of a progress report obviously means that the individual doesn't understand agility and the organization wants to preserve status quo.

While we can simply assert that it would be best for the team to operate in a vacuum  - they don't. They operate within a context, and that context won't magically go away just because we wish it were so.

An agile progress report generates transparency where teams face systemic impediments and where they are calling for help. An agile progress report allows senior managers to pull levers that teams currently can't pull.

Senior managers are third-row stakeholders for your team who are hardly involved. Their skin isn't within the game, but they can  initiate change, and when they're responsible for dozens of teams, they can't give half an hour to each, every week - because as unthinkable as it sounds, they also do things that have nothing to do with the team's problems.

Can you respect the responsibilities senior managers have and that they are trying to use their own time as effectively as possible?

Returning to Reason

You may still disagree with the explanations I have given, but hopefully you have realized, "Yes, there's some reason behind this, and the person isn't actually so insane that they need to be lobotomized on the spot."

Speaking about our perspective opens the door to a conversation. Reasonable people are willing and able to listen to reasonable arguments. Blame and accusation aren't reasonable. Attacking the individual who speaks their mind and tries to learn closes your own door towards learning and growth and betrays the idea behind agility.

A wise person once said, "We are all where we are.
A 3-year-old lives the life of a 3-year-old, an 18-year-old that of an 18-year old, and an 80-year-old that of an 80-year old.
We can not expect the 3-year-old to live the life of an 18-year-old with the wisdom of an 80-year-old.
When we look at a 3-year-old, we should enjoy that they can live the life of a 3-year-old. They will be 18 in fifteen years, so give them time.

Can we have this kind of respect towards people who are not where we deem ourselves to be?

What is "Value"

In the book, The Professional Product Owner (which by the way I recommend each Product Owner and Scrum Master to read) the authors Don McGreal and Ralph Jocham, under the heading "Value Defined" (pg56) discriminate "Value" into three different categories:

Types of Value

The italic quotes in this section are verbatim quotes, and I will comment on them below:

Personal Value = Personal happiness

 As people, anything we consider to be of value ultimately comes down to one elusive element: Happiness. Is money valuable? Only if it makes you happy. More time with your family? Only if it makes you happy ... Time, money, good job, these are only circumstantial evidence of value. We assume having more of them will make us happy.

Business Value = Money

 As companies, anything they consider to be of value ultimately comes down to one elusive element: money. Are happy customers valuable? Only if they pay for your product. Is a good culture valuable? Only if it reduces the cost of attracting and retaining employees. Happy customers, good culture, steamlined processes; these are only circumstantial evidence of value. We assume having more of them will make (and save) us more money.

Nonprofit Value = Improving Society

 An obvious exception is nonprofit organizations (...) where value is about improving society. For nonprofits, money is circumstantial. In fact, revenue while not positively impacting society would be considered negative value.

A myopic definition of Value

The short form would be: "People see value in happiness, businesses in money and nonprofits in improving society."
Personally, I disagree. All three of these statements are myopic. And here are my cases for ponderance:

Basic human needs

Why do people see a doctor? Is it to get well, or is it to be happy?
While there are indeed certain pills that "make people happy", most people would agree that health is a value in and of itself, regardless of whether it's connected to happiness.

The entire Maslow "Hierarchy of Needs" doesn't even contain the term "happiness", and there's a reason. When people's basic needs, such as food, shelter and safety are unmet, happiness is irrelevant. Likewise, it's entirely possible to have psychological needs met without seeing fulfilment - which meets the need, but doesn't result in happiness.

Therefore, people are looking for other things than happiness as well.

Emotional Compass

And finally, to put the nail into the coffin on the happiness argument:
Happiness is but one of many human emotions. When we study the Plutchik Wheel, we discover that there are eight base emotions, with different nuances on each, accompanied by different attitudes, and they can even combine to form yet other emotions. The mix of all of these is what makes us human, a biased pursuit to ultimately have only happiness makes us shallow.

And without going further into details, both Christian and Buddhist teachings contradict the idea that the pursuit of happiness leads to a fulfilled life.

Therefore, happiness is one, but definitely not the only, thing people strive for.

Online Games

Why are "free games" such powerful cash cows? Is it because everyone eventually pays? No!
One of the core tenets of Free-to-Play Games is that you need a massive player base in order to attract some so-called "Whales", that is, people with a high willingness to spend a high amount of money on games. Some games go as far as calculating that they need about ten free players to attract and retain just one paying customer, and maybe one in a hundred of those paying customers is a whale - so basically, your entire business model is built on the idea that 99% of your player base play at or below cost in order to rake in the cash from a few hundred!

Therefore, attracting and maintaining unpaying customers may be crucial to your business model!

Cross Service Subsidization

About a decade ago, Deutsche Bank chose to make their unprofitable private customer banking segment so unattractive that millions of customers simply left.

Too late did they realize that many individuals (myself included) are entrepreneurs who also have a company. And when your bank basically gives you, as a private person, the extended middle finger, you'll consider twice where you, as a businessperson, take your transactions.

The money of this segment wasn't what made this customer group valuable - their entire value was in enabling other business segments!

Therefore, eliminating unprofitable customer segments may be economic suicide!

Interests aren't Improvments

It's not necessary for a Non-Profit Organization to actually want to "improve society". Although a large number of NPO's are formed around a societal goal which they themselves consider an improvement based on their perspective, this isn't the only reason to have an NPO. Indeed, an NPO only means "Not for Profit", which only excludes profit as a motive. And this should also hint that there are indeed other motives which an organization could hold.
Also, according to Wikipedia's definition of an NPO, it's entirely possible for an NPO to further exclusively the self-interests of the organization.

Therefore, "improving society" is neither excluded from being valuable for a for-profit organization, nor is it necessarily valuable for a non-profit organization!

Other types of Value

Is money, or bottom line, the best measure for company value? I consider this view myopic.

"We're in business to earn money, and we build products to earn money, hence the best product is the one that earns most money." That's common thinking, but it's not that easy and probably the reason why so many companies get in trouble on a strategic level.

Personal Values

People value a whole range of things, and happiness is just one of them. There are a wide range of things people can value that neither directly nor indirectly translate to happiness. Instead, the validity of these values depends on a person's core belief system, which is not the same for every person.

Here are just a small number of things which people might value that have at best extremely fuzzy links to happiness:

• Health
• Life
• Compassion
• Kindness
• Integrity
• Respect
• Religion
• Patriotism
• Environmentalism

I would like to argue, based on the standpoint of the authors, which shows the absurdity of the concept of taking individual happiness as ultimate measure: 

• Is another person's life valuable, even if it doesn't make you happy?
• Is respect towards other people valuable, even when they don't make you happy?
• Should we do something about climate change, even if it means that you may have to stop doing something that currently makes you happy?

With the argument that "only what makes you happy has value", we create a corrupt, unsustainable society!

Although each person has their own set of core beliefs, I think I made the point that adopting the core belief of "do whatever makes you happy and ignore everything that doesn't" could lead to an entirely broken moral compass.

Strategic Values

When I was an inexperienced agile coach, I used to abide in the narrow definition of value that everything can ultimately be translated into fiscal value. I was quickly taught something else. Managers in organizations see a huge variety of "strategic values" that are extremely difficult to express in terms of money, just to list a few of them:

• Brand
• Reach
• Dominance
• Exclusivity
• Publicity
• Influence
• Reputation
• Visibility
• Networks
• Recommendations
• Partnerships
• Alliances
• Capability
• Scalability
• Descalability
• Flexibility

While some of those things could indeed translate to money in the long term, it's about impossible to relate a single backlog item's contribution to any of the above to a meaningful fiscal quantity.

Conclusion

Ultimately, if we stick to an overly narrow, dogmatic definition of "Value", we lose opportunities and might be acting against the best interests of ourselves, our organization, our society and eventually of humanity.

Instead, we might want to reflect on this one simple point and explore: "What do we consider valuable - and why?"
The answer will be different for different people, different teams and different organizations, and change over time.

The Management-Coach clash

When an agile coach or Scrum Master is brought into a traditional line organization, there is a high risk of misunderstanding and clashing, oftentimes leading to frustration. Why is that so? Let us explore the traditional expectations towards different roles.


Upton Sinclair said it all with his famous quote:

It is difficult to get a man to understand something when his salary depends upon his not understanding it.

As I had these discussions multiple times in the past, here is a short diagram to illustrate what causes the clash. We will explore below:

Asserting authority

Managers get paid to be in control of their domain. When things aren't under control, they are expected to bring them under control. A good manager is expected to be able to state at any time that everything happens according to their provision, and nothing happens that wasn't agreed beforehand.

A consultants' authority is granted and limited by their hiring manager, and the consultant is expected to exercise their authority to drive their specific agenda in service of their manager.

A coach doesn't assert authority over others, and won't drive a predetermined agenda. Instead, a coach helps people realize their own potential and freely choose the course of action they consider best - although clearly within the scope.

And that's where coaches and managers clash:
Managers might think that coaches will exercise authority over the team and thus be sorely disappointed when they see that the coach isn't in control of the team's work, and the coach will be sorely disappointed when management reveals that they think the coach is doing a crummy job for not taking control.

Solution focus

Managers are expected to have a solution, and do whatever it takes to get one. The proverbial statement, "Bring me solutions, not problems" is descriptive here. When higher ranking people within the organization ask a manager about something within their domain, the only appropriate answer is either "This is our solution" or "We are working on a solution."

For consultants, the only appropriate answer is "This is the solution", or maybe "I need x days and then I will give you the solution"

Coaching is an entirely different book: "The solution is within you. I will help you find it." - maybe the coach does have a clear understanding of the solution, maybe not. This isn't even relevant. Important is that the coach guides others in finding their solution.

And that's where coaches and managers clash:
Managers might think that coaches are problem solvers. With this expectation, either the coach should take proactive steps to install a solution before the problem occurs or immediately resolve any issue once it occurs.
Looking at the flip side of the coin, the coach may argue that they can't work with managers who always look to the coach for the solution and aren't willing to spend time and reflect on the situation.

Getting people to think

In traditional management, managers are considered intellectual, "thinkers". Their job is to think, so that others can do. (Let's ignore for argument's sake that most managers' calendar is so cluttered with appointments that they have zero time left to think.) Statements like "This is above my paygrade" are epitomes for a corporate culture where thinking is considered the responsibility of management.

A consultant has a higher self-interest in getting some people to think - at a minimum, the hiring manager should put enough consideration into the consultant's proposal to understand how their solution will affect the organization, preferably in a beneficial way.

Coaches take another stance: Ideally, they encourage others to think by asking probing, critical questions and being skeptical about other people's solution - in order to help people get beyond preconceived notions and think in wider horizons. The more thinking a coach does for the organization, the less sustainable the solution will be once the coach leaves.


And that's where coaches and managers clash:
Managers might expect the coach to use their free time to think of better ways of doing things and then come back with a clear list of improvement suggestions that just needs to be ticked off.

A coach might not do that, which neither means the coach is lazy nor that the coach isn't smart enough to do that: The coach will have a number of items in mind that need to be worked on, and help the organization get to these points one by one, when they are ready. Maybe the only thing management sees is that coaches asks a few key questions so that people will think about what's really going on and which systemic changes will improve the situation.

Defusing the conflict

Misalignment of expectations is the main cause of frustration between coaches and management. Early and frequent communication helps. Coaches need to understand how managers tick, what they get paid for and what they expect. Likewise, managers should be cautious about hiring coaches before they understand how a coach works.

For a manager, it's okay to get a consultant rather than a coach, and indeed that may be better than hiring a professional coach and expecting them to work as a consultant. It's also okay to tell the coach to tone down on the coaching and dig more into consulting.

For a coach, it's okay to start a serious discussion whether coaching or consulting is more congruent with management expectations, and propose switching into a consulting mode as fit. It's also okay to tip your hat and take your leave when consulting isn't what you expect to be doing.

It's not okay to get angry and blame one another just because we don't understand each other.

You have to be crazy to hire consultants

"You have to be crazy to hire consultants." - I repeat this sentence quite frequently after arriving at this conclusion almost a decade ago. Being a consultant myself, I think this statement is merely a reflection of the way how many clients see consulting work. Let me explain. 


Before we start, this article isn't about outsourcing services far outside your core value stream - for example, I myself resort to the services of a tax accountant, because studying tax law in detail would derail my value focus. This article is about consultants dealing with the core competencies of your organization.

Pervasive Taylorism

Most organizations are still set up according to the principles of Taylor - workers do the work with managers ensuring that they do the right work right. In knowledge management, "doing the work right" is known best to the workers and not to management, so that leads to the first level of craziness:

Organizations both expect and reward managers for being in control. Managers are expected to be responsible for coming up with solutions to known problems. Workers, on the other hand, are being overburdened with work and couldn't care less about resolving endemic problems, since that's not what they were hired for.

And like this, the most qualified people don't do that which would help the organization most and the least qualified people often decide on changes that don't help at all - and nobody sees a problem with the approach.

Inability to solve problems

When a problem arises, team members are neither enabled nor available to solve it. Management would then often demand, "Bring me solutions, not problems" - although teams working in a local context are often incapable of doing this when the root cause is outside their sphere of control. When the teams themselves have no solution, the obvious solution is to bring in consultants to provide a solution, since managers are busy with their other responsibilities.

And this is the second level of craziness:

1. People with the skills to solve the problem don't get time to think why the problem exists.
2. People in a position to solve the problem don't have the skills to solve the problem.
3. People hired to solve the problem won't have to deal with the consequences of the solution.

Absurd Incentives

Dysfunctional organizations thereby create absurd incentives, the third level of craziness:

• Team members willing to solve problems get punished with overload because problem solving time isn't factored into their already full workload
• Team members might be reprimanded for wasting time when their solutions are ineffective, making "doing nothing" the preferred option
• The separation of management and doing work renders managers who solve problems ineffective in their management role, rewarding managers who do not spend time to solve problems.
• Not investing time into active problem solving rewards managers who delegate problem solving to others.
• Project organization rewards managers for band-aid solutions with a life expectancy not much longer than the project's duration.

The need for consultancy

Thereby, organizations reach the fourth level of craziness:

Team members and management are likewise incentivized to not assume personal responsibility for sustainable improvement - thereby incentivizing management to hire external consultants, who get paid to solve problems nobody else benefits from solving and who can conveniently be blamed when the solution doesn't work out.

In conclusion: the amount and frequency of resorting to external consultants are a decent measure for the level of organizational craziness.

Fixing the root cause

You'd think it should go without saying that the solution here isn't hiring more consultants to do an Enterprise Transformation, yet that's what organizations do: the ultimate level of craziness.

So, if more consultants aren't the solution - what is?

To make a long story short, rather than adding further layers to the problem, we need to dig down to the root cause: the distribution of responsibilities within the organization and the perception of what management in a knowledge era means.

Fundamental change must start there, and the people who have to make the change are the people of the organization themselves!

While consultants and trainers can provide options for a different way of doing things and can assist in the transition - the change must ultimately be determined, owned and executed by the people of the organization themselves!

Coaching or Consulting?

Draw your own conclusions.

Making sense of Agility

"I know this doesn't make any sense, but ..." - aren't you all too familiar with this response towards questioning a specific process or practice? I have started the agilecartoons series to highlight the absurdity of practices and ideas some organizations hold dear. But is absurdity sufficient reason to say "That's not Agile"? I myself am not a big fan of either using the "Big-'A' -gile" nor about branding anything or anyone without understanding their context. So let's drill in.

Transparency

We need to be able to understand what's going on around us. Awareness of what's happening is very important when making decisions. With more transparency, we can put our ideas, actions and options into a more appropriate context. As transparency goes down, we resort to doing more and more guesswork and the probability of poor decision making increases.

So, here's the first sense-making question:

Does it make sense to make a decision with the understanding we currently have?

Inspect

Rather than just doing work, this work must be seen in context, the big picture. And then we need to take one step back and determine whether our actions, choices or ideas fit into the picture and whether that picture looks odd.

This brings us to the second sense-making question:

Does it make sense to do the things we're about to do next?

Adapt

Upon discovering that something does indeed not make sense, does it make sense to do that thing? If you answered "Yes", I will rest my case. Otherwise, we need to look for the most sensible option at our disposal. I carefully avoid the term "right", because right and wrong may only be visible in retrospect.

This brings us to the third sense-making question:

Does it make sense to do something else instead?

Feedback

When acting within an complex system - and organizations tend to be inherently complex - then our predictions about what would make sense are often not very accurate. We could be anywhere from outlandishly wrong to precisely correct with the choices we made. Fire-and-forget decision making often results in heaping one more dysfunctional approach over another. When we tried something, we need to look at our current situation by asking:

Did the things we just did turn out to make sense?

Does it make sense to "go Agile"?

If the answer to the sense-making questions is "No", hesitation, reluctance or even resistance, then - sorry to say - what you do doesn't make any sense, by design. As long as there is a mental barrier to getting to "Yes", no amount of "Agile" frameworks, methods, practices or concepts will make you agile. Your system is broken and you should examine that first.

If, on the other hand, everyone can wholeheartedly say "Yes" to the four sense-making questions, then you may find value by experimenting with those agile frameworks, methods or practices that make sense.



P.S.:
The avid reader may have noted that the first three elements are called "The Pillars of Scrum" (and/or "Empiricism") - and at the expense of stating the obvious, your willingness to uphold these elements is essential in determining whether it makes sense to introduce Scrum.

The self-preservation of Corporate systems

Can we fundamentally change a company culture? If so, how can we approach it lest the self-preservation mechanisms snap the system back into its former status quo? Let us examine the joints and levers within a typical corporate system with a causal loop diagram - and what we would need to tackle to make a lasting change.

A stable corporate system

Before we take a look at the slightly scary diagram, let me explain the basic representation model:

Defining the model

Black rectangles represent organizational artifacts and/or structures.
The colors red and blue represent negatives and positives, so respectively:

• A red circle represents a negative system variable of which you probably want to have as little as possible.
• A blue circle represents a negative system variable of which you may want to have as much as possible.
• A red arrow represents a negative causation, which means by adding more of the source, you get more of the target.
• A blue arrow represents a positive causation, which means that adding more of the source means you'll end up with more of the target.

With this in mind, take look at the model:

Example 1: Titles and hierarchies

Why do organizations assign titles and positions? You may find numerous reasons,such as a way represent responsibility, denote boundaries, indicate paycheck size or soffer prestige as a non-monetary reward or incentive.

Regardless of the initial reason for creating a title, the title or position derives meaning from the privilege it provides. Any such privilege indicates that a hierarchy is formed.
For example, you can't have a Ministry of Silly Walks if there's nobody in charge of Silly Walks - so the organization gets divided into those responsible for Silly Walks and those not.

As long as the position and the title exist, the organizational boundary continues to exist, and as long as the organizational unit exists, it needs someone in charge and some executive function to take strategic responsibility.

As the years go by, it becomes impossible to discern whether the Ministry of Silly Walks exists because the company needs it, but since it has a function, it needs to continue to exist - and when someone from that unit leaves, another person is hired to fill the role: The position exists because the hierarchy has a place for it, and the hierarchy has a place for it because it exists.

As more organizational units are added, the hierarchy becomes stronger - and a strong hierarchy needs clear separation of responsibility to function: a positive reinforcement loop.

Example 2: The mindset of a hierarchical organization

As soon as a hierarchy has been defined, people start to think in terms of that hierarchy. "We need a Silly Walker for the Ministry of Silly Walks".

It doesn't stop at needing someone who meets the requirement of Silly Walking: we wouldn't want to hire just anyone for Silly Walks - we need someone who is good at Silly Walks, who has experience and who is the perfect fit for the position. Rather than consider the myriad of ways in which a person can add value to the organization, the position of Silly Walking would be given to a person with proven track record of Silly Walks, a person with a history in Sales and Marketing wouldn't even be considered.
Likewise, a person who worked in Silly Walks for years is "obviously" best suited for Silly Walks. It becomes ludicrous to entertain the idea to place such a person in IT or customer care. The pervasive mindset becomes that people can only be good at the things they did before - a "fixed mindset":

As titles become more important, people themselves stop entertaining the idea of changing roles - why would a VP of Silly Walks want to take the role of "Developer" or "Scrum Master"? So instead of moving towards a system where people can learn and contribute the highest value to the organization, the system preserves its hierarchy: "Because I have this position, I will fight tooth and nails to preserve its existence."

We end up with a vicious circle where a fixed mindset entrenches itself and becomes a self-fulfilling prophesy.

Example 3: Transitive preservation mechanisms

When an organization would take steps to fix their problems one by one, they could do something about it - for example, let's say the organization would choose to get rid of the hierarchy in an attempt to remove the need for Resume/CV processing:

They will soon discover that the hierarchy isn't what led to the need for CV processing, although by direct causation, the primary construct which made Resumes necessary no longer exists. Even if the entire management layer would leave, people would still think in titles and positions, would still feel a person's value to the organization could be defined by their CV - and would think that CV's are still a good idea. Eventually, people would resort to "fixing the problem" of absence of hierarchy by - reintroducing hierarchy.
The transitive nature of systemic dependencies would rengenerate the system back to former status quo.

The complexity of the system

We just took one small example on three items from the system model - and there's a whole lot more to it. For example, large hierarchies with clear boundaries set people apart: "Those sales peeps" or "That's an IT problem" are just examples of common statements we often hear.
To control this separation, reports are introduced - and reports without consequences are meaningless, so systems of reward and punishment are introducted - which induces fear, both on punishment and reward (Fear of Missing Out) - which leads to shoving problems under the rug, which reduces transparency, which makes it more difficult to trust -- yada yada.

Regardless of where we look, a corporate system makes sense when looking at it from within the system: if we would abolish any single component, there would be more problems, so we need to re-introduce said component.

The real issue behind such a complex system is its tendency to meet the Laws of Irreducible Complexity.

Self-Preservation

A corporate system preserves itself due to a number of closed and transitive feedback loops: for example, even if we would remove the "Reporting" and "Rewards/Punishments" components from the system, there would still be the problem of distance and absence of trust, which seems most logical in the Enterprise world to fix via introducing the abolished mechanisms.

Delayed effect

Change isn't instantaneous. An organization suffering from strong negative system variables or weak positive system variables won't spontanenously fix their problem by changing their components. For example, if we have a high fear factor, stopping extrinsic incentives isn't going to remove the fear - removal of fear takes a long time, and some people might never overcome the specters of the past.
Removing a systemic component and dealing with the systemic variable by introducing a "repair construct" (such as coaching) need to go hand in hand - yet aren't a guarantee for successful change.

Change your mind!

Startups and small companies get by quite well without any of these mechanisms, and many larger organizations (such a volunteer organizations etc.) can also do without such artifacts.
Why does it work there? Because the basis is completely different. Instead of investing into hierarchies and titles, they invest into getting meaningful work done. Instead of introducing reports, they work on creating transparency and trust. Instead of creating a value plaque to hand into HQ, they talk about what matters to them. Instead of hiring for fit, they hire for value - and so on.

You can't reinvent a corporation by abolishing or fixing one mechanism - you have to start with the mind and work on everything at the same time!

Complex, yet simple

This model contains a lot of assumptions and simplifications. Organizations are significantly more complex, and the mechanisms which make people tick could be innumerate. I wouldn't be able to fit all important factors into this model and still let it be readable.

When attempting to make changes to a complex system, we need to understand the important components, variables and levers. What we consider "un-important" and neglect in our modeling might crawl out of the cave and bite us at the most inconvenient moment. Even with the above model, careful consideration needs to be exercised before trying to change a system.

Conclusion

There is no simple way to change an established organization, even when that organization is a dreadful place to work.

It's much simpler to build up a new organization with a blank slate and without all the harmful constructs than fixing an existing system.
Where this is not an option, the process of change relies on constant feedback about the current state of the system and permanent discovery of the hidden systemic factors which would snap the old system back into place.

Why "Agile" rarely works

Have you ever wondered why every organization wants to be agile, yet very few managers are? 
In this article, I will explore a highly philosophical model to attempt an answer.

TL;DR: Because it means changing how we see reality - and that's a price few are willing to pay!


Let's explore the model:

Yes, the main terms are German - because I realized that the English language uses the same term for "how we see the world" and "how we think the world is" - a distinction that clearly exists in the German language. Then again, I use the term "world model" - so let's float with English. Let's take a look at the model from right to left. I will just gloss over the deep concepts of these terms, because this is just a quick glance rather than a scientific essay.

Reality

Reality does not care for us - it's just us who are affected by it. The better we get at predicting how reality will respond to our interactions, the more we start to believe that we are "right" about reality - while essentially, it's just congruence between our world model and reality around us.
For example, a team might just do what they do - oftentimes, oblivious of their managers' thoughts and without regards to whether any manager is even around.

Impressions

As we observe or interact with reality, it affects us - what we feel, see, how we classify things, and what we would do next.
Our impressions are strongly filtered: First, we only receive a limited amount of impressions - essential information may exist outside our impressions. Second, we have a strong tendency to only receive those impressions we are looking for.

As a specific example: A traditional manager observes an agile team in action. The manager might get the impression that "this team is working laissez-faire" because nobody is checking on people, and might also get the impression that "this can't work" because there is no visible hierarchy in the team.

To change our ways, it's quite important to discuss the impressions we receive, in order to learn where we lack "the big picture" or we're over-emphasizing details.

World view

Our world view is the main filter of the impressions we receive. Every impression consistent with our world view will be forwarded into our conscious thinking, while impressions that are inconsistent with our world view will either be reinterpreted until they fit - or they will be discarded outright.
In this sense, our world view is the "eye" through which we obtain information. A narrow world view will imply that few impressions will go through unfiltered - while a broad world view will allow us to receive a lot more impressions.

Giving an example again, when an agile team decides to abolish progress reporting in favour of live product reviews, their manager must first be open to the idea that "working software is the (only relevant) measure of progress". As long as the manager's world view does not allow measuring progress in terms of production-ready software, they will discount both the benefits of interacting with users and the additional productivity obtained by not tracking work. Instead, their world view will make them see all the problems encountered by the team as caused by not following "a proper process".

The challenge with our world view is that it is strongly related to our world model (which is why in English, that would be the same term): what we see depends on what we can see. As long as our model does not permit us to process a different perception, our view will be limited to perceptions consistent with our model.

Genuine change, then, requires us to at least permit the possibility that our model is incomplete or even "wrong".

Perception

As the German word "perception" is also rendered, "taking as true", we can only take as true that which makes a true claim within our world model - i.e., only that which is both consistent with what we already call "true" and also within a spectrum of what we can classify to be "true".
Problems arise when we have already accepted false claims as "true" - we will discard or re-classify perceptions that are actually based on relevant impressions.

To take this out of the abstract realm, as long as we swallow the idea wholesale that "order is good, chaos is bad", we will never be able to appreciate the shaping and creating power of change - because change means that we change away from that which we consider "ordered" into something that, based on our current understanding, might be "chaos". Specifically, a self-organized team may not have a spokesperson or team leader at all. Such a team appears "totally chaotic" from the perspective of a manager who is used to corresponding only with team leads - and it will be very challenging to accept such a team as mature.

As long as we rely on an immutable world model, it's really difficult to see the benefits of conditions that don't git our model. Our perception of things that others consider "good" might be "bad", and we will classify situations accordingly.

World model

At the core of everything we see and do is our own world model. As hinted above, our world model has already decided whether any impression we receive is "true", "possibly true" or "false". Our world model helps us determine whether reality as we perceive it is "good" or "bad" and what we should then do.
The more static our world model is, the more binary this classification will be - and the simpler we will make decisions. Or, in other terms, "confidence" and "certainty" depend on a rather static world model, while ideas such as "doubt" or "hestitation" are related to a shifting or shaken world model.

Let's talk about me in this example: A few years ago, I was certain that clear process definitions would solve all business problems. Today, I stand on the perspective that clear process definitions in a changing world are the cause of all business problems - we need to be flexible to deal with situations that haven't happened before (and that may never happen again).

Summary

"Agility" might have to shake up our world model - as long as we're striving for certainty, we apply perception filters and biases that make situationally right choices invisible and lead us off-track. At the same time, the price of adjusting and softening up our world model may be high: we may need to admit that that which we fought for, sacrificed for, stood for, are no longer valid.

And that's the difficulty with agility: before we can get the benefits of being agile, we ourselves need to adjust our world model to be ready being agile.