There's an excellent video by Nicolas Brown about "How (agile) charts lie." See:

https://circle.tameflow.com/c/conversations/how-agile-charts-lie

In one section of the video Nicolas expresses deep concerns about the use of Flow Efficiency.

Kevin, one of my community members asked me how "I might help a client get comfortable with the notion of Flow Efficiency assuming they had similar concerns to those Nic raised."

I wouldn't! And here is my full reply:

First, Nic has a concern with the Flow Efficiency Chart. (That is Flow Efficiency over time.)

Please note well: there is not a single page in my books or in my posts where I ever suggest to use Flow Efficiency Charts. In this I agree with Nic that they are not very useful. And it makes absolutely no sense to talk about "average" FE, which is an abomination.

So if anyone is suggesting to use the Flow Efficiency Chart or to use Average Flow Efficiency as a metric, I would say that your client is correct in being very skeptical. In fact they should not use them!

Note well: In general I advise not to use FE as a metric! Though knowing about it, and how to calculate it (correctly) can be very beneficial, because...

Second, I use FE primarily as a Mental Model… to make people think that there is actually "work waiting for workers” inside their system. If you present FE from this perspective, you can give a business reason for why it is important to address that situation.

See my example on page 64 of The Book of TameFlow, or (more funnily) my Twitter thread about 'The Magic Wand Experiment.' There you will have a very convincing argument for why businesses should focus on reducing Wait Time rather than Touch Time.

https://twitter.com/tendon/status/1524978237692006400

Notice that those two are components of FE. So if you attend to the right part of FE, you can get a lot more juice... while if you attend to the wrong part, you will be losing money.

Third, I use the Flow Efficiency Board both to make it explicit when work is waiting for people, and also as a psychological driver. Again, this is explained in The Book of TameFlow.

In theory, there is no great difference between a Kanban [Doing/Done] column split, and a Flow Efficiency Board's [Waiting for.../... in Process] column split. For any running process, the FE will be the same... But practically the impact is huge.

How do you feel when you read "X is waiting for Kevin" rather than "Kevin is done with X." Which gives a stronger bias to action? You see, we don't care so much about measuring FE.

We care much more about creating the behavioral responses and attitudes that foster higher levels of performance.

In conclusion: while you can measure FE, don't waste any effort in doing so. Instead pickup the Mental Model that underlies the idea of FE, and help people to make operational decisions based on that Mental Model.

You will improve because of the improved understanding, decision making, behaviors and attitudes you develop in the teams - not because you're chasing a metric.


Would you like to discuss more - then please join my weekly huddle on Thursday 17th of November at 19:00 CET.

RSVP here:

https://circle.tameflow.com/c/events/tameflow-circle-weekly-huddle-e920f5

You can read the unrolled version of this thread here: https://typefully.com/tendon/ERt0UBQ

Flow Efficiency as a Mental Model

This quote by Jamshid Gharajedaghi is one of the most powerful and clearly articulated statements of an idea that is at the core of #tameflow.


Let's read it again:

>> Natural science has discovered "chaos." Social science has encountered "complexity." But chaos and complexity are not characteristics of our new reality; they are features of our perceptions and understanding. 

>> We see the world as increasingly more complex and chaotic because we use inadequate concepts to explain it. When we understand something, we no longer see it as chaotic or complex.


It is particularly relevant in this world of Agilists that see complexity everywhere, and need necessarily to proceed with "empiricism" (I use quotes because it is not real, necessary, but artificial empiricism) like being blind fold in a coal cellar on a new moon's night.

Let's break down the quote, which - mind you - comes from one of the greatest systems thinker ever (together with Ackoff):

>> ... chaos and complexity are not characteristics of [...] reality.

Got it? Chaos and complexity are not real!

>> ... they are features of our perceptions and understanding.

Chaos and complexity are what we perceive and believe. They are created and exist in our minds. We are causing them.

>> ... we use inadequate concepts to explain it.

That's the crux of the matter. Our mental models are giving us a distorted interpretation of reality.

>> When we understand something, we no longer see it as chaotic or complex.

And this is the hint of the direction of a solution to manage chaos and complexity.

