 The question that is commonly asked is, which is better? It's called more Kanban. I am not going to discuss that, but I'm going to make a clarification on it. And the other point, which is the important one, is a lot of people think that Kanban cannot be used, for example, in software development because it has no iterations. So we're going to clarify that there's no need of iterations to be able to work effectively. However, Kanban does offer a way in which we can handle something alike iterations. OK? So let's get started. So first off, it looks kind of fuzzy over there. I don't know why, but you guys don't mind about the image being a little fuzzy on the side. I think we're OK, or maybe. No, I don't know. I just leave you like that. OK, so I'm going to start talking a little bit about waterfall. And I think it's very important to set up a mindset. So there is this very strong belief in the agile industry with the agile field that waterfall is bad. It's like evil. And I strongly disagree. Why do I disagree? Because the problem isn't really waterfall. The problem is that we really, most people don't know what waterfall is. So we think waterfall is something like this, right? So we have our big monolithic set of requirements and design and all that stuff that we know. But that's not true. Actually, a waterfall came from a paper that was written by Winston Joyce in 1970 as part of his PhD research, which was sponsored by the DOD in the US, the Department of Defense in the US. And what is really interesting is that this is not waterfall. Nowhere did Winston Joyce say, this is waterfall. This is actually one of the introductory diagrams in his paper. And actually, this paper is very easy to find nowadays on the internet. So you just Google it and download it. It's a PDF. And this is not waterfall. So here's where the surprises begin, OK? So taking that into account, we all know that the most popular agile methodology is scrum. And we like it because it's actually cute. It's nice. You have these very nice looking structures with these loops. It's just kind of cute. It has a nice balance. It could be probably a piece of art on a wall or something like that. That's why it is popular. One of them was a marketing strategy that has to do with certification and all that. But if we ignore that, why do technical guys love scrum? Well, there's two reasons. One of them is, oh, now it's going to be hard for the stakeholders who have nothing to do with the project to come and bug me. So I can go heads down and focus on adding value. So that's a nice one. That's a big deal. I have somebody who is protecting me. We know who that is. But the other aspect is this mechanism of having this short period of time to create and deliver value actually really cool because they helped me have a discipline for value delivery, which is much better than having to wait six months or a year or so. And an advantage of having that short periodicity on top of getting that discipline and having a sustainable pace is the fact that at the end of each sprint, there's a demo. And it doesn't matter how outgoing or how shy the technical people might be because we have all kinds of them. We all, I used to be one of them. A long time ago, I used to be a developer. No matter what, we really like showing off. Like, hey, look, I do that thing. Everybody's looking at or using it like, oh, wow, yeah. So having this very short periodicity of that kind of feedback or showing off my stuff, we just love it. So that maybe is very, very cool. And of course, from the customer standpoint, is values being delivered. So that's nice so far. So now taking that into account, let's go back to Waterfall. So Waterfall is actually really more something like this. So as we go through Winston's paper, what we realized is that what he's suggesting is actually iterations. He said, that diagram is just an introduction to understand that we have a sequence. But what he says is, as we go about doing that, we have to revisit what we're doing, OK? So this idea of short iterations, so that is not new. I just didn't bring something new with that. Royce, instead, was saying we have to loop. And there's actually some more really cool looking ones. So I put these ones just to make it easy to understand. And not only that, he said, you have to do this. If you do this whole thing, you have to do it at least twice. And he also said, beware, this is the result of a PhD research. This is academic. This is not to be applied directly as such in the real world. But what happened? Well, we know what happened, right? This is why we are here. So we know what happened. So I don't need to go beyond that. But what I want to point out is, you can keep very successful organizations and very successful products doing Waterfall. Of course, you can be more successful if you start maturing that idea. A reason why I'm mentioning this is because maybe some of you, and in my line of work, I encounter many customers and potential customers who work on their Waterfall approach. And they are like, I'm not sure if I want to do this agile thing or this lean Kanban stuff. I don't know. So if they are like die hard, Waterfall, then we can tell them, then why aren't you doing this? You want to continue doing Waterfall, then do it right. And to do it right, you have to start going this route. And you know what that means. It's going to be easier for us to start bringing new elements that are going to maybe approach more effectively. So we shouldn't see Waterfall as the evil enemy or whatever. We can actually help mature that. So even organizations who don't want to adopt agile can be benefited. We start bringing this in a gentle fashion. And I think that's huge, particularly in certain companies and some customers. They're really hard to convince. So these arguments will make it easier for you. OK? All right, so far so good. Now, so we all talk about time boxing. A lot of people say we're doing agile. They are really not doing agile. They're just doing the scrum. The scrum and agile is not the same thing. You agree? Agile is a mindset. Scrum is a methodology. And something that is very characteristic of these approaches is time boxing. So why do we do time boxing? What's the advantage of that time boxing? Beyond what I mentioned for a scrum. Well, what we have to begin with is whip limits. As people say, we're a second master. Whip limits has nothing to do with a scrum, for example. That's a lean or a campan thing. In campan, you have whips, but you don't have that in a scrum. And that isn't true. We actually always have a whip limit with a scrum. We just don't call it that way. The whip limit is the number of tasks, the number of user stories, that we have on our spring backlog at the beginning of the sprint. That number of tasks that we have is a whip limit. Why? Because I'm saying this is the maximum number of tasks that I'm going to work on during this sprint. Yes, we don't have whip limits anywhere else, but the entire scrum structure has a whip limit. And of course, something that is interesting in this case is that whip limit changes sprint after sprint because what we keep fixed is not the whip limit. It's the velocity or accuracy of that kind. However, something that is important with the time boxing approach is that we have whip limit. This is also another aspect, which is small batches. The fact that we have a small time box obviously forces us to have a small amount of work to do. Having a small amount of work to do means we want to have a small batch. What is the advantage of having a small batch? Well, the advantage is that it allows us to focus more easily on getting a small amount of work well done, which is much better than doing a large amount of work poorly done. And there's also a psychological advantage. And if you don't believe me, just try yourself. Either with yourself or experiment with someone else. Just give someone a small amount of work to do, a tangible amount of work. Like put a pile of paper or something and say, you have to do all this work. And then give another person like four, five, six times that amount of work. And be very observant of the body language, the facial expressions. And what you will notice is that there's actually a reaction of stress in the person who gets this big chunk of work to do. And they will be like, whoa, hey, what's going on? If it's a small amount of work, they're like, oh, OK, cool. Yeah, man, I can do it. So just probably from the purely psychological standpoint, having a large amount of work to do already starts lowering quality. Because I'm already stressed even before I began. And that affects quality. Then we had the periodic delivery. So again, the fact that we know the benefit of being able to provide a small amount of value and being able to either get feedback from the customer or getting some feedback from the test side of things or the user acceptance test, et cetera, this periodic delivery allows me to more quickly be able to know whether I'm doing OK or not. So that's an advantage. And as I mentioned, it brings discipline, which is, I think, the biggest advantage of having a sprint. But there's a small problem, a small, big problem. If we're working with the sprint, the sprints have absolutely nothing to do with providing the best value to the customer. And it has absolutely nothing to do with really taking into account how the customer is appreciating the value or if he's actually getting the value the way that is best for him. The sprints have everything to do with just bringing a discipline of work towards the team. So Scrum is really cool from the development standpoint towards the team or towards the customer beyond the fact of getting this benefit of getting this value every two or three weeks, there's nothing else. And that's dangerous, because the customer, after a while, it could happen. I say, well, it's nice. I appreciate what you're doing. But it's not really giving me the best I could get. So you start having some problems there. So what we have to understand is that one side doesn't fit all. We cannot just say, I'm going to pay something. And whatever it is, I just encapsulate it in two weeks, and I'm going to deliver to you whatever. I'm just happy that I have the discipline and I can deliver to you. And the news is, it's not about us. It's about the customer. So what we need to do is that which really satisfies the customer, that which really increases the value that we are delivering to the customer. So what I'm saying is that whereas, yes, there is value on having the sprints and being able to deliver, there's something even there that we can do for the customer. So I am not saying that Scrum is bad. I am not saying it's wrong. I mean, I still do it. I have customers with whom we work on the Scrum framework. But we mature that to be able to deliver better value. So what I want to bring into this talk is for you guys to realize that we can do even better than that. So this is pretty good, but let's not stop there. Let's take the next step. And what we realize, hopefully everybody at the end of this talk, is that even if we're talking about Kanban iterationless approach, we will learn that this can be applied to Scrum as well. So let's just go the next step. Let's do even better for the customer. That's what I'm trying to bring into this talk. So what happens? We want to fix things into a sprint. So what do we do? Well, we have epics. And we break them down into stories. And we just keep on breaking down until they fit into a sprint. And if they don't fit into a sprint, then we have to be creative. And what we try to do is make sure that we don't do that. So it would be really nice if we could have stories that can be completed in between one and three days. You know, from the technical standpoint, that's ideal. For example, LinkedIn in Mountain View, California, their IELIN implementation is more than impressive. And they work mostly with Scrum. They do some Kanban. And their story points, maximum size is eight points. And the maximum amount of time to deliver these stories is three days. Most of them are between one and two days. So that's a nice thing to do. However, maybe sometimes this is a little too much. Maybe this idea of breaking things down, I mean, from the technical standpoint, it's okay. But when you talk about the story, trying to break it down into smaller chunks might make things just harder, rather than easier. So we have to be careful about that. So what do we do? Well, typically, you know, the considerations are let's use variable speeds, right? So some, so we change our speed for our screens as we go along to adjust to, you know, what we want to deliver because we just can't fix the things in to what we have. So that's one strategy that is used to deal with this kind of situation. Another strategy has to do with generating different kinds of requirements. So then we say, okay, this kind of requirement, it always has to fit within a screen. This one is okay if it takes two screens and so on. So we start being some sort of flexibility, but with discipline. And one way to do it is just we have, we classify different kinds of requirements. So that's another strategy. And another one is, well, what I mentioned, we can just say, let's leave this story to bleed to the next screen, okay? So basically, we are acknowledging that in the real world, things are not as pretty as they look just in the diagram or as it was written in the book. You know, we had to accept the natural philosophy of things, that is we have to accept the way the real world works. And in the real world, things are not that pretty. So we have to adjust and we start being creative to be able to fit things into that structure. So there has to be a better way to do this, okay? So what can we do? The big question is, okay, so yeah, that sounds kind of interesting, but what else is there? What is it that we can do? And why do we want to do it? So what we have to take into account first of all, is when we are dealing with knowledge work, and specifically we were talking about software development, we cannot see inventory. If we were working at a factory, we can see the accumulation of work. But when you are talking about software development, you don't know. I mean, just go back to work, you know? And as your manager, what is the amount of our designing process inventory? And he will look at you as if you just got up, he hit on your head and had no clue what you're talking about, because he's gonna say it doesn't make sense while you're asking. But it does make perfect sense. There's a homing, right, from the sound. Excuse me, there's a homing there. He's on the cell phone, he's paying attention to the phone. All right. Hey, girlfriend, hold on. So what we have to understand is that even the fact that we cannot see it doesn't mean that it doesn't exist. There is actually an inventory that we're accumulating on different steps of the process. And what this means is that what we have to do is we have to make sure that the flow of value throughout the entire process is the best possible one. And that's something that we're not used to taking care of. We're just saying, I have a limited amount of work that I'm going to take care of during two, three weeks or whatever my screen size is. But we really don't care about how that is worked within the screen itself. How do the designer, developers, testers, and all of them go about doing that work within the screen? We don't care. It's like, oh, it's autonomy, go and do it. You know really well how to do it and go and have it. And yes, autonomy is excellent. But that doesn't mean that we shouldn't figure out a way to improve the way we're actually creating that value within the screen, for example. So what that means is that we have to understand that there's this aspect to consider when we're talking about queues. So what happens? Well, depending on the size of our queue, we can run into this. So if our queue increases, then we have a longer cycle time, which means it takes longer to finish the work. We increase the risk, obviously, because the larger the amount of work that we have to work on, there is more to consider. And then risk accumulates. There is more variability. Something inside that amount of work has some sort of issue or there's a variation. That variation can trigger other variations. So then that also accumulates. There is more overhead. Seeing that we see with large projects, even with a small batch size, if we start increasing it, even if it's within a small range, we start having overhead. And this compromises quality. Why? Because I think we need to focus more on the amount of work than on the quality of the work. And of course, people lose motivation. So we have to be very careful about that. And what does that mean? Well, what that means is that we have to reduce that size. Why? Well, to attack those issues. So we want to reduce all those aspects. But one important point is to accelerate the feedback and improve the efficiency. So how can we manage the handling of that within the execution? And how can we deliver to the closer in a way that is reasonable? Well, so what we can do is actually to the couple. What is it that we are used to? What we are used to is, OK, here comes a sprint. OK, so everybody is ready. And so we have to get the customer or the representative of the customer, my field, to say, OK, so I have to have my backlog ready. And I have to decide what I want to propose to be done. So then the team takes it. And we do the sprint backlog and so on. We just move on. I'm using Scrum as example, because it's very clean for explanation, but this applies to other approaches as well. The point is, in the real world, let's say that for some reason, the product owner is on vacation and the customer for some reason is on available within the sprint. We are ready to take over. And we don't have anything to take. Or we don't know if the value is up to date and so on. So there's a problem with having this synchronization that happens in the real world. So what will happen if we can decouple that? And also what will happen if we could decouple the value creation with the value delivery? Well, that level of flexibility will make it a lot easier for us to deliver better value to the customer and to reduce dependencies. So this is what we can do. We start decoupling. And the way to decouple is beginning to bring elements into our approach. So either we can just say, well, let's go the Kanban route because Kanban already includes all that. But what if we're not doing Kanban or we don't want to or we can't or this particular team has some allergy towards Kanban? We cannot do it because it inches. Well, we can just bring elements that make it easier to do this. And the decoupling can happen in different ways. So what if we were to decouple not only the fact of when we get the requirements and when we deliver, but also what will happen if we can decouple all sorts of activities in such a way that we get the best possible value flow? Well, we have to consider always the economic factor. So what are the economic reasons behind the ideal methodology? What are the economic reasons behind an approach like Kanban? What are the economic reasons behind wanting to decouple? So we're used to saying, I finish a sprint and I deliver. And over time, if it became accepted the fact that we can actually do a different kind of delivery that has an economic reason, which is my MMFs, my minimal marketable features. Well, another economic reason could drive us to do an MMR. MMR is minimal marketable release. And what that means is what we're going to do to determine our MMR is to consider the transaction cost of the release and the cost of my cycle time. Why is that important? Because we're talking about money in the end. So maybe doing deliveries after each time box, the sprint or whatever it is, can become a little too costly. And we are actually delivering something that is not really ready for the customer or that the customer isn't ready to take. So then why do it? It doesn't make sense from the economic standpoint to do it. From the functional standpoint, yes. From the process standpoint, yes. From the economic standpoint, hmm, question mark, okay? So we had started taking that into account. So then what we have is that if we have a process, a given process, whatever it is, in this case, this Kanban, but whatever it is what we have to take into account is how can I go about flowing my value and being able to deliberate in a way that makes sense? And let me give you an example. So in this case, this is a process for a customer care organization. And so we have different tasks going on. We have two teams working in parallel. And we get to this point and I think it's very clear where we have more tasks accumulated are exactly at the last column. And the last column is guess what? User acceptance. So we have this work happening and this accumulation of work. And what does that mean from the economic standpoint? What that means from the economic standpoint is that nothing is being really done. Meaning if the objective of what we're doing is to deliver a benefit to the customer in terms of value, the customer is receiving zero value. He's just not going beyond this, he's not being delivered. In this case in particular, he's not being delivered because the customer itself is not doing its job. So in a regular point you say, hey, well here it is and you're not taking it as your problem. I don't care, but we should care because basically if we're doing all these work spending all this time and effort and money, to do something that is never going to benefit the customer, what we are doing is we are creating waste. And what benefit does it have to generate waste? Nothing, none, okay? So these customers say, okay, we don't know what to do here, very simple. Take a photo of this, email it to the customer, call them up and say, you know what? You are not doing your part, therefore there's no value being obtained from your end. So what we are going to do is we're going to finish what we are doing right now because we are not going to do things have done, you know, it's not a good practice. It has no economic value, but we are not taking any new tasks to work on because we are wasting our time. So we're just working on this and then we're going to start working on something for another customer. Once you're ready for us, then we will come back to generating value. Two hours after that phone call, this was smaller, okay? The customer realized that the value was being generated but was not being received by him. So what can we do? You know, I'm still having to do this, how can we just be proactive and make sure that this doesn't happen? Well, so there's something that's called cadence. Henry Gnever mentioned the word cadence, right? I know if some of you attended his talk, he mentioned that. So I'm going to dig deeper into this so this is a very powerful point. So cadence has to do with being able to deliver value in a way that actually has economic sense. And what this means is that we can have more than one cadence established to deliver that value. And we can take into consideration different aspects. So these are some of them that we can take into consideration. So let's think about this, okay? Let's say, you know, I'm a very lazy person and I don't like doing my laundry. So I say, well, you know what? I'm just going to hire a laundry service. So I call these guys up, you know, the superlongly.com, 100% customer satisfaction. So I call them up and they say, oh yes, Mr. Maeda, absolutely. We make sure that you get the best satisfaction ever, we deliver great value. So what would you like us to take care of? Well, my personal clothing, bed sheets, table clothes, curtains. All right, yeah, we can do that. And you can trust us entirely. So even if you're traveling, you know, we can, you know, get into your house, everything that needs to be taken care of. And we bring everything back to you every three weeks. And they go, well, you know what? I mean, for the tablecloth, it's okay. The bedding, maybe I'm not quite sure, but personal clothing, having to wait three weeks, I really don't think I like that. I mean, just doesn't work for me because I will have to buy a lot of clothes and they'll have like a ton of clothes waiting, you know? And that doesn't work for me. So then they say, oh yes, you're right, no problem. As we say, 100% customer satisfaction. So now we're going to deliver everything to you every three days. Yeah, that satisfies the personal clothing, but you know, having my curtains, like, you know, every three days taking care of is a little, like, overkill. I'm not quite sure. That's what happens with the current approaches. It's one fixed time box to do everything. So that brings discipline into the team, but that is not really satisfying the customer need. So what if we were to start understanding what is that the customer wants? And one way to do that is, let's say we have different kinds of tasks. So instead of having one kind of task within my value generation, I understand the different kinds of tasks that we are working on. And then we make it explicit. And then what if we say, what will happen if instead of having a time box for everything, we determine a time box depending on what it is that the value of these different kinds of tasks bring? That's point number one. Point number two, what will happen if we do this in an intelligent fashion instead of just making it up? There's just going, I think this will be, okay, no, no, no, no. Why do we actually have a way to really understand that which is what the customer will satisfy, that which will satisfy the customer better? So, and also understand that this can be applied to anything. So this is, for example, in solar development, you could have something like this. Your urgent tasks, you know, the unavoidables, something urgent is going to happen every now and then. What that has to do with tasks that the customer doesn't perceive. We're adding a new server rack, updating the database, stuff like that. We have work that needs to be finished on a specific date. Oh, we need this for Valentine's Day. So this functionality has to be there. Or just in every other task. Why do we just have a way to really maximize the value, the way we deliver that value with the best economic terms? And also being able to do this for any kind of context. So this is, for example, for business development. And all these are real cases. The first one is very typical for development. This is for a company that has a large customer base. This is a solution for a hospital. And this is a real thing. So we have a different way to treat and deliver value. We were talking about an outpatient versus an inpatient, administrative tasks, and so on. Imagine somebody comes into the emergency room and says, I know we treat one patient every two days. Just wait there, it's okay. Hey, I'm dying here. Yeah, just wait, don't worry. So we have to be realistic. So how do we get into the realistic point? Well, we quantify it. Okay? We are used, if we are very much into agile and strong, to do a lot of qualitative evaluation. We cannot stay stepping away from quantitative. But it's actually good to go back and taking that into account. So if we quantify, we're gonna have a huge advantage. But not only that, when we quantify, we have to be careful to quantify properly. So we are used to saying, okay, I have my somewhat Gaussian curve with my sigmas. And based on that, I can know what my variation is. And I can make promises to my customers based on that. But most of the times, we made a mistake of quantifying only up until here, to this part. Or this part here, or this part here, or this part here. So the curve is, it can be quite uniform, or you can just lean a little bit over one side of the next. And we could say, okay, I have the idea of what my behavior is, for example, of how long the tasks that I'm working on, how long the user stories that I'm working on are taking to be delivered. Yeah, I start quantifying that. If I only take this main curve, and I say, I'm going to take my one sigma, for example. And then I'm gonna tell the customer, if it's a customer, 93% of the tasks, the user stories that we're creating, we're going to deliver to you every seven days or less. Okay, that's better than saying we're going to deliver a hundred percent of them every 15 days or less. Because the customer will say, well, 15 days is probably a little too much. Seven days sounds kind of cool, even if it's not 100%. And then we'll say, well, we're quantifying, so we're safe, yeah, we're delivering. And what we will realize is that after a while, the customer will be very unhappy because we are actually not delivering as promised. Say, oh, you lied to me, you know? I don't like that, you know? I don't like being taken advantage of. And it's not that we were taking advantage of the customer, it's just that we weren't taking into account the whole story. And the whole story is taking into account your full data set. Because what you will see is that in the real world, this is the behavior, all these charts are for real things in the real world, in different contexts, okay? This is something from NASA, has to do with gravitational lensing, that has to do with something, has to do with supplier evaluation, that has to do with advertisement, this has to do with customer portfolio management. And what we will see is that we have outliers. We have a main curve, and then we have, it goes down, and then there's a little bit of an extra bump, it goes down, and there's an extra bump. So this usually like one, two, or more. So if you take a larger sampling of your data set, then your promise is going to be realistic. So what that means is that we will tell the customer, instead of every seven days, we will say it's every nine days. And even though nine days is longer than seven days, if we are actually delivering as promised, the customer will love it. And that's huge, because that increases confidence, okay? And at the same time, we are delivering, you know, in a way that really works. So what that means is, okay, we can try that out. So how do we do it? Well, we can take different approaches. We could take a sampling of everything we do, okay? So let's say in the case of an approach like a storm, we only have this story, we don't differentiate. We can take a sampling of everything and make a promise based on that. But we can actually go and do better. And there are different ways to do it. One of them is, you know, the classes of service, the different types of tasks that I showed before. Or we could say we have, for example, for a project, we have capacity allocation. So we have one team is working on this and the other team on this, and these are other tasks, like defects, infrastructure, whatever. And we quantify and we could say, well, if we assign the specific kind of functionality to team one and we understand the way that team one behaves, then we can make a promise based on that. So we could tell the customer, you know, this kind of functionality is going to be delivered to you every nine days or less. This kind of functionality is going to be delivered to you every five days or less. And this work, we're always going to make sure that it's done every 48 hours of work and this is done every half a day or less. What does that do? That actually increases the discipline within the team. It makes it easier to understand what we have to do. It makes it a lot easier to make decisions and we actually deliver much better value. And what the result of this is that the time of delivery is going to start getting better over time. So for example, if you look at this graph here or this graph here, what you will see is that these lines which indicate time to start getting shorter over time. And what does that mean? Well, that means that this project that we will finish sooner, we actually finish it more sooner. Or if not, at least we're going to get better quality. So basically what this means is that we do this capacity allocation and we apply this concept of cadence. We're going to have a really nice improvement which was impossible to obtain before. Before the only thing we could do is we're here, we apply something like this from, we have a really nice improvement and then it goes almost flat. It improves by very slightly. So everybody's really excited because like, wow, look at this big improvement. We have a sprint and so on, but then what happens? It's the same thing, it's the same rhythm, it's the same modus operandi. Why else is there? Whereas here we have a way to actually start going and doing better and better. Okay, that's very, very important to consider. So again, we can apply this to any kind of approach. So for example, if you're talking about scum, what could you do? Well, something that you can do is improve your board. You have your board and instead of just having to do the wing and done, they do in part visualize it better. That doesn't mean that you're going to make it waterfall style, like how development and testing and so on. You practically have a board in which you have, you're doing a column and they subdivide that column in sections and then you visualize where it is that you are within that development part. Are you doing unit testing? Are you developing test code? Is there such a development going on? What is happening with it? And that increasing on visualization added to, I did find that different kinds of tasks will allow you to start doing this kind of quantification. So imagine that instead of being seen, you say all these are say, my regular tasks, these are my fixed deliveries, these are my urgent, et cetera. And you quantify that. What will happen? What will happen to the urgent tasks? Well, instead of being treated as a hook, as usual, we could establish a discipline behind it, which will be something like, if an urgent task comes, what we have to do is, we look at it immediately, we determine what needs to be done, we pull out the resources that are necessary in the order that is adequate. We keep a log of that behavior and we quantify. And then at the end of that, when we finish and deliver that solution, that's not the end of the story. We're going to do root cost analysis. We do root cost analysis and we determine which variation that generated that urgent task can be tackled. What it is that we can do so that this kind of variation either doesn't happen or has a lower impact. So the next time we have an urgent task that has something like this one, we can tackle it better. But then eventually, some urgent task will stop happening thanks to this. So we start having that kind of improvement and we will see it because if we quantify, we will see that, let's say, your typical urgent task takes six hours to be resolved. Then eventually, similar urgent task will take five hours and maybe four, and maybe less, and so on. And that's what we want to do. So what does that mean? Well, that the value to the cost, the delivery of value to the cost might be more efficient without us having to work harder. Where you're working is matter. And we're still keeping our approach of the way we do things. Do you have a question? Okay. Okay, so this has to do with Kanban. It doesn't mean you cannot do it with a scum. So what those numbers mean is the maximum number of tasks that you want to have at that step. And this is what, you know, at the beginning of the talk, I mentioned that in the scum, you have only one week limit, which is the number of tasks on your sprint back load, back load at the beginning of the sprint. So what you can do is granularize that. You can indicate I want that for design, I can only have a maximum of four tasks at a given time for development five and so on. And also there's a criteria that helps us determine how to do this. There's not a magic formula as to, you have these resources or this condition, this is the right number, that doesn't exist. Because it depends on, it's a case by case thing. But what is important is that you can make story or whatever it is that you have, you know, use case, whatever flows from the beginning of your process to the end of your process in the best possible way. That's what you want. Because again, what matters is the delivery of value. Okay, okay, thanks. The best thing that you can do, independently of whether you're doing Kanban or not, I mean, it doesn't matter, it really makes a lot of sense if what you do is make sure that your board reflects your current reality. What is my process right now? That's what I want to visualize. I don't want to visualize what is documented. I don't want to visualize the idealization of my process. I want to know exactly what's happening at this very moment. That's what I visualize. So if you visualize that, then you're going to understand what's going on and information, well, do you guys agree that this is an information right here? In the end, it's a way to visualize what's going on. Then, you know, I have a rich way to visualize my reality. And the advantage of doing that is then, whatever I encounter, that something is not going quite right or that it could go better, then that's an opportunity for improvement. And I can say, okay, now let's analyze this. Let's explore it. Let's get into detail. And how do you do that? Well, if you're quantifying, and if you have a log of activity behind that task, or behind the behavior of your entire section, then it's easier to determine what's going on and then figure out a solution. So what is important here also is, this is not going to give you the solution, okay? It's never going to give you the solution. This just makes it evident that something is going on there and it's up to you to figure out how to solve it. Yes, this is a Kanban ball. So, okay, thanks. So the first thing to understand is that Kanban is not a software development process, okay? You can apply Kanban to a process that already exists, but you cannot say Kanban is my process. Something is already there and you use Kanban to visualize that and then start working on it. So if your process has iterations, then that's fine, Kanban says good, there's iterations here. If your process says there's no iterations, Kanban says great, there's no iterations. So talking about Kanban being iteration-less, for the purpose of that, doesn't really make sense because it's entirely independent of Kanban. But what we are saying here is that you can actually use Kanban and the information that you have, the information they provide to quantify the behavior and then be able to make decisions. And one of those decisions that you can establish is a cadence for value delivery. Now, this is based on this quantification. So you're not saying that what you have is what one person is doing. It's the behavior of your system. So the system's behavior is what allows you to establish that cadence. It's not one person versus the next because that really doesn't matter. We don't care if it's Bob or James who is doing it. What we care is for this type of work, what is that the behavior that allows us to make a promise to the customer. You have to apply these two. Scrum, for example, you can get rid of the spring because the cadence, the different cadence that you have replaced the spring. Henry actually mentioned this often when he stopped. Why are we doing the spring? Because we have this, we have a cadence. So it's a different way to bring this point. And actually something I'm going to take out by this to mention this. If any of you, in your organization, you have a team or your team is already a very highly effective, very mature scrum team. There to remove the spring. The moment you remove the spring, the protein is going to go off because the spring where it was bring the discipline. But if the discipline is already there, it actually starts being an element of friction. We could do more, but now we are limited. So you could try that. Many things have done it and they get shocked by the improvement. Okay, so yes, you want to mature your board and you just want to mature that status. So basically what this means is if I have a project and I have a visualization of the project through a Kanban board, I'm hoping that everybody on the, we end up getting really interesting discussion. A project changes over time. The indicator of a project changes over time. It doesn't indicate the same way as the beginning and the middle towards the end. If the Kanban board is a fingerprint of my current process, that means the Kanban board is going to change shape. And then what you're doing is bringing continuous improvement, but that also means that down the road, as you observe your behavior, you may come to the decision of changing the width. Beware, the moment you do that, all your previous quantification is no longer valid. You start anew, which is okay. Well, I mean, yes, it is true that you have, you know, the similar design, well, the more predictable it is, right? I mean, that's a nice way to do things, but we have to verify that there's not going to happen. And if I force to break things down to that, I'm making more trouble than not. And that will have all these samples. So you have different tasks, but I should probably put this one up here, to make it easier to see, because this one is a bunch of dots. But what you see there is that different tasks are taking different time. Or like here, for example, these are days. So if, well, you know, these satisfy customers' demand within a certain range of time, there are some demands that take longer, and some that take longer. So we have different size tasks, and I would say it's not really the size of the task. You know, it's the complexity of the task, you know? So it can be a small one, but it could be a really hard one to take care of, and it takes a long time to work. Okay? All right, so actually a pretty good time. So they just go into the conclusion. So just to, you know, to graph this up, it's important to take into account different variables to be able to do the decoupling. Okay? So just consider different alternatives, and then make a decision and act accordingly. Do I want to decouple, you know, the way things get into my system, you know, the how frequent or in which way the customer tells me what I need to work on, what I work on, and then how I deliver. Do I want to decouple that? Do I want to take into account, you know, the size of what I'm doing, the complexity, depending on the shape of my board, do I want to do it based on how I allocate my capacity, et cetera? Do you have to make a decision on that, and then establish your cadence based on it? What is important is that the customer is going to be way happier. Why? Because I'm getting my personal cutting every three days, and my bedding every week, and my table cutting every two, and my curtains every three months. I'm a lot happier with that because I don't feel like I'm being fooled, and I'm overpaying, you know, for the service. There is also less work for the customer. If I force, you know, like in the spring, that every two weeks something has to be there, you're like, hey, wait a second, no, I cannot, that doesn't work with me. You know, the way I operate or my needs are such that I cannot do that. So I appreciate that it's good for you, but it's not working for me as a customer. But if I decouple that, then I as a customer can provide to you what needs to be done in a way that works for me without affecting the way you have to do your work. And of course, it increases the team's productivity because we are actually doing the work not only just based on the number of tasks per time box, but we're actually doing it in terms of the kind of work that needs to be done because of the value they provide to the customer, okay? So nonetheless, we have to still keep those good practices which have to do with considering a small batch size that's something to do, you know, establish the cadences. And, you know, for people who are in an agile environment, you are already familiar with the fact that value is more important than time. So those who are new to this, you know, to agile and lean, it's very important to understand that time begins to lose importance as you mature your organization and the value of the leader. Okay, so that's all I have. If there are any more questions, please do. Let me, okay, okay, okay. So what I refer to specifically with this dependency is the dependency of you as a customer having to give things to me in a given phase which is the one that works for me as the creator of value. So you're the customer and I say, you have to give me something to do every week. Like, well, you know what? I can do it probably once or twice, but then I get busy with something else and I didn't have time to prepare what you need and so on. That's what I'm talking about. Is that dependency? So when you tell the customer, you know what? I just need to have work to do, you know, and in this way, this is how I need it. But how you create it and you provide it for me is up to you. And then you can actually help, you know, then make the decision of how to do it. But what is important is that you eliminate that dependency. So you decouple one from the other. It's good to have small things to do, but it's not a good idea to have things smaller than they should. Okay, so you can break it down to certain point and if that critical point doesn't fit your thing, what do you do? Right? So that's what I'm referring to, that you have to be careful about that. Don't make things more complex than they are. If breaking something makes it more difficult, more complex, then you don't want to do that. Yeah. What is what? How do you know it's quantifying? If you see your behavior, then you know. Because there is no magic number. It depends on your process, it depends on the project and the kind of product. That depends, you know, it depends on the team. So there is no one number or one range. What you have to do is you have your own context, you quantify and then you determine what to do. But definitely, the smaller the device size, the better, up to a limit. And one way to actually appreciate this that is independent of hard quantification is the stress level. If you have a large batch size, what you will see that your team is going to be stressed. You start lowering it, you start getting better, but then you see people lowering it and the stress starts going up again. So you have to be very careful. There's actually an exercise to do that. And there's an opening space. Okay, so I am going to do this. I am going to attend a talk after this, but at five, five, five, four, five, I don't know where open space is and I know there's open space at that time. But maybe what we can do just to be on the safe side, once you get to the launch area, you go to this, there's these rooms and the other rooms, right? And then the elevators are on this side. You go exactly the opposite way. There's like some sofas there. I'm going to go back to my room and bring down, you know, a game that we can play to understand this point. Okay, of the stress level. So I will be down to 35, four, five, okay? That's an interesting question. No, I mean, that was an early belief just because Kanban was born there. But I mean, let me tell you, my company, more than half our customers are not even software or IT. So we have applied this into new projects, new software projects, existing projects, software projects, IT, healthcare. So what I tell you there is actually free that we have worked on, healthcare, education, telecom, so, yes, no. I think to think where we have encountered particular challenges. What I have encountered is different challenges. I mean, I couldn't say this particular context is harder than the other. I really don't know. The one that I'm actually curious about is one that we haven't had the thing to put our hands on, the proposal is on the table, but it hasn't been approved yet. I mean, it's for exploit a copper mine using this. But I mean, within a bit, say software and IT, I can't seem to be saying there's actually a pattern. I haven't seen that. Maybe there is, but I haven't seen it. Yes, yes, yes, yes, and actually, well, I'm gonna tell you one right now. So I have this team, they are doing the scrum, and they are being effective. I'm definitely in effect doing the scrum, but it was clear to me that again, the way the value was being generated wasn't really a clock. And I wasn't happy with the amount of value. It was like, this team can do much better. So the only thing I did was, you know, one day I took a post-it. No, no, no, they were delivering value. They were delivering value, okay, they think. But you also have the behavior, and you don't see a pattern of behavior. What you see is that they are just doing something. I can do something else right now, take this task, do some testing, or to the development, do some design. So you see that they are taking tasks and working on them, but there is no pattern. So basically what they do is, I have 15 days to finish this amount of work, and I'm going to do whatever it takes to get it done the best possible way. Of course, we don't want to compromise quality, but that's it. Is your talk, oh, perfect. Okay, we're out, we're out. Let's talk outside.