Wednesday, February 14, 2018

Five Things to avoid as Scrum Master

What makes a good Scrum Master, what makes a bad Scrum Master? Here is my short list of things a Scrum Master will not do in my team. This post is written from a Product Owner perspective, so YMMV.

#1 - Dogma

This has got to be the absolute #1 on my list as it is my personal pet peeve.
I don't care what this or that guru said about Scrum, and I don't even care what you think Scrum means. I'm not using Scrum for Scrum's sake. I care for stuff that works - and for fixing stuff that doesn't work. I've had too many conversations with certified ScrumMasters who claimed "According to Scrum ...", and my only response was: "Show me the passage in the Scrum Guide!" (knowing full well they were proliferating a myth). If you can't explain to me (or my team) why the things you think should be different would work better than what we're currently doing, you're wasting everyone's time.

#2 - Factions

Your job as a Scrum Master is to create one high-performing team, and that just won't work if the team is wasting energy fighting against others (or even worse, against each other). If factions exist, you should try to mend them - and if none exist, I would expect you to be the last person to create some. Factions often come with actions such as placing blame (aka. finger-pointing) or perceived feelings of superiority. I expect you to not tolerate, much less support any such behaviour.

#3 - Menial labour

Also known as the "Jira Admin". If your entire responsibility in the team boils down to doing the things nobody else wants to do, such as updating tickets, writing reports or organizing meetings, you have clearly not understood your role. As Scrum Master, your value is exclusively limited to the additional performance you bring out in the team. If you can get 5 people to work 50% more effective, you're pulling your weight. If, however, you're just doing work that a minimum wage worker could do after a week of training, don't expect a higher pay than minimum wage.

#4 - Breach of trust

As Scrum Master, I expect you to be the person in the team who has the highest level of trust from anyone within the entire organization. I would expect that people should feel ready to confine their innermost secrets to you, even stuff that's totally NSFW, because they might need someone to talk about it in order to have a clear head for work. If you do stuff like reporting to management or tell team internal information to outsiders, you will never again be able to regain the trust you need in order to do a proper job.

#5 - Project Management

I do agree that not every team is ready for self-organization and sometimes, an intermediary path needs to be taken. As Product Owner, the person who would be doing inevitable PM activity would be me. As Scrum Master, frankly, you don't even need to know more about the team's progress than I and the team feel necessary. There is no reason why you should feel the need to coordinate, organize or report anything for anyone. Well, unless you're being asked to - and even then, you should ask "Why?"


If I see you, my Scrum Master, doing any of the above things, you're up for a long conversation with me regarding your role and responsibility. You will walk out with a clear list of things that you will change about your own behaviour as soon as possible.
If I see you continuing these things against better knowledge, I will make sure that I get a Scrum Master on my team who knows their ropes.

Sunday, February 11, 2018

The Agile / DevOps ecosystem

The question, "How does an organization, especially one that is already using an agile framework, benefit from DevOps?" is very common. In this article, I provide a succinct answer to this question by examining the benefits provided by some standard frameworks.

The development lifecycle

Irrespective of which approach a company is using, it all starts with a customer need:
This need must be understood, so we need to invest some effort into understanding.
In Scrum, we call this "Refinement". It could also be called an Ideation or Prototyping process. Regardless of how you call it - it's essential to build the right product!

Once understood, our next job is to build something. Any kind of iterative approach encourages us to build just a little, then learn from that. We want to minimize our upfront planning efforts and jump right into doing delivery work. In Scrum, that's our timeboxed "Sprint".

The objective of delivery is to get something shipped right to the customer, we want to make the product available. This is often called "Minimum Viable Product", in Scrum we call it the "Product Increment".

When we got the product out of the door, we want to learn how customers respond to it. This is where most agile implementations disconnect: Scrum has a "Review" - although the Review still happens disjoint of both the problems and opportunities arising when our product hits the shelves!
What happens in the "Real World" becomes the job of Support, Customer Service or Marketing.

This final piece of the puzzle is vital to build an even better product in the future. We want to iterate a full cycle in increments as small as possible:

The business opportunities when integrating this cycle are immense: Anything that is of value can be turned into revenue, anything that wastes effort can be turned into saving. To harness this potential, it's essential that a single team has the ability to recognize and create these benefits.

Now, it's time to take a closer look at some agile frameworks:

Standard frameworks


Scrum is the most common framework. It excels as a delivery framework. Based on the Scrum Guide, it neither cares for what happens in order to get the right items into the Product Backlog nor what happens after the product increment has been delivered.
A small fly in the ointment is that Scrum scopes the timebox: it doesn't bode well for a Scrum team to deal with unplanned work. Yet, everything that happens with customers in real time is hardly planned, much less does it make sense to plan it upfront.


Like it's cousin Scrum, Kanban focuses strongly on optimizing the delivery process. Kanban provides less emphasis on getting a planned shipment through the door, offering higher flexibility in dealing with unplanned work. Teams that have productive maintenance responsibility often fly well with Kanban.

Side note: Scaling Frameworks

Scrum scaling solutions, such as Nexus, Scrum At Scale (S@S), LeSS focus on doing the same thing with more people - getting better at delivery. Combining these frameworks with Enterprise Kanban practices, like suggested in SAFe, is still limited to the delivery portion.
While SAFe strongly encourages integrating DevOps, the suggested use of DevOps is still restricted to getting the product through the door in the most reliable fashion.

Design Thinking

It's often adertised that Design Thinking combines well with Scrum, and indeed it does. Design Thinking addresses understanding the customer need through systematic exploration before delving into a more costly delivery process.

Lean / Six Sigma 

Regardless of whether you're thinking Lean, Six Sigma, or the standard combination "Lean Six Sigma" - these frameworks address optimizing our existing product through better insight:

Extreme Programming

Returning to the agile hemisphere, Extreme Programming and some of its derivates, such as Programmer Anarchy, add more emphasis on understanding the customer and providing the right solution for the customer's needs.


DevOps is concerned with two things: Getting the product to the customer with minimal overhead and delay - and understanding how the product is being used.
The first, and well-known, portion of DevOps is providing an automated delivery Infrastructure - Continuous Delivery, Infrastructure as Code, Containerization, Logging, Authentication and many other things come to mind.

In addition, DevOps, done well, provide a myriad of analytical insights into the product: which features are being used, how new features are being received, where unexpected things occur, how to solve customer issues etc. This requires more than technical insight - it requires harnessing business insight as well!

The big picture

DevOps is an essential piece of the puzzle towards hyperperformant teams. The full power of an agile team requires a smart combination of discovery and delivery methods. It's your choice whether your team sails under the Scrum, Kanban, XP, none or any other banner - just make sure you cover all of the blocks:

Design Thinking shines for the "Understanding customer needs". Scrum is great to cover the "Doing work on customer needs" section. Combine these two with DevOps to optimize your "Working on the available product - both before and after delivery" approach.
For best results, you might want to add a touch of Lean, an ounce of XP and a pinch of Kanban,

Closing the loop

Let's forget frameworks for a minute. What's important is that you got everything covered. Use Design Thinking where it helps you build a better product. Apply XP where it helps you build the product better. Try Scrum elements that improve your delivery process. Utilize DevOps tools and practices to ensure you're doing the right thing when the rubber hits the road. And never forget - Lean/Six Sigma has really powerful tools that help you do the right thing better!

