Romain Couturier - Kanban avancé, comment regénérer son système ? (FR)

[00:00:16] Good evening everyone, and welcome to this session, advanced Kanban, how to regenerate your system. My name is Romain Couturier. I am a big fan of Flokone, former Kanban link in France. I fell into Kanban when I started as an Agile coach almost 10 years ago now, and it's true that today my missions are evolving. Much less agility, much less Scrum in the teams, and much more Kanban. I was already doing a lot, and now most of the Kanban support that I do, well, it's becoming widespread across many, many teams. And I must admit that I am still amazed by all, by everything we can discover with, with this approach. And uh, so, amazed is not necessarily entirely the right word. There are certainly, there are obviously some bad surprises. Uh, which allows me to check, by the way, if you see my, if the video feedback is good. Can you confirm that the video feedback is good? Yeah, okay, because I have the reverse video feedback.
[00:01:27] So, not always only good surprises. For example, this article from Le Monde, uh, taken from, uh, October 18, 2020, uh, there's pretty much everything to shed a tear in, in, in this title. Uh, when we read things like that, we, uh, and yet there are interesting things, huh. It talks about tools, indeed, it talks about Trello, Jira, Asana, Monday, Wrike, Master Task and so on. Uh, but I tell myself that we, we missed something. Uh, and what we missed is that we are at a stage of simplification.
[00:02:01] Of simplification of concepts, while we are precisely on a theme of complexity. Now it's true that in the, in the statement of this conference, I, I indicated that, uh, it would be good to reposition a bit what we could call a normal Kanban. So, uh, we're going to set a fairly simple framework again, generally, it's true that they're not entirely wrong either in the IT world. What they have going for them is, it's the columns. That's pretty much all they managed to get out of it. Uh, so we're going to find ourselves with a system with a visual management. Uh, in this visual management, we're going to obviously find a stock, uh, obviously, we're going to find things that will be, well, we hope, in any case, that they will be delivered. Uh, the titles of the columns will not be by status but rather, rather by activity. The statuses, we will rather find them inside, uh, and we will rather find something with in progress and finished. The only exception will be the second to last column, which will not have finished, since the finished of the last column is rather the in progress. Uh, in each of the columns, cards, tickets, requests will circulate, it can have several names. And we know that on, uh, on this, on this part, we're going to find a certain amount of information, where we hope, but that's a big, big subject and we'll come back to it later. That there is a value indicator, uh, and that's sorely lacking in a lot of systems. We hope there is a field somewhere that allows us to know at what moment this card started. Uh, and then obviously, if we want to do a statistical analysis that I will present later, we hope there will be an end date, which will allow us to calculate what we call the delay. Obviously, so the first Kanban principle, visualization, second Kanban principle, we hope, we obviously hope that there are. Limits, limits to, uh, limits to each of the, each of the stages of the system. These limits will relate to the, rather to the number of elements that are inside, not so much to the capacity of the people. We will also have the application of, uh, of the third Kanban principle, explicit rules. We're going to find somewhere, ideally visually, or in a wiki, uh, well, all the rules that are, uh, that are documented by the, uh, by the team. Uh, the rules, uh, the rules of passage, the rules of exit. All these things. We will also need to, uh, to maintain the system, which is the fourth Kanban principle. What are the associated rituals for maintaining, uh, this system?
[00:04:52] Uh, to maintain this system, we will perhaps need indicators. Uh, the one in mind that we can note is the control chart and then a cumulative flow diagram. That can always be useful.
[00:05:09] Uh, what we can also more commonly call CFD. That's what we could call a correct Kanban. Uh, one last thing, also, to be sure that we specify, well, that everything is clear for everyone. We will know which team member, uh, is rather specialized in each of these activities, knowing that a team member is not reserved for a single activity. So that means we'll have visualization of the team.
[00:05:34] Uh, if we want to do, uh, that's what we could call a correct system. So obviously, uh, everyone will have their, their, their criteria. Me, the reference point that I will, that I will take, we could say, it will be, it will be this one, it will be the, uh, in short, the Kanban simulation. Uh, if you haven't played Kanban, you may have played Get Kanban, uh, one, a storytelling that is, uh, that is more interesting than the other, I think. Kanban has at least the specificity of being able to address a much wider audience.
[00:06:09] And then, once we have this, uh, once we have this correct system, well, we're going to be able to, uh, ask a certain number of, of questions, uh, when we've, when we've asked that, uh, where do we see the bottleneck areas? That is, the areas where there is, uh, a lot of, a lot of tickets, what are, uh, what are the limits, what are the entry rules? Uh, the exit rules, uh, the passage rules that I mentioned earlier.
[00:06:35] What are our rules, how do we share them? Uh, do we have a timeout that is set for certain, for certain requests? Who maintains this system, who are our requesters, by the way? It's a whole lot of questions, who are we, who do we address? Uh, to whom are we going to deliver? Uh, and then, the last Kanban principle, how do we improve our flow, evolve and improve is a bit at the heart of the device.
[00:07:01] Uh, all these questions, you could find many, many, many others. If you haven't read it, I recommend this, uh, this white paper that came out, that's a bit old now, but that, uh, explains it very well. That of, uh, of Christophe Achouan and of Johann Nordin, who intervened at, who, who intervened at the Flokone a few years ago already, and who list, well, a whole bunch of questions that it's still useful to ask oneself.
[00:07:33] Nevertheless, among the, when, when, well, when I work with the teams, so when I work with teams, they're not necessarily very large teams, they're teams of about ten people maximum. Uh, it's, it's rare when we have a, a correct Kanban. Uh, a certain number of, of, of bad practices remain and persist. So, bad practices when we are, uh, when we are, when we are practitioners, but it's true that, uh, there are things that are still a bit troubling to observe. The first is that when we talk about, when we put in place a Kanban system, it's generally, uh, to fluidify. And we know that, uh, to fluidify, uh, even if we could demonstrate it again, but that's the object of other conferences that I've been able to deal with, and others have also done it, uh, it's the implementation of limits. How many Kanban systems do not have limits, or if they have them, they do not necessarily have them at all stages.
[00:08:37] Among the bad practices, also, uh, now, we agree, there's no murder either, so it's not, it's not, it's not critical. Uh, but whoever says we don't have limits, means that, well, we're going to allow ourselves a principle of going back. And these rollbacks are, they are, they are not very healthy, and I, I generally don't encourage it, uh, because they don't allow us to understand that, well, to turn a team towards precisely the flow of the stream, and a rollback means again that we are in a, in a management and a steering, not by value, but again by, by occupation and by skills. And a rollback means again that we are in a, in a management and a steering, not by value, but again by, by occupation and by skills. Among the other practices that we're going to, uh, that we're obviously going to find again, uh, and, and further accentuated by the absence of limits, uh, it's the fact that we are, uh,
[00:09:31] the explosion of multi, and I'll come back to that later. Uh, multi, so multi, multi-task, multi-request, multi-client, multi-product. Who, uh, who, when pushed to the extreme, well, will cause what we call interruptions, simply. Uh, interruptions that have, uh, catastrophic effects. Uh, interruptions that are also caused by a good professional conscience, in teams that want to do well, well, they will have a completely natural capacity to change, to go from one task to another, to go from one project to another. We have aggravating factors, uh, obviously, among the bad practices, it's always delicate to, uh, to, to, to evoke them. But we have, uh, we have God, uh, who, who, uh, the emergencies, the urgent God, who is a factor of, of, of provoking urgency. Uh, some organizations actually testify that they are multi-gods.
[00:10:29] Uh, some organizations actually testify that they are multi-gods, which means that it perturbs, uh, obviously talking about limits, uh, it's, it's, it's very complicated. Uh, we have, uh, among the other bad practices that I could cite, globally, the fact that this, this flow remains static. That is to say that, well, contrary to other approaches and other methods, Kanban does not prescribe any role. And so, as there is no role, we have to find someone responsible for, well, first for ensuring the logistics and the maintenance, the updating. It's much less true now that we've switched to remote, uh, with the COVID, but, uh, it will certainly come back when we return to in-person. And then, among the, among the bad practices that we can still find, it's, uh, well, globally, people who testify from time to time. Uh, of a form of, of, of overload. Now, it's true that, now I'm exaggerating, if all these bad practices are in place, we could globally say that the team has not truly switched to Kanban. But, a correct Kanban, uh, generally there are one or more of these things that are there and, and, and despite everything.
[00:11:51] When, uh, when we ask these people, when a Kanban has been well implemented, uh, the real first tipping point that we can observe, uh, it's really when the team members are serene. I think that a team has found, uh, has found its interest in using Kanban, even with some bad practices, huh. When, globally, the team testifies to much more serenity, uh, that it's much less in the act of suffering.
[00:12:24] She is much more in anticipation of everything she couldn't do. I don't know if among you everyone managed to cross this passing point, if in your teams, uh, it testifies to a serenity. Uh, you can say it in the comments, that will allow me to see a little, a little activity. If you have found this, this tipping point. The tipping point generally on a team, it intervenes, uh, well, a team of a few people, less than 10 people. Generally a few weeks, a few months, uh, it's, uh, it's the time it takes to, uh, to purge, uh, to purge all the, well, all the, all the demons a bit, all the debris that there is, all the, well, this, this purge. Uh, I often talk about toxic systems. The detoxification of a system, uh, we observe it, it is, it is accessible. Uh, if only because we put in place, uh, that we establish a correct system. I'm not even talking about trying to improve it, just trying to put a correct system in place.
[00:13:28] a correct system. And that's, and that's where the starting point of this, of this conference is, because we managed to achieve that.
[00:13:39] We are happy, the approach has been sponsored.
[00:13:44] Uh, people showed patience, because waiting several weeks, several months to have these results, uh, well, you have to be patient, it's the interest of having, uh, of having this sponsor. And now? And now that we're serene? Now we're happy.
[00:14:07] And how, how could we, what's, what's next? Uh, what continuation are we going to give to that? Uh, if we take a little height, we could rely on any, uh, on any theory of change. Me, the one on which I lean enormously, is that of, of Virginia Satir, uh, but globally we always observe the same things, that is to say that over a period of time, the team had a, a level of performance. Uh, but globally we always observe the same things, that is to say that over a period of time, the team had a, a level of performance, it wasn't terrible, generally when we put in a system, it's because when the system is going badly, so when we slowed down, when we put all these strategies in place, well, we worsened the situation and now that the team has regained serenity, it feels better. It feels better and it finds a new plateau of performance. We are fine here at the conference, we are here.
[00:14:58] And that's the big question that drives me. And once we have that. What's next?
[00:15:10] Because you have to be honest, uh, we, people, uh, this, this part is called, it's called the Valley of Despair, it has a name. Uh, so when we, when we hit the Valley of Despair. The first time, we didn't know. So, well, we went a bit with the flow and we said, oh, it'll be fine. In fact, even if they told us, it didn't go well. But there we are saying, okay, now we have to continue. The sixth Kanban principle, it's, it's, it's difficult, huh. Uh, continuous improvement. In fact, that's the principle we'll find in all good approaches and in all good approaches.
[00:15:47] Imagine doing something like that, uh, all the time. Now, even if we say that these are small steps. We need to find energy again. What are the weak signals? How can we give, give new momentum? And it's, it's quite paradoxical, it's a, it's a paradox that is notably evoked in the, in the fifth discipline of Peter Senge. Uh, we know when there will be a triggering factor. Uh, it's when there will be an emergency. Moreover, most Kanban system implementations that are very effective and that, well, have better results, it's because there is an emergency. The emergency is generally because we are, we are underwater. And what is the emergency once we've solved the problem? And what Peter Senge reminds us is that emergency situations are rarely the best situations, and it's a bit of a paradox, uh, that we're going to wait for the emergency situation to get moving. Whereas the best conditions are met to start the next change, it's when we are calmer. And we are not educated for that. We are not educated, we are not mentally ready, uh, and why, why impose this on ourselves again?
[00:17:00] So we're going to, we're going to look for, we can find some leads. Uh, we could find a lead in, uh, in David Anderson, uh, who, uh, well, once is not customary, to share, to share his work. Uh, with the Kanban Maturity Model, which is a helpful matrix, uh, there, uh, we're not going to, it proposes a, a, well, a maturity model, a scale, that's interesting, it allows us to see depending on the, depending on the six Kanban principles. Uh, that proposes a, a, well, a maturity model, a scale, that's interesting, it allows us to see depending on the, depending on the six Kanban principles, what we can expect to put in place. I don't know if this linear logic, uh, it is applicable in, in human systems that are varied, complex, different, multicultural. But in any case, it deserves, it deserves to exist, uh, but it remains theoretical, and it's true that we all know the difference between theory and practice, it's that, well, in theory there isn't any, and in practice there is. And it's true that we all know the difference between theory and practice, it's that, well, in theory there isn't any, and in practice there is. So, to regenerate your Kanban system, uh, I don't have a miracle recipe, however, I, I, I submit a number of questions. In any case, these are the questions that I, that I try to ask when I intervene. Uh, and we're perhaps going to finally return to the basics, that is, the first principle, visualize your system. And so, what do we see? What do we see in our system?
[00:18:24] If we're, we start from the hypothesis that we are the calmest, uh, it's perhaps in this best, in this best period, that we could tidy up. Tidy up his Kanban board. So there are great workshops that work, you can use the whiteboard workshop which is very, very good. Uh, but well, tidying it up just to tidy it up, uh, how to improve my visual management? And for that, we could rely on a theory that we talk about very little, uh, in any case, I use it when I work in graphic facilitation, uh, it's what we call visual Gestalt.
[00:19:04] Uh, if there are people who are familiar with Gestalt, uh, it's the declination of the application in the visual domain of Gestalt principles, that is to say that the whole is more than the sum of its components. Which allows us to understand how our brain works.
[00:19:23] Uh, these are also, visual Gestalt is also a concept that is used in design and interface ergonomics. And what you need to understand is that there are a certain number of, a certain number of laws and we can, we can fight against these laws, uh, well, we'll always have trouble getting rid of them. The first law that I would like to share with you is what we call, uh, the law of similarity. Uh, the law of similarity, similarity, excuse me. The law of similarity is the fact that your brain will have all the more ease, uh, to absorb information from the moment the information resembles each other. Uh. Which allows us to understand how our brain works. Uh, these are also Gestalt, visual Gestalt is also a concept used in design and interface ergonomics. And what we need to understand is that there are a certain number of, a certain number of laws, and we can, we can fight against these laws. Uh, well, we're always going to have trouble getting rid of them. The first law that I would like to share with you is what we call the law of similarity. Uh, the law of similarity. Excuse me. The law of similarity is the fact that your brain will have all the more ease to absorb information from the moment the information resembles each other. Uh, if we look at our tables and particularly at digital tables, everything looks alike. Therefore, our brains will have a very great difficulty in segmenting the information. Now, a visual management board is made and must be designed when we talk about information radiators, precisely so that it is easy and accessible. It should be legible, that we can deduce it, analyze it quite quickly. So be very, very careful, Gestalt laws, when they are poorly used, will have bad effects, when they are well used, they will have good effects. Uh, a pleonasm to remind you that everything does not necessarily have to be similar on our boards. Conversely, color and the use of color will be a structuring element. So let's be attentive to what we make similar and let's also be careful about the choice of digital tools. Uh, I'm not sure that those presented in the article of the world respond well to this Gestalt law. Among the other Gestalt laws that we will also find, there is what we call the law of continuity. The law of continuity is the fact that when we present elements that succeed each other, well, our brain will have a lot of trouble. not to dissociate them and especially to see them as a continuous element. Similarly, it can be interesting as a principle to see a continuity of things. For example, if I want to visualize the breakdown of a feature into different components, why not? Nevertheless, the fact of aligning things with each other will make us see a continuity. Is that really the message we want to convey? Another law that we will find in Gestalt is what we call the law of proximity. The law of proximity means that your brain, whatever it says and whatever it does, will not be able to dissociate two elements that are close to each other. You cannot see two triangles independently of each other simply because they are close. If the elements are close, knowingly, it allows us to make a good association, if elements are close, when they shouldn't be, we will make bad associations. We can therefore question our visual management and behind all these post-it boards, finally, is the information structured correctly? I have some doubts, including on the boards that I can also accompany.
[00:22:15] I am not the perfection. It is therefore a permanent questioning. In any case, this visual Gestalt allows us to reinvest our boards in another way. Among other laws that we will also find, generally often in visual Gestalt, we have what we call the law of common destiny. Uh, perhaps less interesting, perhaps less, more difficult to envisage, uh, it's uh, the fact that elements that converge will lead us to see. Uh, we're going to have a common destiny of different elements that point towards the same, towards the same place. Excuse me for my cold. Another law that we will find in visual Gestalt is what we call the law of closure. The law of closure that allows a brain not to need the entirety of the shapes to be able to complete the shape it lacks. For example, you don't need to know that my square is closed.
[00:23:13] You understood it. Uh, all that, it's uh, all that is, all that is possible because there is a principle that governs all that, uh, and it's the principle. of past experience. What does this principle of experience, this principle of past experience mean?
[00:23:36] Uh, it means that the more you are subjected to, uh, tables, the more you are subjected to visual information, the more you will be. uh, influenced in its understanding, or on the contrary, the more you have seen the same information. The more you will perhaps go straight, the more we will make shortcuts by telling ourselves that we understand them. The question arises then of reconstituting these tables, perhaps of reinventing them, of revisiting them. Having in mind a law that I, that I, that I forgot and that I will add at the very top, uh, which is the law of good form. That is to say that the law of good form.
[00:24:13] reminds us that when we submit a visual thing to any brain, it will have a form, not a just form. And if someone tells us, for example, that this table is incomprehensible, it is undoubtedly because this table is truly incomprehensible. That is to say, his brain cannot segment the information. It's an invitation. What do we see? Uh, that's the first question.
[00:24:39] But on Kanban,
[00:24:42] we saw that there is also, in any case, I discovered through all these years of practice, that there is a whole aspect that is not there. In any case, which is more difficult, and I, I, I wondered why, in fact? Why was it, why was it absent? Uh, especially on the indicator part. And in fact, uh, the question, it, it came to me, uh, not very, uh. it wasn't very long ago. Do you like math?
[00:25:10] Because clearly, there's a whole field accessible on Kanban when you like math. So it's true that when you don't like math, uh, well, it's a bit more complicated. But it's okay, we can still do remedial sessions. We're going to try to do one, we're going to try to do one together. I'm thinking especially of those indicators that we build when they exist, or when we find them in the tools, because often they are built. Uh, the first is the control card. The control chart presents uh, a cloud of points. Generally, you have, uh, so there in ordinate, you have the deadline, and uh, in abscissa, you have uniquely the, the, Excuse me.
[00:25:53] Uh, you just have one point per card, in fact. So when a card comes out of the flow, because it's finished. We're going to calculate its deadline, so I remind you, end date minus start date, which gives us the deadline. And so we're going to trace, we're going to trace a point. Now the question is how do we do that thing? Well, in a rather logical way, in a rather intuitive way, we are going to use, well, try to make this kind of curve. Or we could try to calculate the average.
[00:26:28] So point number one is to make averages, that is to say, you add them up, you divide by the number of points, which gives you an average, an average of delays.
[00:26:36] Uh, if we, so obviously it's going to be more or less fair, but it can be a first indicator.
[00:26:45] If we read the book by Sam Savage, "The Flaw of Averages." Uh, we're going to realize that there's going to be a, literally the trap, or the problem, the flaw of the average. Uh, it's, it's the dispersion. That is to say, if I draw the average on. Well, let's say it's going to be roughly here. Uh, well, it's not, it's not quite the same, the same. Besides, everyone will have noticed that my average is probably wrong.
[00:27:14] But it doesn't really matter for my presentation. Uh, what will therefore interest us is, uh, these are the deviations. The deviations from the average. These deviations from the average, uh, they have a name, uh, when we make, uh, when we sum them, it's called, it makes zero. So suddenly, to calculate the deviations from the average, we calculate what is called the variance. The variance, you take each deviation from the mean, you square it, that is to say, you take each deviation by itself, and you sum it. Which will give us the variance. So it will therefore be the sum of the squared deviations. And to have what interests us, that is to say the standard deviation, well, we're going to take the square root of the variance. And so it's this standard deviation that interests us.
[00:28:06] And we will have all the more ease to project uh, uh, deviations, uh, finally to project estimations, uh, estimations on the delivery times when a request comes out, we could say, and in any case, that's what we're looking for.
[00:28:23] We're going to say on a basic Kanban, a Kanban, uh, between inverted commas, again, normal, uh, correct, uh, we're going to say on average. We know that a request will spend X time in the system. A more advanced version would be to take into account the deviations, in order to be able to focus. to work on uh, what Laurent Morisso in his book "Kanban pour l'IT" quotes "Shuwart," uh, the causes of dispersion.
[00:28:53] The causes of dispersion, we will look for the, uh, the limit points. Limit points will be points that will be at the top or very at the bottom. Uh, and he therefore cites two causes: there are the common causes. That is to say, well, these are things that must happen in this way, and special causes that rather have an exceptional character. And so the analysis of these, uh, of these, uh, of these causes of dispersion, uh, will allow us to therefore reduce the standard deviation and by reducing the standard deviation.
[00:29:22] We will thus be able to create a much more predictive system.
[00:29:26] This is a statistical approach, but it doesn't stop there. Because, uh, as I'm sure you like math, we'll be able to rely on other statistical tools. Uh, one that I took much longer to understand the interest and usefulness of, is Little's Law. Little's Law, which is cited in almost all good books and which is difficult to see in use. We're going to give an example to really understand what Little's Law is. Uh. Uh, if I have a dozen flowers to plant.
[00:30:06] Uh, which, moreover, I should have taken an example with many fewer flowers, it would have made me much less drawing to do. 2, 4, 6, 8, 10. Uh, and that I manage to pick. to pick two flowers, so I, I have ten flowers. I pick two per minute. And so, logically, the question is, how long will it take me? Yes, I, I, I take the time to pick the flowers. I talk to them, I observe them, I look at their color, I look at their grain, if there are no small insects on them. But above all, the question is how long it will take me to pick all these flowers. Normally, even if you don't like math, you will have done the division quite quickly and you will have understood that it will take me 5 minutes. The operation you performed in your head is relatively simple. I have work in progress. What we're going to call the work in progress in English, the WIP.
[00:31:11] Uh, there, I have my flow, that is to say, two flowers per minute.
[00:31:16] And so it gives me my delay to pick all these flowers. So we made the WIP, the work in progress divided by the flow, equal. the delay.
[00:31:32] And that's exactly Little's Law. Now, as we are on a division, so I restart my division, WIP divided by flow equals the delay, and as we are on a division, we can invert, the WIP divided by the delay.
[00:31:49] Is equal to the flow. And that, that interests us, is to know what is the flow of our system. Uh. An example of an application that I was able to do recently on a system of an organization. Uh, on which we had measured that on average, and I remind you that.
[00:32:16] the pure average is not simply sufficient, but since my team was starting, I didn't have to. overwhelm them with the standard deviations and the dispersion, I just relied on the average. Uh, the average flow of this team was five features per month.
[00:32:35] Knowing that, uh, the team has a WIP of 50. that she has a stock of 1200.
[00:32:44] And that she also takes about twenty additional requests per month. The question is therefore, when will it end? Well, it's exactly that. Plumbing CAP, thank you for the comment. It's exactly that. Uh, well, these are operations that will, uh, that are quite simple, and especially beyond the operations, beyond the math. It will help us to make predictions, but above all to make proposals. for system improvement, by observation and by measurement. In this case, we proposed, I proposed a multiple strategy. The first is to limit the number of, to limit the number of elements that enter, that is to say, to limit the entry.
[00:33:39] Uh, to divide the WIP by two. Because obviously, when we understood Little's Law. And when we see how managerial decisions are made. Well, the factor we want to rely on is the flow. That is to say, it's almost the only one on which we have no leverage. It's like telling people to produce more. Uh, this injunction. Uh, this injunction does not work. And so Little's Law, it guides us and helps us to educate the governing bodies to explain that, well, the other levers precisely to increase the flow. It will be to work on the, on the, on the delay. Uh, and it will be to work on the WIP. So we're going to reduce the, I suggested reducing the WIP. Obviously, to reduce the stock, and I will come back to that later, and then to increase the flow, well, it allows us to reposition and re-justify the interest of breaking down and granularizing the need.
[00:34:38] Please excuse me for my cold. Granularize the need, so it will question us about how, what is the granularity of the elements we inject. These are things that are sometimes necessary to re-justify and re-explain.
[00:34:58] But if it was sufficient as a mathematical tool. It wouldn't be funny. Do you like math to the point of using, uh, using three tools?
[00:35:16] The third and I think it's the most, uh, the most powerful is the CD3. Uh, for those who know, uh, it's the use of, uh, the use of the cost of delay. So that's uh, uh, I'm going to take again the example given by Don Reinertsen in his book "The Principle of Product Development Flow," where Don Reinertsen explains the interest of having an economic model for requests.
[00:35:54] The interest of this tool is to be able to prioritize and to know which element should enter. Because here we focused a lot on the output, on the flow, but also a whole question that arises about, yes, but then which one enters, this one, that one.
[00:36:07] What is the strategy? To properly understand what this notion of, uh, of CD3 is, uh.
[00:36:18] We're going to take an example where we have a functionality that has a release duration of one week, another of three weeks, and another of two weeks. Uh, knowing that the cost of delay, that is to say the economic impact of not releasing this functionality, would be evaluated arbitrarily. at uh 3,000 euros for each. So, on this example, all functionalities have the same cost of delay. So the question arises, what is the element that should come in first, then in second, then in third? Logically, you will have found that it is this one.
[00:37:04] Because it will allow me to, well, number one, exactly, uh, it's quite simple. Let's take another example now.
[00:37:13] Uh, always with the duration and the cost of delay. But this time we're going to have, uh, the same delay. So we're going to put all these elements at three weeks. All these functionalities have the same delay to come out. Except that the cost of delay for this functionality is, I don't know, for example, 1,000 euros. Uh, for the other 3,000 euros, and for the other 10,000 euros.
[00:37:40] Always the same question. In this situation, which functionality should we take first?
[00:37:51] And indeed, as specified in the comments, the WJSF, the Weighted Job, uh, Weighted Shortest Job First. It's exactly that.
[00:38:06] Well, in this example, it's this functionality that we must take first. In both cases, we performed the same operation. And that's the CD3. It's the cost of delay divided by the duration.
[00:38:28] This cost of delay, now we're going to take it in another situation.
[00:38:35] Much more real and much closer to reality. That is to say that we don't have the same duration for each of the elements of the system. And we don't have the same cost of delay either.
[00:38:50] This operation will therefore lead us to question, uh, what are the elements that we will take first. It's the cost of delay. divided by the duration.
[00:38:29] This cost of delay, now we're going to take it in another situation.
[00:38:35] Much more real and much closer to reality. That is to say that we don't have the same duration for each of the elements of the system, and that we also don't have the same cost of delay.
[00:38:50] This operation will therefore lead us to question which elements we will take first.
[00:39:01] And it's a question we're going to be able to ask ourselves about each of the elements that make up our system.
[00:39:10] This approach requires having an estimate of the cost of delay, globally, it means we have a value-based approach and that we are able to associate an economic model. Most of the organizations I accompany don't use this tool, not because they don't want to use it, but because they can't use it because they don't have the cost of delay. That poses an enormous problem, it means that today we need to accompany organizations to establish economic models that are necessarily false because they rely on hypotheses, so that means taking hypotheses. And no doubt that it will also be necessary to take another variability index, which is that all demands do not have the same cost of delay. Which brings us directly to the notion of class of service. Classes of service with normal classes, intangibles, emergencies and fixed-date requests. So we'll have different curves.
[00:40:15] So that requires management, though. Uh, this this this this management, uh, it's not neutral, but it's something that is necessary if you want to make decisions that are rational and that go and that go in the right direction. Also taking into account the classes of service, well, that's the beginning of implementing a risk management strategy.
[00:40:40] And you can imagine that if we start doing that with everything in our flow, well, in any case, that's what the team told me the other day, they told me but you're crazy with all that we have in the flow, we can't do it. So,
[00:40:51] Which brings us to another question.
[00:40:56] Do we have the courage? Do we have what it takes to throw away? Why should we have the courage to throw away?
[00:41:03] Do we know how to lighten our systems today? Uh, lightening systems, that is to say, the pure and simple suppression, the abandonment, uh, we can we can we can do what we want, uh, that is to say, really to to to purge the systems to the point where there is almost nothing left inside. Uh, nothing left, that is to say, everything that would be the the the things that are pending.
[00:41:29] All hopes, disappointed hopes, because today we throw away, but we throw away by oversight or we throw away by weariness. How many, what is the the the duration, uh, well, the the date of beginning of the oldest ticket in your system? For certain, uh, for certain teams, it's, I'm always surprised to see that we can go back up to, up to 10 years. Uh, a request that is 10 years old has been abandoned, in fact. But this this inability to to to throw away, uh, it's it's a bit like when we clean the house, that is to say that at some point the requests, uh, well, when we have things at home, well, we're going to we decide, either we throw them away or we put them, either we put them in in in boxes, uh, but we know very well that we won't go back to the boxes. And it's a form of abandonment, except that here we're not talking about a toy, uh, we're talking about a request that was made by someone, and so the act of throwing away, the act of deleting, uh, it's about having the courage to go see people to tell them, well, no, we won't process your request. And so it's about establishing a new relationship. So we see that behind this act, it's much more than a simple technical objective, and no doubt that this act is slowed down today, uh, notably by the the the problem of the infinity of the infinite capacity that our systems have to be able to store tickets. When we are at home, we are forced to throw away because we generally have no more space in the cupboards. On a tool, it's much more difficult because megabytes, gigabytes. So why throw away? And that's a real, that's a real invitation. So that's why I'm proposing a new workshop format, uh, which is the antithesis of brainstorming, uh, it would be a brain destroying workshop. Uh, I don't know what form it would take, but anyway, what would be fun is that we would spend our time buying, there, and then we would leave a workshop, we would come out with a lot of things, and we would come out with not much. And and I find that pretty cool when you manage to do it, you get the feeling of doing it well. Um, it's not that far in the end from this, it's a bit like the happy sobriety of Pierre Rabbi, but applied to the world of the tertiary sector.
[00:43:40] Another question we can ask ourselves, are we adventurers, adventurers of organizations? Because doing it in the hypothesis
[00:43:50] where we manage to clean up.
[00:43:57] We would nevertheless remain in a local optimum. However, in Kanban, we work on the principle of the principle of systems. A system, when we work on our own Kanban flow, it feeds other other areas of the organization. And it is fed by other areas of the organization.
[00:44:26] If we therefore consider that our flow is not an A to Z flow but for example C to O, we therefore consider that we are only on a sub-part of the puzzle.
[00:44:36] Our challenge would be to accompany the other organizations to implement their own Kanban system because they are exactly in the same situation. And we know today that with Kanban, we are not limited to IT. Contrary to received ideas.
[00:44:54] The application of Kanban in the field of marketing, in the field of commerce, in the field of support, in the field or even of technical services. Everything that will be of the field of ideas, that is to say, of project management, of the management of things that pass through several functions.
[00:45:13] That's courageous because it allows us to reconnect. We talk about teaching, about reconnecting to other systems, about going to see them, about going to see other humans who share exactly the same constraints as us.
[00:45:30] But there, obviously, uh, it questions it questions the the the object, the vision, the shared vision, uh, our common culture. Well, there is one, there is one culture that is common, and it's not only common within organizations, it's common perhaps more broadly to human beings, in any case in the organizations that we can see. Um, that's the culture of multitasking. And so this culture of multi-tasking,
[00:46:04] uh, what is its impact on you? What is the impact in in the organization? We still need, despite everything, to re-explain what the impact of multitasking is. Uh, that multitasking is not dirty and that it's not serious, as long as there is no issue of delay. However, as soon as we have an issue of delay, the fact of segmenting tasks, the fact of putting work on hold, the fact of segmenting projects, if it's not tasks, we can even go back to a project level. Uh, this this hyper parallelization, structural, unregulated, undiscussed, which is quite absolutely staggering, when one knows the the the catastrophic damages,
[00:46:51] uh, the worst being, for example, burnout, generally they are people who work on a lot of things at the same time. The the and and for that, there is just need to, well, we're not going to redemonstrate it again, but just to re-explain it, to understand that all of this is a change of context, and that the change of context,
[00:47:10] cannot be quantified, little quantified. It is not taken into account in the estimates, and so it's not surprising that we see movements emerge like no estimate. which should rather be renamed to uh no old school estimate, but which should rely on other forms of estimation and therefore on uh on measurement, as we saw as we saw previously, notably with control charts. And there is a huge challenge to work on multitasking not only at the team level but at the organizational level. That behind this multitasking hides the question of silos, because uh if we are parallelized and multitasking, uh, it uh well, it creates strategies of uh of isolation. And so, well, when we're going to when we're going to be dependent on other other services, and then we're going to come and interrupt them. And what is quite paradoxical in a system is that when we try to collaborate, well, in the end, we spend our time making people lose time with whom we are supposed to work.
[00:48:20] The change of context, uh, will also create delays, create delays, create enormous urgency. How slow are we?
[00:48:36] Another, it's it's always astonishing to see how much we can, well, this natural, it comes back at a gallop. This parallelization, it's not about suppressing it, but just about regulating it. And we tell ourselves and we remind ourselves of a principle that we find a lot in Kanban but but elsewhere, uh, we always talk about starting by finishing and stopping starting. That often leaves traces the first time because we are because we are underwater, and then after that we forget about it.
[00:49:17] We have to go see the others.
[00:49:21] A bit like, it's really this, starting by finishing is accepting that we're going to be slow. And finally, what Kanban tells us again is that the slower we are at a given moment, the faster we will be. And that, for example, we could quote La Fontaine, uh, to do the, we could take the fable of the hare and the turtle. Uh, that would mean that if I start by stopping, it means that I'm only interested in what I can do, so I already align what I do with my abilities, so I already start to value what we are capable of, what we are capable of achieving. Uh, that means that we also question the question of value.
[00:50:09] So which brings us to the subject I proposed to you earlier.
[00:50:16] And what also brings us back to the notion of urgency. I think it's one of my best LinkedIn posts that I made during one of my Kanban coaching sessions a few years ago. I had posted the the result of a work session where
[00:50:30] where the client, I specify, it's not me, the client had had put in their work rules that an emergency does not exist. Everyone queues. And it's true that in these new times, uh, which were already a given but are even more so now. Uh, it's perhaps a reminder of the relative inefficiency of using the word emergency and perhaps of putting things in perspective as an emergency. I I am convinced, but that only concerns me, that we generally have very, very few emergencies, given the situation we can experience today. And reserving this urgency for true emergencies that need it, our systems and our Kanban will only be better off.
[00:51:21] And I wouldn't want to end this intervention and this conference by having only a technical and mechanical, logistical, fluid approach. And perhaps come back to this essential question that we forget. How is the flow today? How are the individuals who are actors in the flow? We can have a flow that has super sins.
[00:51:50] Superstats, uh, we can have a flow that uses the latest advanced techniques, but globally, how do people live their flow? We can perhaps do a visual weather exercise. Are people happy in your system? If they are, then so much the better. That's exactly what we're looking for. Uh, finally, it's perhaps not worth bothering them with something they don't need. But if they have a request,
[00:52:25] what would the request be? It can't be a request driven by the Kanban system. It can't be Kanban driving the request. When I talk about people, I'm not just talking about people who are in the system, it can also be the users. Are people today satisfied with the system they're in? that they see. Is the measure of client satisfaction done? How many organizations don't measure it at all, or how many people in organizations aren't aware of it? And that's a bit the condition for continuing on your way in this time management and in these priorities with Kanban. It's perhaps to focus on the demands that the individuals who make up the system have. And it's there that we will find, I think, a pool, and it's a pool of action, in any case, to improve the Kanban system, and it's also there, because there won't be any, that we will learn,
[00:53:20] if we are in the improvement of the system, a virtue that I discover and that is difficult when one is a fan of Kanban, which is called patience. Waiting for people to have a request is long, but if they are happy, that's perhaps the main thing. In summary of this conference, advanced Kanban, we were able to address uh well, the notion of always having a correct Kanban, first level, the different checklists to apply.
[00:53:54] The real tipping point between a correct Kanban and an advanced Kanban is really achieving serenity. I told you about visual Gestalt to re-question your visual management, some mathematical tools known or in any case that deserve to be deployed more, the control chart, uh Little's law, the CD3, the courage to suppress, to go see the other services.
[00:54:19] To constantly question ourselves about the impacts of multitasking, to question our slowness. To be even better, and above all, to take good care of the people who are in these Kanban systems.
[00:54:33] Thank you, and now I'm open to all questions.
[00:54:53] It's very difficult to, I, it's this configuration at a distance, but your messages are very, very pleasing, and it's true that it's very, very frustrating not to be able to

Transcript (Translated)