TameFlow on the SPaMCast #599

Tom Cagley interviews Steve Tendon
25 minutes read

On May 10, 2020, Steve Tendon was interviewed by Tom Cagley, the host of the Software Process Improvement Measurement Cast.

Listen to the interview here:


Here is an edited transcript:

[01:25] Tom: Today we are living in interesting Times. How does the TameFlow Approach and the Theory of Constraints translate into real life in a scenario where people are social distancing and working remotely? Can we use these methods in remote circumstances?

Steve: What a question! Certainly it is a very relevant one. Yes, there are many things that come to mind thinking both about the Theory of Constraints and TameFlow. Of course with the Coronavirus we are facing a phenomenon that is on a exponential growth curve and we are having a constraint in the whole system which is the healthcare system which has a finite resource aspects: there are only so many respirators, so many many doctors, so many masks that need to be shared and used by all of us, sooner or later.

The Theory of Constraints gives us a way to reflect on these kinds of systems where you have only so many resources, and so much to do, and to handle. Of course it also gets down to some of the fundamental aspect that we keep on going back to in the practices of the Theory of Constraints and TameFlow, like prioritisation

It is a sad state of fact but when the situation goes off and the medical system has to switch to warfare practices. You get to the point where you have to triage the incoming patients and save the most healthy ones.

It is an extremely sad situation but it is still a rational choice. It is similar to what we would do in TameFow when examining the incoming work, and trying to figure out what is is the most important thing where to focus our attention

Another point, more related to the actual topic of TameFlow and software processes improvement is that while we are learning - or forced to learn - to work remotely, we are necessarily taken away from many of the conventional face-to-face meetings, events and ceremonies.

We know from the initial school of thought of Agile that face-to-face meetings are the most effective ones, where you have the highest degree of exchange of information and knowledge. So it would seem that by going remote you would be missing this. Though we must also say that with the advanced - and advancing - communication technologies, with video audio conference calls and shared real-time whiteboards, that distinction has almost disappeared.

[05:10] Remote working still poses this challenge: of psychologically being used to meeting people, and all of a sudden you are just staring at a screen. That might create some difficulties and challenges.

[05:33] One way is to become more focused on these shorter and less frequent meetings - because of course if you are remote you just do not bump into your colleagues when you go to the water cooler or get a coffee - is to become more focused and effective on the actual contents of the meeting.

05:56 For instance if you’re used to doing daily stand ups as you do in Scrum or in most of the Agile approaches, then the practices of TameFlow where the daily stand ups are not promoted - but instead you will call meetings on demand when you have execution signals - is certainly a practice that comes to greater fruition this new situation. You would be calling ad hoc meetings - realizing the paradigm of Management by Exception - only when there is a need, and the work is showing you that you need attention; and you also know why the meeting is me called and what you will be focusing on. This will also allows you to reduce the time that you dedicate to the actual meeting and therefore achieve the outcome of the meeting sooner rather than later . You would involve only the people that need to be involved and not have like freewheeling meetings where everyone is participating but looking at their Facebook streams during the meetings.

[07:20] Tom: That takes us to why all change is difficult. I think we’re all facing a very different world if we’re not used to working remotely. Thinking of all of those people that said: if you’re going to have remote teams or remote team members, you can’t do this or you can’t do that; and they are suddenly sending out newsletters or having webinars telling you exactly how to do that. It is interesting to know where their conversion came from overnight other than obviously a little bit of adversity definitely is the mother or father of invention. When we use things like signalling and the TameFlow Approache, what is the transition approach from leveraging what are more common methods today - things like scrum or other agile approaches - and either replacing them with TameFlow or layering TameFlow in? Is that a transition path that you’re seeing? And is that possible to do remotely?

[09:05] Steve: I think that there are several questions there!

Tom: Pick one!

Steve: OK! Before you actually started articulating the question you said something about change is difficult. I want to disagree with that because I think change is easy if you approach it from the right direction. This is peculiar to TameFlow, and it will also relate to what you are asking about transitioning towards something like TameFlow, or replacing what you’re doing with TameFlow, or layering what you are doing with TameFlow on top. Why? Because it is really different. It is not a framework; it is not a maturity model; it is not based on principles and values; it is not built on practices… So people ask me: “What the hell is it based on!?” Because it’s not this, and it’s not that, is it something?