The solution is to act on your mind, on your understanding.

No amount of scaffolding reality with frameworks will allow you to manage the chaos and complexity, it is only by upgrading our thinking that we will make progress.

You need better mental models to appreciate the Inherent Simplicity that governs all of human created social systems, like companies.

One of my favorite examples is dependency management in #SAFe, the Scaled Agile Framework, with all the cob web of red threads representing the combinatoric explosion of a dependency graph. No wonder they need days of planning & months of execution to produce anything at all.

With #tameflow's focus on the Constraint, that incredibly complex dependency graph implodes into a single, simple, linear queue in front of the Constraint.

What's the difference in the two approaches? 

That in TameFlow we have a clear awareness of the impact of the presence of the Constraint and the Mental Models to manage around the Constraint. What appeared to be a rat's nest of dependencies becomes just one straight line.

And there are many other examples where this simplification through upgrading of the Mental Models happens all the time in the TameFlow Approach.

Indeed...

>> When we understand something, we no longer see it as chaotic or complex.

Strive to understand, instead of deliberately choosing to blindfold yourself and continue poking around to make some sense of reality.

THINK!

More of this at https://circle.tameflow.com

You can read the unrolled version of this thread here: https://typefully.com/tendon/ZPZ3d3W

Complexity and Chaos is in your Mind - not in Reality

Are you using SAFe? And still cannot figure out how to make software engineering work "at scale?"

Try something different...

Read this book!

Here's are some of the topics I cover...

• Take an economic view of your backlog
• Balance and collaboration between business and engineering
• Little's Law and system stability
• Finding the Constraint in the Work Process
• Finding the Constraint in the Work Flow
• Finding the Constraint in the Work Execution

• Achieving Scalelessness
• Integration with classical Project Management
• Dependency Management
• Psychological Flow States
• Fostering agile interaction and collaboration
• How to get started with the approach: agile bootstrapping expediencies

Here are some of the things you will learn:
• Manage a scaled software engineering environment with multiple projects/products or value streams, multiple events or deadlines, multiple stakeholders and multiple teams.
• Manage the backlogs in a financially sound way.

• Confront and master the most complex dependencies, with development or delivery precursors; architectural elements and architectural dependencies; exploratory works; failure demand work.
• Quickly bootstrap the fundamentals of the approach with simple team-level actions.

If the book is not enough, then join the TameFlow Community to discuss further and share your reflections with other readers:

https://circle.tameflow.com

You can read the unrolled version of this thread here: https://typefully.com/tendon/CMHcy73

Are you using SAFe and cannot make it work?

FIX YOUR KANBAN BOARDS!

Are you using Kanban boards? 

Do the column's look like those in the left side of the picture here?

Well, then rejoice because you can improve the Kanban board a lot, with a very simple change.

The one shown on the right side.

Let's see why.


In particular, if you are accustomed to splitting any activity column into two semi-columns like DOING and DONE, ask yourself:

Does it make sense?

To put the reflection in context, maybe revisit the "Patient in the Hospital" metaphor?

https://twitter.com/tendon/status/1524814642819698692

When you go to the hospital, what is the first thing that happens when you need to be subject to some action?

With a few exceptions, you start by having to WAIT.

It is the same at your work.

Most of the work that needs to be DONE, typically starts of by having to WAIT.

Typically because people are already busy doing other stuff.

So why does the Kanban board model activities with an initial DOING?

That's not what happens in reality.

Furthermore, once an activity is "done" whey is it kept in the column of the activity that just finished?

Ask yourself again: does it make sense?

If you're done.. why do you keep on hanging on to the work? Shouldn't you pass it over to the next activity in line?

A simple change in the design of the Kanban boards fixes this misrepresentation of reality and work dynamic.

We split any activity into the two semi-columns: 

WAITING FOR...

and

...IN PROCESS.

Ask yourself: does this make more sense?

By renaming the semi-columns we effectively represen the fact that work startsby having to WAIT.

Only after some waiting work is started.

Once the work is "done", it is passed over to the next activity's WAITING FOR... semi-column

Ask yourself: does this make more sense?

