Optimize at the Constraint - only!

The Constraint of a system, in a nutshell, is "the most limiting factor." By definition, it determines the capacity of the entire system: if the Constraint is underutilized, the entire system is underutilized. However, if the Constraint is overburdened, no amount of additional input into the system will lead to more output. Many organizations struggle with this - and that has dire consequences!

Let's start by taking a quick glance at the Constraint:

In our example, the third step (C) is the Constraint - because it has the minimum capacity in our system. An important consideration is that we're not talking about investment or staffing here, our concern is the ability to generate throughput.

As an example, if we have a single A costing $100k to generate 50 Throughput, but ten C costing $1m to generate 30 Throughput, then the Constraint is C, not A.

This simple truth has tremendous consequences:

Don't work more than necessary

All of the capacity in our entire system in excess of the Constraint won't help us generate additional throughput. Let's examine what this means in practice:

• Excess capacity behind the Constraint is "idle." It exists, but can't generate throughput. Adding more capacity at this point has no effect.
• Excess idle capacity in front of the Constraint doesn't generate throughput.
• Excess busy capacity in front of the Constraint adds overburden to the Constraint!

The third point is critical - because of the consequences: Let's say our Constraint is a specialist, and work is piling up at their doorstep. Work waiting at the Constraint generates no value for our company. Since someone was asking for that work in wait, these people will start wondering when their request gets served, i.e. they become unhappy. Eventually, the Constraint will be tasked with managing their undone inventory. At a minimum, some capacity gets diverted away from doing actual work - into managing work. At worst, it will reduce their capacity with each piece of work in wait, until they are fully incapacitated and spend their entire time in status meetings, explaining why nothing gets done.

And that brings up an important question:

Assuming you are not the Constraint: should you optimize your own work?

The astonishing answer is: No. And here's why.

Where's your Constraint?

This image visualizes four possible scenarios:

1. You're stream-aligned. The only people depending on you are the customers. 
2. You're behind the Constraint. There's someone, or something, that determines how much work arrives at your desk, and you get less work than you could do.
3. You're before the Constraint. The more you work, the bigger the "waiting for" the Constraint pile grows.
4. You and others are working in parallel. What you do, they don't. What they do, you don't need to.

The image doesn't display the scenario that you are operating at the Constraint, because that's equivalent to being unconstrained: the more you do, the more throughput you get. So - let's examine the above four scenarios.

In scenario 1, you are operating as if you were the Constraint, until you get into a "Before" or "Behind" scenario by overburdening your customers. Here, improvement works in everyone's favor until customers start to scream.

In scenario 2 - you have excess capacity anyways. Customer throughput is limited by the Constraint, so the only thing you can spend your optimized capacity on would be gold-plating. At best, nobody notices. At worst, you'll get scolded for wasting company assets. In any case, your optimization efforts won't win you a medal.

In scenario 3 - your capacity outmatches the Constraint. If you want to optimize the Whole: do less. You can only make a difference by reducing burden on the Constraint, that is: by taking work away from them. If you optimize in ways that allow you to do more work, you'll either get scolded if that makes you idle, or your extra work won't lead to extra customer value. In the latter case, you'll get scolded for not delivering more (even though you did, but the customer doesn't see that.)

When optimization doesn't work

In scenario 4, you're acting similar to scenario 1 - you're essentially the Constraint yourself and optimize accordingly.

That leaves scenarios 2 and 3. In both scenarios, you lose by winning.

Any optimization you do when you're not the Constraint will evaporate, be invisble, or make things worse for the Constraint, and thus for the system, and thus, in extension: for you.

When teams try their best to optimize their ways of working, and see that it either does nothing, or backfires - eventually, they get change fatigue: "Why should we change anything that doesn't help us?"

And that's a core problem with Scrum: The Scrum Guide suggests that teams should identify improvements in every single Retrospective, without considering whether the team is even the Constraint. If you aren't - you won't see anything coming out of your changes. To make  Retrospectives meaningful, identifying and enacting change is insufficient. You have to make sure that the changes are actually beneficial to the organization as a whole.

