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.
ConsistencyLow
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.
EffectivenessLow
Unstructured organizations are significantly less
effective than even the added potential of each.
Problem
Solving
Ad hoc
Most problems never get addressed.
Workarounds are commonplace.
Role
Distribution
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.
Internal
Satisfaction
Low
There is constant dissonance between expectation and
reality, bursting out in occasional conflict.
Customer
Satisfaction
Low
The customer is the least problem people would care
about.
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:

ComplexityHigh
Indirections add complexity to even simple requests.
ConsistencyLow
When indirection chains break, processes or requests
might be hanging "mid-air" without being resolved.
Major effort is required to maintain consistency.
EffectivenessLow
The bottlenecks inherent to the communication chain
reduce the effectiveness of all those who rely on
anything provided by a bottleneck.
Problem
Solving
Sporadic
Problems get addressed when a bottleneck is aware
of a problem and has an interest in resolving it.
Role
Distribution
Reactive
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.
Internal
Satisfaction
Moderate
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.
Customer
Satisfaction
Low
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:

ComplexityModerate.
Indirections add complexity to even simple requests.
ConsistencyHigh.
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.
EffectivenessHigh.
Centralized structures remove redundancies and
optimize for "The Greater Good".
Problem
Solving
Systematic.
Problems get resolved where they occur, by those
who have central control over the domain.
Role
Distribution
Planned.
Roles are typically created to meet a specific need.
Communication paths are then updated to integrate
the role properly.
Internal
Satisfaction
High.
People know what they are doing and where they fit in.
Customer
Satisfaction
Moderate.
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
    perspective
  • 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:

ComplexityLow.
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.
ConsistencyHigh.
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.
EffectivenessExtreme.
Removing indirection and structural overhead results
in maximal effectiveness from an organizational perspective.
Decentralization removes the local inefficiency and the
need for ineffective compromizes.
Problem
Solving
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.
Role
Distribution
Irrelevant.
Roles are simply no longer important, as the focus moves
from "job descriptions" towards contribution potential.
Even leadership becomes situational to meet specific needs.
Internal
Satisfaction
Extreme.
People are able to align their personal sense of worth with
the company's goals. Motivation and morale become
non-issues.
Customer
Satisfaction
High.
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



Summary

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.


Summary

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



Summary

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.


Conclusion

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.


Conclusion


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?

Wednesday, July 12, 2017

Being a Product Owner

I am a Product Owner. I'm on a mission to create great products.

I don't have a title

Some clients call me "Agile Product Manager", "Agile Project Manager" or even "Agile Architect".
To be honest, I don't give a hoot what you call me. I'm not in it for title games. Titles don't matter.
Those who know me call me "Michael". That's me, and that matters.


I am the product

When I get up in the morning, I think about what the product needs. When I drive to work, I consider the challenges my product faces. While I am at work, I discuss the product with others. My discussions are centered around the product. While I eat, while I walk, while I dream - the product is there. I am the Product - you do something for my product, you make me happy. You mess with my product, you hurt me.


I am narcissistic

I identify with the product. I want the product to be great. I feel with my product. When my product suffers, I suffer. When my product succeeds, I succeed. I don't take criticism on my product lightly. If it's justified, I will do everything I can to improve. If it's unjustified, I will give you a chance to correct your opinion before you get a problem.


I don't accept "requirements"

I dedicate myself to making the product rock. You are allowed to explain to me why you think that the product should offer a certain ability, but you can't make me build it. If you manage to convince me how the product will be more desirable with your idea, I will place it in the backlog. Otherwise, you're short on luck. And no, I don't care for your job title. I care for the merit of your idea.


I don't work for you

I work to build a great product. If you have a need for which I have a vision, and you are willing to fund me to find excellent ways of turning your need into results, we can have a talk. I will dedicate my time, energy and every brain cell to making the product happen in a way that meets your needs and expectations, in terms of the product's content, price tag and its value. We will work together as long as I can bring the product forward and the product brings you forward. When either is no longer the case, we will part ways.


I protect my team

I need my team to make the product rock. I invest my time into instilling the vision into them and I enable them to do what they need to. I respect my team members, because I know they do the best they can. Without them, the product vision would remain a mental blob. When someone messes with my team, they have a problem with me. And I don't care what title or role that someone has.

I don't follow Scrum

Judge me or condemn me if you want for not living up to whatever agile bible you follow. I don't give a hoot, either. I'm not in it for a methodology. I'm in it for building a great product with a great team. I don't follow Scrum - nor anyone or anything else, for that matter. When rules and regulations become impediments to doing what needs to be done in order to succeed, I will stomp over them. As long as Scrum follows me, I'm fine. When it no longer does, it better get out of my way.


I am an extremist