If you look closely, you will discover that this cycle is an implied "Build-Measure-Learn" cycle, which is the core premise of Lean Startup, yet another framework from the agile bucket.

Closing remarks

No single framework, approach or method is sufficient to deal with the complexity of creating and maintaining a successful product. All frameworks have useful and important elements to offer. Combining them for best results is a core practice of agnostic agile practitioners.

Sunday, January 14, 2018

Rules in a structureless organization

A critical aspect for Structureless organizations is how they deal with rules. One might think, "As soon as humans need to deal with each other, we need rules". Yes and no. Let's explore how rules change as an organization becomes Structureless.

We will explore the topic by starting with an unstructured organization, then progress from there.

Unstructured rules

Martial law - Unstructured rules
Unstructured organizations have rudimentary rules, which are often simply made up on the spot, either ad hoc or post hoc. Rules mostly serve as a means to protect existing power structures, i.e. to beat others into submission and to exhibit superiority.
Rules are made exclusively by those who have power, and the rules serve them and their interests.

There is little mention of rules unless one is quoted or created to deal with a specific situation - and even then, the rule is hardly ever communicated to anyone beyond those involved. There is no examination whether these rules are consistent, conflicting or even make sense.

Most rules are arbitrary and wouldn't stand up to scrutiny, yet they never get challenged, as challenging them would equal challenging those who hold the power. The only people who will challenge rules are those higher up in the food chain, and only when it serves their purpose. This is usually not necessary, as further rules can be added at any point in time, as the lack of transparency around rules will already ensure that nobody realizes the conflict.

The following characteristics are symptomatic of "rules" in an unstructured organization:
  1. Double Standards: Rules apply only to some groups. Others are exempt from the same rules for no transparent reason. For example, favorable rules apply only to those with power and unfavorable rules only to others.
  2. Rules that don't solve problems: Rules serve more to shame those who have infringed upon them than to solve a real problem.
  3. Post-hoc rulemaking: When a situation occurs that is unpleasant to someone in power, rules are set up post-fact as a smoke screen to deflect the blame.