[10:07] And yes it is something, because it’s based primarily on - and here I use a term I relate to, but it is not mine; I heard it recently and it resonated - Decision Science: that is, how you make decisions. The key point which renders any kind of transformation easy, is to put yourself, put your people, and put your organisation in a situation, in a mindset or mindframe of awareness about that there is a deep shared common interest. This goes back to Goldratt’s “The Goal” - we start from that. For Goldratt, the goal was: to make money today and in the future.

[10:54] Now people get upset when you start saying this, because of course to be dedicated to the “cause” of making money will just bring about bad things - as we have seen many many times. But it should not be interpreted in that way. To make money today and in the future just means to become aware that that social body of people collaborating and interacting under one brand, one company, must make money to survive. One exercise I do at the very beginning of any kind of TameFlow workshop, especially if we are with the C-level execs, is this: Guys raise your hand and keep your breath for as long as you can. Then lower your hand. Of course they will be disconcerted! What does this have to do with serious business?

[11:48] The point is that after a while - when you start to get blue in your face, you lower your hand and you have to breathe. Why? Because you need oxygen. That is the point! Companies need oxygen and that oxygen is money. They need to get that oxygen today and in the future. So there is a long-term perspective. It is not about the quarterly report that you must satisfy; those buying and speculating on stock prices. You must make money today and in the future. And if a company is not making money, then you won’t get your salary.

[12:22] There you have like the first point of convergence. The first element of something that if someone disagrees, you would seriously think that they have some perceptual problem, some awareness problem, that they are not really connected to reality. If they really hold the belief that they are outside of this system, then probably you do not want to have them in the company. It is tough; yet that’s the whole point of building a team. Any team from sports teams to others will have certain criteria by which team members are selected and elected. Now, if you can come to that point, that you agree on such a simple and fundamental thing, you have defined the goal in Goldratt’s terms. Goldratt teaches - this is not TameFlow, this is TOC - that if you have one goal, one common shared goal, then there is no conflict within the company that cannot be resolved. TOC goes to great depths in teaching how to use the Thinking Processes and many other very fancy things; but the bottom line of this is that if you start off with that common shared interests, then you will have this element of enlightened self-interest that will push everyone to do the best for themselves. But - and this is the key point - if the decisions they undertake to preserve their best self-interests are all aligned towards that single Goal, you see that they are all effectively - instead of only taking care of themselves - helping one another. So this is the sense when I often say - and you asked me also recently what is the one thing that characterize great teams - that it is the ability to clearly articulate - and have the courage to articulate - your own self-interest; and see how that self-interest is connected to, and is dependent on the success of the organisation you’re working in. That is the key to create the alignment between the decisions that individuals take in their daily work and what you want to achieve as an organisation. If you get to that point, then change is not difficult at all. It will happen by itself.

[15:04] Tom: Recently I have been struggling with the observation that many of the agile mindset kinds of ideas are at odds with the skills and capabilities and mindset required to climb the hierarchical corporate ladder. The idea of helping and maximizing at a team level is at odds with the need to be sharp elbowed and to sacrifice your neighbour so that you can get a head. Those two things don’t seem to work together. If we had this one shared goal, I think you’re right, it would be fundamentally a different conversation. We’re still struggling with that; and it’s been many years since Goldratt published ”The Goal”. So how does that one shared goal translate into how we apply the TameFlow Approach

[16:35] Steve: First of all I completely agree that there is a huge disconnect between conventional individual priorities; and elbowing; and running over one another is “business as usual” - it is what most corporations are. That is a state of fact. Likewise, the team-centred and soft-skills based actions of Agile coaches are another reality which has all reasons to exist because it creates much more healthy and humane environments. What I am claiming with TameFlow is that there is a third way. But how do you make that happen? Well it’s when you start talking with this C-level execs, VPs and managers who have certainly been conditioned during the whole of their career to just look at the bottom line and and reason in terms of getting the best return on the Investment; well that’s when you realised that these two camps are structurally unable to have a conversation on any topic because they are reasoning in different terms, they are using a different languages, they are using different mental models - so we get back to the core of TameFlow.