This change transforms the Kaban board into what in #tameflow we call a:

FLOW EFFICIENCY BOARD.

The change allows us to better focus on Flow Efficiency.

Revisit the Magic Want Experiment to recall why it is important and makes business sense.

https://twitter.com/tendon/status/1524978237692006400

This change is not just a renaming of columns and semantic sugar coating.

The change will allow the *proper* collection of FLOW METRICS.

Flow Metrics are essential in order to identify the CONSTRAINT and apply the ideas of the THEORY OF CONSTRAINTS.

There are many other operational consequences of this change, that we pursue with #tameflow. 

But in particular one has relevance for the team spirit: the psychological and motivational impact of having an explicit WAITING FOR... semi-column in front of the work process.

 Teams start to attend to wait states.

There is no false sense of accomplishment ("I'm done!... now it is someone else's problem!") when in reality the work is still in process and is waiting.

When work is waiting for YOU, then you are prompted to action, not celebration.

Did you find this thread about fixing Kanban boards with Flow Efficiency Boards interesting?

You can read more about Flow Efficiency Boards in "The Book of TameFlow."

https://leanpub.com/tameflow/


You can read the unrolled version of this thread here: https://typefully.com/tendon/U33RgmI

Fix Your Kanban Boards with Flow Efficiency Boards!

4X IMPOSSIBILITY DEBUNKED

In the previous thread we wondered if the amazing improvements anecdotally reported by #SAFe, #Scrum and #Kanban practitioners are real or not.

The doubt has reason.

They cannot reliably reproduce the results.

You can check the questioning here:
https://twitter.com/tendon/status/1528359372815859712

The reason they cannot reproduce the results is simply because of the lack of some obvious or missing knowledge.

The kind of knowledge that was at center stage in the Story of the Egg of Columbus. 

https://twitter.com/tendon/status/1523949167587905536

If we gain such knowledge, the seemingly impossible task of reliably getting improvement in multiples, will become actionable.

To understand how it works, we need to see what the presence (or absence) of THE Constraint can be of consequence.

We need to revisit the Magic Wand experiment.

We improved FLOW EFFICIENCY by reducing the WAIT TIME.

In particular, we saw that a 20% reduction in WAIT TIME would yield a 23% gain in THROUGHPUT; while a 20% reduction on TOUCH TIME would gain only 1%.

https://twitter.com/tendon/status/1524978280981352448

The WAIT TIME reduction had many other benefits: avoidance of costs, burdens and risk associated with  TOUCH TIME reduction.

Now I have to disappoint you!

This story was really a lie!

In reality the improvement you would measure, would be much, much greater than those 23%!

So it was a "white lie." 

By focusing on the low hanging fruit - WAIT TIME - we will go in the right direction; and it might be possible to have those incredible performance gains.

But how?

It can be puzzling to understand.

For example, if you are familiar with Little's Law:

TH = WIP / FT

THROUGHPUT is WORK IN PROCESS over FLOW TIME (all measured in averages), then you will reason that WAIT TIME reduction will decrease FLOW TIME. 

The denominator goes down; and THROUGHPUT must go up.

It makes sense. 

In fact it was the basis for our +23% gain calculation.

But that is not what happens

In fact it can NOT happen at all according to the THEORY OF CONSTRAINTS.

Why?

Because to increase THROUGHPUT, the capacity of the CONSTRAINT must increase.

But we did NOT change TOUCH TIME!

So capacity did NOT increase.

We should not witness any increase in THROUGHPUT!

Yet if we actually reduce WAIT TIME, our measures will show us beyond any doubt that THROUGHPUT does increase.

Should we may discard the Theory of Constraints at this point?

After all, what use is a theory if doesn't match reality!

Or maybe we are missing something?

Yes! We are missing the fact, postulated by the Theory of Constraint, that reducing WAIT TIME does NOT directly affect THROUGHPUT. 

What it does, however, is that it will *indirectly* affect TOUCH TIME!

Note: I said "affect;" not increase, nor decrease!

Let's delve deeper.

Reduction of WAIT TIME will invariably cause a proportionate reduction in WORK IN PROCESS.

