The "Laws"​ of Flow and Agile

The BlueOcean Home of BlueDolphins and Source of Flow

The "Laws" of Flow and Agile

February 12, 2022

In the last 19 years of using agile concepts and helping organizations find the optimal flow, I have seen one big obstacle. Most agilists and managers talk about methods (like Scrum) or frameworks (like SAFe, Spotify, LeSS, ...). I'm fine with that - but most of the time, they do not see the effects they produce by "blindly" applying such stuff. What is missing is an understanding of the underlying "Laws of Physics." Unless you understand these, you will always be surprised by what happens! Then the world around you looks very complex - but in reality, it's your lack of understanding.

This led to this small overview of laws that are important for understanding Agile and Flow and for not being surprised by what happens when applying methods ...

#1 Little’s Law

I call Little's Law "the law of lead time (or time to market)." In the original, it goes like this: L = λW. This means "the long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system."

I normally use it in this way: Lead Time (of an Item) = Work in Process / Throughput. Of course, this applies only to stable systems where inflow and outflow are equal and over enough time for many noise factors to level out. Both assumptions are true most of the time - when inflow and outflow are not equal, the system starves or explodes - such a system will not survive. And the long-time assumption is also often valid - if it takes days to produce a part or a story and the system is older than a few months, then the assumption is fulfilled.

Little's Law is so important because it explains why it's so important to reduce the "Work in Process (WIP)" to the lowest possible level without interrupting the flow. Reducing WIP immediately reduces the "Lead Time (LT)" - Flow kicks in. Furthermore, reducing WIP typically reduces mistakes, negative multitasking, and flow disruptions, all of which lead to higher "Throughput (T)."

But be aware that you need some WIP to maintain a steady flow and prevent any kind of "buffer holes," which means starving the constraint (#2)! That has to be avoided at any cost!

#2 Goldratt’s Law

I call it "the law of focus and throughput." In the original, it goes like this: "Every complex open system has exactly one element that constrains throughput!" It applies to nearly all systems because all useful systems are open.

Most people stumble over the "exactly ONE" in Goldratt's Law. By the way, it's easy to validate using normal reasoning: if a system has no constraint, then it will grow infinitely fast, consume all resources, explode, and die - it will not be very long-lasting - so such systems are seldom seen, and then only briefly. If a system has two constraints, then it can oscillate - small fluctuations in one of the constraints will lead to one becoming stronger, and if they have more or less equal capacity, this will cause the other to start constraining, and so on - it starts to oscillate. Each oscillation will require some refocusing and resetting of priorities - so it does not perform optimally - this can work, but if another system with just one constraint occurs in this environment, it will win - so the system with two constraints will suffer and maybe die. A system with three or more constraints should show chaotic behavior (often confused with complex behavior) - this will lead to even lower performance - it can exist, but at a very low-performance level. This low level is then determined by a hidden, invisible constraint, often the lowest level the market accepts - so there is again just ONE.

The implication of Goldratt's Law is dramatic! If you accept that there is just one constraint (per value-stream network), then you have to focus all your management activity on this one point. All optimization activity happens there, priority decisions are made based on constraint consumption, and investment occurs only in the constraint. Even more dramatically, if you accept your constraint, then you realize that if you want to get the most out of it, you should avoid any overload or starvation. Therefore, you need a buffer beforehand, and the maximum planned load of the constraint should be somewhere around 80-85% to account for fluctuations. But if the constraint is not overloaded, then all the other resources should be loaded even less to avoid starvation.

In the end, the goal is to have no internal constraint anymore - the constraint should be in the market. But then you have to open new markets - and so on ;-)

Did you get it? If you accept Goldratt's Law, then you understand why it makes sense to underload your organization to achieve the optimal throughput and to focus management only on the constraint. Then everything becomes simple - we call it "Complex systems are inherently simple!" This all leads to a whole management system called the "Theory of Constraints (TOC)."

