On February 16th, 2021, Steve Tendon was interviewed by Jay Hrsco, Scott Wagner and Benjaming Auyeung of the Agile Uprising podcast, which was published on June 13, 2021. What follows is the edited transcript.
Jay – This episode was recorded quite a bit ago prior to a major revision to Steve Tendon’s book so if you are looking for the book that is being discussed in this week’s episode please go to https://leanpub.com/tameflow to find The Book of TameFlow by Steve Tendon.
Steve – Hello everyone! I’m happy to be here on the Agile podcast podcast. I was invited to talk about my [book] and about the TameFlow Approach in general.
Jay – […] for this episode we are going to be talking about, probably, the book that made me take more notes -we were talking about it before we started recording - this book has made me take more notes than Dan Vacanti’s “Actionable Agile Metrics”. It was really one of those mind awakening experiences. We’re going to talk about [The Book of TameFlow] and joining is the creator of TameFlow himself: Steve Tendon. Steve, thank you so much for joining us!
Steve – It’s a great great pleasure to to be here. I’m really glad you invited me. I’m looking forward to have this conversation and your questions!
Jay – we got we got plenty for you, Steve. Before we dive into the questions, for listeners who may not be familiar with you or your work, can you give us a little bit of an intro, a bio about um about what you do; and then you can start talking about the genesis of TameFlow, and we can run from there.
Steve – That’s a long story. I’ll try to make it short. In the previous millennium, I was a software engineer. That’s like the the stone age of this field. I started off in the late 80s, early 90s; with the legendary Borland company, the makers of Turbo Pascal, Turbo C and and all those products. That experience shaped a lot of what we today see in TameFlow.
The story is that ATT was interested in finding ways of developing software quicker and better. They tasked Jim Coplien to do a cross-industry study. He came across Borland and found that Borland was off the charts in any way you tried to measure the company.
Now this is interesting because the way he approached this was quite unconventional. It was not like a process engineer, which you would expect from ATT labs but. It was more from a point of view of a sociologist, an anthropologist, a psychologist. He used new ways to investigate what made a good company. There were two things that came out of this.
One was a paper about the Borland Quattro Pro for Windows case. I mention this because it was highly influential on Jeff Sutherland and his making of Scrum. So I could say that TameFlow has some common heritage with Scrum due to that study.
The other big thing that came out of Jim’s work, was the notion of organizational design patterns. Jim is a great scholar of Patterns and Pattern Theory. He applied it to describing and designing organizations - in particular organizations that engage in software development and software engineering. I picked that up. I was fascinated by those thoughts and made the “pattern thinking” the centerpiece of TameFlow.
Now fast forward like 25 years and more, finally in 2013/2014 I decided to give a name to the way I was working. It became “Tame the Flow”, or - for short - “TameFlow.”
Why “TameFlow”? Because I “tame” four flows: the Operational Flow that most people are familiar with; the Financial Flow about how companies make money; the Flow of Information like the feedback loops that we are so familiar with in Agile; and last but not least the most difficult flow of all which is Psychological Flow the one that that American-Hungarian psychologist Mihaly Csikszentmihalyi studied. He said [psychological] flow is the basis for for happiness and optimal experience.
So i want to bring people and companies, teams, entire organizations to that optimal experience; where they are happy at work; they are hyper performing; and the business results just come out of that. So that’s what I think I’m here for: to make people happy!
Jay – […] Ben we were talking before you joined, this was one of those “fear of missing out” events where you peer pressured Scott and I! Ben picked it up and said it’s great you guys got to read it. So I picked it up. Scott picked it up. We blasted through it. It goes without saying that almost everybody has read “The Goal” right, Dr. Eliyahu Goldratt’s work on Theory of Constraints. It almost creates like a cognitive distance of: “okay that’s manufacturing how does Theory of Constraints work in a knowledge-work situation?”
And Steve presents a way that he not only makes it work! It seems to the point where he explains in a way that you stop and you go well duh why am I doing other things and not not doing this!? But we’re not going to drain the book.
I do want to kick off with Ben: you had a couple of good questions.[…]
Ben – All right. I’ve got some harder questions that’ll hopefully lead to some good discussion. But i want to start off more generally, with the um subtitle the book is “How Dr. Goldratt of ‘The Goal’ would apply the Theory of Constraints to Rethink Knowledge-Work Management.” Which is actually quite unorthodox when you consider the way that most people think nowadays. Most people probably think Theory of Constraints does not apply to knowledge-work. So what are they missing? How come it does work for knowledge-work? And why are we all misled to thinking that it doesn’t and it’s only good for things like manufacturing?
Steve – That’s a great question. The answer to that question took the best of the last 10 or 12 years of my life to pinpoint. The result is there in the book!
So why do we have this mismatch perception?
Because, obviously, how dr Godratt his theory with “The Goal”: it was in a manufacturing situation. But we must not forget that the Theory of Constraints (notwithstanding what I have been adding, and we’ll get to that in a moment because that is the answer to your question); we must not forget that the Theory of Constraints is a huge body of knowledge.
Most people read “The Goal” and say: “Oh, yeah! it’s about finding the bottleneck!” - not the Constraint, but the bottleneck. Shrug of shoulders: “Yeah! We can do that! We do it all the time!” Especially if you are in software, you know you have to find the “inner loop” and what keeps you back the most. But it’s not that simple because the Theory of Constraints has evolved a lot since those times. It has been applied not only to manufacturing, but also to project management, to distribution, to sales, to health care, to all sorts of situations.
The thing that allowed Goldratt and other practitioners of the Theory of Constraints to extend its reach beyond the manufacturing floor is that part which most people do not know about the Theoriy of Constraints and which goes under the name of the Logical Thinking Processes, where you apply logical thinking to whatever you’re trying to resolve. If you are aiming to reach a goal, by definition, by logic, there must be something that holds you back. So you want to apply the thinking, the logic to find what holds you back.
It is from there that I started. Now it just makes sense. The counter argument there is: if there were not a Constraint, well your productivity would be infinite because nothing is holding you back! But obviously something is holding you back. We just need to be able to think and identify what it is that holds us back.
The step from the manufacturing floor to knowledge-work is quite a tricky one. Why? Because we have precedents that have failed.
David Anderson started off by writing a book on software and the Theory of Constraints. It was the book that introduced me to the Theory of Constraints.
I was fascinated by this theory. Do you know why? Because - remember what i said, that my work is based on patterns. In TameFlow I have come to define three foundational patterns. One of these foundational patterns is Unity of Purpose. Why is this so significant? Because if you have a bottleneck, a Constraint, a single focusing point, then you can get all people to gang up around that point. It’s like the swarming idea we have often in Scrum and Agile: all are there, looking at that single problem.
David Anderson eventually introduced the Kanban Method. If you’ve seen the latest broadcasts Dan Vacanti, he even tells the story how that happened. Long story short: trying to apply the Theory of Constraints in a knowledge-work setting, with the manufacturing mindset, is a recipe for failure. In fact out of that came Kanban - the Kanban Method; not the kanban of Taiichi Ohno (and that history goes back even further). I is not the Kanban of the Toyota Production System or Lean. It is the Kanban Method that we have in software, with the kanban boards and so on.
The error that most people do is believing that you will find the constraint by looking at the pile ups in the columns. That is not the case. That is very misleading; and it becomes even um a self-fulfilling prophecy that you cannot find the constraint! Because: how do you try to to cope with the situation? You introduce Column WIP Limits; but Column WIP Limits will just make the situation worse. One moment it’s one column that gives you a signal; the next moment it’s the next column; and you are really under the impression that the Constraint (or the bottleneck) is just jumping around in madness. There is no way to pinpoint it; and remember: step one of the Teory of Constraints is to find or identify the Constraint. If this constraint keeps on moving there’s no point! You don’t get a fixed point where to focus!
Jay – Not to cut you off, but that was the mind-blowing quote that I dropped in a meeting of a bunch of coaches, where we were talking about this directly. Ben and Scott were both on the call where I said: you know one of the things I took out of this book was when you put on Column WIP Limits you hide the Constraint; you allow it to move; and you don’t really see where it is. And you literally saw certain people just sit back in the chair and their head just like exploded! Because - to your point - WIP Limits have been beaten in our head for so long that the idea of taking them off to really see the system as it is, was completely foreign. And these are people who were experienced and know what they’re talking about. […] Scott, what’s your question?
Scott – I’m actually going to do the compliment sandwich. My question’s going to sound negative, but it’s not in the least. I love the book; I love the content; but I always go to the people part. So when we’re establishing Mental Models I’m just wondering if you’ve found this harder to actually pull into reality, than the book sometimes portrays? And what I would say to that, is I also - when we got to the end and we hit the patterns section, i just love the section so it kind of gave me some faith that this is true - but I wanted to hear it from you.
Steve – Wonderful question. I don’t think it’s negative. I think it invites deeper reflection. The starting point: TameFlow is based on four flows, but the book is primarily on Operational Flow. Why? Because that’s where people feel the most problems. That’s what they can relate to. If you start doing a few things, like low hanging fruits, like improving Flow Efficiency, you have better chances of actually getting traction and people trying out things.
On the psychological side, one pattern that I always relate to is what I call the Enlightened Self-Interest (ESI) pattern. With TameFlow I wholeheartedly invite people to be absolutely selfish; to think only about themselves! Now this might not sound quite politically correct, because we should be caring and taking care of one another. But the point is: unless my needs are met, my own personal needs are met, then I and you will have to reach a compromise. A compromise always means that nobody is really happy. We are just making half wins.
The premise here is we want everyone in the company to have their own personal individual needs met first! Start with that in mind and then relate that to the Mental Models that you have discovered reading the book. Start to compare those Mental Models to what might be your own personal needs.
The classical one, that I always mention, is how you value time. Your time is the most precious thing you have in life, in this existence we have on planet Earth. And you don’t want to waste your time in stressful jobs; where you might always be fire fighting; where you are always doing over time; and you don’t even have have the time to read good books like [The Book of TameFlow]]! You’re you’re always under pressure. Now imagine that if you apply these Mental Models one thing that comes out, is that in order to perform only Herbie, the Constraint has to work at maximum capacity. All others have to stand still. So they have time on their hand to do other things! I often say, if you have nothing to do, don’t do anything! Go fishing! Go have fun! But don’t create more chaos than we already have. It is only Herbie that has to ork to the maximum.
Okay! Maybe that’s an extreme; but you see that applying that Mental Model that if you’re not Herbie you’ll say “Aha! I see! I could have time and I could use it for something else!” - that is my interest. It is the “Aha!” moment that is the “enlightening” you see through the Mental Model. You see how it relates to your own interest - and that’s where you get the buy-in. TameFlow is structured on this mechanism at all levels, from the CEO to the junior hire.
The other thing about these Mental Models is that we want them to be really a few, only a handful, and have them shared across the entire organization. Therefore we don’t have the problems that maybe Scrum has that you need to scale; or that the agilists have that oh the agile mindset has to be “adopted” and all those top managers they just don’t get it. Well you’re starting from the wrong end. You must start from the self-interest, the “what’s in it for me” of all the people in the organization, and find ways to make them pull in the same direction; but you will not do that with any of the Agile approaches; you will not do it with traditional project management; you will not do it even with um with a management theories. The things that get closest are maybe things like holacracy; maybe things like uh team science where you study more how people actually work together. So sociology and anthropology will give you the replies.
TameFlow brings all of this together with a handful of Mental Models, where you, on the ground, might see that “Oh, yeah! I get more time for me. I can study the good stuff. I can help Herbie!” And and the CEO will say: “Wow! now our business performance will improve dramatically!” Many of the things you gain business-wise with TameFlow are not in need of investment; or restructuring; or training.
It’s just about making decisions differently. Why? Because you’re enlightened by a new Mental Model and you see reality differently.
Jay – I love your usage of the term “enlightened,” because there’s an old saying, I forgot who said it, that altruism doesn’t work but enlightened rational self-interest does. There’s definitely something at play there. We’re getting people to change their minds, to look about things differently. There was a lot to unpack in that remark. I mean you even touched on the idea of low-hanging fruit, and how reducing wasted wait time, I think the term you use in the book is: it’s not work faster as much as it’s delivered sooner. And the way is smart like you said. It doesn’t require any capital investment to take a step back to look at your process, figure out where your wait times are and then look to decrease those.
Steve – Not only is it very easy to do. The the main thing is that by chasing Wait Times (and of course there are limits to how much you can do that, but you have lots to gain), by definition the Touch Time doesn’t change! That means that your way of working does not change at all. So if things don’t change, there is a small risk of failure. Why do all the Agile transformations; the business process improvement; initiatives here initiatives there; why do they mostly fail? One because they aim at improving on the Touch Time and in doing so they incur in a lot of risk; so it is very easy to fail. But even if they are successful, the problem is that the Touch Time they “touch” - pardon the play on word! - is mostly the Touch Time of the non-Herbies. We know that that - from the Theory of Constraints - does not add anything at all. So that is my explanation why all of these initiatives are just so wasteful.
And what happens then? People get burned out. There is like “change fatigue.” They don’t want to see another consultant, and another method, and… Oh no! Here we go again! […]
Ben – I wanted to ask about a sentiment that’s brought up a few times in Reinertsen’s “Flow” book, because he makes quite a distinct point about differentiating, I don’t know if he uses the word “knowledge-work,” but he always talks about stochastic processes and how the Theory of Constraints, he claims, does not work for them; because the bottlenecks and Constraints move. So he basically makes the case for local Kanban signals that radiate upstream, rather than subordinating the entire system to the Constraint, because by time work flows to the Constraint, it may have moved.
The way that you’ve constructed TameFlow, I believe, addresses this particular concern. Could you explain that a little bit? And the alternative point of view from saying that what Reinertsen is saying that Theory of Constraints does not apply to stochastic processes?
Steve – First of all, I love Reinertsen’s work. It is absolutely fantastic. Though, yes!, he has a few misconceptions about the Theory of Constraints and that’s probably the only flaw of his work.
First applying deterministic methods in a stochastic context is a recipe for for failure. That’s why chasing the Constraint on a Kanban board will inevitably fail, because you’re looking at at the “pile ups,” that then just keep on changing and changing. So in that sense, the observation is correct.
But that is not the way you should identify the Constraint in a stochastic context. In a stochastic context you should identify the constraint with stochastics methods. And, in fact, what do I do? What is the main breakthrough in looking for the Constraint on a Kanban board? Well I look at the Flow Time Distribution across the board. (Many will talk about “Cycle Time” or “Lead Time.” I call it Flow Time, because that was the original term that Dr. Little of Little’s Law used.)
Not only do I look at the Flow Time Distribution across the entire board, but also at the Flow Time Distribution “in state.” So in the single column: what are the Flow Time Distributions?
Of course, being a distribution, you can find an average. These averages have long term stability, especially if you start limiting Work in Process, and you get to a stable state like Dan Vacanti teaches. You want the the demand line to be parallel to the delivery line, so you have your CFD (your _Cumulative Flow Diagram) is nice and smooth and parallel.
Well, in those conditions, the the Average In-State Flow Times, are very, very stable. So it’s easy, easy, easy to find the Constraint: you pick the column that has the longest Average Flow Time. And it is around that column that you build all the thinking of Dr. Goldratt.
Now mind you mind you: in complex knowledge work, where you have multiple teams and you have unknown work coming at you, that’s not the only way to find the Constraint. In fact in TameFlow I call that the Constraint in the Work Process. The Kanban board is a work process.
But we also look at the Constraint in the Work Flow which is the work coming towards you, that can change from day to day. One day it’s nothing; next day it’s a huge pile.
Then we must also account for […] Mr. Murphy. Mr. Murphy will visit your teams and know your top performing team, from one day to the next, might just be at a standstill. So we must have a dynamic view of finding where the Constraint is at that moment; and that is the Constraint in the Work Execution. […]
Scott – From the point of cue signals, and just wondering your take, and what you’ve seen, your experience around overhead in this area. Because that tends to be the first place people go, when we think fast we don’t think add we think remove! Have you seen that overhead? and what has your experience been?
Steve – Do you mean overhead in terms of resourcing, of people head count?
Scott – Yeah because that to me adds that middle layer, and we’re trying to really let let the flow happen, whereas this to me is top level.
Steve – There are many, many dimensions to this question first. Within the team, the moment you identify a Constraint - it could be a group within the team, say developers; or if you have multiple teams, it could be a specific team - you are in the situation where if you apply the thinking of Lean, you might be tempted to do the wrong thing. Lean, in the pursuit of taking away waste, will say: _“Okay! Herbie can only walk at five kilometers per hour. That’s still quite fast; but if the guy in front and the guy after can walk faster, then there is stuff [capacity] in excess!”
Now if they get the point that they must not walk faster than Herbie, they will want to eliminate all the capacity that is in excess. It is a Cost Accounting exercise: you want to take away the stuff that you don’t need.
But that is a huge error because the point of keeping the whole system at the capacity of Herbie is guaranteed only if the Non-Constraints have Protective Capacity, and even more Excess Capacity.
So you should not be cutting heads in the name of becoming Lean. That is a major, major error. The Protective and Excess Capacity [that you have] you should use for other purposes, which could also be of strategic nature.
The other point which maybe is connected to this, and which relates more to the narratives that we have in Agile is: now, what do we do with all these mid managers? They are absolutely useless! They just warm their chairs; and give orders. It’s that narrative! Unfortunately it is about the anti-management sentiment that has developed in the Agile space.
You all know the story of Herbie, and how it goes - and I won’t repeat it.
Instead of explaining the Five Focusing Steps, which was the original purpose of that story, I look at it from another perspective. The essence of the story of Herbie is that, even if Herbie is the slowest guy, is overweight, has problems with his shoesk and whatever… We leave no man behind! We don’t leave anybody behind in the woods!
So if in an organization we see that some roles, like mid-managers, are becoming less incisive because the organization is getting better, and faster, and slimmer because we’re doing all the things we’re saying in the book; we don’t fire them! We find a way to value what they know, and maybe retrain or repurpose, but do not leave anyone behind! We will maybe take that as a golden opportunity that we have “resources available, that could do other things and stuff!
Scott – Yeah! I like it! So I guess I’ll make a jump, and this will bring us full circle, right back to where we’re standing. In the beginning you talked about work flow which to me is kind of like the opposite of Covey… he wants to go to the end; we’re talking to start in the beginning, right, and understand the people and start there. With DBR Scheduling, you have a piece in here that mentions that in most companies there’s simply not sufficient stability to manage cues in this fashion. So i’m trying to understand that piece, as well as reading end to end, how much this works from a tooling perspective? How do those two not conflict with each other? […] It basically says it takes deliberate top-down decision to adopt DBR Scheduling, it isabout metal models; and then there’s that last piece about how there is simply not sufficient stability to manage queues in this fashion in most companies. So saying that we really need to get to DBR before we put it in place!
Steve – Yeah! It is a chicken-and-egg problem. DBR Scheduling is really counter-intuitive. If you try to implement it by yourself in your little team, and maybe you’re in a large corporation with many teams, you will not gain a lot out of it. What often happens is that your team will improve so much, that it will stand out. It will stand out so much, that the surrounding context - the other teams, the other managers - might start deliberately sabotaging! Why? Because you make them “look bad.” You know how it works in silos: you have KPIs, and all of a sudden there is an imbalance there. That’s something to consider!
The only way DBR Scheduling can work is if it is put in relation to the Enlightened Self-Interest of the CEOs, where they might really understand that by exercising these decisions about when to start and stop work in a different manner, the company will “make more money” - which is their mission. You get to those positions because you have to make more money. At that point, you have the preconditions for this to to happen. The top will want this to happen.
You mentioned the patterns at the end of the book. One pattern to get started is quite different from what you would do, let’s say in Scrum, where you start with a team; and then you “scale” upward. Or in Lean, where you do a “big bang:” change everything, everywhere at the same time, which is very much top down. What I suggest in TameFlow is that you focus on a slice; […] you want to to exercise the whole stack of your “application.” Thus you start with a team and you go through all the managers, from that team, up to the top. And you get all of them involved. So it’s like a vertical slice of the organization. That’s where TameFlow starts and when the top manager sees the impact of working that way, well then it can fan out horizontally and arrive at the at the other uh units and teams.
But there is still one point: stability. It is also one of the key points of Godratt, who noticed there is this tension in the company between “growth” and and “stability.” Unless you have a stable situation, you will not be able to [gather] the the metrics to find the Constraint. What I mentioned before! Remember I said that we need the Cumulative Flow Diagrams to be nice and and parallel? That is a sign of stability. Which [requires to] limit the Work in Process. There you have the circle of the chicken-and-egg. You have to be good at that.
Jay – One of the things you touched on, which I think we could do an entire episode on, is the idea of Throughput Accounting. Where do I invest my money? This was another one of those! like Ben does the exploding brain emoji! Right this is another one of those things that made my brain reset. It is when you remark in the book that any money not invested in the Constraint is basically money waste; you’re throwing money down a hole, right? That’s any money not invested in optimizing the Constraint, right? Which ties to the idea of Throughput Accounting. I’m sure every single person has been in an organization where they spend an outsized amount of time trying to figure out the budget for next year, and the allocations. It’s painful and brutal. You know! We try to do some voodoo-chicken waiting to figure out how much money we’re going to spend! So let me ask you this, Steve: in regards to the practice of Throughput Accounting, looking at your Throughput versus your Operational Expense versus your Investment, why does it seem that this is such a hard concept to grasp for a lot of organizations? I’m under the assumption that they teach this in MBA courses, but then it gets ost by the wayside, when people come out of their MBA school and then it’s cost accounting - the one methodology to rule them all. Why do you think Throughput Accounting runs into that lack of adoption?
Steve – First of all they do not teach this stuff in the MBA courses. That’s a huge gap. It’s pretty much a Mental Model gap. They don’t teach it in accounting schools, not in MBAs, almost nowhere. Of course it is always perceived as as an esoteric “voodoo practice,” as you as you mentioned. […]
If a conventional cost accountant is to make a management decision, with the tools they are equipped with, they will almost always, invariably arrive at the complete opposite decision of Throughput Accounting. If you try to go through the steps, and “handhold” them, they will often jump to the conclusion that their choice is correct, that there is no need to further elaborate the case! But they are missing that if they just walk another three or four or five steps down that dark path that we just hinted at, they would find the pot of gold. It is like a self-fulfilling prophecy, they see their obvious conclusion before they have seen the whole story. And because they know the conclusion from their point of view ,they are not open to explore the rest.
That’s where we need to be very delicate in the way we present this this topic because it’s very easy to immediately provoke a rejection, a reaction like “No! this is not interesting!” The only way to do that, that I know of, is to do some some whiteboard exercises, and have the narrative of this is is what we want! We want the Unity of Purpose and how do we get there? We don’t want to have conflicts? but the primary financial exercise in companies is budgeting. What is budgeting? It’s warfare. It’s everyone against everyone, last man standing. Who gets the largest slice of the pie? And then you have all those games: not only is my budget larger than yours, but if I don’t spend all of my budget this year I would get less next year! And all these bad behaviors that are induced by the process.
So by starting from there, we might say: well if we just look at the numbers differently, we might create a situation where instead of having these infights, and instead of wasting our energy and and nervous stress fighting one another, we can put that energy in winning the markets. These are the arguments that you start bringing in, and maybe then people start to listen. “That would be nice but you know it’s impossible!” Well, let’s see. Let’s look at the numbers.
Then you start bringing in the numbers, and after a few exercises you come to the Throughput Accounting element. Then you have, again, the Enlightened Self-Interest: yes we do make more money!
Let’s do it! Why didn’t you do it before?!