Such rules will never be written down, as the mere prospect of doing so might end up in a lawsuit. Those in power will make sure that it stays like this.

    Indirectly structured rules

    Indirectly structured organizations do have rules - and lots of them!
    There seems to be a rule for everything - and most of these rules are highly formalized. They are intended to prevent any potential misunderstanding.

    Most rules serve as a means of avoiding the need to address the root cause of the problems which have surfaced in the past, and every action of people is encompassed by some form of rule. Similarly to unstructured organizations, there is little discussion around whether rules make sense or are even applicable.

    When people are unsure what to do, they will either try to discover which rule needs to be applied, or will look to someone in charge to provide a rule. In fact, people will try to avoid situations where no existing rule can be applied, as this poses an undetermined challenge. People tend to be more concerned with keeping the rules they have than whether these rules make sense.

    Rules in indirectly structured organizations serve a more noble purpose than those in an unstructured organization. There are actually two different purposes:

    • Providing safety to those acting upon the rules that their actions are meeting prescribed standards.
    • Providing a sense of reliability to those creating the rules that people will act predictably.
    The most denominating characteristic of indirect structures is the separation of decision and execution: Those making a decision are not the same people as those acting upon that decision. The indirection is in full effect when people state, "If you want to know why - please ask that person!"

    The following three items are symptomatic for rule-making in indirectly structured organizations:
    1. Decision proposals: Instead of just doing the right thing, people need to prepare formal proporals with slide decks for managers to get approval for doing what they feel should be done.
    2. Central Process Decisions: It's not the people doing the work deciding what the best way to do the work is, but some people who - for some reason - are believed to have some form of superior knowledge about this work. This often comes with a Process Management division defining SOP's.
    3. Finger-Pointing: People would rather apply an inappropriate process than admit they are not aware of what needs to be done. They can point to someone who prescribed the process and will claim inaccountability for the consequences.

    The rules in indirectly structured organizations are often religiously followed by people at lower levels of the organization, while people on the higher levels are hardly aware of their existence. 
    Managers in indirectly structured organizations are often even aware of this problem, yet are unable to trace this back to the system they have created.

    Directly structured rules

    Directly structured organizations oddly have fewer rules than indirectly structured orgs!

    Rules are less constraining and prohibitive than in an indirectly structured organization, as they are aimed more at clarifying structure, helping people organize themselves and getting things done than at stopping undue actions.

    Rules serve everyone and no longer treat everyone equally unfair. Rules acknowledge context and provide guidance. Rather than abolishing the application of common sense as an indirectly structured organization would, they guide common sense decision making at every level. Unlike indirectly structured organization, inapplicable rules are scrutinized and reworked as needed.

    Rules help people discover the most sensible course of action without being prescriptive on the course of action, permitting leeway for sensible choices. As the social and procedural context of the work might be dynamic, people need to be comfortable with discovering the best way to move forward. Rules would only be created when those doing the work are unable to produce a desirable result.

    Rules in directly structured organizations serve an even more noble purpose than those in an indirectly structured organization. Rules are directed at:

    • Providing a basis for mutually beneficial, positive collaboration.
    • Providing consistency on a larger scale.
    • Avoiding preventable fault, thereby providing psychological safety for those doing the work.

    Direct structures align need and provision: Those who have the need are able to either resolve it by themselves or directly access those who can. Rule decisions are made by those who can see and affect the outcome of their choices. The most sensible form of rule making in a directly structured organization is by asking those at the receiving end of a rule which kind of rule makes most sense for them.

    Characteristics of rules in a directly structured organization include:

    • Alignement with business goals: Rules support the work, rather than impede it. Rules that contradict business goals will be revised.
    • Scrutiny: Everyone may discuss rules, and this doesn't happen out of frustration, but to drive improvement. Rules that no longer serve their intended purpose might be abolished or changed.
    • Consistency: Conflicting rules which would result in a stalemate get revised.

    Rules in a directly structured organization clearly correlate purpose and outcome. It's not essential for people in areas unaffected by the rule to know about the rule - and when effects occur that are not intended by the rule, it will be subject to scrutiny.

    Structureless rules

    The weird part about rules in a structureless organization is that they don't seem to exist. This, however, would be a misunderstanding as rules actually do exist - except that they are usually implied rather than defined and people don't even feel the need to formalize them, as this formalization does not add any value.

    In general, the need for rules decreases as mutual understanding and alignment increase - and the high levels of collaboration in a structureless settings foster these things. While the creation of collaborative bonds usually requires a clarification of mutual expectations, rules are often not very helpful, because they are created with a lot of ambiguity and therefore, often misdirected. Much more important than setting a rule is aligning on the intended outcome of collaboration and creating an environment where impediments are quickly addressed and resolved.

    Formal rules in structureless organizations are usually externally imposed, such as laws. It goes without saying that structureless isn't anarchy - so such imposed rules need to be maintained. As they are not an intrinsic part of the organization, people will discuss these rules not in a setting on what to do with them, but on the easiest way to get along with them.

    Because structureless organizations no longer care about the rules themselves, discussions aim at:

    • Finding positive, effective ways of collaborating
    • Aligning mutual perspectives, understanding and outcomes
    • Resolving issues which might otherwise require rules.
    Nonetheless, these are already implicit rules - the rules of getting along and communicating. Probably the most important implicit rule of a structureless organization is the "No Asshole Rule". It will never be mentioned, as the mere need to mention it already means that a problem occurred that should not exist.

    Characteristics of the rules in a structureless organization include:
    • Implicit: Probably the most important characteristic is their implicitness: Rules do not need to be formalized, because they are implied by interactions.
    • Minimal: Since rules cause or hide problems, they are a "last resort", when all else failed.
    • Ephemeral: Structureless organizations rely on being able to constantly change and adapt, so rules might simply disappear when their context disappeared.
    • Local: Rules would only exist in a local setting, and there is no attempt trying to consider whether they could be generalized to a broader context, as if there was a need, it would pop up anyways.
    Structureless organizations aren't about rules. They are about aligning, collaborating and moving forward. When considering, structureless organizations have a lot of implicit rules - potentially more than the explicit rules found in an indirectly structured setting. The big difference is that rather than being in a manual nobody has ever read, these rules live and are part of people's lives.


    An unkeen observer might confuse structureless rules with unstructured rules - although the difference is immense! Whereas unstructured rules are makeshift constructs to preserve power, a structureless organization understands the advantages and disadvantages of formalization and has moved from the level of top-down exercise of power to mutual understanding.

    Structures are created to minimize communication over rules, assuming that rules can be formalized in an unambiguous way. Structureless organizations acknowledge that communication is essential to move beyond a limited and superficial mutual understanding. Once the necessary communication over collaboration has happened, the need for formalization disappears. Hence, the rules become implicit rather than explicit.

    Sunday, December 24, 2017

    Communication in a structureless organization

    How do structureless organizations communicate - and why is that an advantage?

    In a recent post, I addressed the topic of "structureless organization" from a maturity perspective. Let us explore structureless communications by comparison.

    Unstructured communication

    An unstructured organization doesn't have direct, congruent or consistent links between people. Somehow, everyone fits into the picture - but this "somehow" may neither be meaningful nor helpful to the organization or its customers.

    Broken links, ineffectivity everywhere: Unstructured!
    In the above illustration, there are inconsistencies between formal and lived structure (center), people who are somehow isolated from the structure (on the left) and broken links (manager to CEO). This means that necessary communication either doesn't happen - or only by chance.
    An unstructured organization amasses communication debt at the missing links!

    Now, let's look at what the communication looks like:
    Rabbit Trails, Loose Ends - good hunting!

    There are two communication chains. Assume you are a customer and need something that only the person (!) can help with.
    Should you happen to address person (1) in the picture, they will refer to their manager, who will refer to another employee, who will refer to a coworker, who will ... blah yada yada -- until another manager gets involved, who will address an employee who happens to know the person who can help you. There's a good chance you've already stopped in frustration before you ever meet person (!).

    Should you be so unlucky to address person (A) in the picture, they will refer you to person (B) - and you are none the wiser.

    Of course, "unstructured" is merely a strawman as this is definitely an undesirable state for any organization to be in. Just be aware that even within your structure, there may be unstructured areas that simply "fall off the chart".

    Indirect Communication

    An indirectly structured organization has directed and usually consistent links between people. The only downside is the nearly inevitable incongruence between need and structure. 

    A typical org chart

    This is what a typical "org chart" looks like. Communication is centralized around managers, who then delegate the task back into their own unit, until an executable level is attained. The idea behind this is to maximize the efficiency of the workforce by minimizing the amount of disruption due to inadequate requests.
    And this is how the communication is intended to flow:

    Don't worry. You will get an answer. Eventually.

    When you have a request that needs to be served by Team Blue (Tech), but your contact point is Team Red (Customer Service), the request will be judged by their manager, who will then take it yet one level higher, who will then inform the division manager, who will then inform Team Blue. The only good news in this one is that even though you have a long wait, something is eventually going to happen. It just takes patience.

    Let us examine what happens when people are missing: Flu season is coming!

    In this example, the blue manager has delegated represenation (<) to (?), so when Manager Blue is missing, (?) will act in their stead. This works out quite well when only one person is missing at the same time. However, when (1) needs a specific kind of help from team Blue, and the person named by Manager Blue as contact (?) is also missing, the communication chain is broken. When (4) realizes that neither (<) nor (?) is available, they might approach one person that occasionally also represents (<) - (5). However, that person is equally unable to help and so, the matter might remain sticking around until (<) returns. Usually, by then, the issue will be rotting as mail #51194 in Blue Manager's mailbox - abandoned, forgotten.
    In the worst case scenario, person (1) would require something from their communication partner (2), but has been named representative of (2) and the superior of (2), namely (3) is also missing - so (1) might be stuck in a catch-22 - making indirect structures similarly susceptible to fault as unstructured organizations.

    Side note: I happened to work for an organization once where the CEO claimed in an official newsletter that "if everyone would follow the defined communication paths and stop addressing other departments directly, we would be much more efficient". Does he really believe that?

    In reality, most communication in org-charted, indirectly structured organizations happens outside the formal chart - because it's so terribly ineffective. They implicitly create - direct communication, just to be able to get things done.

    Direct Communication

    The issues so commonly often associated with indirected structured can abysmally hamper an organization. Silo structures with broken escalation chains lead to tremendous inefficiencies. Direct structures resolve this matter by installing direct points of contact between departments who reduce both the amount of managerial involvement as well as the amount of steps required to get something done.

    We know who can help you.
    The typical term commonly associated with direct organizations is SPOC - "Single Point Of Contact". A senior member of each unit who is familiar both with the work that can be done by the unit and the people doing the work within the unit is assigned "SPOC". This person can be approached by anyone regarding requests within their unit, so SPOC Red would receive all requests done by Team Red.
    SPOC's are transparent, so a customer would either approach SPOC Red directly, minimzing the amount of overhead - or, if they don't know who SPOC Red is, they would approach anyone who would immediately know that SPOC Red needs to be addressed.

    Optimized for efficient communication
    SPOC Red might either handle requests to Team Red immediately or involve any team member from Team Red who can help. If SPOC Red receives a request that would massively interfere with how Team Red operates, SPOC Red will involve Manager Red for a decision.

    The reason why many organizations do not move towards direct communication is fear - managers fearing the loss of control.
    In a directly structured organization, managers aren't even aware of what their staff do most of the time. They operate autonomously to do what they can do to help the organization. This requires trust

    So - are there any drawbacks? None that would warrant going back to indirect structures. Compared to indirect structures, there are no business relevant downsides to establishing direct structures.
    The only drawback is queuing - the SPOC is an implicit queue. In some cases, the queue becomes explicit by having a ticket system where the SPOC stores and distributes requests. The more SPOC's an organization has, the more queues they own.

    How do we solve the queuing problem?

    Structureless communication

    Queues are horribly ineffective to manage - request load is hardly ever balanced in the working world. While one SPOC idles, another might not know how to handle all those requests. Managers might be tempted to install multiple persons as SPOC - increasing the throughput of the queue without ever addressing the issue why the team receives so many requests.
    Structureless organizations are different:

    In a structureless organization, communication paths are replaced with communication networks. Each person has their own, individual network of persons they collaborate with to get their work done. Managers in a structureless organization work fundamentally different from indirectly structured organizations: instead of controlling the work and communication, each manager supports their own people in order to collaborate better.
    Structural boundaries start to lose importance, as the manager's focus moves from departmental efficiency towards organizational effectiveness.

    And this is how structureless communication happens:

    When someone (1) in team Blue needs something they aren't familiar with, they ask around in their network. Maybe this is another colleague or even the manager - no reason not to. Manager blue might refer them to another person who works closer to that area of expertise, but who might not have the answer either. This person will then check their network until they found someone who can help.

    This is where the Bacon Rule kicks in, which posits that the maximum separation path between any two people on Planet Earth would be six, so usually within an organization, there would usually be four or fewer leaps until someone (!) is found. Once help is avaiable, the person will connect directly with the requester - so the next time, no communication path would be traversed.

    In a structureless organization, neither Manager Blue nor Manager Red are concerned with what (1) or (!) are doing and how much time it costs: If it's the most important thing for (1) to work on, there's a good chance that (!) benefits the organization as a whole by chiming in.

    What happens in a structureless organization when people go missing? Not much. First, people get familiar with the work of people done in their network, so they might actually be able to do part of it by themselves - otherwise, they do have some insight who the contacts of the missing person are and will ask around there.

    I would like to conclude with a small illustration of what happens in a structureless organization when one person leaves: Fill a bucket with water and put your hand in. Look at the water, look at the hand. Take your hand out. Look at the hole it left ...

    In a structureless organization, you are treasured part able to contribute. No bad things happen when you leave. You are free to be where you are or go somewhere. The organization can cope with it. No bad feelings when you're on vacation.


    From an objective perspective of reason, there is no reason to not move towards a structureless organization. This does not mean that there are no arguments against structureless. Most of them fall into a fear category:

    1. Fear of the Unknown ("I don't know what Structureless is")
    2. Fear of Poor Results ("But we won't reach our quota")
    3. Fear of Losing Control ("I don't know what my team will be doing")
    4. Fear of Lack of Authority ("But people need to be told what to do"), or vice versa:
    5. Fear of Uncertainty ("I won't know what to do unless someone tells me")
    All of these fears can be handled, although this takes a lot of time. Once someone has seen the beauty and effectiveness of structureless organizations, most of them go away. 

    To conclude, I will provide you with some examples of structureless organizations:
    1. Your friends. Nobody manages the bunch of you, yet you still get along.
    2. Any well-functioning team. There might be managers, but it's about getting things done, not about following structure.
    3. The agile community. Not only do we have vastly differing opinions and goals, we also argue quite a bit. But we can well get things done.

    Sunday, December 10, 2017

    Moving towards a structureless organization

    In a recent post, I explained the concept of "Structureless". Let's dig a little deeper into how we can explore this concept to build high-performing teams and organizations.

    Structural Maturity

    Without explaining the above model too much further, let's see how we can use this model in team organization.

    Unstructured Organization

    It's very easy to set up an unstructured team - basically, all you need to do is: nothing. Even then, people dislike the chaos that ensues and will usually self-organize to create at least some kind of structure. What I see happen as a first step to move away from the total lack of structure is contact lists - people making lists who can be contacted for what.
    This is often the first thing people would do when confronted with a new working environment.

    Key characteristics:

    ComplexityNot clear
    People try to make ends meet.
    It's unknown how complex the system really is.
    Nothing is really known.
    There might be be problems hidden beneath the surface,
    which aren't even explored.
    When they surface, the way forward is unclear.
    Unstructured organizations are significantly less
    effective than even the added potential of each.
    Ad hoc
    Most problems never get addressed.
    Workarounds are commonplace.
    Ad hoc
    The best way to describe how roles are distributed is:
    "Might makes right".
    People either grab roles they can meet in ways that
    please people in charge or are assigned a role.
    There is constant dissonance between expectation and
    reality, bursting out in occasional conflict.
    The customer is the least problem people would care
    Next steps
    • Discover what structures already exist
    • Discover who is responsible for what
    • Make communication paths visible
    • Close communication path gaps
    • Create a "skill matrix" who contributes what

    Indirect Structured Organization

    Indirect structures solve the problem of not knowing who to address when or for what. The indirect structure tends to rely on bottlenecks, i.e. communication paths that are used more often than they are available. Most organizations never make the leap away from indirect structures, as those are already stable. Moving beyond this indirection means resolving the bottlenecks - and some people use their bottleneck status as safety zone.
    Typical bottlenecks are managers who insist on being part of communication chains and irreplacible specialists.

    Key characteristics:

    Indirections add complexity to even simple requests.
    When indirection chains break, processes or requests
    might be hanging "mid-air" without being resolved.
    Major effort is required to maintain consistency.
    The bottlenecks inherent to the communication chain
    reduce the effectiveness of all those who rely on
    anything provided by a bottleneck.
    Problems get addressed when a bottleneck is aware
    of a problem and has an interest in resolving it.
    Communication paths typically determine a person's
    role aligned with their communication network.
    A person's role is often defined by the bottlenecks
    which limit their progress.
    Bottleneck roles tend to have high satisfaction, both
    from the feeling of being needed and the power
    at their disposal.
    Those limited by bottlenecks tend to get frustrated
    when blocked.
    Indirection is a customer's worst nightmare.
    The complexity of the structure becomes the
    customer's problem one way or another.
    Not getting responses, delayed responses and
    unproportionally high transaction costs are just
    some symptoms.
    Next steps
    • Discover where the bottlenecks are
    • Address the indirection issues
    • Strengthen direct communication paths
    • Create a "delegation matrix" to relieve the
      overburden of bottlenecks

    Direct Structured Organization

    Direct structures emphasize the value of getting things done. They regard results higher than personal affinity and value outcome over process.
    Very few organizations make the leap from indirected towards directed structures, and this relies especially on "managers getting out of the way". Direction requires re-thinking the manager role in fundamental ways. The toughest nut an organization needs to crack when moving towards direct structure is Larman's Law #1, the implicit optimization around preservation of personal power.

    Key characteristics:

    Indirections add complexity to even simple requests.
    Processes do not rely on single points of failure.
    Managers/specialists move from being bottlenecks
    towards creating robust structures that reduce reliance
    on their involvement.
    Centralized structures remove redundancies and
    optimize for "The Greater Good".
    Problems get resolved where they occur, by those
    who have central control over the domain.
    Roles are typically created to meet a specific need.
    Communication paths are then updated to integrate
    the role properly.
    People know what they are doing and where they fit in.
    Customers get the impression that people know what
    they are doing and that their requests move forward.
    They do not like that the company's structure is their
    problem - at least to some extent.
    Next steps
    • Simplify request processing from a customer
    • Instill a "customer centric" mindset in those
      not directly working with customers
    • Identify the communication issues that exist

    Structureless Organization

    The structureless organization is not to be confused with an unstructured organization. Instead of optimizing for reaching some kind of internal goal, a structureless organization sacrifices internal efficiency for meaningful outcomes. Redundancies are the means by which a structureless organization generate robustness without falling victim to stasis. 
    Managers are no longer the joints by which organizational units move, instead they become the glue keeping the construct together.
    Specialists move from adding value by executing on their topic towards enabling others to excel in their field.

    Key characteristics:

    From an individual's perspective, complexity may
    appear to be higher, as each person requires to be in
    contact with more people. From an organizational
    perspective, complexity is reduced, because less
    formal communication is required.
    People are not concerned with structure as much as they
    are with collaborating to achieve results.
    Where communication links are missing, "self-repair"
    will create the most effective new links.
    Removing indirection and structural overhead results
    in maximal effectiveness from an organizational perspective.
    Decentralization removes the local inefficiency and the
    need for ineffective compromizes.
    On the fly.
    Problems get resolved where they occur, by those
    who are involved in their occurrence. There is no longer a
    concern for local optimization, as decentralization removes
    the problem of needing to globally optimize.
    Roles are simply no longer important, as the focus moves
    from "job descriptions" towards contribution potential.
    Even leadership becomes situational to meet specific needs.
    People are able to align their personal sense of worth with
    the company's goals. Motivation and morale become
    Customers feel that the company is out to please them, and
    everyone is pulling in the same direction. 
    Next steps
    • Be aware of the danger of falling back into old habits
    • Strengthen informal links
    • Continuously improve


    It's not inherently bad to be in any given stage, even if that stage is "unstructured" or "indirect structure". The important pieces of the puzzle are understanding:
    1. At which stage you are
    2. Why you are there
    3. What can you do to move forward
    4. Why it's worth moving forward

    While I think that it's possible in theory to move directly from unstructured or indirection to structureless, my personal observation has been that this is extremely difficult. I personally like to move towards direct structure in a matter of days or weeks, and enable structureless from there. 
    The most important piece of the puzzle is understanding that once we stop with an indirect or direct structure, we create a stable condition where change becomes increasingly difficult as time proceeds.

    Saturday, November 25, 2017

    Ticket debt - why ticket systems are bad!

    Ticket systems are an easy way to organize your work - yet potentially, the most damaging one as well!

    What  could be so dangerous about a ticket system, the quick and easy helper tool which has found its way into almost every organization already?

    Creating tickets is easy

    The better the ticket system, the less effort is required to create a ticket. Some are actually as easy as "New --> (type some text) --> Save" and there you go, that's your ticket.
    And this is actually the biggest problem. Let's explore why.

    A ticket is an IOU

    Let's look really close what a ticket is. It is a description of some work that needs to be done. It's undone work. By documenting this work in a ticket, we create a future promise that this work will get done at some point down the line.
    Let's take a small real world example: "Send product offer to Tim Bobbins". That job might just take two minutes to do, or it might take longer (depending on whether Tim gets a standard document or a custom offer). In any case, by opening a ticket, we force our future self to promise to our current self that Tim will get his offer. In complete disregard what our future self will have to do later on, we sign an IOU for some work.

    Tickets are a debt

    Now that we realize that a ticket is nothing more than an IOU, we realize that we're actually creating some form of debt with each ticket we open. It's really work debt.
    Now, just like in the finance world, there is no problem if we take some debt contract that allows us to move freely now while paying off easy rates in the future.
    Unfortunately, this analogy hinges on a dangerous assumption: Inflation and business propagation allow us to earn more money with less effort in the future, so 100k Now-Dollars are a burden equal to maybe 80k Future-Dollars.
    The working world behaves differently: The time we have at our disposal to do work does not grow or expand, especially not in the short term!
    A 24-hour Now-day is equal to a 24-hour Future-day, so the best amount of interest you can afford to make tickets a good deal is zero.

    Tickets have a real interest rate

    When we borrow from the bank, we usually pay interest on our loan - we service our debt. This service pays for the bank's expenses and compensates inflation. We are fine with any amount of interest rate where our Future-Dollars are still worth less than our Now-Dollars.
    Let's return to the discussion of ticket debt, then. Just like in the bank, tickets have some kind of administrative effort. Starting with the (short) time of creating the ticket, we need to administer it, we need to look at it when we work it off, and at some point we 'll to close it.
    Depending on how the ticket looks like, the administration and consideration of its message may happen multiple times. Each of these times, we're not doing work, we're servicing ticket debt!

    And depending on how your organization has set up your ticket process, this service can take a whole bunch of time - potentially even more than the real work to be done in the context of the ticket!

    Ticket debt kills

    Once we realize that there is an interest rate associated to tickets, we can look at the effect of this interest.

    Here is an example of deadly ticket debt:

    As long as there is still flow and the amount of tickets that get serviced equals or exceeds, there's not much of an issue - but when this trend flips and there's more tickets in need of servicing than those getting serviced, the following happens:

    1 - Tickets pile up

    When you get a bill from your bank, it's usually not much of a hassle, but when you get hundreds, it actually does become a hassle. And we're not only talking about the work of servicing each one, but also about the amount of work invested into keeping track of what still needs to be done. All of a sudden, extra efforts start to be required into managing the pile: Prioritizing, sorting, stashing, deferring, reorganizing - just to name a few.

    2 - Ticket debt reduces ROI

    Like financial interest, the amount of service interest has no contribution to actual debt reduction. Once you get into a condition where ticket debt grows faster than you can reduce it, the amount of work sunk into service interest can quickly exceed the amount of work sunk into debt reduction.
    The increased service interest, especially when coupled to the limited amount of work available means that the ROI of tickets decreases with each additional ticket in the ticket pile - to the point where you may no longer be creating any value!

    3 - Ticket debt reduces Value

    Let's quickly return to our initial example: If Tim doesn't get his offer in 2 or 3 days, he may no longer remember the conversation and the great deal he's up for. Worse yet, he might have found another vendor in the meantime. By the time your Future Self is getting around to send Tim an offer, Tim may no longer be interested in buying anything at all. The value of the ticket decreases with each day.
    Of course, this also means that when you're creating tickets to be served months down the line, you're considering Now-Value, but get Future-Value.


    Take some time and look at how, where and why you use tickets in your organization. If you suffer from ticket debt, take a good look on how to reduce the amount of tickets you juggle in order to reduce the ticket debt you're servicing.

    There's also a chapter on ticket systems in my book, "Extreme Agility".

    Wednesday, November 1, 2017

    How career progression damages companies

    Is "career progression" really necessary? Let us explore how the very concept wreaks havoc in organizations and damages the very thing it's intended to foster - value generation. To illustrate the point, I will use the example of four individuals from my own network.

    Greg, the expert

    A while ago, I received a text from Greg: "Do you know any company looking for a team lead?" I had worked with Greg. He really enjoyed development work and did a splendid job. "What happened?", I asked. We met. Greg related his story: "I had a talk with HR, asking for a raise. It got rejected, because I was already at the Senior Developer level. I would need to become team lead to get more salary, but there's no vacancy." He was sorely disappointed.
    I probed: "Why do you want to be a team lead?" - "Obvious, to get more salary." - "But would it make you happy?" - "No. I hate the organizational stuff related to that role. But I got family - kids to feed." I shook my head: "You're not looking for a team lead role, you're looking for a way to earn more money?" He nodded. We discussed. "How about we find a company that's willing to pay developers as much as you intend to earn?" Long story short, Greg enjoys his developer role in another organization.

    Greg's company lost a formidable developer, because "developer" was considered inferior to a management role - both in appreciation and compensation. The loss? A great developer who would never want to be a team lead.

    Tom, the misplaced developer

    Tom fared better than Greg. He was in a similar dilemma, but slightly more "lucky": He managed to receive a coveted team lead role, with the additional salary on top. Tom's team had high churn rates. He let his responsibilities slide and continued doing his former job, with a new title.

    Tom was in a similar boat like Greg: He loathed the responsibilities of a team lead and loved technical work. He never bothered doing the things a team lead should be doing - for example, ensuring people had meaningful work, dealing with impediments or resolving conflicts.

    Tom's company suffered a fate worse than Greg's: Instead of losing one developer, they lost an entire team, just because they weren't willing to admit that a great developer doing great development work can receive the appreciation and compensation that their ability commends without needing to be in a leadership role.

    Sandy, the underpaid CSR

    Working with Sandy was a pleasure. She was amicable, smart, knowledgable and extremely resourceful. It didn't matter what the customer's issue was - she would manage to find a satisfactory solution. Getting a team lead role wasn't difficult for Sandy, and she excelled in that role as well.

    Over a cup of coffee, Sandy related that she wanted to switch out of Customer Service. I asked her: "You're great at your job, and you love what you do. Why?" Sandy confined: "CSR roles are notoriously underpaid. A regular worker close to minimum wage, the team lead's near-double salary might sound impressive, but it is still significantly below what others in the company made. If I could get into Engineering, my salary would rise by over 50%."

    Given her repute for the company, HR agreed to move Sandy into Engineering as a team lead. She actually did well in her role - being a great organizer and people's person, her lack of engineering expertise didn't count for too much. A small fly in the ointment: Since Sandy had left the CSR's, complaining customers had a much higher churn than before.

    Andy, who got it right

    And then there was Andy. His job? Close deals and keep customers coming back. He was a classic sales person - and good at that, too. He never played the title game and didn't want to get dragged into titles, either. I asked: "Andy, you've been a salesperson for over a decade now, why aren't you interested in having your own sales team?" Andy leaned back: "I don't need to. My salary is linked to the customers I bring in, and as a team lead, I'd have less time to take care of our customers. I'd probably make less than right now, and the company would have less customers, as well."


    Companies are great at setting up systems rewarding behaviours that are detrimental to their success. Corporate ladders are just one more example of that. By creating systems where people's personal goals can't be aligned with corporate goals in the most valuable, sustainable way, companies lose out on the ability of their most talented employees.

    Regardless of whether a person's role is technical, business-oriented, customer-oriented, managerial or administrative - if they are happy and good at what they do, don't force them to take another position, title or whatever. Create a reward system which allows them to align their own goals with the corporate's intended goals - not with the designed, corrupted goals that would force them to either stop doing what they do best or to leave.

    Winning companies encourage excellence, not gaming the system.

    Thursday, October 19, 2017

    How splitting work kills companies

    "Divide and Conquer" is a common strategy employed to solve problems by splitting it into pieces, which then can be solved in parallel by many. When it comes to managing the problem of having too much work, Divide+Conquer comes with a big red warning label: it may be highly counterproductive.

    Let us study this at the example of a call center.

    I was working with a company which had decided to outsource certrain Customer Service activities, as the amount of inbound service calls was too much for the organization to handle, and there just weren't enough CSR's who were capable of handling the sheer volume of customer requests. The obvious solution? Get a call center to receive the calls and create tickets for the remaining staff.
    Let's explore really quick how the "legacy process" of this organization worked:

    This process took roughly 10 minutes to get a customer satisfied and the work off the desk.

    Prepare for outsourcing

    Let's look at the process created by the organization. It's still rather simple and straightforward, minimal and down to the point:

    Adding queues

    The first notable, and obviously intended, difference is that the activity is now split between two organizational units: The Call Center agents operate in a different unit from the Backoffice CSRs. This separation introduced asynchronity, i.e. the customer doesn't get served on the phone, but later, when a CSR resolves the ticket. An additional activity, reaching out to the customer, has been added to the process - and with this additional activity, we introduce an additional difficulty: How do reach the customer?

    And soon, the process looked like this:

    Quality Issues

    The split of activities caused another problem: Instead of the erratic "customer calls" queue with an ideal size of 0, we have a dispatching queue for tickets, with an undetermined ideal size. The hand-over point between the agents creating the ticket and the agents resolving them suffers from information loss, so the quality of the communication needed to be controlled.

    Don't worry, we're not done yet - we wouldn't want to leave a process hanging mid-air. Once quality was managed, it didn't take long to realize there were actually significant quality issues related to lack of knowledge of this complex process. And there's an obvious solution:

    Process Management

    At every point where the fragmentation of the work caused a knowledge gap regarding the consequences of a person's action, there needs to be an improvement. Those improvements affect a large chain, so they need to be properly planned, orchestrated and coordinated. Bingo - the result: we add a process management function.
    And this is the glorious picture of an outsourcing strategy for a process which consisted of two steps and a whole bunch of tacit knowledge:

    You can guess that this process still isn't reliable, definitely not cheaper and significantly slower than the original process.


    Just based on this simple example, we see how the splitting of work causes the amount of work within the organization to explode. Once the above structures are implemented, the organization will suffer from the "Law of Irreducible Complexity", basically: You won't be able to omit a single activity in this overbloated chain without causing the whole house of cards to collapse.

    Sunday, September 10, 2017

    DIRFT is misleading - Philip B. Crosby got it wrong!

    Maybe you heard the slogan "Do It Right the Rirst Time" (DIRFT) before? Well, I have - and in the past, I firmly believed in it. No more. Let's explore this together.

    What is DIRFT

    To quote Wikipedia,
    Crosby's response to the quality crisis was the principle of "doing it right the first time" (DIRFT). He also included four major principles: 
    • The definition of quality is conformance to requirements (requirements meaning both the product and the customer's requirements)
    • The system of quality is prevention
    • The performance standard is zero defects (relative to requirements)
    • The measurement of quality is the price of nonconformance 
    His belief was that an organization that establishes good quality management principles will see savings returns that more than pay for the cost of the quality system: "quality is free". It is less expensive to do it right the first time than to pay for rework and repairs.

    Problematic assumptions in DIRFT

    DIRFT is based on four "principles", which I have to reduce to the level of "assumption" - because they are somewhere between shortsighted and incorrect!

    #1 - Quality isn't conformance!

    There's at least three major problems hidden in the very simple statement "quality is conformance to requirements" - and each of them can be disastrous!
    Can we assume that people can objectively and comprehensively phrase all requirements at all - much less before validating them against the outcome?

    Objectivity: I leave it to you, dear reader, to determine what happens when those who specify, those who implement and/or those who verify the requirement have a different understanding of the others! I then challenge you to create a surefire method of ascertaining this before even beginning with the implementation.

    Comprehensiveness: The need for objectivity would force us to create an explicit, comprehensive list of requirements. Remember: "Quality is conformance to requirements" - and if it's not defined, it's not part of quality!
     I now challenge you to create a comprehensive list of requirements for even the most mundate item of daily life: a piece of paper! Don't forget that it should be fit to write upon (don't forget to specify the type of ink that may be used and at what temperature - maybe you should also include how the paper should behave when an eraser is used?)

    Validation: Validation occurs on many levels, let's just get into the kind that DIRFT is considering implicit: How do you ensure that requirements are specified correct, comprehensive and consistent? Of course, you validate them. So - if you want to build the product right the first time, you have to absolutely and unconditionally ensure that each and every requirement, as well as their entirety, is valid. Only then do you have a chance to meet them.
    I leave it to you to figure out a method of ensuring that a product's requirements are exhaustively valid without having even started implementation!

    #2 - You can't prevent all defects

    DIRFT assumes that all potential sources of defects are known and controllable. That's another two strong assumptions that hardly hold to a practice test. Honestly; what good is a product that is "of high quality" if it simply doesn't work the way the customer expects it to?

    Omniscience: There's a proverb, "If you make something foolproof, someone will make a better idiot." Google for "Use for intended use only" - a helpless plea of designers who already realized that once the product is in the customer's hands, people will get ideas that nobody could ever anticipate!

    Omnipotence: You may have gotten it completely right, but because the world behaves differently from how designers anticipated, the product still doesn't work. The only way to prevent that kind of defect is by making the product so robust that it'd effectively be omnipotent.

    #3 - Zero defects are arbitrary

    As explored above, requirements are an incomplete subset of what makes a product valuable, even potentially incompatible with the definition of value. By adding any implicit requirement (such as: "paper shouldn't be lethal to the touch"), the product may appear defective again. The only chance to fix the defect is by making changes - both to the design, and to the product!

    Finality: One of the core, hidden and implicit assumptions of DIRFT are that there is ever a point in time where the final design is "known", and that this point in time is before the beginning of implementation.

    Perfection: Along with the finality of the design comes the assumption that this design is "perfect" in relation to whatever requirements exist. While one can reasonably argue that a "good enough" design can be procured, one will be hard-pressed to argue that the first attempt will result in a design that leaves no room for improvement anywhere.

    #4 - Nonconformance is a pointless measure

    As tester, I always found joy in discovering nonconformance - more so, if the nonconformance was somehow "critical". It didn't take me much longer than a few days into my first job to discover that nobody cared for nonconformance in the presence of other business-relevant metrics, such as the cost of delay or the cost of change.

    Time-Value discount: The above statements come into play again. With every added requirement, the implementation effort increases. It's possible to conform to 1% of requirements now, and to 100% at an undefined point in the future. Getting it right the first time assumes that the Time-Value discount is Zero. This is diametrically opposed to the idea that "the marginal value of every technology is Zero", i.e. as time progresses, the ROI on technology decreases.

    Measuring nothing: The entire hypothesis of "DIRFT" is that somehow, magically, the created product is done right the first time, i.e. the idea of measuring nonconformance is supposed to measure the empty set. Does it sounds odd to anyone else to base a core business metric on an empty set? The mere idea of measuring nonconformance implies that the Crosby is somehow aware that this is a fictional, impractical approach!

    Okay, after setting the groundwork that pretty much every single word of "Do it right the first time" relies on unfounded assumptions, let's shred the final conclusion:

    Quality is never free!

    DIRFT assumes that when someone somehow has looked into their crystal ball to create a flawless design of a perfect product and those creating it somehow have all the required time and money on their hands to build something that matches this design, then somehow magically, "quality is free".

    Let's ignore even the (infinite) costs for building, and ponder for a minute how much time and money is required to produce the perfect design which then just needs to be "done right". Any design document you produce, I will find at least one unlisted requirement, at least one relevant edge case, at least one "bad case" that can wreck the product. And the longer your requirement document is, the easier this will be.


    We end up with "quality is free" only when we invest an infinite amount of time, effort and money into upfront work - otherwise, the entire idea of "DIRFT" isn't even applicable.

    "Do It Right the First Time is a nice ideology, but impractical for anyone doing product work, where deadlines, budget constraints and uncertainty about the customer's needs are the key constraints.
    In development work, quality is an optimization goal, and while it makes a lot of sense to maximize quality, it is never free - quality is where the money and effort goes!

    Friday, July 21, 2017

    How do you identify a proper agile coach?

    One of my personal pet peeves is the huge amount of "imposters", i.e. self-proclaimed, potentially even certified "Agile Coaches" who are jumping into a high-demand market.
    The problem they cause: Not understanding what a coach even does, how to properly coach - nor what the intended outcome of coaching is supposed to be, they ruin teams rather than establish them.

    A year ago, I myseld would have gotten a decent score on this list, and even today, I'm still learning. It is through my contact with a few select, truly inspiring coaches that I have learned the difference.
    If you think you're a coach, you can use this list to reflect. If you are looking for a coach, this list is a non-extensive (potentially growing) list if things you want to look out for. Careful: A job interview may not be when you discover the signs. I observe my peers at agile conferences and meetups - and thus, this list was compiled:

    How do you identify bad coaches?

    When you notice these things about a "coach", proceed with utmost caution:

    #1 Doing what the client asked

    Most companies need agile coaching, because they don't know what agility is - and most likely also have little understanding on the power of growing people. As such, these clients can not be expected to understand where specific demands they utter are supportive or detracting agility. The agile coach should remain true to their role and also work with the very people who hired them, even when that means correcting the initial mandate.

    - The Client doesn't need what they ask, but what they don't know.

    Question: How can you understand the difference between what the client says and really needs - and how to get there?

    #2 Calling Agile a method (or: process)

    Many companies look towards "Agile" in the hopes of obtaining a better software development process. The "Agile umbrella" contains a whole bunch of methods, tools and techniques for improving both the way and outcome of development. Clients may believe that by changing the structure, adopting new roles and using new techniques, they will be agile. Bad coaches will go about doing exactly this and never realize that the systemic problems are caused by a philosophy that isn't consistent with agile development, therefore - never solving the root cause. The consequence? Yet another cargo cult. Lots of fuss, little benefit.

    - Agile requires a mindset shift

    Question: Can you identify the main reasons that might interfere with a new process doesn't yield benefits?

    #3 Agile is considered a goal

    Agility can never be a goal in and of itself. It's context sensitive and has to depend on the company's optimization goals. For example, agility in a fast-paced environment would look completely different from agility in a safety-critical environment - as agility accomodates the needs of the business, customer and market. It is merely a means to become more successful. "Being agile" isn't successful when the company can't meet the market demands.

    - Agility is a means, not an end

    Question: What is different once your client "is agile"?

    #4 The Silver Bullet

    Let's take, for example, Scrum. Scrum makes a lot of implicit assumptions on the team's environment for the team to succeed. When those assumptions aren't met, Scrum may potentially lead to disaster. Coaches need to be aware of what the success factors are, and then either first work to enable the conditions or choose an approach that is compatible with the current reality.

    - Solution agnostic adaption

    Question: How do you know that your approach will succeed?

    #5 Preaching dogma

    When you have a pressing problem in your organization, the last thing you want is a religious sermon on how you're not adhering to whatever dogma the coach subscribes to. This can get very irritating when the coach is unable to connect the current situation you are in with specific, actionable measures that will help you out.

    - You need a pragmatic way forward

    Question: How do you turn ideals into results?

    #6 Hypocrisy

    Advice given by coaches is doubtful when you don't see the coach themselves doing the very things they advise. The worst thing is "special pleading", claiming that they are exempt from the rules they want others to follow. The peak of hypocrisy is reached when they are pleading special on absolutes, for example: "Everyone must..."

    - "Dogfooding" also applies to coaches

    Question: Are you applying your approach to yourself?

    #7 Narrow-mindedness

    “Whatever the mind can conceive and believe, it can achieve.” - Napoleon Hill
    Different thinking leads people to different conclusions. Speaking in terms of "right and wrong" becomes extremely difficult for an open-minded person who considers others' perspectives equally valid to their own. The faster a coach is in making statements like "No", "Wrong" or "Bad", the more likely they are narrow-minded. 

    - People have reasons for their thoughts, words and actions.
    Question: Will both participants leave the conversation with a sense of a broadened horizon?

    #8 Preconcocted solutions

    Maslow's "Law of Instrument" or "Golden Hammer" is a cognitive bias indicating that when you know only one way to approach a situation, you will rely on that way - regardless of whether it's a good idea or not. Similar to narrow-mindedness, the inexperienced coach will throw the one solution they know at the problem and hope that works out.

    - Explore multiple feasible solutions before stepping into the solution space

    Question: What will you do when you can't use any of your "Golden Hammers"?

    #9 Change Push

    Sustainable agile transformations rely on autonomy and intrinsic motivation. It is extremely challenging to find the levers within the organization where people *want* change and are willing to change something. It's much easier to push the change on others. This produces results much faster, but people will gladly return to old habits as soon as the coach is out of the building. Even "hard selling" is still pushing, so "convincing others to do what I say" doesn't count, either.

    - Relies on "Pull". People must want the change.

    Question: How will you approach change when met with resistance?

    #10 Arrogance

    I recently encountered a coach who literally said, "Everyone I work with is an imbecile." They may never have said this ad verbatim to their clients, but this coach carries the burden of the hidden belief that they are somehow better than the people they work with. This doesn't permit the coach to have a deeply rooted relationship of equals with their coachees. At some point, this attitude will become a barrier to coaching. This strikes as the Dunning-Kruger effect: " How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments"

    - Radiate an aura of appreciation and humility

    Question: How would you classify people with different levels of competence?

    #11 Trying to change behaviour

    There's an entire coaching approach called behaviouristic coaching, so behavioural coaching isn't inherently an issue. However, behavioural coaching doesn't focus on changing behaviours, it focuses on changing the beliefs which lead to the observed behaviours. The behaviour is *never* the problem - it's always a belief issue!

    - Focus on beliefs

    Question: What do you do when someone does things that should be changed?

    #12 Process Change

    Processes are external structures. They do have a strong effect on outcome, and of course, agile transformation is supposed to have an outcome. Any structural change is ephemeral - until people change what they believe, they will revert to familiar structures, and the longer a structure existed in the past, the more likely they will return. Once people understand how their old process was worse than what they can realistically do right now, they will drive the process change themselves.

    - Change minds, then processes will follow suit

    Question: How do you approach change to processes?

    #13 Certainty

    "I know that..." - Socrates would conclude this sentence with "... that I don't know anything."  The knowledge in the world grows faster every day than any human could learn in their lifetime. With new knowledge comes the revision of old knowledge - former beliefs no longer hold true. As Kant put it, "Reason puts to trial like a judge every statement presented and interrogates every witness to discover the truth." Our understanding grows as we learn to ask new and better questions. 

    - Constantly challenge beliefs

    Question: Which is the most fundamental belief you have changed recently?

    #14 Blame-shifting

    Even our very existence already affects the situation. When things around us go wrong, we always have a hand in it - knowingly or not. It's very easy to accuse or blame others for their actions, yet many people seem blind towards themselves and how they have affected the outcome. At a minimum, we need to understand that if we ourselves had done a little better, the outcome might have been better. Coaches are hired for leverage - and when the effect is undesirable, it's just not possible to fully abjure oneself of any form of responsibility.

    - Be aware of the effect of yourself on the situation

    Question: What do you do when a situation gets out of hand?

    #15 Wallpaper Certificates

    Certifications entitle people of being called something, more certificates entitle to better jobs. Or, so some feel. The difference between certified people and uncertified people may just be that certified people follow paths gone by others, while uncertified people do things that nobody else has done before. As agility is about finding new and better ways, the coach better have some experience which can't be minted into a certificate. If all the coach offers can be packaged in shined, stored, standarized boxes of certification, the coach isn't going to bring the team into new territory.

    -Pioneer and discover

    Question: What's the last thing you did that nobody did before?

    #16 Relabeling

    The easiest way to kill an agile transition is to reassign labels and keep the same structure. Product Managers become Product Owners, Team Leaders become Scrum Masters - and line managers become "Agile Coaches". There you go, transition done. That was easy. Nothing accomplished. Genuine change goes far beyond assigning new labels - the way of working is different and people may discover they aren't suited for the role that they were intended for. 

    - Reframe the situation so that old structures don't stick any more

    Question: If we remove any form of labels, new and old - how do you create a different structure?

    #17 In it for the money

    Certain certification bodies even advertise that agile coaches earn better money than traditional roles. Of course, this attracts people who are looking for easy ways to earn better money. They come, grab as much money as possible, then leave. Coaching, however, isn't about doing work as much as it is about making meaningful change. A good coach should have a portfolio of people who will tell stories how things have changed through coaching.

    - Build positive relationships

    Question: Aside from the money, what have you gained when you exit an engagement?

    #18 Demanding trust

    Trust is a precious and fragile commodity. You might consider trust like a porcelain vase: Once shattered, it leaves numerous shards that create a mess and leave deep cuts when touched. Demanding an upfront reserve of trust can leave people mortally wounded when exploited. Some environments make it difficult for the coach to build trust relationships, especially when managers are known to play a hidden agenda.

    - Invite trust by extending it from your side

    Question: How can you gain trust in a low-trust environment?

    #19 Judgmental

    It's easy to say that someone isn't coorperative or performing poorly. It becomes much more difficult to make such statements when you see that people are very good at adapting to their conditions and that their actions are the consequence of a very long history which formed them to become like they are. As coaches, we can't be fast to judge people without understanding why they are the way they are.

    - Consider events, causes and circumstances

    Question: What do you do when someone does a really poor job?

    #20 Insistence 

    The worst thing a coach can do is insist they know "what is right" and others don't. This is also the fastest way to create distrust and damage relationships. Those who insist on others following their lead aren't leaders in the first place. Real leaders make others *want* to go the right way, then offer help in moving forward. At the same time, they are forbearing when others choose a different route.

    - Accomodate, provide leeway

    Question: How far will you budge to make your coachee comfortable?

    Bonus - Taking any job

    A coach has better things to do than work with organizations who intend to abuse the coach for ulterior motives - or who don't even have an intention of receiving coaching. Roles such as "Delivery Manager / Agile Coach" should ring an alarm bell to serious coaches. Especially when the job description contains terms like "Responsible for the delivery" or "Reports individual performance", that's clearly a non-coaching role. In an interview, the coach would clarify what the real intention is, whether the job ad was written out of ignorance - and how this is supposed to turn out later. 

    - Turn down offers that are in clear violation of a coach's identity

    Question: How can you be a coach if you're expected to not coach?