Thus, THROUGHPUT as calculated by Little's Law remains unchanged.

But there is a side-effect happening too.

We know that FLOW EFFICIENCY is low.

It is typical of Knowledge-Work!

Low FLOW EFFICIENCY means that an inordinate amount of time is spent in MULTI-TASKING.

Even the CONSTRAINT will be subject to MULTI-TASKING.

A lot - really a lot - of its time goes wasted.

And we know, that time wasted on the Constraint, is time lost by the entire system.

Now, reducing WAIT TIME will remove WORK IN PROCESS.

The degree of MULTI-TASKING will go down!

We help the Constraint to reach it's nominal capacity.

Note well: we are not increasing the Constraint's capacity; we are avoiding wasting it in unproductive MULTI-TASKING.

The increase in THROUGHPUT comes from the "more work" done by the Constraint, simply because there are fewer interruptions (coordination and synchronization costs); here is less waiting for others; and less context switching.

The Constraint can operate in a more focused way!

We reclaim time that previously the Constraint literally lost in MULTI-TASKING.

Instead of MULTI-TASKING the Constraint can focus on doing work. 

In other words, we get more TOUCH TIME to "touch" the work; but all still without changing the way of working!

Work is not performed any differently. 

Remember, we did not reduce TOUCH TIME, only WAIT TIME. 

So the "touching" is the same as before.

We only use time in a wiser way.

If we do this alone, we might truly experience improvements in the order of 4X!

The image at the start of this thread illustrates how such a 4X improvement can happen.

If you want the detailed explanation, you can find it in Chapter 4 of The Book of TameFlow:

https://leanpub.com/tameflow

So we can get 4X improvements by being smart about WAIT TIME, without incurring costs, burdens or risks.

And... we haven't seen yet what we can achieve if we decide to really improve on TOUCH TIME - but that will be a topic for future threads.

Don't miss any. Follow @tendon

You can read the unrolled version of this thread here: https://typefully.com/tendon/WDBk4hb

4X Impossibility Debunked

WHAT ABOUT 4X IMPROVEMENTS?

We often hear about incredible performance improvement achievements, like 3, 4 or even more times the baseline.

Proponents of #SAFe, #Scrum and #Kanban are know to purport such results.

Yet many are skeptical. 

The question is: are they real?

There are plenty of anecdotes and even case studies presented at conferences and in papers and books.

But in all these cases, there is fact - or Pattern - that recurs very often.

While the result was achieved somewhere, it seems impossible to reliably reproduce it elsewhere.

The managers, consultants and coaches that were successful in one instance, try to do "exactly the same" in some other context.

And the results - while positive - are often disappointing compared to the high bar set by the successful precedent.

So what is missing?

If you do "exactly the same" things, it is reasonable to expect comparable results. 

By then why are there such differences?

Are these just unique instances of happy chances, alignment of the Planets, and sheer luck?

Is it just all random success?

Or is there a method?

I'd claim that most of such reported cases are due mostly to luck.

They happen as the methods suggest actions that indeed increase the odds - but do not guarantee - a spectacular improvement.

There must be something more than just following a recipe!

As in the Story of the Egg of Columbus, there is indeed a secret ingredient to make such cases reproducible by design, and not by random chance.

As in that story, it is a matter of knowledge. 

If you have the knowledge you can do it.

https://twitter.com/tendon/status/1523949167587905536

Would you like to know more?

Follow me @tendon for the next thread, where I will debunk the myth of the impossibility of 4X improvements.

And like the Story of the Egg of Columbus, you will realize it is obvious in hindsight, while not self-evident from the outset.

You can read the unrolled version of this thread here: https://typefully.com/tendon/cYWKPFu

What about 4X Improvements?

CYCLE TIME VANITY!

Most people will take it for granted that if we perform work in less time, it must be better. Right?

All the mainstream approaches - #SAFe, #Scrum, #Kanban, #DevOps - obsessively insist that reducing Cycle Time is a Good Thing(tm)!

Or is it?

We primed ourselves to be open to what is not self-evident from the outset, but obvious hind sight.

