 We welcome you all to the session software engineering management at scale with the theory of constraints by Steve Tandon. Steve Tandon MD from team flow consulting limited. He's an author consultant and advisor on organizational performance and emerging technologies. Steve is the creator of team flow approach, a management approach that helps business focus on the things that makes the greatest impact on people. Performance and profit in collaborative knowledge work without compromising sustainability quality or humanity. Steve holds a MSC in lean and agile software project management with the University of Aberdeen. Without further delay over to you Steve. Thank you for the introduction Vinay and I usually start all my public appearances with the greeting. Hello, friends of Herbie, and you will understand why in a moment when we go into the presentation. And as Vinay said, I help businesses to focus on the fewest thing that make the greatest impact on people performance and profit, and I am the creator of the team flow approach. So what is team flow? Well, it is a management approach, but it has a long history. And in fact, it has a pedigree, which is shared with a scrum, the scrum framework. I will not go into that story now, but you can ask me later in the hangout if you want to know about it. So with team flow, I focus on the holistic systems organizational view. I consider every organization as having a purpose. We don't content what that purpose is. It's individual to every business leader to define it. But to get to that purpose, you certainly need to have happy people on board, you must deliver outstanding performance and you must turn a profit. We call team flow, team the flow, because it teams for flows, the financial flow, operational flow, informational flow, and psychological flow. Financial flow as the name implies is about money. And we use concepts from throughput economics throughput accounting, a very simple way to quantify the business operations of, well, any organization. And we can also deal with non-economic decisions and make economic prioritization using techniques like the impact estimation table of Tom Gill, who gave a keynote in the conference earlier. We have then the operational flow that looks at how well we are delivering. We use flow metrics. We are concerned about flow efficiency, which we all know is better than resource efficiency. But we go even further and have something that is even more powerful, which is throughput efficiency. And it's therein that we find the notion of Herbie, the constraint. Then we have informational flow. We work on designing the feedback loops. Let's say that go from top to bottom and back in the organization. And we trigger the conversations through what I call work execution signals. It's the state of the work that will indicate when attention is needed and when intervention is needed. All of this goes under the name of management by exception. I know the term is overloaded, has been used by other schools of thoughts, but it renders the idea. We offload management of lots of their work because we allow them to focus on what really matters. And all of this is achieved through a very intense collaboration between the business side and the engineering side, so that they can make a move together. And that is a play on words and you will see soon why. Finally, we have the psychological flow, psychological flow, which takes many shapes, but one which you will experience already in this talk is the use of metaphors of story. In fact, we have the story of Herbie, which we'll see in a moment, the story of the patient in the hospital, the story of the jungle, the jeep and the journey, and even others. So, we are also using the metrics from operational flow to inform how to act on the psychological state of people, so we can bring them to states of flow of optimal performance. And all of this will actually impact the culture, the mindset and the attitude. Long story short, we do all of this because we want to create the unity of purpose and the community of trust within the organization. The scope of action of team flow is very broad. It covers the areas of interest of teams, managers and executives, which often find help in external entities like coaches like framework and professional bodies like advisors. We cover all three of these areas and we glue them together with the flow of information. So, let me get you to the story of Herbie. Herbie is a scout in a team that has to hike through the woods, the stream, climb a mountain, descend across the swamp and finally arrive at base camp. That is a plan. There is a goal and a deadline. Seems very much like the things you have to contend with every day. So, the story goes this. The hike starts and Bluey is the fastest guy off the line and he walks in front. Herbie troddles along and is there in the middle and at the end we have Greeny who is a lazy boy and always drags himself. But Herbie starts to lose ground as the terrain becomes more challenging and then finds himself at the end of the line and the team leads Charles. Herbie and then Herbie gets even further behind and he shouts even more, come on Herbie, speed up. And we all know that shouting of people will certainly make them perform better, right? Well, it didn't work so the team leads stops and thinks about it and then gives the instruction that everybody stays behind Herbie. That way, at least, nobody is going to be lost in the woods. They will all walk together. But still, it's not fast enough. So, after a while, the team lead asks Herbie and the Boy Scouts to stop and ask Herbie, what you have in your backpack? And he has all sorts of equipment, cans of tuna, fry pans, boots, all things. Why do you carry all of this? I'm a Boy Scouts. I'm always prepared, said Herbie. Okay, said the team lead. Now everybody takes a piece of Herbie's gear and carries it for him. So, sorry, I'm seeing a chat that someone is not seeing the screen. John, is that okay? Tim, if you're able to see the screen, yeah, it's your screen share is on. Okay, we are able to see. Looks good. Okay. Yeah, please proceed. Thank you. So, that way, when everybody carries a bit of Herbie's gear, finally they arrive at the base camp just in time before sunset. So, this story is an illustration of the five focusing steps of Dr. Goldrath. By the way, the story of Herbie was first told by Dr. Goldrath in this business novel, The Gold, which you really should read. And these five focusing steps happen in disorder. First is, one, Herbie identified the constraint. Two, exploit the constraint, meaning that Herbie should walk at the maximum capacity, is able to sustain. Third is, subordinate to the constraints. Everybody walks behind Herbie so that no one, like, runs away and leaves Herbie alone in the woods. And fourth is to elevate the constraint, to help Herbie to move faster. There is a fifth step, which is not illustrated in the story, but it's called prevent inertia, which means that Herbie, the constraint, could actually move. Blueie, who is the fastest guy and who is there walking in the last position, could, for instance, have an injury. Maybe he has something with his shoe or anything else that prevents him from walking, and all of a sudden, he becomes the slowest scout in the troop. And at that point, we have to start over again, identify, exploit, subordinate, and elevate. With this simple recipe, we can resolve many things. But because we are in a business context, we want to know what is the performance we should care about. And I define business performance as the speed of generation of money, money over time. And in particular, we want to think about what I define as a throughput generator, something that bears a price tag that someone will pay for in some market. And now let's get to how we can put this idea into practice with the normal things you do in agile development. We all know about our beloved endless backlogs. Well, I suggest that you go through those backlogs and try to cluster all the items into things that have values. We call them moves, one, two, three, four. And we want to make this clustering so that the move actually can bear a price tag and can be sold, so to say. And with that idea, we then can sort of calculate how much time every move employs and put that in relation to the money it will generate. So we can compare these ratios and thereby reorder the moves according to which one produces, how to say, the most bang for the buck. So from move one, two, three, four, we get to the new sequence, move three, four, two, one, which will generate more money for the company. Now what is a move? A move is a target scope. It's a minimal target scope. If you do less than that, you cannot sell it. It doesn't matter. It will not get bought. If you do more than that, you've done too much and you're wasting the company's money. So it has a very precise economic definition and I use the term logon, which is a Swedish word, and it means just about right, not much, not too little. So why do we have this minimality? Because in the companies, we always have conflicting forces, forces that want to do more and forces that want to do less. It is growth against stability. On the one side, we have sales, marketing, QA that always want to add things. And on that side, we have engineering, accounting, security that always want to take things away. Most of these can be classified as external forces that want growth and internal forces that want stability. The growth forces are fighting for fitness for purpose, while the stability forces are fighting for preservation of resources. And as the diagram shows, they are in conflict. They are pushing one against the other. And it's when we find the balance, that's when we find the scope of the move. It's not too much and not too little. But really, I don't like this thing that we have conflicts within the organization that one is pushing against the other. So we want to do some kind of separation of concerns that we can bring about collaboration. And this is where the money over time diagram becomes very relevant. Because we can say that, hey, internal forces, you care about the time part. You want to be very conservative with time. You want to reduce the time as much as possible. And hey, external forces, you be concerned about with the money part. You want to bring in as much money as possible. And if we have this separation of concern, you can see that the business responsibility and engineering responsibility can start to collaborate. And both will aim at increasing that slope, the angle of this money over time diagram. So they have found a common ground, something that they can reason about, and that will resolve a lot of the conflicts. Now, the time must be, well, you would normally say estimated, but I say forecasting. Because in TeamFlow, we do not do estimates. We don't use story points. We don't use planning poker. We don't use t-shirts, nothing of that. We do probabilistic forecasting. So the engineers are very happy because they don't have to provide estimates, expert opinion estimation. But there is a counterpart that the money must be estimated. So all of a sudden, the business has this additional concern of estimating how much money that piece of work will generate. If we can get these two numbers in place, we can get over many, many problems. So how do we have to think about these two elements, money and time? Well, money corresponds somehow defines the scope because we said too much is waste and too little cannot be sold. So there is a direct correspondence between the amount of money and the scope you're doing. But then the time, what is the time? Well, broadly speaking, we can say it's the time that it takes to do the thing. And that is the time we will use in the money over time diagram. So it's that exactly same duration. And of course, on the scope time diagram, we have the normal, let's say velocity measure to use a term that you might be familiar with. Now, what is time? Here it becomes more tricky because we might consider the time that it takes for work to go through the entire process. What normally is known as cycle time. And if you use that time in that ratio, you can get to something that you might be familiar with. It's the cost of delay over duration, CD3. It's a very good metric, but it's not good enough. In our perspective, we will have another measurement of time, which is based on finding Herbie, finding the constraints. Suppose that in this process of business analysis, development and test development is the constraint. Well, the Herbie flow time, I call it flow time, not cycle time. And there are many reasons for that, but we don't go into the details. Well, that is the time we will use to compute that ratio. And when we use that time, the ratio is known as the financial throughput rate. That is the magic number we will be looking at. So now we get to the point. Step one, how do we find Herbie? How do you find the constraint? Well, actually, the answer is multi-dimensional. We have to look at several things. First, where is the constraint in the work process? Well, what we do is that we start logging the flow times that work items take through the process. And we can see, for instance, that there is one item that takes three days. There are two items that take two days. There are four items that take five days and so on and so forth. So this is simply a diagram of the elapsed time versus the count of items that took that time. And we can draw like a diagram, a curve, and we can find an average. This average will play a very important role. So where is Herbie? Now, if we do the flow time distribution diagram for each state in your process, maybe if you're using Kanban, well, then we can indicate that the constraint is where we have the longest average in-state flow time. So this is very different from what you might have learned in Kanban that looks at the queues inside the Kanban board. We look at this statistical measure and it's very stable, so it's quite reliable. Now, when we are using the average flow time, this brings in the queuing theory and Little's Law. We can use the queuing theory to do forecasts. So how do we do that? We have to look at the formulation of Little's Law, which is expressed by this ratio that the operational throughput or velocity, if you want to use that term, is the scope over the time. The equation also takes this form that throughput is working process over flow time, and therefore we can resolve for flow time, given the amount of work we want to do, and looking at the historical throughput that we have been performing in the past. Of course, this falls into the flaws of averages. We have to be very careful. And the application of Little's Law is subject to some very harsh assumptions, conservation of flow, consistent units, and above all, system stability. What does it mean system stability? Basically that you limit the working process. How do you limit the working process? Well, in Scrum, you do the sprinting and you load with velocity how much work you think you can do in the sprint. In Kanban, you use the column width limits. They do limit the working process, but they do not make the system the most stable possible. To do that, we need to have a construct from the theory of constraints, which is drum buffer rope scheduling. How does it work? We find the constraint column, we place a buffer in front of that. Let's say it has three slots, and this size can actually be calculated, but let's just assume it's three here. And what happens is that when one item moves out of dev to test, you pull from the buffer, so you empty a slot in the buffer, and that is your replenishment signal, which tells you now you can start at the beginning of the process to take the next item to pull the next item from the backlog. This mechanism is the one that ensures the minimal working process, and therefore it will keep the system stable. By keeping the system stable, we can apply little slow. We get to the point that we start using work execution signals, building on top of these constants. First of all, we have to introduce a notion that comes from critical chain project management, which is get the signal if the work is becoming late. How do we do this? We start with a move, we find the target scope, we know the historical throughput we've had in the past, and project that to the scope, bring it down, and have a forecasted delivery time. Notice that this is most likely an average forecasted delivery time, so we can tuck onto that buffer. We can do this using a bit of statistics or heuristics, but the point is we want these three zones, green, yellow, and red. So it's very operational, you can do this very quickly. And how do we use this? Well, suppose this is another move, it just happens to have the same colors and the same number of items, and we have just finished to deliver the first two work items. And we measure how much time that took, we know the actual throughput, we project, we bring that down, and where that line intersects the buffer, excuse me, we get a signal according to the coloring we have provided. Now this signal is simple. If you are in the green, everything is okay. If you are in the yellow, it means pay attention, you might be late. If you are in the red, it's most likely you will be late. You better act and intervene. How can we use this? Well, there is a tool which is called the fever chart, and it gives an even finer signaling mechanism. We will compute the percentage of work done compared to the totality of work in the move with the percentage of buffer consumed until that date. And this brings us to the metric of the buff and burn rate. It is the buffer consumed expressed as a percentage divided by the work done expressed as a percentage. Now this is extremely important because we are dividing two percentages. So this number is scale less, it's scale free. And this means that you can compare tiny small projects with enormous projects. You can understand which one of those is most critical. It's one element that renders this way of thinking, scale less, and therefore you can apply it at any scale. Now, that was the constraint in the work process, but we need to think broader. That was for one team. What happens if we have multiple teams? Nowadays, it's very fancy to talk about value streams. In reality, when you have complex knowledge work, it's always about value networks. So if you have these situations with team A, B, and C, each one of them will have their own Herbie. Suppose those are the Herbie columns, different for every team. The question is, which team is the constraint here? We cannot tell by using those columns. We have to do something else. Well, remember what we are trying to do here. We are trying to find the best economic value of the work that we want to release into the team. So we have to find the time that is at the denominator of our money over time fraction. We have these moves. We know that. And here we have to use a projection. Imagine that those moves we are future looking will be hitting those teams. To what extent will they hit every team? Well, we see that these are being distributed. And you see that in front of the teams, those items, I've drawn them as dotted, meaning that they are not real. They are like a projection. We are imagining that that is what will happen. But also, since we're using little slow, we can compute the length of those queues in terms of, guess what, time. That's very powerful, because that is the dimension we need. And therefore, we can define that the constraint in the workflow, the workflow through this value network, is the team with the longest queue time in front of it. That is what I define as a workflow constraint. And it is the constraint in the work process of that team that we use to compute the financial throughput rate. So what does this give us? Okay, this is the situation as before. These are the virtual time queues in front of the teams. That is the workflow constraint, the longest virtual queue. And that is the Herbie of the entire situation. So on the one side, the buffer in front of Herbie there is what will schedule the work for the entire network. That little buffer will determine when we release work from the move backlog on the left side. But also, we get the Herbie flow time. We can use the Herbie flow time to compute the financial throughput rate of all the moves. We can then sort the moves according to that ratio. And that, of course, will also change the virtual queues, the order of the virtual queues. But there we go. We have found the optimal sequence of moves to send through this network of teams that are creating value together. But that's not enough because that was future looking. What happens when the work is really going through this value network? Well, remember we could draw the buffer fever charts? Well, now let's draw them for each and every team. Let's suppose that these diagrams are a moment in execution and those fever charts capture that moment. So here we have a powerful visualization. Instead of having those static diagrams, imagine that we have a time series and that we animate this time series. The easiest way to understand it is just to look at the animation. Do you see what is happening here? Team A is rushing ahead. The bubbles are spread out. Team B is recovering. It was going bad in the red, but it's pivoting. It's going back into the yellow. And Team C, Team C, well, it's having a problem. You see all the bubbles are piling up just like the cars on rush hour. So in this situation, Team C is the work execution constraint. It is what will be holding back the execution of the entire backlog of work that is hitting the entire network, the value creation network. Now here we have to be careful because remember that we started off by saying that Team B is the workflow constraint. And that's the team we use to compute the financial throughput rate. But what does this mean if Team C is slowing down so much that it will become the new workflow constraint? We see that Team C is slowing down in real time so we can compute the length of the virtual queues according to the new throughput it is generating. And if that length happens to become longer than the length in front of Team B, well then we have to stop and think. This is a judgment call because if we conclude that that change is permanent, is systemic, well then we have to do riddle the whole calculation on Team C rather than Team B. But mind you, it's a judgment call because this is runtime. It could be that Team C is only having a temporary hiccup and we know it will recover and in that case we don't do anything. We continue with Team B as the workflow constraint. But if we conclude that Team C is really slowing down badly because it has a long-term problem, well then we have to recalculate everything. But this is easy to do when you know what to do. Now there were many moving parts here and I'd like to summarize this with the metaphor of the jungle, the jeep and the journey. So the jungle is the workflow and the workflow constraint, remember we have multiple teams, is like the longest path through that jungle. And the jeep is the team, now every team is like a jeep, but in particular the jeep that goes through the longest path is where we find the work process constraint. And that's also where we place the system-wide drum buffer rope buffer. And finally, when these jeeps are actually eating off their backlog so the jeep is moving through the jungle, they are doing that through an actual journey. The journey is full of surprises and the jeep might be slowing down. That is the work execution constraint. The reddest buffer burn rate that we are measuring at that moment. And there we have to do that consideration of the judgment call. Is this long-term or is it short-term? Can we ignore it or do we have to reconsider everything? Now a few more things that are really important in this setup in this arrangement. How do you manage dependency? Have you seen this before? Isn't that a wonderful way to manage dependencies? I feel bad just looking at that picture. So how does this approach make that easier? Well, we know that what matters are the moves because they provide economic value. So the only dependencies that really matter are those in between moves. Anything else inside the move is not really a dependency. You can do it in any order that you wish what you must deliver is a move. And remember, we have these virtual time queues. And we know where the workflow constraint is. That constraint is establishing the order of the moves. So if the order of the moves have some dependencies that go against the calculation, well, that's where you have to override the calculation. But that's so easy to do. Now do you see what is happening? Or any dependency in between moves is resolved over there in front of the constraint with a linear sequence that madness the cobweb of the program boards. That's really crazy. It gets resolved with this. A single priority queue where overriding the calculated sequence is kids play. It's really, really simple. That's how you can manage dependencies at scale and very, very quickly. So, of course, there are some details here. I don't go further into explanations. But we have different types of moves, for instance, for architectures, for explorations, for failure demand. These are just ways to classify and be able to do that ordering better. But that does not change the fact that we have just one sequence, one linear sequence where we manage all dependencies, not that craziness of all the cobwebs. Now, just a few more minutes. How do we integrate this maybe with traditional project management or critical chain project management? And you would say, why is that necessary? We would only do agile everywhere. Well, sometimes you're doing like embedded systems and you have to deal with hardware engineers or suppliers and especially in large organizations, they are very project-driven and you still have to contend with traditional project management. So, suppose you have this sort of project plan. This is a multi-project critical chain project management plan. I don't explain critical chain here, but you see that there are two activities, A1 and A4, which are software development. The others are not software. So, what happens is that we introduce a second layer and we feed that layer with those activities, package them as moves. And here we have our canonical situation. We have the jungle, the jeep and the journey. Actually, it is simpler in a way because the priority has already been established through the critical chain scheduling. But you see how we can integrate our way of thinking and in particular the way to detect the constraint with critical chain project management or even traditional CPS. A final consideration about psychological flow, we refer to the works of the late American-Hungarian psychologist who passed away this year, Mihaly Shitzin-Mihaly, who defined the notion of psychological flow states. And he uses this diagram. Basically, it's finding the balance between the challenge and the skill level. Now, doesn't this diagram look very much like the fever chart? Yes, it does indeed. And we can use the fever chart. We can calibrate the size and position of the buffer of the fever chart so that the teams are always there in the yellow. They are in the flow channel. We keep them there because that's where they experience optimal performance. And that's where they are also typically happiest. So we can use our metrics to calibrate the workload so that the teams are always in the state of flow. And since I have some more minutes, one final point is, I often get asked, but how do we start this? Well, if you're at the team level, there is a very easy way to do this. But again, it's based on metrics. We know about the flow time through your work process and the flow time distribution. Well, we can do the same calculation from the start of your process to the end of every state. So the flow time until BA is done, the cumulative flow time until development is done, and the cumulative flow time until test is done. What does this give us? Well, if we arrange our Kanban boards like this, we're on the left side. We have the actual current age of the work items. We see that we get like a signaling system here as well, green, yellow, and red. And this will change the way you run your daily stand-ups. You will run a stand-up only if there are red items. Otherwise, as I say, let people work. It's not necessary to have a stand-up. Of course, this does not exclude the case where in the light of some situational awareness, there is something beyond the work that needs to be discussed. Then, of course, you have to call the meeting. But if everything is under control, so to say, and you have no red items, don't do the stand-up. It's not necessary. But if you do the stand-up, focus your discussion only on the red items and start with the reddest one. See how this is very distinct from Scrum, because in Scrum, you talk about the people, what they have done, what they have to do, and the impediments. So it's a focus on people, not on the work. While it's also different from Kanban, because Kanban walks the board, typically from right to left, with the logic that you want to focus on the right most things, because you want to finish them off sooner. Here, we don't do neither of those two strategies. We simply focus on the reddest items and we deliberately filter out all the rest. So you can see if there are no red items, no stand-up. If there are red items, focus only on them. Don't waste time talking about anything else. And then we get to what is the behavioral response when there is a red item? Number one, you have to swarm the whole team. The team has to resolve that issue internally. If they are not able to resolve, that's where they escalate. And this is where informational flow comes into play. And this is how we put into place the behavioral responses from management side as well. Let's say the working agreement with management. So we are very keen on getting the whole team to swarm, to get their collective minds together and focus on the problem at hand. Remember, everybody stands behind Herbie and the topmost red dot there is Herbie in this situation. So it is likely subordination. And if you're not able to resolve, we need help. We ask management for help. We are stuck. We need to get this out of the door. And if we do this properly, management will respond likewise. Okay, this tool will be, if you apply it consistently, another very powerful element to introduce psychological flow states in the team. Because it actually exercises 17 of the most powerful flow triggers. I will not go into the details, but start doing the stand-ups like this and you will see that your teams will literally take off. So that's it for me. You can discover more by reading my books. There are two books right now, the book of Tameflow, which you find on leanpub.com slash Tameflow and Standing on Bits. Standing on Bits is the basis of this presentation. So anything you are wondering about this presentation, you find it explained in detail in Standing on Bits, which you find at leanpub.com slash Standing on Bits. Finally, if you want to discuss these topics in more detail, well, there is my community, the Tameflow Circle. You find it at circle.tameflow.com. It's an open community. We discuss anything that pertains to collaborative knowledge work, whether it is scrum, safe, kanban, lean, anything else, and of course, Tameflow as well. So that's it for me. Remember, I am Steve Tandon. I help businesses to focus on the fewest thing that make the greatest impact on people, performance, and profit. Thank you. Thanks, Steve. It was really a very great session. A lot of knowledge, a lot of concepts that we had learned through. I have a question in the Q&A channel. I'll read out the question. The question says, in the teams and flow diagram, it was showing us if team three starts late when compared to team one and team two. Is my understanding correct? Why was it? Well, remember, we are dealing with value network. So what we are looking at that diagram is the topology of the network. It's not like the run time. So that diagram did not have, let's say, it's not like a Gantt chart where you see that one activity is before another activity. We see the precedence of activities in terms of topology of the diagram. And therefore, the question we are asking us, now this piece of work, the move, when it has to reach the respective teams, for how long does it stay in line? And the objective was to find the workflow constraint. So the team that virtually will have the greatest queue in front of it. Yes, team three was at the end. And materially, team three will start working after team A and team B. You could imagine, given the shape of the drawing, that that team was actually an integration team. It took the work of team A and team B and took the integration. And therefore, materially, it has to come afterwards. Okay, I'll come back to the Q&A channel. There is another question. It's my first exposure to team flow. How different are moves from features or epics, way of grouping requirements? This question is from Sarath. Well, from, like you say, an operational perspective, it's not that big a difference because they are containers of work items. And by the way, I don't make the distinction of the epic features, stories, or tasks. I see the moves as something that is like fractal. And in fact, this is another element that makes this scale less because you can, what is a work item for someone becomes a move for another organizational unit. So that's why you can use this concept at the portfolio level. You can use it at the initiative level. You can use it at the team level. The main criteria is that the move, and this is distinctive from features and epic, the move must have a relationship to the, well, let's say the economic impact it has on the bottom line. If you cannot substantiate an economic impact, well, then as a CEO, I would question why are we doing it? Are there other ways to quantify the impact of that move? Then those have to be made explicit. And that's where we would use like the impact estimation tables of Tom Gilb. So I think that is the main difference. It's the clear focus on the economic value of what we're doing. I think we have come to the end of the session. And thank you, Steve. Thank you for sharing your experience with us today. Thank you, everybody. And remember, Herbie is your best friend.