Laurent Morisseau
Transcript (Translated)
Well, hello everyone.
This is a session in French. I don't know if there are any...
Everyone understands, is that okay?
Welcome to this rather introductory session. The idea is, for those who may not be very familiar with Kanban, to have the keys to appreciate all the other sessions you will be able to see at their true value.
To give you some context, to provide you with a bit more information on the foundations, on the why. Okay.
Is it going well, can everyone hear me or should I use the microphone? Is that good?
Great!
No, thank you.
I'm not comfortable with microphones.
Well, let me introduce myself, Laurent Morisseau, I am from Rennes. For those who have seen some of my sessions over the years, you may have noticed that my photo keeps getting bigger and bigger, it's going to take up all the space.
I am an Agile coach and Kanban coach, and I wrote a book called Kanban for IT, published by Dunod last year.
I will give you a little context on Kanban, the why, and also some practices associated with Kanban.
First, to ensure that the 'how' makes sense for you, in your context. Do you have a flow of requests, and especially a flow of requests of different types?
Like a maintenance team, with enhancements, fixes, a bit of support.
Or even a large project, but with requests for enhancements, technical and functional evolution, things like that. Yes? You are allowed to interact. Yes? Okay.
And is your flow of requests... A little unbalanced compared to your capacity to deliver? Are there any of you in this situation?
A rich problem, that. It's rare. But it happens from time to time.
I think you are rather in this situation.
With a bit of overload, slightly different requests, emergencies to handle, priority changes.
In this case, Kanban is made for you, because one of the objectives of Kanban—you saw with David's keynote that Kanban can be viewed in different ways—I will focus on one,
among others, to balance the capacity of our system to deliver with the demand.
So what does that mean? There are several points of view. It will be about balancing the demand at a microscopic level between planned and unplanned work.
With Scrum, we know the Scrum Master must protect the team from disruptions, that's the unplanned work. Yes, but it happens. When you have an application in production, there are bugs that need to be managed, blocking bugs, things like that.
But also balancing the types of requests, between enhancements, fixes, investment in technical debt reduction, for example,
requests of slightly different types, with different constraints, for example with fixed dates, If you are a software or game publisher, for example, Christmas will be a bit important for you.
So that is a relatively specific type of request that disrupts our work with a strong constraint on dates. And at a macroscopic level between client demand and internal demand,
Also, balancing short-term requests. When we manage by value, we will prioritize creating short-term value, over a sprint, over a release. But we must also adjust our investment in medium-term and longer-term requests, so that what we are producing has sustainability beyond the release. So that's a bit what we will do.
I started with Kanban, but at the time it was rather called flow-based development. I started 5-6 years ago, and in this case, it was on my first project as an independent consultant.
And at the time, I had more of a Scrum hat. However, there was a strong need for agility, but business agility. And I arrived with a solution at the method level, agility at the method level. But it was a context that was very far from the core target of agility. Yet the need was there. The business need, especially to improve lead times.
And the problem is that Scrum did not work in this context. So it was necessary, especially since it was my first project as an independent consultant, to make it a success. So I had to get back on my feet, so I looked for other ways of doing things. That allowed responding to certain challenges. And the challenges here, so the business expectations, increasing user satisfaction, improving lead time, these are expectations, these are strategic challenges that we obviously encounter in our contexts. So there are different ways to respond to them. Typically, to increase user satisfaction, agility, Scrum responds very well. With feedback loops, sprints, demos, so it's perfect. Improving lead times is more complicated. And especially, there are contexts where we cannot improve lead times, even with a Scrum approach.
The need to improve lead times, so that will be a bit of my angle for this session, it is based on two needs, typically TTM, Time to Market, that is, being able to deliver frequently with a frequency that meets the volatility of the market, the needs of... The changing needs of your users. And also, for decision-makers, the just-in-time approach. That is, postponing the moment when I must make a decision as late as possible so that I have the best information to make the best decisions. Whether it's TTM or just-in-time, we need to improve lead times. The problem we encounter in contexts where agility does not work, well, I did my little survey, I had conducted a poll at the time with about a hundred CIOs. And unsurprisingly, the number one problems, the problems that were reported regarding improving lead times, the first is getting all the actors in the chain to work together. Okay, that's easy.
The problem behind it is that each team has its own constraints, its own disruptions, its own productivity, its own way of doing things.
And when we put them one after the other, we are not in a global optimization.
Generally, in the contexts where we operate, we ask teams to improve locally.
And the sum of local improvements does not necessarily result in a global improvement. So that is a fundamental problem we will try to solve when we want to improve end-to-end lead times, that is, improvements that are visible to users. So we have a strong challenge here, and the second, as I said, is to optimize the chain globally rather than locally for the teams. The problem with global optimization is that, as David said earlier, we are in complex systems, and to improve a complex system, we cannot do it predictively, it's very complicated. So we will rather have a pragmatic approach. And an evolutionary approach. That's a real problem. When we conduct surveys, notably, I cite the survey by the French Chrome User Group, one in three projects, for one in three projects, complexity is a barrier to the adoption of agility. Have you perhaps encountered this type of problem?
Yes, no? No, that's not your problem? Yes, there are a few, good. Okay. And so here, we will have to find another solution to improve. Another problem is that one in two problems in Agile also comes from interactions with non-Agile entities. That is also a problem. Yes?
Sorry, I thought you had... You confirm, we all confirm, we've all experienced it, it's generally in the dysfunctions. So, if I come back to this, agility, overall, addresses part of the process,
And we struggle to have, how to say, to grasp, to address the entire chain. And in some IT departments, we have specialized teams. It is difficult to be in the target of agility, that is, a multidisciplinary team with all the skills that allow taking a request and delivering it. In these contexts where we cannot have a multidisciplinary team, what do we do?
The results we observe, well, these are figures that come from Lean, and then from workshops, I regularly encounter this figure in the workshops I do with my clients, it's that overall, if we look at it from the point of view of a request, the request spends 95% of its time in the chain waiting. And overall, 5% of its time,
what we call touch time, that is, the moment when it is valued, when it is transformed to reach a solution. Does this figure mean anything to you? This seems realistic to you. Yes?
From the user request to the moment I use it. So if I want to improve my lead times, I won't try to optimize the 5% At least, that's our point of view. The 5% where I add value, where I transform my request, but rather I have a big lever on the 95% waiting. So there, there is a real lever. And these 95% of waiting time, if I am schematic, mainly come from the interactions we have between teams, or between requests, between activities.
Between two activities, between the business and the implementation, I will have stock. The stock is my specifications that are not being coded.
So here, I am a request, I have been specified and I am waiting for someone to take care of me, to develop me. Ah, it's stock, it's time spent and time lost. And so on, from team to team, from activity to activity. we will have this stock. The problem in our field is that this stock is not visible. Besides, we never talked about stock.
The vocabulary may shock you.
Okay, so here are a few of the issues we will have to address in contexts where typically we are not in the core target of agility, but where expectations are high in terms of meeting deadlines, that is the first thing, and then improving these deadlines.
So we will gently arrive at Kanban, the image we often use.
is to imagine a relay race where the baton is the request. That is, we no longer position ourselves from the point of view of a version, a set of scopes, but rather of a request and we will watch it go through our entire system. We use this metaphor because Scrum has another metaphor which is the sprint.
Sprint on part of the process.
Here, we will have a slightly more global vision and we will have a relay race. The problem I mentioned earlier is that the teams have constraints, a different way of doing things. It's a relay race, but in triathlon. I will go from the pool to the bike, etc. Each with its own difficulties, its own ways of prioritizing all this.
It becomes complicated to do everything when we put all these issues end to end, but these are issues we actually encounter.
And so the point of view here will be to address the system, process, and the rules governing this process. To reduce lead times, we will address the processes and the interactions, interactivities. But that is not obvious. Because we have silos, because we have specialized teams, they do not necessarily communicate. So we will bring in triggers that allow for stronger interaction. Why, if we want to explain a bit why we address the process, I often refer to Deming, you know him, the Deming road, PDCA cycle, it's the one who somewhat formalized empirical approaches, plan-do-check-act, does that speak to everyone? And so Deming's point of view is that 95% of a system's capacity, Well, capacity in France, we are not comfortable with the notion of performance, we call it capacity, but it's the system's performance. These are the fitness criteria that David mentioned in his keynote. So we will rather address the 95% of the capacity that is influenced by the system's design, rather than the 5% that is carried by the people.
That's a point of view.
And we will do it with the right level of abstraction. Because there are several types of Kanban.
Goodness.
If the image I take, if I want to look at a map, if I want to go from one city to another, I will have a certain level of information. However, if I want to go to a specific street address, I will go more finely, a finer level of information to be able to locate myself. So we will find a bit of this same pattern in the Kanban approach.
Do you imagine how? Any ideas?
We will see how at the portfolio level, portfolio management. And we will do it with the right level of abstraction. Because there are several types of Kanban.
Wow.
If the image I take, if I want to look at a map, if I want to go from one city to another, I will have a certain level of information. However, if I want to go to a specific street address, I will go into more detail, to a finer level of information to be able to locate myself. So we will find this same pattern somewhat in the Kanban approach.
Can you imagine how? Any ideas?
We will see how at the portfolio level, portfolio management,
You have these issues, some of you have these portfolio management issues?
Yes, a few. Imagine an IT department that manages 200, 300, 400 projects annually. We can see it as a flow, a flow of requests, but with a project-level granularity.
And well, we will be able to move to flow-based management. There is a switch over there, right? That allows you to change the light.
So we can address this flow management issue at the enterprise level with portfolio management. So I might as well tell you right away that in France, there is very little feedback, very few initiatives at this level yet, so a lack of maturity, a lack of experience. I invite you to experiment with this in your context. But some IT departments are their first pilots on this subject. What we know best is the classic Kanban, that is, on a value stream, on a product family, on a product, and we take user requests from production, that's what we know best.
We also have team-level Kanban. For example, if I focus a bit, this could be the case, as Claude will tell us about it. just after, to have a team-centered vision, with Scrum for example, and within this team, try to streamline our work. Obviously, you see that we do not have the expected benefits of a higher-level Kanban, which is therefore streamlined up to the user. And then at the personal level, we have personal Kanban, I mention it for culture, and we have a worthy representative here of this lineage, who is Guillaume Lours. I don't know if you will talk about it during the two days. No, but you can go ask him anyway. So, we have several levels of abstraction for Kanban, it's up to you to choose where you want to intervene. Well, obviously, generally, it's more like, we will start pragmatically at the team level, and then we will try to go to the product level, and at some point, we will ask ourselves about portfolio management. The organizational challenges of Kanban are therefore to improve agility, but business agility, We will use a method without methodology, I learned that earlier. So we will rather seek to improve business agility with all the issues that come with it.
Improve the predictability of the process that responds to it. If this is an issue for you, as we said earlier, keep the metrics that interest you, and set aside those that do not.
Have an evolutionary approach to change, as we have already said and repeated around the keynote, and then have a risk management approach. These are the organizational challenges. that are behind the camp.
With some operational challenges, concretely for the teams, it is to make the process transparent, white box.
First, it is to identify it and make it transparent to the outside of our team, to the organization. We will decentralize decision-making if we want to streamline throughout our process.
We should not have a central coordinator who makes all the right decisions daily. But we want to delegate this daily micro-decision-making to the teams. And so that each team, each person, makes the right small decision to globally streamline our work. This will be a very strong challenge. Simplify complexity, because we have seen that it is a barrier to adoption. Simplify complexity, meaning we will be pragmatic, we will model as simply as possible the way we work. And when starting a Kanban approach, we will not try to model a system that works for all our requests, for 100% of what we handle. We might start with 80% of what we handle, and the other 20% will not work well at first. But when we have learned and matured enough on our Kanban system, we will be able to improve it to expand the scope of requests, to handle more and more marginal requests, and expand the scope of our process as well.
Develop collaboration. Between teams.
And all this to streamline the work.
So, these were the challenges.
And I would like to talk to you about some organizational contexts that are now switching to Kanban, and in particular all the first clients, all the early adopters of Kanban, especially in France, that we have met.
I would like to know who is already doing it, how.
Apart from all the coaches, the real people who do real work,
No, not you. Not you, not you. Yes, yes, we know. What context are you in?
No, not you. Not you, Pierre. The others, what context are you in? Well, start-up.
There you go, start-up.
Pardon? Internet company.
Portfolio. Ok. Very good. Other contexts?
Team.
Support team, sorry.
It's very complicated.
Other teams, other contexts? So, start-up, support, web team? Support and delivery. Well, the contexts I have encountered, which were the first to request switching to Kanban, are, unsurprisingly, siloed organizations where we tried Scrum. Within a process, development testing. We had teams that were so specialized, so geographically distributed that we couldn't make the leap to agility, we've all experienced that. And also up to pre-production. And so at some point, we ask ourselves, Scrum is great, we have many benefits, user satisfaction, all that, it worked well. Now on deadlines, we still have issues. And we have optimized this part well, but it is not visible throughout the entire chain, so how do we make the switch. And so, we will work upstream with the business and downstream with post-production to have Kanbans that will chain together in cascade, from team to team, to streamline the entire workflow. The light is really strange. I need to do some tests.
The other context I have also encountered in IT departments is the context where we did a first version with Scrum, which also worked very well, or at least worked well, in any case, we want to keep the benefit of this organization for the next versions. But the first version is finished, it is going into production. And well, it worked well, but there are still quite a few, there are some bugs. So support, corrective maintenance, is an activity in itself. And then Scrum tells us... commit to a scope, to a sprint, freeze changes within a sprint, to be disciplined about it. And so, all in all, they decide to have a Scrum team for major developments, and then a more traditional team, I would say, for the corrective maintenance part.
Do you have this context? Yes, well Pierre, you have all the contexts anyway.
Have you encountered this context? So, it's more of a transition context, we want to keep the benefit of agility, but we don't yet know how to manage all this well, and there are problems because obviously we work on the same foundation, on the same product, So, we have interactions that are artificial as a result, with two separate teams. And the idea here is to be able to reconverge these two teams toward a... team with an approach that combines the best of both, keeping the benefits of Scrum, but being able to expand the scope of what we handle and take on corrective work, support, that kind of thing.
And so, it has converged toward Kanban. The contexts of software publishers as well. With small teams that do everything, but they do so much that they handle many products, many clients, support, etc. And in this case, planning even for one or two weeks is just not possible.
So, in these contexts, we aim to work truly in flow mode. Are there any of you in this context? The publishers? Yes, Pierre, are you in this context?
And the last context that is emerging is portfolio management. For example, this is a workshop I did last week. We have five projects across the entire process. This is just the output from the workshop we did last week. Except that behind this, there are 80 live projects.
So, this is just a small view of what portfolio management represents in this context. And here, we still have a lot of work to do.
Okay, so if we look a bit at the domains, the most intuitive to move toward the 'how' is maintenance, the MCO (Maintenance in Operational Condition). This is where we feel we are at the heart of CIP (Continuous Improvement Process), because we have this flow of a different nature,
A flow of a different nature, David talked about having a service-oriented approach. There will be different service levels depending on the nature of the request. A blocking production bug, obviously, we will react much faster, it's clear, than an evolution, than the migration of a minor version of a technical framework, for example, which remains important in the longer term. But we do have different service levels. And what we want is to have a team and a system that can handle these different service levels.
So, application maintenance is really the core target, but what we have also learned from large projects,
is that Kanban can also be very interesting, in fact, wherever there is a good context for continuous improvement, meaning large projects that will span over time,
or flows of small projects, but with a stable team over time.
Even though it is service-oriented, Kanban, we also have real added value in having this approach in these contexts, for continuous improvement and evolution. And then there is the support activity, which is a real issue in itself. You have a Kanban Ops community.
Pierre does not agree.
No, I... Huh?
I didn't include portfolio management. For now, regarding portfolio management, again, we don't have enough feedback yet. Personally, I don't have enough experience feedback to talk about it more than that. So, I didn't include it at this level.
So, the support activity, as I was saying, involves practices that are distinct, which are not exactly the same as Kanban for IT. And so, the community is Kanban Ops. I don't know if you follow it. On Yahoo groups, it's led by Dominique de Grandis, for example. I don't know if you know her. So, it's a real field. Okay, so we've seen the challenges, we've seen the contexts.
What is Kanban? We touched on the subject a bit this morning.
On some slides, I will go faster. So, Kanban, the main principles,
To reduce lead time, again this is one perspective, we will work on small batches, we will streamline our work, that's the first thing, and we will aim to work in flow. That is the first step, working in flow. It's already a real challenge to work in flow.
What does that mean? We will see that later. And then, so that everyone works at the right pace, because if you recall the previous issues, It was that we have teams that follow one another, each with their own way of doing things, their own constraints or speed, All of this needs to be well orchestrated. So, to ensure everyone works at the right pace, we will create a pull system. And all of this makes up Kanban.
Our experience shows that moving to a pull system is quite difficult, that it takes time, and we won't get there overnight. However, implementing flow, that will be our real first step.
Who works in a pull system already?
There are only people who do Kanban left.
That's funny.
You've had some feedback, so those who work in a pull system. It's difficult, you have to take the time, we won't get there overnight. However, setting up the flow, that will be our real first step.
Those who work in a pull system, already.
There are only people left who do the kanban.
It's funny.
You’ve had some feedback from experience, so those who work in a pull system.
That’s our culture, that’s our profession. It’s well established in our profession. So it’s obvious that already working in a flow brings us benefits. But if we want to achieve the benefits that address the challenges I mentioned earlier, we need to move to a pull system.
And that’s not so simple. So, pushing, well, pulling—does that make sense to everyone or not? So, we’re more in a push mode. Well, we’ve mostly known the push mode.
I produce all the specifications if I’m an analyst, and then I push them to the developer or the development team.
I’m exaggerating, and I’m not judging the V-cycle, all that. I push regardless of whether the implementation team is capable of handling it or not. If they’re not capable, it will create a queue. If they are capable, perfect. We clearly see that the risk is creating this queue, thus delays, and we return to the previous issues. The pull system, so this is a change in perspective, and indeed, we’re not used to this in our field—it’s the developer who will trigger it. A little ahead of phase, the work is still very much pulled here. He will trigger it with a little advance notice, he will tell the analyst, 'I will soon need a small piece of spec to implement.' Not the whole spec, but a small piece. The whole spec, but a small piece. There will be triggers. And the triggers, the simple, mechanical practice to move toward a pull system, to have these triggers, to discuss between teams, what we propose to start with is to set limits. The limits that will go. It’s simple, effective, but difficult in reality. In any case, what’s difficult isn’t necessarily setting a limit for a team. It’s balancing all the limits throughout the chain so that everything flows smoothly. The difficulty really lies there. There’s no mathematical or scientific model that will allow us, in our field, to define these limits. So, we’ll have a pragmatic and empirical approach. We’ll try, we’ll adjust, until the flow is well established and regulated.
So, very quickly, how limits work. I took a few somewhat generic activities. For each activity, I set a limit of 3 for the first one, 2 for the others. And now my system is full. Full, there’s as much work as the limits allow.
So the little blue star means that I’ve finished my task, and as a result, naturally, I’ll go take a new one. But to take a new one, I have to push my task into that activity, which is currently full, so I won’t do it now. until activity N frees up a spot, and for it to free up a spot, it needs to finish a task and push it to its neighbor. Step by step, we reach the end of the chain, and at some point, what must happen happens—a spot frees up.
A spot frees up, which means, relative to my limit, the limit being tied to my capacity to do work, so relative to my limit, I now have the capacity to go get more work. So I’ll go do that in the upstream activity.
So I pull a task, which frees up a spot in my activity N, and step by step, it will reach me. And now I’ll be able to go take a new task upstream. So here, we’re in a pure pull system, in the mechanics of it. Well, that raises a lot of questions. What do I do in the meantime? Do I twiddle my thumbs? Do I go help the others? Do I work ahead of phase?
It obviously raises a lot of questions, but the mechanics are there.
Why a pull flow?
I said it—to balance the whole system, but beyond that, in terms of value creation,
avoid waste, inventory. There you go.
Is it necessary? We’re really focusing on value to reduce internal inventory. It’s a word that grates on me—reducing inventory. But that’s a bit of it. So here, I’ve used the words of Corey Ladas. I don’t know if you know him. He was the one who published an essay on ScrumBan a long time ago. It was an essay, but it was a real source of information. And he translated it as follows. We don’t build more features than anyone needs right now. Okay? We don’t describe more specifications than we can code.
We don’t code more than we can test, we don’t test more than we can deploy, and most importantly, at the end, we don’t deploy more than the user can use. That’s also important.
And so, if we go back up the slope, our system—I will only deploy what the user is capable of using now,
There you go, what I can... No, sorry, I won’t code more than I can... I won’t code more than I can deploy now, etc. And I go back up. So we’re really in a pull system that comes from downstream and moves up our process, pulled by our capacity to do work throughout the chain. That’s what will regulate our flow. That’s how you work, then. Pull system—do you manage to go all the way to the end of the chain or not? Yeah?
You can very well start, when initiating a Kanban approach, on a part of the chain, because sometimes it’s quite difficult to go all the way to the users. So we’ll start on a part of the chain, and then we’ll try to increase the scope of our Kanban system more and more. And that, too, will take time. When I say it takes time, it’s several months, a few years—we’re in continuous improvement, we consider we have the time.
There are practices for success, so I’ll go through them quickly because we’ve already seen them. So we have six practices: visualization, limiting work in progress, measuring, managing the workflow, making management rules explicit, implementing feedback loops, and then improving collaboratively.
All the first ones, the first four here.
The goal of these rules is first to regulate our flow. To control our flow.
We won’t try to improve until we’ve regulated our system. Because improving chaos, or with a lot of variability, is very complicated. And above all, we won’t learn.
So that’s what we’ll try to regulate. Once we’re in control, we’ll learn and then improve and evolve our process.
Who goes all the way with the practices.
We're going to talk about Guillaume.
And apart from Pierre.
It's interesting to... That's another discussion, though.
I suggest we talk about it during the break. No, we won't have time to finish.
Okay, so we have foundations, we have a practice, I also propose an empirical approach based on Deming's PDCA cycle.
With a design phase where we design the process. This phase can last a few hours with the team, and we go for it. But a design phase for our system to identify, visualize, and model. Take a snapshot of our system at a given moment, then implement it, put it into action. Put it into action to bring it to life.
And bring it to life to see all the dysfunctions, all the issues it will raise. And all these issues, all these dysfunctions will allow us to study our system and understand it, to learn from our system. And the learning will allow... to improve it and restart improvement loops. Schematically, the continuous improvement approach of the camp will rely on these cycles. And we'll do all this gently. So, likewise, these are the foundations; we'll start where we are.
However, we don't stop there, because otherwise nothing happens. So we'll start where we are, respecting the current process, roles, and responsibilities. Typically, Kanban doesn't come with new roles; there's no Kanban Master, none of that. We work with what exists: project manager, Scrum Master, whatever, team leader, whatever is in... whatever is in our environment. However, we commit to changing incrementally. Incremental will be our cycle turns. And cycle turns are turns that are of the year.
with leadership at all levels, here we are in decentralization, and to give weight to the teams, give them the right to evolve their process,
And let's go!
We designed, we modeled, we took the snapshot, and we have our boards. Here, I've shown you different boards.
Who can tell me—which are very different from one another—who has an idea of which team in these boards is the most advanced in terms of process maturity.
Any ideas?
The one at the bottom?
No?
It's hard to tell.
We still have some strong signals.
The strong signals are that this one... I'll start with this one. I expected some to say this one because it's super clean.
It's spotless. However, it's so spotless that I don't dare touch it. And in fact, no one dares touch it. I've been trying to intervene in this team for six months. The process has never evolved in six months.
We're not in a continuous improvement loop. However, indeed, this one, the team,
And by the way, it's the same team as this one. But a year and a half later, It seems they've deteriorated because this one was clean. And this one isn't super messy. But this is a board that lives so well that everyone, all the people on the team, all these people feel capable of proposing changes to how they work. And it shows; you can tell this board is very evolutionary.
So here are a few examples.
And how does it work on a daily basis?
We'll have a daily meeting with all the teams, as much as possible. And we'll manage the workflow, so this time we'll focus on the movement of elements, Not necessarily on the people—Scrum—the goal of the meetings is self-organization in the longer term. So it's normal to have a format that relies on people. Here, the focus is more on the workflow. So we'll look at which elements are blocking, which we're injecting, which we're going to finish. So more on the movement.
The problem is that... Since we're going to set rules, especially limits, it won't all be smooth sailing. We'll have some dysfunctions, some obstacles. For example, here, activity 2 is blocked.
Blocked by activity 3. It's blocked; it could go look for other tasks. So there's a real blockage here. So the team, day to day, will have to learn to manage this.
And it's typically this kind of blockage that will lead them to talk with others. How can I help you? Can I start something? What can I do, basically? It's all these discussions that will allow us to gain maturity, find solutions, and evolve the way we work together this time.
Well, there are plenty of other dysfunctions. And ultimately, what David was saying earlier, the Jeet Kune Do of Kanban is that Kanban doesn't provide everything in the method; we don't have all the solutions to the issues we bring up with Kanban. However, we'll draw from different methods. Once we've seen our dysfunctions, know how we're going to improve them, how we're going to understand them. We'll draw from different methods. For example, we'll seek to streamline the work. Here, we'll rely on queueing theory. We'll seek to work at the right speed. And work at the right speed relative to bottlenecks or constraints. That's the theory of constraints, which will teach us a bit about how to secure this work. We can seek to reduce variability. If variability is a problem for you, we'll identify the natural limits of variability in our system to focus on cause-and-effect analyses, on why we have... So much variability, so that's statistical process control, ugh! Six Sigma, ugh!
We won't go that far, but they've brought us interesting things, like control charts and that kind of analysis. We'll also seek to reduce delays, so we'll dig into Lean, problem-solving, etc. You see, we have pointers to other methods. which will give us a better understanding. and possibly solutions to improve. There are others; I've listed the main ones. We're talking more and more about real options; it makes more and more sense when we go to the project management level.
We continue our loop. We designed it, it resulted in dashboards, we managed it daily, it fueled our conversations, we were able to see dysfunctions, we studied our system with different models, and now we are evolving it, we will adjust our system. And here we have quite a few levers in the adjustment. In particular, the process. Should I add a buffer between two activities or not, precisely to absorb or secure against a bottleneck? We will evolve our process. Or remove a finite queue, for example, if two teams have learned to work together so well that they no longer need this intermediate stock, this intermediate queue, it happens.
We will also evolve the rules, the explicit rules that allow elements to move from one activity to another.
Obviously, the one that makes sense is to adjust the limits. We will rather seek to reduce them.
To decrease queues, reduce delays, and also variability.
Now, we won’t reduce them too much because we still want to maintain flow above all else. If we reduce them too much, we may end up with a dam effect and releases, and then we are no longer in the flow.
So, adjust the limits empirically. Also, the elements, these feedback loops, if we have issues with blockages or congestion, will also teach us to better split, to split at the right granularity the elements that will go through our entire system. This is real learning.
And so, just enough, we will adjust the system just enough to provoke the next round. And learn from it.
Learning from the Kanban system, we will evolve it and evaluate it so that the system evolves, and this will be an evolution specific to each team, as we said again this morning. Learning from emergent behaviors, you see that Kanban, that’s all there is to it. There are few practices. However, there are many emergent behaviors or emergent design patterns, like two-level boards, swarming—we were talking about swarming, but I’ll talk about swarming now because Claude has...
found better vocabulary, service classes. All of these are emergent design patterns. It’s not because you don’t use service classes that you’re not doing Kanban. But on the other hand, you will eventually be led to identify service classes because, precisely, there is variability, there is an opportunity to create different levels of service.
And so we will learn from these emergent behaviors to move toward greater organizational maturity on the part of the teams and also on the part of management.
So just for information, I’m telling a little story about this maturity evolution in the very good collective book, *Rupture Douce*, you can browse it at the back, there’s a copy. So, Kanban, an agile method, a project management method, a task management method? Yes, it could be a bit of all that, but... No, it’s a method for leading change through process improvement to move toward pull flow. But be careful, continuous improvement, all of this while respecting the teams. Respecting the teams means that it is the teams who bring about the change and, above all, who bring it about at their own pace. When you’re in operations, you can’t absorb change all the time, so you have to accept that this change be slow. And it applies in different contexts, V-cycle, engineering office, That’s a bit of the irony. Of the thing, meaning we’re returning to the engineering offices of industries with a great new method, Kanban, which they’ve known nothing about for 40 years.
And I’ll finish with that, particularly in Scrum. And so you have a great session following this with Claude Aubry to Kanbanize your Scrum, so to know concretely what that means.
And that’s it.