We used the Story of the Egg of Columbus to get this idea across.

Deeper knowledge will afford us non-conventional thinking.

https://twitter.com/tendon/status/1523949167587905536

It's like the proverbial two sided coin.

It is not only about finding counter-intuitive solutions to our problems.

It is also to be ready to question what appear to be obvious solutions to well known problems.

Cycle Time reduction is of this nature.

Who in their right mind would ever question that reducing Cycle Time would not be a good thing?

(Besides, "Cycle Time" is the time from start to finish of an activity. In TameFlow I prefer to use the term "Flow Time" - but stick to "Cycle Time" here because of familiarity.)

Let's consider this thought experiment (another MENTAL MODEL).

An activity typically takes 10 days to perform.

There are two improvement proposals.

One will reduce the time to 9 days.

The other will increase it to 11 days.

Which do you pick?

No brainer! Right? 

The 9 days solution!

Only a madman would go from 10 to 11 days.

This other proposal is even _increasing_ Cycle Time.

Of course it must be discarded!

But let's have some additional information.

The original activity of 10 days is broken down into three sub-activities taking respectively 3, 5, and 2 days (total 10).

First proposal changes to: 2, 5, and 2 (total 9).

Second proposal changes that to: 3, 4 and 4 (total 11).

The slowest activity was 5 days. It is the WORK PROCESS CONSTRAINT. It limits what the entire process can deliver.

The first proposal leaves the second step unchanged.

The second proposal reduces the second step from 5 to 4 days.

So the original process will have an effective OPERATIONAL THROUGHPUT of 1 item every 5 days; or 0.2 items per day.

The first proposal - despite the overall reduction in cycle time from 10 to 9, will still deliver 0.2 items per day.

So it really brings no improvement at all!

The second proposal reduces the second step from 5 to 4 days.

So the second proposal, despite the **overall increase in cycle time** from 10 to 11, will deliver 1 item every 4 days; or 0.25 items per day.

Conclusion:

First proposal with 10% cycle time reduction has zero impact on performance!

Second proposal with a 10% increase on cycle time will produce a 25% increase in performance: from 0.2 to 0.25 items per day.

Unbelievable!

Moral of this story.

Don't mindlessly pursue cycle time reduction.

Most of the time, the effort is vain.

And if you celebrate the gain, you are celebrating a vanity metric!

The only way to improve is to reduce the FLOW TIME of the WORK PROCESS CONSTRAINT.

This also explains, yet again, how operational performance improvements that might be celebrated as victories, at the end of the day delivery zero impact; yet the company sustains the cost of change, for a total loss!

The only improvement that matters is on the Constraint!

Did you enjoy this mind-boggling example? 

It is taken out of Chapter 5, "Where to Focus Improvement Efforts" from "The Book of TameFlow".

https://leanpub.com/tameflow


You can read the unrolled version of this thread here: https://typefully.com/tendon/DsyjBeb

Cycle Time Vanity - Is Cycle Time a Vanity Metric?

BETTER THAN FLOW EFFICIENCY

We know FLOW EFFICIENCY is more powerful than RESOURCE EFFICIENCY.

Results are so spectacular! 

You might be content and not compelled to improve further.

After all, we did discover that FLOW EFFICIENCY is the key to make incredible improvements.

As we did conducting "The Magic Wand Experiment."

https://twitter.com/tendon/status/1524978237692006400

Could there be anything that sustains even more the outrageous claims I did?

With FLOW EFFICIENCY we have already seen it is possible! 
https://twitter.com/tendon/status/1524306595995262976


But we can do even better, and sustain the Outrageous Claim in an even more powerful way.

Be introduced to THROUGHPUT EFFICIENCY!

Just as FLOW EFFICIENCY trumps RESOURCE EFFICIENCY, THROUGHPUT EFFICIENCY trumps FLOW EFFICIENCY.

Let's find out how it might look like.

WHICH PRODUCT SHOULD WE SELL?

Let's consider a simple example. 

We have four products: A, B, C and D.

They will be sold respectively for 50, 50, 55 and 52 dollars.

The question we want to answer is: which product should we produce and sell to make the greatest profit?