What now?

Here are four simple checks you can do:

1. If you are the Constraint, do whatever it takes. Do less, do more. Simpler. Faster. Better. It will be noticable immediately, and you may even generate massive leverage. If you're five, and you have 100 people in your organization, every minute you save will have a twenty-fold impact. You'll be celebrated like heroes for even minor improvements.
2. If you're pushing work "downstream" for other teams to pick up, and you see work piling up, do not try to discover ways to do more: Do less. Use the free capacity to pick up work that would otherwise happen downstream.
3. If you're not receiving enough input from "upstream," don't try to do whatever you do better. Instead, pick up work that would otherwise happen upstream.
4. If you see that "downstream" is challenged, and you receive flowback, i.e. defects, complaints, questions or anything that makes downstream wait for you, then you have to improve how you work, so that there's less work to do downstream.

Look after the BRO's

 One reason why many agile teams are challenged is because their Coach or Scrum Master isn't looking after the BRO's.

Too many coaches and Scrum Masters focus on framework rules, roles, events, facilitation, process, practice, tickets ... But while they're doing that - who's paying attention the BRO's?

A coach's value isn't in being a nanny for grown-ups. It's not in enforcing a framework or process. It's not in telling people what or how to work. All of these are ultimately irrelevant - or worse: impediments.

A coach is there to make a difference. And if the only difference a coach made after a year is that now people are correctly doing X, they made none. A coach needs to work with the BRO's.

Agile Coaches need to know their BRO's, keep them in sight, and work to improve them. A good Coach always pays attention to their BRO's and makes a difference for them.

Ok - so what are BRO's?

Business Relevant Outcomes.

What "Fail Fast, Move On" stands for

There's some confusion as to what "Fail Fast" means - it's caused some disturbance in the force. Let me give you my perspective. 

I'm going to use a business example for illustration. The message won't change if you apply the ideas to a product, a way of working - or even just a task.

The Fail Fast Move On Philosophy

Of course, we would like to maximize our probability of success. But - sometimes, we just can't know.

Let us use a restaurant as a showcase: I haven't seen any restaurant owner ever who opened a deli in order to go broke. And yet, almost 90% of restaurants don't survive their first year. Worse yet: the average restaurant owner loses at least $50k on the ordeal. Which, by the way, is the reason why I haven't opened a restaurant. For me, the upfront investment plus bound capacity (it's a pretty taxing job) isn't in sound relationship to possible benefits. But I digress ... but only slightly.

Fail Fast

During the "Fail Fast" stage, we start by figuring out what we're trying to do, what we know and what the unknowns and risks are. We exhibit a healthy skepticism of facts, for example, "Do we really know people in this part of town like Sushi?" and ask critical questions, such as, "What will happen if they don't?" We can then classify how much we're risking in case our assumptions turn sour. That gives us an analyzed, itemized list of risks which could make our endeavour fail.

Experiment

With our risk list, we propose a counter to our business idea, and we try to prove that the counter is false:

Returning to our sushi example, "We will offer a piece of Sushi to 100 pedestrians and ask them whether they'd visit a Sushi bar offering the same level of quality. [Counter:] Fewer than 10 positive answers mean that there's not enough interest in Sushi here."

Next, we're not even going to try to open a Sushi bar: all we want to do is disprove the pessimistic notion of an empty Sushi, our key risk of failure.  (We could still be wrong - but now we know that there's a possibility of being right.)

We're not trying to succeed, we're trying to rule out predictable failure.

If our counter-experiment succeeds, we just saved all followup effort: Why should we rent a facility, purchase decoration and cutlery, hire a cook and waiters - if we already know that we won't have enough customers? When we learned that we can't deal with known challenges, we need to change our goal and backtrack.

