On June 30th, 2021, Steve Tendon was interviewed by John “The Agility Chef” Coleman about Constraints in Knowledge Work. Here’s an edited Transcript.
Steve – I’m really happy to be here with you again with this new title. What is it? The “Daily Flow!? I was just so i’m impressed by that, because my thing is the “Tame Flow” Approach. So if you have a “Daily Flow” it’s almost as if I should be here every day!
John – It would be nice to just talk about some of the basics of Constraints in Knowledge-work; and maybe if you could help us understand what is a Constraint?
Steve – Right! Well Constraints in Knowledge-Work is something that I have been chasing for the last 15 years or so. It’s not something that is so obvious and straightforward to pinpoint. Of course the the whole idea comes from Dr. Goldratt’s Theory of Constraints and his famous business novel “The Goal” - which I invite everyone to read because it is really the basis of the Theory of Constraints. It contains everything of the Theory of Constraints And, Yes!, Dr. Goldratt wrote many, many other books after that one, but they were almost just re-elaborations of the basic concepts that are there.
I always start my interviews and shows with the phrase “Hello, friends of Herbie!” But who as Herbie? Herbie was a boy scout. If you read “The Goal” you will learn that the the theory was discovered by this scout lead who was trying to get a team of scouts walking through the woods to the base camp, andwasn’t able to get there in time before the sunset. Sohe was trying to figure out how do we get there? and how to get there ontime?
One boy scout, Herbie, was the slowest. He was at the end at the end of the line. The lead shouted: “Herbie! Herbie, move on!” as he was trying to make Herbie walk faster and faster. It didn’t work.
Then he reflected. He stopped the whole team. He told all the others: “Now everyone stands and walks behind Herbie!” That was a great idea: at least no one would get lost in the woods!
But the walk was still too slow. They would not make it to base camp before sunset. So he got a second idea and said: ” Now everyone stop and let’s see what is in Herbie’s backpack!"
There were many many things. The lead invited the scouts to share the load. Of course, Herbie now having less to carry, became faster. With everyone behind him they finally made it to the base camp before sunset. So that is, in a nutshell, the origin of the Theory of Constraints."
Herbie is often referred to as the “weakest link” in a chain. You always want to work on the weakest link because, of course ,it does not make sense to strengthen the other links. The whole chain is only as strong as the weakest link. That’s how the Theory Constraints comes about.
“The Goal” was staged on on the manufacturing floor. Often there is this misconception that it’s about “the bottleneck on the factory floor.” First of all, it is not about bottleneck. It is about the “Constraint”. The Constraint is something very different from the bottleneck. It applies not only to the manufacturing floor. It applies to any goal-oriented human system. Now that is a very very broad definition.
Notice the the presence of “the goal.” We want people to be directed towards something together. In that system of human people moving together there will always be a “Herbie!”
Now whether that is on the manufacturing floor, or in a software development shop (where people are sitting at the keyboard and thinking, rather than moving widgets around machines on the factory floor), we still have this element of limitation of capacity. The Constraint on the manufacturing floor can be thought of as the bottleneck; but in more general terms, it is “whatever “is keeping you back from progressing more and faster towards your goal.
This is a very, very, very broad definition. We will get to the notion that, for instance, Management Attention can be the Constraint of the entire organization. Why? Well, because they [managers], just like Herbie, are overloaded! Their backpack is overwhelming with decisions that they have to make; their inboxes are overflowing; they cannot keep up! How can we offload that backpack, so that the right decisions are made, at the right time?
Another example could be the market: the market is the Constraint when it will not absorb more of what you have to sell. Another one could be the policies. Another one could be the pricing structure of your competitors!
The constraint can be many, many things. It is not about chasing bottlenecks. It is about thinking deeply of what is holding you back.
John – Thank you, Steve! I got into a bit of trouble talking about Herbie, believe it or not! I didn’t tell the story as well as you did, because I said we’re looking for Herbie! So people thought I was looking for the slowest person in the company! I [meant] systemic, what’s the slowest part, what’s slowing us down. That leads us on to another question: How do you even know where that Constraint is?
Steve – That’s the key question! But let me just add a few words there about Herbie! Recently I was in in touch with someone in USA. The issue was was raised that it might not be “politically correct,” so to say, in today’s world where it’s so easy to upset or offend someone, to speak about someone in terms of a “Herbie.”
I want people to reflect on the deeper meaning of this story. What we are really saying is that it doesn’t matter who Herbie is; because one day it is me, the next day it is you and the day after it is someone else. Anyone can be Herbie. There is no dishonor in being Herbie!
You know what they [the scouts] did? They all stood behind Herbie. Literally! And they all shared the load of Herbie!
So we leave no one behind alone in the woods. This is a message of togetherness! And we will share the load of whomever is the weakest in the organization. This is a message of solidarity!
I want this to be very clear, because if you’re looking at Herbie only as as a machine on the on the factory floor, then it is dehumanizing. The story of Herbie is is really a story of people, human beings!, that have a goal and want to get there together without losing anyone on the way. i think that’s that’s an important message to be told.
John – […] So in terms of um finding the constraint where would you start?
Steve – Let’s start with how this started. You know Dan Vacanti has a very interesting story to tell about how the Kanban Method came about. It started with with David Anderson applying the Theory of Constraints - or trying to apply the Theory of Constraints - in the world of software engineering. The idea was absolutely great; but it did not work out in practice.
From that failure, the team where he was working that included even Dan Vacanti and others, as an emergent practice Kanban [the Kanban Method] came about. It was not called “Kanban” at that time, but that’s how it it all happened. It is really interesting. It shows that even extremely experienced and smart people can be challenged in finding the Constraint in a setting of software engineering where we have VUCA (volatility, uncertainty, complexity and abiguity): the Constraint, the “Herbie,” is fleeing. You cannot really pinpoint it.
In fact when you start modeling your way of working with a Kanban board, without having the deeper thinking, what you will experience is that this Herbie is really jumping around all the time. One moment is here. The next one it is over there. And you don’t know where it will pop up next. It is like the famous whack-a-mole game. You will get a nervous breakdown before it’s over.
It is really, really challenging. The Kanban board is great to improve any pre-existing situation. But it also has an adverse effect, especially if you apply the conventional “Column WIP Limits”. It has the adverse effect of really masking out and hiding where the Herbie is.
We have first this problem to to resolve: where is the Herbie within a team, like the [team of] boy scouts walking through the woods. But it’s not the only thing that matters. If you have only one team, then - yes! - that is the problem. But how many companies today have only one team working on software. I think it’s probably just the startups that are starting up. Software is eating the world and everyone is getting more and more involved and engaged with software. Most businesses, even if they are doing other things, they become “software intensive” businesses. Like, for instance, the automobile sector. Nowadays cars are really computers on wheels.
When you start having two, three; tens; or hundreds of teams and thousands of individuals then that idea (of finding the Herbie in one Kanban board) is no longer sufficient. You need to figure out how the work flows through the entire organization.
There is a lot of talk, nowadays, about Value Streams and Value Stream Mapping. That is a very important step but it’s not sufficient. You should really start modeling the system in terms of Value Networks, with connections in in all sorts of directions between the different teams.
When that happens, then you have another problem which I [represent with] this um metaphor: The Jungle, The Jeep and The Journey.
All these teams can be considered as different jeeps that are going towards a common destination, traversing the jungle. What is the jungle? It is the Work Load that is coming towards all the teams.
You will always find some team that will get more Work Load than others. It could even be, and often it is, your star team; the one that, if taken alone, would outrun all others. But because they have so much work to do - in other words the path through the jungle that they are traversing is maybe the longest or the hardest because of the climbs are more demanding - well even that teamk that theoretically could be the strongest, becomes the Herbie! Not because they are weak, but because of their load, their backpack is much greater than all others.
So we have this distinction. The Herbie on the Kanban board, inside a team, is the Constraint in the Work Process. The one team that is facing the highest load is the Constraint in the Work Flow.
But this is still not enough. Why? Well, if you have ever looked at a Kanban board, you know that things happen from day to day. That is even more true in a multi-team situation. So which team is the most challenged right now?
Yes! We might have identified this very strong team that is traversing the longest path with the hardest climbs and and therefore is Herbie within this collective movement of all teams towards the goal. But then it might so happen that [for] some other team, which was trotting along happily through a very easy non-challenging path, Mr. Murphy comes along. An accident happens. All of a sudden that becomes the team that keeps back everyone else. That team becomes the what I call the Constraint in the Work Execution.
With these three concepts - the Constraint in the Work Process, the Constraint in the Work Flow and the Constraint in the Work Execution - we have all elements to manage even enormous arrangements of teams and Work Load. Just to give you a sense: the case that is my star case was managing 4,000 engineers across 120 teams with a monthly Work Load of 70,000 change requests. Now where was Herbie in that context? I found it and resolved the situation.
John – The first time I came across the need for something that dealt with a Constraint in Knowledge-Work was when I was giving training, only three years ago. I was giving Kanban training. In all sorts of agility training we teach that utilization is not so good; the utilization of people is not so good. We want to optimize for flow, but if you have a Constraint you could starve the whole system if you don’t utilize it.
So that’s where I see TameFlow adding a lot of value. If you do have a Constraint in your Knowledge-Work and you just use one ofvanilla Kanban or scrum or pick your method whatever; and you’re not really paying attention to the nuances of the _Constraint, you could end up in a lot of trouble.
Some people would say, you know, the devil’s advocate would say: well can’t we just move the people around? Because they’re people, so we can just move them around if there’s a Constraint. Just moving from one team to another team. Do you hear that kind of comment? How do you deal with that?
Steve – There are many things to unravel here. First of all the notion of of a Constraint in the classical project management terminology, which maybe is (I’m perfectly aware of this) not a nice one, but the concept is important: a Constraint is always a Resource: it is some thing or some one that is executing work. We we must keep that in mind.
Then the first thing to keep in mind in answering that question - about moving people around - is, guess what!? - the story of Herbie. What happened? All people came together when the team lead stopped the team. They all came together around Herbie.
This is something I know you teach in Kanban: when something gets stuck, you try to get people to swarm. I teach the same thing but it comes from this Constraint perspective. Where should you swarm? Not on any ticket that gets stuck! You should swarm on the resource, the Herbie that has trouble and problems. So, yes!, you in the Theory of Constraints you do move people around. You always try to help Herbie!
What you said as an introduction to the question: if you don’t know where the Herbie is, the risk is really that you will be canceling all the advantages you have with Kanban because at the end of the day you will still be clogging up the system, the individual teams might be ticking along as a Swiss clockwork, but the Herbie team will just get more and more and more work piling up in front; and you might not even realize it. I have an example in the book where the apparent Herbie team is not the [actual] Herbie team at all. Even when you analyze the situation, you would be misled if you are using say conventional Kanban [boards with] Column WIP Limits.
Now, moving people around is also a double-edged sword! Why? We know that in Knowledge-Work which by definition it’s based on knowledge, you have to “know your stuff!” Who typically becomes Herbie? Well, those people who know the most! Why? Because their knowledge is in the highest demand. So your “super engineers,” your “alpha programmers” or whatever explicative we want to use, become the the Constraint! And if they are the most knowledgeable, it might be difficult to find others who can offload their work. So you must try to figure out ways to offload any non-essential work, so that others can do that.
And, yes!, I am perfectly aware that in the Agile and Kanban narrative we have the notion of T-Shaped People. I think that T-Shaped People are highly counterproductive! Why? Because - believe it or not - it is a manufacturing concept that has nothing to do with Knowledge-Work. The T-Shape Person comes from Taiichi Ohno’s “U-Shaped” workstation, where any operator was required to at least know what the machine on the right and the machine on the left were doing, so that if something happened on those machines, they could step in and replace the neighboring operator. Now that is all very linear, sequential and easily codified operational work. Creating T-Shaped People on the factory floor is easy. It is just a matter of instructions and training. But in Knowledge-Work you can’t get there! The skills needed by these software engineers are just too diverse. Even the famous “Full-Stack Coder” is more of an illusion than a reality. Yes! Of course! You will always have some super brilliant individual that that has it all; but on the larger scene, that kind of eclectic knowledge does not exist.
So what do you do about it? Well you manage the Constraint! You structure your company as a set of highly skilled people: get the best you can find on any task or capability or skill! And - of course! - you will have a Constraint; but that’s normal.
A Constraint will always be there. You cannot avoid it. So instead of trying to work around the Constraint, learn how to manage the Constraint.
And, by the way, if you know how to manage the Constraint, you will also strive - believe it or not - to keep it there. Now, I know the warning in the Five Focusing Steps, at the end, is to beware that the Constraint might move, if you are elevating it. Then you have to start the cycle all over again.
If you manage the Constraint you will strive not to move the Constraint. Why? Because then you have a way to “control” the elevation of all others [non-Constraints]; and they can go just one step ahead [of Herbie], all the time.
Why is this so important? Let’s go back to some fundamentals of Kanban and Little’s Law. You know: Little’s Law is absolutely critical if you really want to push the the pedal to the metal. One assumption, that Dan Vacanti teaches (or should we say preachers! because he’s is very adamant about this! :) is the notion of Stability.
You want to keep the system stable because otherwise your two lines on the Cumulative Flow Diagram will not be parallel. If the Constraint keeps on moving, you are introducing instability. So you want the Constraint to stay in place, because that gives you the stability. And that gives you the predictability; and a way to systematically improve overall performance.
John – We’re going to go to some questions. […] Mike Levings: pricing, i assume it’s your own pricing, and not your competitor’s pricing as there’s very little you can do directly about your competitor’s pricing.
Steve – No! Your competitor’s pricing can be your Constraint! But this is a long long conversation!
John – Yeah maybe another episode! Okay, thank you Mike for that question. [..] Matthew Ijogi has a question: How do you rate behavior Mental Models as a Constraint? Decision making, non-localized, not based on evidence etc., so how do you figure that out?
Steve –If we are moving from from the Theory of Constratins to the TameFlow Approach, then that is really my thesis: that the ultimate Constraint is in the Mental Models. It is not even management attention as often is the conclusion with TOC. It’s really the Mental Models.
The idea is that it’s not only the Mental Models of the decision makers, the top managers; but really the Mental Models that are shared across the entire organizations. These lots of implications in terms of organizational culture; in terms of all being on the same page; in terms of avoiding unnecessary conflict.
Now I often get the objection that we want diversity of thinking, and we want to avoid “groupthink.” This this has nothing to do with that or that sort of dysfunction. In fact, one of the big teachings of TOC is that when you have a conflicting view but you share a common goal - []in other words there is] the assumption that if you are together in a company, we can assume or we should assume that we are walking or heading towards a common goal - then those conflicts become opportunities for learning! Why? Because those conflicts are really just hiding the other conflicting parties’ assumptions that they have.
The Theory of Constraints is not only about chasing the bottleneck and it is not only about the Constraint. There is a whole body of knowledge that goes under the name of the Logical Thinking Processes where the application of logic is used (mostly) to resolve these conflicts.
In most companies there is an inordinate amount of energy being spent in in-fights, where people are fighting one another inside the company. But why? Because they belong to different silos; they have to fight for the budget; they have different KPIs; they never agree on anything. Now what about if all that energy could be directed towards making your customer happier instead of trying to win the battle of the day so? That’s what we are trying to achieve with the TameFlow Approach. The _Mental Models play this role: to make all players understand that t’s really a team sports!
But we must, first of all, play the same game! Otherwise if I play football and someone else plays, I don’t know, volleyball… it’s still a ball, it’s still software engineering so to say, still making money for the business… but we are not agreeing on the rules of the game. The “rules of the game” are the Mental Models. That’s where I see that this is, absolutely, the greatest Constraint for improvement. In general terms: fix your Mental Models and the operational improvements, the financial improvements, will come by themselves.
John – Thank you very much, Steve. […] I was wondering if we would get a reaction to the to the “T-Shapes”… and we did! Eric Laramée [comments]: “So as a competent Java developer I can’t write documentation? I can’t write and run tests? I can’t contribute to the UI?” Yeah! Eric is upset!
Steve – I’m sorry to have upset you, Eric! But, you know: I think i can make you happier as well. So let’s maybe go back to the the origin of my story. I’m not going to repeat that again; but you know I was with Borland in the late 80s and 90s. The work that was done there was also highly inspiring for a scrum. That inspiration came through the work of uh James Coplien, and resulted in his book Organizational Patterns of Agile Software Development. “Organizational Patterns” is the key word here.
Borland was embodying a number of [organizational ]design patterns. One is particularly relevant to exactly this question. Borland had an entire department who was dedicated to writing documentation. Mind you not only user documentation, but internal technical documentation. What was the reasoning? Well, a skilled engineer - whether it was in C, Assembly or nowadays Java, Closure or whatever - shouldn’t really waste time in writing, when there are so many people who can write, and they just need some guidance and instructions. Then you can review what they have written.
It’s exactly the concept of trying to get Herbie to be dedicated to what only Herbie can to do. It’s not that you “cannot” write documentation, you “cannot” do this and do that. It’s about: what can you do that is most effective, if you are the Constraint! That is the key point.
John – So, okay! You wouldn’t be objecting to people being multi-skilled in areas other than the Constraint. But at the Constraint, if we really want to manage that well, we need to make sure that people are doing what they’re good at, is where you are going?
Steve – Well it’s not an objection to the multiplicity of skills, by all means! It’s all that it’s all adding up, and you might need to step in when someone gets sick or there are other urgent problems. It is more the notion that, as a strategy, rather than seeking out to create many multi-skilled people, it’s far more effective and you get far better results if you strive to get a number of highly specialized people. If you are concerned about redundancy, well get two of them instead of one - but get them really skilled on on what what needs to be done. Then, because you are focusing on specialization, the impact of Constraints Management will have even a greater leverage point.
That’s why the performance can become so much better. You know! if you have been developing software at any time, you know how it is f you keep on working in a certain environment. You start learning by heart, in your head, all the the deep data structures, the logic, the the libraries and everything that gives you a huge edge over someone who might not be as skilled as you are in that environment.
That’s where you really find these 10x differences. No that is also a myth that some developers are 10 times more productive than others. Well if all things are equal they are not; but the fact is that rarely are all things equal. You will have 10x factors if you have had the opportunity for someone to become a super specialist. It’s the same in the real world. You have these athletes that run 100 meters in less than 10 seconds. Why? Well because they keep on doing it all day long, training and training and training. So they get very good. If we were have to have “T-Shaped Athletes,” well well then I could be an athlete, but I would not do the run in 10 seconds.
John –Eric made a comment as well, quoting William Schneider saying: “So feed a culture of competence versus collaboration.” My own immediate reaction is that I’m not sure if it’s a “versus,” it’s “both”.
Steve - It’s not “versus.” It is competency “with” collaboration. And it is reinforced - again - in the story of Herbie, in that swarming. The swarming is the collaboration; and the sharing of the Work Load is the collaboration.
The example I gave with Borland having a documentation department, was really about offloading the task of writing technical documentation from the engineering side. Of course the ideas of the engineers had to be transferred to the heads and minds of the writers. So there were heavy sessions of knowledge transfer, guidance and then of review. Again, knowledge work is really teamwork, even more so when you have specialist, and you apply this notion that you want to offload a lot of stuff from them. If you offload, then the stuff that gets offloaded still needs to have integrity with what they are doing; so the ideas that are in their heads must be moved over to the other helper roles. Collaboration is necessary in today’s Knowledge-Work.