Note: this is a "manufacturing" example.

You might believe that this does not apply to knowledge-work.

Remember how we work in TameFlow. 

We use MENTAL MODELS to gain deeper insights about reality.

This is another MENTAL MODEL. 

Maybe it applies to knowledge-work too?

COMPUTE UNIT PROFIT

We need more information to make the decision.

If we can get data in the form of production times, material costs and labor costs, then we will be able to compute the unit profit.

The unit profits are respectively: $24.00, $18.67, $24.17 and $26.17.

PICK THE HIGHEST UNIT PROFIT

Now the decision can be made.

Obviously we will pick product D, the one with the highest unit profit.

Don't we all agree that it makes sense to maximize the unit profit?

Not so fast...

BEWARE OF CONFLICTS OF INTEREST

The stated objective is to maximize profits

Different KPIs create conflicting interests.

Sales will push the product with the highest price, for the commissions.

Production the one with highest resource efficiency.

We have hidden agendas!

Interesting questions:

1. Can we make more money for the company selling some other product that is NOT the one with the highest unit profit?

 2. Can we resolve those hidden conflicts and create common interests across the roles?

"Impossible!" most will say, to either!

BREAKDOWN THE PROCESS

Who's working?

Mr. Green and Mr. Gray.

See which activities they perform (in this case, assemble or work on the components/raw materials).

Note the order or sequence of the activities.

Map this out for each product.

MEASURE FLOW TIMES / PER WORKER

Measure how much time ("Flow Time") each of them employ to perform each activity.

What stands out is that, no matter which product is being put together, Mr. Green consistently takes more time than Mr. Gray.

Is this significant?

IDENTIFY THE CONSTRAINT

We have found the CONSTRAINT IN THE WORK PROCESS.

(We colloquially refer to the Constraint as "Herbie") 

It is Mr. Green, precisely because he always needs more time than Mr. Gray.

Mr. Green is always the "slowest."

OPERATIONAL THROUGHPUT PER DAY FOR EACH PRODUCT

What does it mean that Mr. Green is the Constraint?

The system can never produce more than what "Herbie" does!

We can compute the maximum number of units per day, for each product, relative only to the capacity of "Herbie."

NET PROFIT PER DAY / FOR EACH PRODUCT

If we know the maximum number of units per day, we can also calculate the NET PROFIT PER DAY for each product.

We do this calculation with the simple equations of THROUGHPUT ACCOUNTING.

Now something really surprising stands out...

WHICH IS THE MOST PROFITABLE PRODUCT NOW?

We see that product A, that nobody cared about, is really the one that will give us the most "bang for the buck!"

It will produce +59% more DAILY NET PROFIT compared to product D which had the highest unit profit! 

Unbelievable!

Reflect on what happened here.

The product that conventional thinking deems is providing the highest (unit) profit, does NOT make the most money for the company. 

It is counter-intuitive, isn't it. 

It is another Egg of Columbus!

And what was the burden to the company? 

HOW MUCH DID THIS IMPROVEMENT "COST?"

We sustained no investment, no hiring, no purchasing of assets, no restructuring, no reorganization, no retraining, no overtime, no additional data (besides what was available).

We changed nothing, except a decision.

We had zero risk!

Again we showed that we can sustain our outrageous claim, just as Columbus did with his egg!
https://twitter.com/tendon/status/1523949167587905536

NO BIG DATA. NO DATA NOR COGNITIVE LOAD.

You might believe that to make such decisions you need lost of data - "Big Data."

But compare the dataset supporting the cost accounting decision making compared to the one of throughput accounting.

They are both the same size!

THE GREATER BENEFIT: UNITY OF PURPOSE AND COMMUNITY OF TRUST

In all this, there is even a greater benefit.

Imagine that all KPIs, of all roles, are aimed at the maximization of FINANCIAL THROUGHPUT. 

We will have a SINGLE METRIC that drives all activities, no matter who!

Not only will this kind of decisions make the company much more profitable, but it will foster the UNITY OF PURPOSE and a COMMUNITY OF TRUST.