[18:13] The way I address this is simply to ask ”Dear CEO, do you agree that the goal is to make money today and in the future” and obviously they would say “Yes!” If they answer differently I will question why they are CEO. That’s really the key, because if you start from there you will be able to show that by applying Goldratt’s Throughput Accounting concepts rather than the prevalent Cost Accounting concepts, these CEOs will be able to make much more money. So, of course, you show that with numbers; and they will say: ”Well, this looks interesting - maybe it’s worth a try; because I will be making more money; the company will be making more money.” It is completely coherent and consistent with their overarching mental model of how you manage a company, how you drive a company. It’s easy to get that kind of attention, but of course they might be very skeptical about you being able to produce that kind of spectacular result well beyond what they are used to. Because when you flip over to TameFlow, we are not talking about the conventional 3-5% improvement on the bottom line which would be considered as a good result in almost any company; we are talking about breakthrough performance so you will often see double-digit percentage improvement and at times even even 2 or 3x of what you’re doing before. Goldrat has shown this many times with the Theory of Constraints.

Now, what is the point? It is that if you are able to flip over the management paradigm from Cost Accounting to Throughput Accounting, all of a sudden you are flipping over to a paradigm that is consistent and coherent with what is happening on - or what can happen - on the ground, on the field. That’s where we have the connection to the Operational Flow and the Financial Flow. Those two numeric representations of performance - in terms of Operational Throughput and Financial Throughput - actually drive the same kind of decisions.

The decisions that the CEO will make will be understood by those who are on the ground. This is a completely different situation than what you have normally because management decisions appear to be totally in contradiction with the everyday experience that people on the ground have. Likewise, if people on the ground take some decision to increase Operational Throughput that decision can be shown to actually have a positive impact on the Financial Throughput that is the driver of Throughput Accounting. While often that very same action would have a net negative impact in terms of Cost Accounting, and therefore it would be denied by top management.

In other words what is happening in the organisation between top management and people on the ground is that there is a latent, underlying, deeply rooted conflict between the needs of Cost Accounting and the actual needs of getting work done in the field. By switching over to Flow, Throughput Accounting, Operational Throughput, Financial Throughput, we are talking the language of Throughput throughout the entire organisation.

One benefit of this is that Throughput is numeric - and numbers are the language of top management. Hence top management can relate to that language much easier than - say - ”Hey we need to do story-point estimation, and have stand-ups and dailies!” and whatever else is in the folklore of Agile. All of which, from a top management perspective, really looks just like black magic… and they just have no choice but to believe that it all works. Then maybe it does or maybe it doesn’t - but typically it does not have a huge impact on the bottom line result. That is also another problem of all these Agile approaches: they promise so much! While they do indeed improve things on the ground and people are maybe more relaxed and happier, the company’s top-management does not see a return that is proportionate to the investment they put into this.

Going back to what you were saying: Yes! There are these two two souls in most organizations: management and people in the trenches. Yes! They are naturally in conflict and the root cause of this - for me, from the TameFlow perspective - is cost-based accounting accounting. If you’re able to flip over to Throughput Accounting with respect to the Goal, you are evaporating that conflict and you get everyone to… ”Live happily forever thereafter!”

[23:30] Tom: Steve you shed a tonne of light on what I would suggest is behaviour that is hard to phantom especially when you’re out trying to transform an organisation. How did you come to take the whole idea of Goldratt’s Theory of Constraints and Goldratt’s other thoughts and incorporate that into a different vision? How did you get there?

[24:17] Steve: That goes back to the Stone Age of this experience of mine. TameFlow got the name “TameFlow” several years after I was doing my kind of work. Originally it was not at all based on TOC. TOC came into focus several years later. As you probably know after reading the “Hyper-productive Knowledge Work Performance” book, my defining professional experience was with the extraordinary company that was known as the Borland International, between the mid 1980s’ and mid 1990s’ which was the golden period of Borland. Borland was relatively speaking a small company, it had like 3000 employees, but it was fighting head-to-head with Microsoft. The connection with what I was doing and how I got started at this, was that at that time James Coplien of AT&T was conducting a series of studies on high performing software organizations. Of course ATT, being a telecom company, was producing tonnes of software. One of their priorities was to be good at it.

Coplien studied a number of companies. No matter how he measured them this small company, Borland international, was a total outlier on the graphs. They were always out there “to the right and to the top” - but by leagues, not just by a few points. So it became a very interesting case to study.

[26:15] Coplien did something very unusual. I claim it was a genius stroke. He started studying these companies not from the perspective of a process engineer or a methodologist. His approach was completely different. He started studying these companies like a social anthropologist. He started to draw graphs like interaction diagrams and used other metrics that anthropologists and sociologists use all the time; and this in relation to the objective of developing software better and faster. As he was doing this, he documented one particular case at Borland. It was the Quattro Pro for Window team. It was a legendary team.

