 Welcome everyone to the session Repairs Safe while Continuing Operations Theory of Constraints by Wolfram. We are glad Wolfram could join us today and he has joined us from Germany. Wolfram is the founder of BlueDolphin.world and his purpose is to make the knowledge how to reach high performance in shortest possible time available for all organizations. Today he will share his experience in overcoming problems in safe implementation to generate float 2.0. We are very excited to hear that Wolfram. Yeah, thanks a lot and I'm very happy to be abroad in India. So hello world, hello India and maybe a very few words to me so you can a little understand who's talking here about safe and repairing safe. My name is Wolfram Müller and I'm an engineer so very technical driven software developer and I was responsible. Maybe you know the company one and one dot com an international internet service provider worldwide active and I was there responsible for the project management office. So I was responsible in my time there for over 500 product developments and projects with a lot of people for the project manager thousands of developers around the world. So and you can imagine internet internet service provider. It was a very, very interesting dynamic time. And we had to react very fast. So we started in 2002 20 years ago already with agile. And you can believe me we did all the mistakes you can do. And once in this, delivering all the projects and products, we came to this idea of theory of constraints. And it was really a breakthrough for us in performance. And after that, I started, of course, to distribute this knowledge you heard about the blue dolphin. And we are now something around 70 people around the world, supporting companies who want to reach this hyper productivity. The best thing part is, since a year, more and more companies are coming to us with the question are we implemented safe. And the safe is not perfectly working in the way we expected it. Therefore, we are asked to support and help to repair this. And I will to show you a little how theory of constraints can help you in this. And as mentioned below in the screen you see the URL and the code, and I would invite you to open a browser a handy or something like that. Then you see the screen here and you can give your feedback and answers and stuff like this. So to have a little more interaction in this session. So, and you can forget about everything, unless you remember theory of constraints, because that is the main key and the main idea to get hyper productivity. So, and now the first, the first test whether Mentimeter is working and to get a little warm with it. What is your experience with safe, you heard about safe maybe you are part of a safe implementation. And now you can vote. What is your experience, got it worse. Was it more or less neutral. Yes, it felt good. And as you heard we are talking or I'm often talking about hyper productivity, and we talk about hyper productivity. If you reach factor two to five more throughput. So really breakthrough throughput and reduction of lead times by 50% and more. So, yes. As you see, it obviously works meant to be it is working. We get the first boats in. So, and it's, it's a very typical picture we see right now. Yeah, sometimes it get worse but but your experience is not like this. It's, it's very often very neutral. So normal, nothing really big breakthrough. And yes, of course quite some organizations feel that they get more agile and that's fine that's that's a main idea, but to be honest, there is no breakthrough. So and that's, that's one of the things, and we are, we got caught of course from the blue ones, very good war worse. And that's my experience what I want to show here. Okay. Thanks you a lot. So many meter works, and you're already familiar with. And now I will have free questions and slides, because very often consultants are telling you oh you have to do this and that and then everything and I don't believe in this. We are believing in assumption and physics of flow. And therefore I just want to check you check with you a few assumptions we have about the world. And you just have to vote yes or no whether it fits for you. And I just explain it shortly. So, and the first assumption we have the goal of an organization has to be generate more outcome. And I already the difference between outcome and output output is just putting something out outcome is, if it is valued by the customer, and if it's valued by the customer, then he wants to pay for it. And then there is value for the customer what do you think is this a valid goal for companies, and you are completely clear. And I love it, because that's a main main main breakthrough and idea really to generate more outcome and if outcome is generated, the company will prosper and grow. So and that's the first part. Thank you for this. Now it's getting a little more tricky. You already heard the theory of constraint stuff. And there's one assumption. And we have one assumption that it's impossible that there are independent value streams. And I showed their picture on the left that are streets by night. And of course you could build streets from every house to every house without intersection. But that's very resource intensive and, and in the end, the fun of a network are the intersection where you can change the roots and make shortcuts. So we believe that it's impossible to have independent work streams. You already see in the voting. That's not so clear because a lot of consultants say you have to have independent streams and independent teams and to end. But in the end, all the breakthrough innovation are across. So just for you, our assumption is that streets are interconnected, the internet is interconnected. And even the value streams are massively interconnected in a company. Otherwise, they would be two companies. Okay, thanks a lot. So now the next question. It's getting harder step by step. If you have such an interconnected network. If you have that theory of constraint, then there will always be a constraint. So one interconnection should be the hardest of all. And my question is how many of the constraints you know in a company. And this is interesting the voting. Oh, that's going in the wrong direction, by the way. So, but that's, that's the key part. And therefore I just can say, have a look in the theory of constraints and the interesting part is, the constraint assumes and we've seen that in practice. There is, there is always one constraint that is harder than all the others. And this one constraint rules all. And if you find this constraint, every in everything in management gets very easy because you just have to focus on this. Okay, so you heard it. Our concern, our assumption is there's always one constraint and you have to find it. And on the left side you see the picture of an airport. And there's very clearly one constraint it's a runway, and it's everywhere in the world the same. And in it organization, it's very often architecture business engineering, or if it's not so mature, then it's deaf ops and stuff like this. So, keep aware, there's always just one constraint in a system. So, thank you a lot. And now back to safe. Now you can give your statement on a scale. What do you think how good is safe fulfilling the goal to improve outcome. Well, the second scale is. What do you think does safe works perfect in a very complex value network with a lot of interconnection. And the last one is in safe environments. Do you see this constraint. It must be very, very, very obvious and visible. I'm a little, little interested in what you think. Oh, it's something in between. So the goal stuff is fulfilled. Yes, I think so too. That's, that's clear. Safe has the same goal than we. It's interesting that you think that, that the, the constraint is visible in safe, and it can deal with complexity. There we will have a look at it. So, I'm a little surprised because we see a lot of trouble in safe working with the dependencies. And of course, we don't see the constraint in there. Okay. Fine. That's always interesting to have a vote. Thank you for this. Now we go a step deeper. So that that were the assumption. We're going one step nearer to the solution how to repair safe. And 10 years ago something around that I learned about self organization, and not the classical standard way of self organization by the scientific approach of self organization. And that's very interested how ends and organizations and physical systems are, are organized. And in the end, it's very, very simple. It must be simple otherwise it would not be a success story self organization. And in the end, you just have two principles or factors that decides whether you are successful or not. And the first one is very strange. The first one is very strange. All living organizations are under loaded. And that's a very, very, very important pre condition. And you voted for, oh, there are more constraints. And very often. This is a effect. If you are overloaded as organization, and you see of course more constraints, then it looks chaotic. If you are under load the organization you will clearly see your constraint. So that's a very important precondition. And the other one is having a strong very fast transparent signal, so that everyone knows about each other and what the state is. So he can decide in a way that's good for himself and for the organization. And that are the main, main points. If you want to use self organization in a positive way, you have to fulfill these two principles. So now this is very abstract. And therefore I just took out my pen and sorry about my drawing ability is not so good. But I tried to paint a crossroad, like in the example before. The first question you always have is, where is my constraint. And this is a simple, simple example, of course, so you immediately know where the constraint is. It must be the area of the crossing, the crossing area, because there are just one or two cars can be in and on the streets, you have at least four times more capacity. So in the cross section, it's always this area where the streets are crossing. Okay, that's clear. And then the next question is typically. Okay, if I have a constraint, I will, I will use it 100% that's the optimum. So what happens if you really reach 100% usage. Very often it is called traffic disruption. But the bigger problem is, if anything happens, and you are fully loaded, what happens then you will never be able to recover. That means if you promise your customer 100% of your ability, capacity, and, and just a small thing happens, you will never be able to catch up. So it's not a good idea to load the constraint at 100%. But what is acceptable, and maybe you know queuing theory and stuff like this, it depends a little on the fluctuations, but more or less a rule of some. I think around 80% is already much to recover from any, any incidents and stuff like this, bugs or misunderstandings. So 80% is a good, good number for the planned load of the constraint. And then the next question is, okay, if what is the acceptable average load in the inflow then of course. The testing part is that it must be even below that, because otherwise if a problem occurs somewhere else, it's also not able to recover. And if it's more inflow than the capacity of the constraints over the long run, you will have a huge backlog, and the lead time will go down. So therefore it's so important to really understand this principle of self organization, you have to under load the organization. And now that means and if you work with C levels, we often let them speak out loud the sentence, resources have to wait for work. So if you really want to have a flowing system, then the people, the developer or whoever, they have the ability to do their job, and then they wait shortly, not very long. And then the next work package comes, and that means the work is flowing in optimal speed and optimal speed means optimal outcome. You have optimal time to market. So, I'm the loading the system is a precondition for really hyper performed organization. It's not hard to sell, but it's a precondition. So, that was principle one, and principle two is the transparent signaling. That's a little more complex. But the question is always, if you do not have a transparent signaling, what will happen, all the cars will run into the cross section, it will have a traffic jam, and the output is nearly zero. The next thing is, is it possible to manage such a system if everyone just knows his car and nothing about the others. It's not possible, even in a self organized system, you need a very fast signaling system, where all the cars are to decide whether you can go into this cross section or not. And by the way, if you let the individual cops decide on their own, then, you know, they will always decide to go into, and you always has lost. So, there must be something like a starts control. And in a cross sections easy to traffic light. And you can believe me, all traffic lights are centrally controlled. That means there's somewhere a computer, he has an overview where the cars are. And they, they do with the traffic light, they do with the starts control. So it's nearly impossible, as I say nearly to negotiate the right, the right inflow, because the local and egoism prevents to really get the optimum. And that's the last question or the second glass question, what's the core of this starts control, and that it's not directly the flow in the cross section, but it's a queue length. So all the modern traffic light controls, look at the cues, and the longest queue will get more resources of the constraint, so that the overflow, the overall flow is smooth. So it, and as I said, it's a more, it's a little more abstract. But, but it's very important to know that if you unload the organization, then you still have the need of a some kind central signaling system, a very light white ones, a very fast ones to really get the starts control done in a way so that everyone gets the precious constraint resource. And the last question is, okay, if there are just two cars, such a signaling makes no sense. And if it's completely overloaded, then it makes also no sense. So it's connected, you can't have a good signaling system in an overloaded system, it makes no sense. So these both principles are very tightly knitted together. So, wow. Sorry about this section. That is the base that are the principles you can read about this. That's a base of all what we are thinking. My question to you, does these two principle make sense to you. Are they reasonable. Wow. Good, because the interesting part of this is, you can look at whatever system. You will find these two principles in our body in until in the traffic system in companies. These are universal systems for all living beings and organizations. So it's very important to understand. And the hardest part is of course, the underloading. But that's a key for hyper performance. So in the, the next question is, okay, you have a little experience with safe. environment really like this, that resources are waiting for work. Is it in a safe environment really like this, that every day, everyone knows where his story is what the end and the start date, and what the status. Every day, I'm talking really about every day. And I'm talking about resources are waiting for work. Interesting. I thought this is more clear. And then the voting would be more clear but it's, it's interesting for me also to have such motifs to learn about. Now I would would be interested in having a discussion why you think that there is every day signal. We have, I learned afterwards a hangout possibilities so we can discuss about this further, but the under load. That's a real problem of safe because everyone pulls in his PI planning or whatever, and they are all 100% working all the time. So they are not waiting for work. Hmm, that's stupid somehow. And the signaling. Yes, it's there of course on the team layer, but on the on the coordination layer and on the portfolio layer. So on the overall portfolio. It's not very clear what my story has as a status for everyone else. So and now it's all about fixing this. As I said, since the year more and more safe implementations are coming to us. We have now a list of 19 fails and stuff like this. And what we see is safe is very, very clear in the goal, a more outcome. Many consultants are telling the people that it's very important to have independent teams and value streams and to end but this is seldom the case. The constraint is not visible. It's not clear who is constraining the output of the overall system. And if everyone pulls work, everyone is busy. So you will see, of course, then many constraints, a lot of discussions about priorities and dependencies. And sorry, I don't see a team over spanning signaling where my story is. So on the coordination layer, the only thing you have to do or can do is talk. So, sorry, that was the safe bashing part. I don't want to bash safe. It's, it's fine, but it had it really has to be improved. And now that's, that's, I think the most critical or hardest question. If you all have the job to, to repair such a situation, then you have different possibilities what you can do first. So you can do first optimize the flow in the team. Now you can first implement dependency or coordination management, you can implement lean portfolio management. And my question to you is, if you have the job to save, save. What do you think should be done first. Wonderful. Okay, that that I really like. And because I think safe is not so bad at all. But they do the stuff in the wrong order. So when we are working with companies to get hyper productivity, the first thing is to identify the constraint and the organization. And then you have the head free for change and doing new stuff. The second thing we are doing is the signaling. So, so you rated the dependency and project management as third one, we, we typically use this as a second one. And then if you have the signals and the under load, then it makes absolutely sense to optimize the flow in the team. And now, now I just want to show you for concepts out of theory of constraints I don't want to go so much in detail. But just to give you a short impression about this. And afterwards I show you where you can get more, more details. But when we are going into a say for any other organization. The first thing we are doing is we activate the lean portfolio management, but not in this general term, like described in safe, but really based on the theory of constraints. And that means, and it sounds a little stupid or awkward, but there are strategic deliveries for each organization. We, we put them on a list. And the customers or the organization put some low data, very rough estimation what skills they need and how much of them, then you simply add every needs. And you compare it to the capacity of the skills. And then you have the constraint identified. That's a picture in the left above. So these are the queue length. And if the demand is over the capacity, then it's get read. And then you have to decide which of the deliveries you postpone or throw away in the fridge or something like that. So it's a real decision hard decision to cut the overall strategic backlog down until the constraint is in the under load. So that's that's what we are calling freezing after the freezing you you have a little more information. You see where you're where you have capacities. And by the way, Skype did it a few years ago. And they found 50% spare capacity by doing this. And then of course you readjust your team sizes so that the constraint is better loaded the pictures below show the roadmap and the red stuff is always the constraint usage. And the game is all about not overloading the constraint. And if you don't overload the constraint, every other team is not overloaded, very typically teams are loaded with 50 to 60% plant load. And that also allows them to do sharpen the X to improve the way of working learn so protective capacity spare capacity is not bad at all. It's necessary to evolve and increase flow. So, if you do this, the constraint is an under load and all other teams have spare capacity. You can't imagine, if you do this, and we did it 35 times. It's already a completely different organization you have. So the next thing that's a little more complex. Sorry about this. And maybe you read the first book of David Anderson. We have introduced the concept out of theory of constraint called ground buffer rope. Then the book of David, a lot of things has evolved. So, we are using this simplified ground buffer concept for cues. And if you look at a safe installation implementation, each team looks like ordered queue of deliveries. And each of these items has, we call it standard lead time. So if it is the only thing to do, it takes maybe a week or two week or something like that. And this queue that's a picture above, you just put everything behind each other. And then you divide a little by the capacity you have, then you have the plan load that is the end of the queue. So, and even new items coming in, you can easily say when you have to stay a start and stop when you can deliver. So this is a very simple heuristic about determining for each item at you date. So, and we did it with Steve kind of together with a four and a half thousand developer company 120 teams, easily to do. And then everyone knows about start and end dates of his item. And the goal is to deliver in yellow. So if an item comes to read, someone takes care. And this we call expediting. And out of the expediting you learn what's what's the problem. And then you can fix the process. If there are too many items finished in green, then you reduce the lead times. So and the, the success story of this is no one has to ask. So you don't need to have a PIP planning. Everyone knows when his items are coming and you do the screen read yellow stuff and expediting, you really can be sure that it is delivered. And that's about this. So there are much more details afterwards you can request. And if you have for each story at you date, then you can do a very simple project management on top. That is the middle layer that is very complex in in say if you have to talk a lot to manage the dependencies with a drum buffer row below. It's very simple. So for example, if you have a small bigger release epic or strategic delivery that contains maybe three stories in three different cues, and they have to be finished at the same time. Then you simply can look in the cues where your parts are. And you just take the last delivery date and then you know when the overall is delivered you can also build dependencies. And that's a very, very simple way to do project management you simply have to look where your parts are. And if one of these parts are too late, then you can look what's before you in the queue, you know, with whom you have to talk. And then you can talk with him, and he's willing to postpone his part. You can easily do decisions trade offs. And it's very easy to get a reliable due date for even bigger complex deliveries with many parts. We've done this to in many companies. And the idea is really and you can do it all the time. You have all the data all the day. And this leads to a very simple preparation of pips, because everyone already knows everything, the dependencies, the due dates, and then you simply have to talk about the strategic strategy about the context and all the stuff around, but not solving these dependencies, because they are already solved. And the last fix for the last part is this flow in teams. Maybe you realize that Steve tendon in three hours has also a speech here together with Steve tendon I wrote the book tame the flow. And it's all about the perfect flow in teams. And that's very simple. You have typically a task board and you manage your sub tasks. I prefer the swim lane version with planned in progress and finished. And the only thing you have to do is to take care that less sub tasks are open then people in the team. Everything else makes no sense in a knowledge working environment. And if something is not able to flow or is there a problem. If it's internal or external problem, you don't have to write an impediment backlog or scrum master to ask for anything like this. I really prefer pull the line stop working on on anything else fix the problem. And by doing this you will really get very fast into very good flow if you solve your problems. If you solve the problems then reduce the sub task size so that the problems will occur faster and more until you really reach perfect flow. And if you have the drum buffer of stuff. So you have a traffic light system. And typically you put this traffic light also on the Kanban board or whatever. So you have a priority. And of course, if, if there is a red line, then please help the people in the red, and you will have optimal flow within days. That's the last fix we promote really reduce the work in progress on team layer, layer less sub tasks, then people in the team, no backlogs no blocking areas, pull the line and fix the flow. So that were the four, the three. No, that are four fixes. And as I said, we do it very often. So, just imagine an organization that is in under load, would you love it, or an organization where everyone knows about every story, the status and the due date, very easy to manage, or an organization where the teams are in perfect flow. So, would you love it or not. Okay, that's interesting. I have to talk afterwards with the one who voted for he does not love an underloaded organization. Okay, so you, I think you get the idea. I really can tell you, we have a lot of testimonies when people came to us and said, Oh, it's so wonderful to work in an organization that is in under load. It's so so relieving. So, where the stuff is. And I really am astonished, working in a team with perfect flow. I really can wish you this, because that's the most wonderful thing, and the team that is in perfect flow and has no hurdles. There was a creativity that that is unbelievable. So, but you're a little on the right side, you're not so happy and in love with the stuff so I have to think about, and maybe in the hang out you can tell me why. And that's it. And it's no fantasy of mine. We do this in 10 years. And just to give you a small impression, one of the biggest was telephonic Brazil with x 1000 employees with this ideas. They doubled the throughput. Other companies like Bush, they reduce the time to market by 35% up to 70% even after five years doing lean. So, and, or for example mega within 20 weeks, they quadrupled the output and wasn't how's more or less the same. So we have a lot of experience 35 companies and a company that's in flow that's also good for the people and the creativity comes back. It's unbelievable all these companies are now more or less market leaders in their area, because they are simply faster than all the others. And just just for you here a little the overview. And the main thing is, we pulled the portfolio management in the implementation of safe in the front in the beginning. We do this queuing stuff and this project management stuff to get the easy, easy dependency management, and then of course, in the coaching area, we really think and help the teams to reach flow, and that's it more or less. So that was it from my side. Thanks for your time and it was too short to show you everything of the last 10 years we did. So here are five links. A lot of resources everything for free. You just can grab it and use it there are tools everything you need to know. And the last thing is, I love India. I really do it and we also have dolphins and supporters in India. So, if you have question afterwards to me. Thank you so much for your time and I will be happy to answer your questions of course too. So, thank you. That was it from my side. Thank you will from wonderful session. So much to digest. Sorry. It's been wonderful. We, we only have like two minutes so maybe we can take one question now and then remaining we can take in the hangout. So there is a question that asks in an organization there can be more than one constraint is what I have seen. Of course one could be predominant. So why do we say that there is only one constraint. There can be two or more, but it makes it very, very complex. And it's, it's as the question I said there's a predominant one. And if you want to grow as an organization, then you have to focus on the most severe one. And therefore we say, there's always one that dominates everything. If you solve this, then you have of course the next one. So, yes, there are in reality more than one, but the idea is to have one and focus on one, and then the next one. Makes sense. Yeah. And thank you so much will from for sharing your experience with us today.