If we succeeded at failing the counter-experiment (yes, that's a double negative!) - we can proceed further.

Move On

In our restaurant example, we know that 90% of restaunts fail, and we'd like to be in the 10% that don't (like everyone opening one of the failing 90% of restaurants.) But: when we can't, we definitely don't want to be lose some $50k+ on the attempt. Hence, we move step by step, keeping the cost of each step low, and accept that everything we invested up to this step is money lost. We're not trying to recoup it - especially not by investing more in order to get some of it back.

"Moving on" means that everything we invested up to this point is "sunk cost" - investments we will never recover. Sunk cost hurts, and it makes us uncomfortable. Yet, there's something worse than sunk cost: "Throwing the good money after the bad."

In order to practice "Move On," we avoid hedging our bets by binding unnecessary assets, so that we have less pain when discarding them.

Moving on

Moving on requires us to let go of what we invested.

The 3 Steps of Fail Fast, Move On

Applying Fail Fast, Move On goes far beyond validating a business idea - it goes for any idea, and thus is all-encompassing for all creative work. Fail Fast, Move On could be considered a 3-step process:

1. Pull risk forward
2. Rigorously inspect and adapt
3. Minimize and write off sunk cost

That, of course, doesn't mean that we either:

• Generate unnecessary risk by negligence or unprofessionalism.
• Act without a prediction to validate.
• Waste our energy on doing things we know we could do smarter. 

To the contrary - "Fail Fast, Move On" is the notion of avoiding these three antipatterns by systematically eliminating failure points.

Proper "Fail Fast, Move On" saves you energy and maximizes your opportunity of success.

You can learn more about succeeding with "Fail Fast, Move On" in my Lean Startup lasses.

Feel free to set up an appointment with me using the PAYL coaching mechanism (on the left) to discover more.

Performance matters!

Performance is one of the most important factors for an agile organization, even though the topic is often viewed with suspicion. Yet, a proper understanding of - and close attention to - performance is critical to success. Here's why:

On Stage

Let's say you go to a concert. You were thrilled with anticipation, you booked the tickets half a year in advance, made an Instagram story about all your preparation, and on the day of the event, a sleepy, un-enthusiastic singer shuffles on stage and sings without any emotion at all. What's your next post going to be? "This was a terrible performance! So disappointed!" Okay, now let's say we sanitize out the word "performance." That leaves your impression at "That was terrible. So disappointed." Well, that feedback won't help the band improve: What was bad? The location, the food, the music? If I was part of the band, I'd just disregard it, because nothing is ever perfect.

In the workplace

Of course, a stage performance isn't the same as workplace performance. Still, we work for people who have expectations on what we do, and to whom it matters whether we achieve something or not. That said, let me briefly define, 

Performance: the ability produce desirable outcomes.

Thus, inattention to performance sends a strong message, "your outcomes don't matter" - in extension, "you don't matter. There is no better way to demotivate people!

We should strive to build high- and hyper-performing teams, and create an environment where each individual is able to perform at their best. We need to constantly ask ourselves, "How can we perform better?" - and relentlessly fix any problem that stops us from performing better.

Aren't "performance measurements" detrimental?

Three remarks - 

1. Goodhart's Law (A measure that becomes a target ceases to be a good measure) 
2. Attribution error (Correlation doesn't equal causation) 
3. Weaponization (Everything is harmful when used as a weapon)

That is: what gets you the bad outcomes is a misdirected measurement system, not performance itself. Don't throw out the baby with the bathwater! 

How does performance matter?

The result of keen attention to performance is pride of craftsmanship and sense of accomplishment: going home after a challenging day of work, we are satisfied with our achievements, and we feel that our time was worth it.

Low performance, in contrast, means that we go home and wonder what we just wasted our time with. It leaves us demotivated, disoriented, burnt out.

And regardless of whether we give it a name, or not: the feelings will be there. We would like to have more sense of accomlishment. Hardly anyone looks forward to feelings of uselessness, worthlessness or pointlessness.

"Performance" is merely the label we attach to these feelings.

If you've ever worked on a hyper-performant team, you will remember that experience for the rest of your life. The experience will continue to boost your self-esteem, your desire to grow, and make you both more professional and a better person. Likewise, if you've ever worked on a low-performance team, you will also most likely remember the experience for the rest of your life - but most likely as a chapter you'd prefer to never repeat.

Performance is paramount.