#3 Ashby’s Law

I like Ashby's law#Law_of_requisite_variety) very much - if others complain about complexity (variety), then I say, "Only variety can destroy variety," or, for starters, "If it's too strong, then you are too weak!" Ashby found a formal way to prove that if you want to be in the lead, then you need a higher variety of behaviors/memes (you have to be more complex) than the system that you want to control.

And then the agile guys come to me with "Scrum" and tell me that this is the solution to everything. And by the way, Scrum is not complex at all. It is a control mechanism discovered by Henry Ford over 100 years ago. Just kidding.

But the interesting part of this is that you have to be more complex. And you already know I love complexity because of Goldratt's Law (#2) - so in complex systems, there is inherent simplicity.

#4 Conway’s Law

Okay, Conway's Law is more of a statement (not scientifically proven) and is, for me, derived directly from Ashby's Law (#3). It says that "organizations design systems that mirror their own communication structure."

The organization's communication structure equals the complexity the organization can think about and the behavior it can show. If this organization controls the design of the system, then it is only in control when the system has a lower or equal complexity.

For example, if communication in an organization only goes top-down, how can such an organization design a distributed, self-organized system architecture? It's unthinkable for them. So the system design will always look somehow top-down.

But the other way around - if an organization wants to play in the modern, distributed world of loosely coupled, self-organized systems, oh, oh - then the organization itself has to organize and communicate like this.

#5 Shannon(-Hartley) Theorem

What does Shannon have to do with this list? It has something directly to do with Ashby (#3) and Conway (#4). In the end, it's all about communication. In the simple form, Shannon said, "To see a valid signal, the frequency of the measurement must be at least double." Okay, in practice, a minimum factor of 5 - but that is just practice.

So if you want to control a system that has relevant events occurring on a weekly basis, then the frequency of measurement must be somehow daily - to be sure that you see the event.

Okay, in a team, this is easy - the agile community has not even made a secret of this and named an important meeting exactly like this: "the daily."

But that is just part of the game. If the event is relevant, then management might also have to receive it daily! In CCPM, it is done exactly like this - management knows everything about everything every day. And it's not command and control - it's just a necessity to stabilize the system (see also Viable System Model).

#6 Haken/Schiepek's Concept of Self-Organization

Now it's getting a little more interesting - and yes, Haken/Schiepek's concept is not a physical law. But they did a lot of research on self-organization and called it Synergetik (only known in German). In the end, they found a way to "explain the emergent shift of a system from one order state to another." And that is exactly what we want to achieve when we implement Agile or want to reach Flow - a jump from a low-performing order state to a flow (high/hyper-performance) state.

Some time ago, I wrote three LinkedIn articles about this, so simply look here: Self-organization 1/3 - why managers should know more about it - a short introduction

And in 2013, Steve Tendon and I wrote a book called "Hyper-Productive Knowledge Work Performance: The Tameflow Approach and Its Application to Scrum and Kanban (The Tameflow Hyper-productivity)" - also worth reading.

Epilogue

For sure, there are more laws that are relevant to being agile and achieving hyperproductive flow - but these are the ones I have used most in my 20 years of supporting organizations in becoming agile and getting into the flow.

Knowing these laws (at minimum #1 and #2) is so important for seeing when a method or framework is not applicable or, if you want to change something, whether you will get the desired result. If you don't know what you are doing (#3), then the system controls you, not the other way around.

If you want to dig deeper, here you can request a free version of the book Management 4.0 Handbook for Agile Practices - you can get it for free in our DolphinUniverse Community. We are ten authors who brought together everything worth knowing about Agile - it's not an easy read, but it is very valuable in the end.

If you want to use all these laws or learn how to use them, you can also join the DolphinUniverse Community for self-organized changes based on TOC.

So have fun with complexity! It's growing. So you will have more and more fun!

CU, Wolfram - your BlueDolphin