Conflicts of interests and hidden agendas, will be replaced by shared interests and actions that all pull in the same direction. 

Did you like this example?

It is from chapter 13, "the Financial Metric Supporting Unity of Purpose and Community of Trust" of my book "Hyper-productive knowledge work performance: the TameFlow Approach and its application to Scrum and Kanban"

https://www.amazon.com/Hyper-Productive-Knowledge-Work-Performance-Hyper-productivity-dp-160427106X/dp/160427106X 

If you want to see how these ideas can be used in knowledge -work, and in particular software engineering management, check my latest book: 

"Standing on Bits, Agile Software Engineering Management at Scale with the Theory of Constraints."

https://leanpub.com/standingonbits


You can read the unrolled version of this thread here: https://typefully.com/tendon/FlgLWmi

Throughput Efficiency is better than Flow Efficiency

THE MAGIC WAND EXPERIMENT

Besides telling stories, another tool we use in TameFlow to explore and understand our MENTAL MODELS are "Gedankenexperiments," that is, "thought experiments."

We will look at such an experiment now, the Magic Wand Experiment.

The experiments starts with this question:

If I gave you a magic wand that could reduce by 20% anything you point it at, how would you use it?

Most business would have no doubt: let's make things happen faster.

Which means they would aim the wand at reducing TIME by 20%.

Let's make some considerations.

FIRST! Most businesses are not aware of the distinction between  TOUCH TIME and WAIT TIME.

When they think about "making things happen faster," that invariably means "work harder."

So, more specifically, they would aim the wand at TOUCH TIME.

It makes sense after all. 

In the hospital metaphor: if we want to "deliver" more healthy patients, the doctors must "TOUCH" them faster - do their work in less time.

The "resources" have to become more "efficient."

This is the essence of the RESOURCE EFFICIENCY paradigm.

Because of this ruling view - the RESOURCE EFFICIENCY, "work harder," paradigm - and the fact that there is no awareness or consideration about the distinction between TOUCH and WAIT TIME, any improvement effort will be aimed at TOUCH TIME REDUCTION.

You must "work harder!"

SECOND! Another obvious effect of improving on TOUCH TIME is it implies sustaining costs, changes and risk of failure.

Think about it. 

The doctors must operate "faster!" 

They must change the way of working; hire more nurses; buy better equipment. 

And risk failing!

If we reduce WAIT TIME without changing TOUCH TIME, then there are no material changes to perform.

The doctors would still be operating as before.

No additional nurses need to be hired or trained.

No further equipment is needed.

And without change, risk of failure is gone!

THIRD! If we reduce WAIT TIME, we are effectively pursuing what is known as FLOW EFFICIENCY.

It can be thought of as "deliver sooner" in contrast to "work harder" of RESOURCE EFFICIENCY.

It can be measured as the ratio between the sum of all TOUCH TIMES over the TOTAL TIME.

Strikingly, FLOW EFFICIENCY is extremely low in the context of knowledge-work.

Unless it has been deliberately addressed, it will typically fall between the 3-7% range.

Let's say 5% for arguments sake.

What does it mean? 

95% of the time the "patient" will be waiting!

Now, with these three factors in mind...

1. We are aware of WAIT TIME
2. If we improve WAIT TIME, there are no costs, changes or risk
3. Flow efficiency is low, like 5%

... let's ask the experiment question again.

Where do we aim the wand at?

WAIT TIME or TOUCH TIME?

The answer is obvious.

It makes much more sense to aim at WAIT TIME.

But how much better is it, really?

If we calculate how much more gets done, we see the difference: a 1% improvement (via TOUCH TIME) vs a 23% improvement (via WAIT TIME). 

Surprised?

It's even worse!

That 1% will probably be eroded by the effort to improve on TOUCH TIME.

It will be eroded by the costs and changes, and it will most likely fail.

And because it fails, it will cause another chase of the next "improvement initiative," effectively triggering a vicious circle!

But is yet even more worse!

Because if the TOUCH TIME improves by 20%, operations are patting themselves on their back, celebrating how good they are!

But business will NOT see any financial improvement. 

A 1% eroded by the cost and risk of change.