I understand moderation, but I also understand that there will be no change without change. I am the PO because I want to make a difference - and since I can't get everything, I need to deal with extremes. From there, we will explore together how far we can go and what it takes to get there. If I didn't have radical ideas, my product would suck.


I don't insist

I am actually quite easy to convince that I need to reconsider my choices, except that I need evidence: Experiments that prove otherwise, business figures that point in a different direction, systemic causes which make other approaches more favorable. "I don't like it" doesn't cut it, I want hard facts. Solid, reliable information. In fact, as new information becomes available, I constantly reconsider my next steps.


Tuesday, May 16, 2017

The Scrum Manifesto

We are uncovering better ways of earning money by getting certified and helping others to do it.
Through this, we have come to value:

Enforcing Scrum over individuals and interactions
Proper Scrum over working software
Undisturbed sprints over customer collaboration
Meeting sprint goals over responding to change

That is, while the agile values are on the right,
the items on the left are much easier to implement.

(Careful, sarcasm)

Thursday, April 27, 2017

Shu-Ha-Ri: Can't we customize?

Let's have a short discussion on Shu-Ha-Ri and how it should affect your learning journey.
Many people feel that "This (or that) constraint isn't right, can't we remove it or try a different approach?"
Some common examples may be: "Why can't we have flexible sprint length?" - "Can't we do that step without a WIP limit?" - or even: "We need more Product Owners!"


Let's explore this matter briefly.

In the basic learner phase (Shu), every approach is rigorous and inflexible - that't the entire point of learning the basics: The constraints serve to protect.

In the advanced learner phase (Ha), the rigour no longer feels like a constraint as you already start to understand why it helps you and you've found ways to harness your potential within those constraints.

In the transcendence phase (Ri), the rigour becomes irrelevant, as you know how to achieve the ends with other means. For that, you must understand these means and the purpose they serve. Now, in the Ri phase, you may even be more rigorous than before - albeit in a different way, that may no longer have anything to do with the original form.


But ...
If you are wondering like "I think Karate hurts my muscles too much. Is Taekwondo better?" I can clearly answer that with: You'll have the same and other problems.

Refrain from the knee-jerk reaction of looking for a different "way out" and consider what you're doing wrong. Also, refrain from considering yourself in the Ri phase - if you were, you wouldn't have so many problems.

For example, a Ri practitioner may feel that Sprints are too slow - they prefer to deliver daily. Or, they don't understand the point of defining WIP limits as theirs is 1. Or, they don't even see the need to have a Product Owner at all.

They can do all those things, but they don't need to do them, because they can achieve the purpose of these practices without any effort.

If you're not there yet, you are Shu.

Friday, April 21, 2017

Changing priorities - what to do?

Taken from yet another LinkedIn post:

"My team mentioned the following: We are unable to focus on the work, resources are being borrowed mid flight, we have to wait for env to be ready for testing/deployment , priorities keep changing and worst of all ; often we hear <Our resources should give their 100%>, now how the hell can we give 100% with these constraints?"

Dear Robert,

Those are six different problems you mention there. Let's address them one by one.

#1 - Unable to focus

The more things you do, the less you can focus. It's easy to focus on one thing, yet impossible to focus on a dozen things at the same time. We lose focus when we lack clarity of what matters - and what doesn't.

Likely Causes:
  • Lack of transparency concerning value
  • Lack of clarity on the impact of multitasking on outcome