[27:16] By the way, the practices that Coplien found at Borland also inspired Jeff Sutherland to institute things like the Scrum Master role, the Product Owner role and the “Standup.” Those are the origins of these Scrum elements - you can check it up in the early writings of Jeff Sutherland or subsequent writings of Coplien. This may also make you smile, because it goes to show that TameFlow and Scrum share some common pedigree and genealogy. Though I am very fond of saying that Jeff Sutherland could only take stock of this indirectly through the writings of Coplien, while I was there! I was on the field and actually experienced how it was being at Borland. That’s also why I have a very critical interpretation of what Jeff Sutherland made out of it.

[28:13] Going back to the study of Coplien, what he did then was that he started documenting these findings in terms of “patterns.” If you are in software you should know about the ideas of Design Patterns as they typically apply to object oriented languages like C++ and Java. Coplien was indeed a very experienced software engineer, very much into C and C++. He wrote some fundamental papers about C++ and patterns.

[28:55] He took that pattern idea and started studying these companies in terms of Organisational Patterns. And that is really the start of TameFlow. I was reading Coplien’s papers just a few years after his study of the cases he was referring to - he presented his first paper in 1994, and Scrum came out officially in 1995. When I read those papers and started to become aware of Patterns I could immediately see how they reflected what had happened in Borland. I could relate to that as my career progressed in other places. I could relate that to what I was observing in these other places; and I always had this feeling of ”Oh boy! they are so slow here… how come they don’t get things done!?” because I was used to the high paced world of Borland.

[29:55] Jeff Sutherland himself noticed in some of his papers that one Borland software engineer was as “productive” as 50 Microsoft engineers at that time. You might debate how trustworthy such measurements might be, but it is undeniable that when a company with 3000 people is competing head-to-head with a company that is at least 10 if not 20 times larger, then they are doing something right.

[30:33] Going back to that experience of moving to other companies and noticing that everything was so much slower than what was happening at Borland, and relating to the Organisational Patterns that I had discovered through the papers of Coplien - which reflected what my experience had been - I started reasoning in terms of what are the actual good Patterns that can make a company stand out beyond all competition. This quest went on for several years. At the end it converged on two Patterns: one is the Unity of Purpose pattern and the other one is the Community of Trust pattern. A few years later I also added a third one, the Inspired Leadership pattern. Note well: it is not “inspiring” leadership but “inspired” leadership. These three patterns are the foundation of high performing organisations, in my view.

[31:38] So where does TOC come into this? In 2004 I came across David Anderson’s book “Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results”. That was the first book I ever encountered that spoke about the Theory of Constraints. I was fascinated by the topic. Of course I went off and read “The Goal” and anything else I could find from Goldratt about TOC. I got all the books he wrote and just devoured them. I came to this realisation that the Constraint, this unique point that you have in any company in any organisation, well, if you’re able to focus on that, then that will give you something very tangible around which you can build the Unity of Purpose. Why? Because everyone will be there to resolve the issues with the Constraint. The story of Herbie: at the end the load of Herbie’s backpack is distributed across his peers. You get this idea that everyone is there to help the weakest one. You leave no one behind in the woods, and you’ll all get to the base camp together. TOC was like an epitome! WOW! I had found something practical that I could use to build the Unity of Purpose. It was just such a natural match with my pattern thinking that it basically became the central theme of my work.

[33:27] But then, as I mentioned David Anderson, you certainly know that David a few years later brought to the world this idea of Kanban. And one reason for [introducing] Kanban is that - correctly - David Anderson stated that it was next to impossible to identify the Constraint in knowledge-work. As you very well know, step 1 of the five focusing steps is: ”Step 1: Identify the Constraint.” And here we were having this observation that, No!, you cannot identify the Constraints in knowledge-work.

David found an alternative way to not necessarily identify the Constraints but to sort of manage around it. That was the indirect benefit of introducing Column WIP Limits; but Column WIP Limits were not identifying the Constraint. I was extremely disturbed by this fact because my central point of focus - the Constraint that could bring about the Unity of Purpose - had been thrown out of the window. And that was when I set out to to resolve this issue and really find out how you can identify the Constraint in knowledge-work; and that’s where we have the convergence of my thinking between Scrum, or rather the the sources of Scrum that came from the experience at Borland International, the Pattern thinking, the Unity of Purpose and the Community of Trust patterns, centered around the Constraint, Kanban to visualize work and the idea to limit Work in Process. Bring all these things together and at the end you start to see how TameFlow came to be.