Business will scratch their heads, and wonder why they don't see results

And they will kick off another "improvement initiative," notwithstanding the "success!"

So the change cycle starts over even so, making everyone frustrated yet again.

FLOW EFFICIENCY improvements, on the other hand, would yield a +23% of real performance gains, which likely would be outstandingly reflected in the business results.

So with this thought experiment, there is no doubt.

FLOW EFFICIENCY trumps RESOURCE EFFICIENCY.

Did you like this reasoning about FLOW EFFICIENCY and its effect on improvement and business results?

You can read more about such ideas in my book: The Book of TameFlow!

You can find it here:

https://leanpub.com/tameflow


You can read the unrolled version of this thread here: https://typefully.com/tendon/Nb4LjcY

The Magic Wand Experiment

THE PATIENT IN THE HOSPITAL

Have you (or some of your relatives/friends) ever had the misfortune to need a hospital?

I hope you have not.

But if you did, you will relate to this story, the story of "the Patient in the Hospital."

Before we delve into the story, let's recap.

When working with TameFlow, we want to make sure you can relate to certain ideas.

Often we start by "telling a story," where the elements of the idea are exposed through the narrative.

https://twitter.com/tendon/status/1522839951401906176

We already met one such story.

The Story of the Egg of Columbus, which prepared us to be open to ideas that are in no way self-evident from the outset, but that are plainly obvious in hindsight, once the solution is revealed to us.

https://twitter.com/tendon/status/1523949167587905536

Many ideas of TameFlow are like that: defeating your common experience to appear outrageously impossible, only to be revealed as totally obvious - once you gain a new insight, a new perspective.

We made an outrageous - seemingly impossible - claim!

Will it turn out to be totally obvious, once we gain some new perspective?

https://twitter.com/tendon/status/1524306595995262976

We want to explore how such a claim is indeed not only possible, but obvious.

But before we learn about such secrets, we need to prepare our mind with a new MENTAL MODEL.

A MENTAL MODEL illustrated by the Story of The Patient in The Hospital.

Let's see how it unfolds.

MEANING OF "PATIENT"

Let's start by reflecting on the etymology (i.e. the history) of the very word "patient."

As a noun, it comes from the Latin word, that means to "suffer."

Of course, a person treated for some medical condition is "suffering."

THE PATIENT EXPERIENCE

"Patient," as an adjective, means someone who "endures" suffering or "bears" a misfortune, without complaining.

That's were we get the notion of "being patient" meaning that you have to WAIT!

 In fact, what typically happens when we go to a hospital?

Unless it is a case of grave emergency, what is the first thing you endure when you go to a hospital?

You have to WAIT!

Then a ward or nurse comes a long, and TOUCHES you.

Maybe not literally, but in the sense they are working on/with you. 

Then they tell you to... WAIT!

Then you are brought to some doctor, maybe a General Practitioner.

He will literally TOUCH you.

And maybe sends you to do some exam, like X-Rays.

There you have to WAIT.

Then the examiner will TOUCH you.

Then you're sent back to the doctor.

And you have to WAIT.

Do you see the pattern?

We are experience alternations of WAIT TIME and TOUCH TIME.

See the picture.

Any activity starts with a red WAIT TIME, and is followed by a green TOUCH time.

Notably the very first segment is red; and the last is green.

It's the patient timeline!

This alternating of WAIT/TOUCH times is the first MENTAL MODEL we consider.

Do you agree that it represent the typical patient's experience in a hospital?

Have you experienced this yourself?

Yes? 

Then you will be able to relate to the upcoming threads.


Besides, if you like working with stories and MENTAL MODELS like the one we just highlighted with the Story of the Patient in the hospital, you might enjoy my book: The Book of TameFlow!

You can find it on Leanpub, here:

https://leanpub.com/tameflow


I hope you've found this thread helpful.

To discuss further, join the TameFlow Community here: https://circle.tameflow.com

Follow me @tendon to make sure you don't miss the sequel threads!

Like/Retweet the first tweet below if you can:

You can read the unrolled version of this thread here: https://typefully.com/tendon/fKj1IzU