Possible Solution:
Create an environment where limited WIP is possible, encouraged and enforced. (it's always possible, the rest is management mindset)


#2 - Borrowing mid-flight

This only occurs when there is confusion in the organization on what is actually important - and why.
It doesn't even make sense to divert people from doing the most important thing they can do.
Again, that's a management mindset problem.

Likely Causes:
  • Confusion around priorities
  • Managers who are unaware of the disruptive impact of their behaviours. Closely linked to #1.
Solution:
Create a stable environment where only ONE priority 1 exists at a time.


#3 - Waiting for environments

Consider the "Developer's bill of rights" - if your organization isn't willing to invest into the best possible technology, you lost the game anyway.

Likely causes:
  • Managers who forget the opportunity cost of saving a few measly bucks on tech. 
Possible Solution:
It's essential that technology is an enabler for developers, not an impediment. A company that doesn't let their developers maximize the value of their time is paying high-cost talented people for twiddling their thumbs and getting frustrated instead of delivering results.
Developers must create a plan how they would solve this and what they need, then management must grant both the procedural and financial way to move forward.

#4 - Priorities keep changing

It's very, very simple for managers to change priorities - yet very hard to get things "Done" when the priority is different before something is. 

Likely causes:
  • This is the same as #1 and #2. 
  • Manaers who are unaware of the cost of change.
Possible Solution:
Make the cost of change visible. Enforce a strict policy that any change to work which is currently in progress requires the requester to sign off the investments up to this point as "burnt money". For example, if you sunk 20 dev days into a feature already and priorities change, the requester of the new priority causes a loss of 20x10 dev-days, e.g., $20k to the organization. Ask them if that's what they want.
Accumulate burnt costs, when they approach hundreds of thousands (which they quickly do) ask if it wouldn't be better to hire more people.



#5 - Demand without enablement

There's a memorable quote, not sure I get it verbatim: "There's nothing more cruel than setting a goal without providing the means" - yet this is exactly what's described here.

Likely causes:
  • Organizational structure
    • Separation of accountability and responsibility
    • Separation of Planning and Executing
  • Management philosophy
Possible Solution:
This is a tough nut to crack and will definitely take a long time. It requires management to reconsider everything they are doing. At a minimum, managers must move from controllers to enablers - even this step can take years to be fully anchored.


#6 - De-humanization of workers as "resources"

That's entirely a mindset issue occurring in organizations where people aren't being treated as people.

Lean thinking is built on "respect for people". "Resource" in regards to people is a very dis-respectful concept that needs to be banished out of the organization, without any form of replacement. That alone will have a positive effect on motivation, morale and therefore, ability to get things done.


Summary

The good news: Those aren't many problems. They are all somehow different faces of the same coin. There is only one problem: a communication gap between managers and developers. Everything else is a consequence thereof.
At the heart of it, managers need to stop "doing manager stuff" and start talking with their people. Try to get NEAR.

A good coach can help here.


Wednesday, April 12, 2017

The 4 drivers of a holarchy

Concluding the introduction to the basis of a holarchy, let us explore briefly what drives a holarchy:

The 4 drivers of a holarchy

1 - Interaction

Interact with those around you. Build relationships.
It's not enough to interact once. You must continuously interact and communicate.

2 - Inspiration

Give others reasons to want to do what you do - or even more.
Likewise, let yourself be inspired by others.

3 - Participation

It depends on you. If you don't participate in what needs to be done, nothing will change.
Participation is not an individual matter. Align with those who pursue the same goal.

4 - Maturity

You're not perfect. Make experiences, learn from others. Seek enlightenment.
Grow as a person and help those around you grow as well.


Act!

You must constantly work on all these drivers. They depend on nobody except yourself. Maybe you will be the person with the most drive in your holon, maybe not - that's not important. Important is that you drive.


10 Principles of a holarchy

How can you make a holarchy happen? First, you need to establish the values of a holarchy to create a foundation, then you must establish the principles to make it "tick". Here are the principles of a functioning holarchy:

The 10 Principles of a holarchy

1 - Care

Care for True North. Care for what you do. Care for people around you.

2 - Leadership

Everyone leads in anything: what they do, how they think and what they believe. Servant leaders never stop to serve, enable or inspire others.

3 - Engagement

Participate. Contribute where you can. Engage others. Take responsibility.

4 - Decentral

Every holon is autonomous. There are no directed dependencies. There is no "HQ".

5 - Informal

Everything is subject to the current need. There is no prescribed form for anything.

6 - Practical

Do what works, don't what doesn't. What works in your holon may not work in another.

7 - Respect

Everyone has something to contribute. You may need to discover what that is.

8 - Non-judgmental

Just because you disagree doesn't mean they are wrong.

9 - Openness

Everybody's perspective is limited. You grow by seeing through other's eyes.

10 - Voluntary

Everything you do is your choice. Nobody must agree to anything.



Conclusion

These principles are not open to customization or "adjustment for pragmatic purposes". If a single principle of holarchy is broken, the entire structure is threatened. Holarchies are fragile and require continuous attention.

Establishing these principles takes years. There will be a lot of setbacks. Failure, getting up and improving are the normal. Regardless of what you see or what happens - never abandon these principles and do your best to keep them.


The 8 core values of a holarchy

In a recent post, I introduced the holarchy as an alternative organizational structure.
Let's look at the core values required to build and sustain a holarchy:


8 Core Values of a holarchy

A holarchy requires shared values. They need to be applied and maintaned without compromize, both on an individual and a corporate level.
If you do not share these values, your holarchy is already set out to fail:


1 - Clarity

First, you need a "true north".
This true north is a transparent, shared set of beliefs and a compelling vision. Everyone must be clear and aligned on the vision and these beliefs. As the vision grows out of sight just by time passing by and life taking it's course, you must continuously invest time on recalibrating yourself.
Shared beliefs need to be clearly articulated and should be as free from ambiguity as possible.

Constantly communicating these beliefs and the vision in clear and simple terms is essential to keep the holarchy going.

2 - Humility

Nobody is better than anyone else, we all are where we are. We do have different responsibilities and different perception, but that doesn't mean mine is more or less valuable than yours.
We all always lack some piece of the puzzle - and we're seeking out more pieces instead of insisting that we got it right. Be willing to be corrected at any time, by anyone, through anything.

3 - Scrutiny

Everything is up to scrutiny. Everyone should be free and willing to say "I could be wrong", or even "We could be wrong" at any time. Nothing and nobody is exempt from being questioned, by nobody, at no point in time.
That doesn't mean we need to have all the answers: It can be that we simply don't know. New information or evidence may imply that our past understanding is no longer adequate or appropriate. When this happens, we must be swift and willing to update ourselves.

4 - Purity

A holarchy relies on following the vision without compromize and being consistent in what you do.
Scrutiny should expose inconsistency, and purity means that you consequently deal with inconsistencies by resolving them to the best of your ability.
True North guides the measurement of the direction you should take. Deviation from True North is an inconsistency that you need to deal with.

5 - Equality

"Rank has its privileges" - and that creates problems. Therefore, there are no ranks and no privileges. Discrimination of people based on any factor beside their actions creates inconsistency and must be subjected to scrutiny.
Roles are transient and subject to need and may change at any time. There are only functions and responsibilities. Not even "leadership" is a role - it is something you either do or don't. It is not a label attached to a person.

6 - Unity

Seek harmony with all those who are willing to move towards True North, regardless of who, where or when. The rules and practices of the holarchy should be inclusive, yet without compromizing on True North.
Tolerate no form of division, not even with those who are just at peripheral touchpoints, such as customers, relatives, or friends. Divisions create inconsistency, and inconsistency breaks the holarchy.

7 - Sincerity

Take a stand. Act on what you believe is right. Do what you mean and mean what you do. At the same time, be willing to be adjusted by those around you. You can't refer to "the system" or "the situation" as a reason for doing something you don't believe in, as both are shaped by your own influence.

8- Responsibility

Responsibility can only be taken, not given. If you don't take it, nobody might. You yourself are responsible, so do something. You have no excuse to point at anyone for saying "They should have ..." or "But they didn't ..." , but you do have the right to lead the change by yourself.


Conclusion

Nobody said Holarchy is easy. These core values are essential, yet incredibly difficult to maintain. and even more difficult to establish in the first place. They are the "magnet field" for your moral compass.

You can't just transform an existing system into a functioning holarchy without first defining "True North". Not everyone will join you in your pursuit of True North, and many will find it too challenging to continue on this pursuit in the long term. A holarchy must be willing and able to continue towards True North, even if their former leaders forsake these values course and it must be ready to leave those behind who choose to become impediments towards making these values happen. A holarchy can only persist with the people who are willing to share these values and True North. Finding the right people is the first problem you need to solve.

Significant change is required to get a holarchy to work. For those who are not willing to work on themselves to live out these values, participating in a holarchy will remain a dream - insubstantial and intangible.

Friday, April 7, 2017

Product Owner: From business or from tech?

There's a never-ending debate: Should a PO be chosen from the business side - or from the technical side? Let's look into this question.


What's a Product Owner?

In short, the Product Owner is the person who is key to the product's success. They decide what is being built - and with that, they decide how the money is spent. The PO is responsible for setting the team's priority, thereby deciding how the product generates value.

This begs the question: What does any of this have to do with their position in the Org Chart?

Advantages of a business PO

The PO from a business background often tends to be closer to real users of the product, i.e., they might have a better understanding how the product contributes to the company's success. Also, due to their background, they might have a communication advantage when talking with non-technical people. This advantage can become even greater if they have already established a network with real users.

Advantages of a technical PO

The PO with a technical background might have a more sound judgment on the development cost of features. They may be better at asking the right questions which open technical alternatives to minimize the effort for meeting customer needs. Likewise, they are able to correct misunderstandings faster if developers and customer have different intentions.


What neither may bring

As mentioned above, the PO is about maximizing the value of the product. This requires a deep understanding of concepts like "value", "ROI", "cost of delay", "opportunity cost", "investment", "customer satisfaction", "growth potential", "priority" and "sustainability". 

On top of that, there are soft skills like dealing with conflicting interests, making tough choices and others. The PO requires more grit than anyone else on the team.

It doesn't matter as much what the PO did in the past - if they aren't good at the items mentioned in this section, you have the wrong PO. If they can do these things in the organization's best interests, the rest can be remedied over time.


Summary

The past of a PO, i.e. their background, doesn't matter all that much. What matters is: Does your PO have the right understanding, mindset and skillset to do their current job?
If the PO doesn't have these, they need some basic training and good coaching. That should help. Otherwise, find someone who can bring thse. Technical, business - doesn't matter.