[35:07] Tom: […] I wanted to push a little bit more on when you went through this personal realisation that caused you to create. I see what you’ve done not just as an academic reporter, but someone who has created something that didn’t exist before and put it all together into something that’s greater. How did that act of creation change you?

[36:04] Steve:I don’t think I can even relate to this question. I don’t see it as an “act of creation.” It was just a continuous, curious mind investigation on how things worked. Yes! They were completely formed and conditioned first by the experience at Borland, and second by the discovery of Pattern thinking and Pattern Languages. Those were the two root causes of everything else that followed. As I mentioned, when I left Borland and I found that all other places were just so dragging and slow and could not compare with what I was used to, I started to frame that in terms of patterns. Of course I was drawing stuff on paper and taking notes… and slowly but surely I was building up my own personal body of knowledge of how things were actually unrolling in companies and what you could do about it. But it was not a systematic thing. It was more like helping people in the context where I was working to overcome situational problems.

[37:36] For instance, way before I started working with TOC, I was involved in a number of mergers and acquisitions. There I put into practice ideas that came from Patterns, Agile and eXtreme Programming. Things were just working. I was always extremely successful in the field. But I remember at a certain point someone asked: ”but how do you do this?” and I didn’t have an answer. I could not give a reply to that question. That was around 2010/11 - and that’s when I decided to document my things. I started to refine my experience notes and also did more research. I spent over a year, like a sabbatical year, just doing research on my own, to clarify this. At the end, all these refined notes were more or less the manuscript of the ”Hyper” book. In fact when I decided to write it, it was just a matter of three and half months and it was written; because all of the refinement was already done. It was just like… do a core-dump and get a print-out of it.

[39:07] Tom: Our conversations are always very enlightening. If you woke up tomorrow morning someone handed you a choice of caffeinated beverages and a magic wand, what two things would you change in terms of how people think about delivering software.

[39:33] Steve: I would expand that, and not talk about “delivering software” but talk in terms of how can the company or you best contribute to the company’s achievement of its Goal - with the understanding that that Goal is something that you yourself buy into; so with understanding that a moment of enlightened self-interest has happened and has been internalized. OK? With that premise, I would say that the number one most important thing is to make sure that top-management discovers and is aware of Throughput Accounting. Or… No! Don’t say that! Because that is the best kept secret of this industry. A company that knows this, will have amazing results, so just go whisper that… don’t say it too loud!

But if you do get management to understand the amazing potential of Throughput Accounting then you are in a great position to guide your company to exceptional results. Why? because for instance if Throughput Accounting - as you know - helps you to reason around the Constraint, then you will also have the situation where anything else around the Constrained by definition has a lot of excess capacity. In that excess capacity you will have the leeway - or the “slack” to use an Agile term - to create a much more humane organization. So all those human-centred values that Agile is promoting will get a factual business-focused, outcome-oriented element in the focusing on the Constraint. Number two, after bringing awareness of Throughput Accounting to management, is for you to discover yourself all the magic properties of Constraints Management; of knowing who your Herbie is and how to help Herbie.

[42:02] Tom: How would others reach out, find you and continue the conversation?

Steve: Anybody can continue this conversation not only with me because there are many other people that, finally after many years, are starting to to discover and become active on TameFlow. So the best thing is to join the community - you will always find me there - and it is at https://community.tameflow.com. Then of course you can always follow me on twitter where I am @tendon; and you can always check out the website, https://tameflow.com for the latest news, and subscribe to the newsletter and so on.

Tom: I am a different person after our conversations and that’s good because I think we all need to evolve and build over time. You know I open up the platform at this point for you to promote anything that you like. Obviously we want people to go out and buy ”Tame your Work Flow”. Probably they ought to go off and buy the ”Hyper” book too. What else would you like to promote today?

Steve: “Promote” is probably not the right word. I just wish that people became aware of the fact that TameFlow is really not something that you can compare to all the other mainstream Agile approaches. As we have gone through today it’s based on different premises, it’s based on Pattern Theory, it is based on Decision Science. It is something radically different; but you will achieve the same or better results than what you’re expecting out of Agile. You will finally have a tool that it’s overarching and puts you and top-management (unless you are top-management yourself, of course!) on the same same page, and you will all be rowing in the same direction. So if I want to promote something, it is just this message: become more aware of what TameFlow really is, and what it can bring to you. Get to that moment of enlightened self-interest! Do that!

Published : May 10, 2020
Share this article at :
Twitter Facebook LinkedIn