Stéphane Wojewoda
Transcript (Translated)
I don't want you to be with me, it's just that you won't learn anything. I'm sure you have plenty of great conferences to go see.
No, but I prefer to avoid disappointment. I prefer to avoid disappointments at that level.
So, I'm going to share a little secret with you. I hate talking. Actually, I'm a big chatterbox and I hate talking because I think it's the worst way to get a message across. The best way for me is for you to practice. And so, I tried to think about how to make you practice, so, touch and understand, to give a conference where I will talk. The metric part. So for that, I will use Kaut. So the way it works with you is that in teams, so you will form groups of 2 to 4, you will take at most one phone, one tablet, any device to connect to kaut.it, you will enter the PIN code, you will give your team a little name, and there will be questions along the way that will spice up my presentation. Okay? So above all, don't stay alone, meet people. Usually, I do a little warm-up, so everyone is all fired up, etc. The format is only moderately suitable.
And since we have 45 minutes, the format is even less suitable. So, I will introduce myself very quickly. I am Stéphane Vaugevoda. I do two things in life. The first is that I am an agile coach during the day in the teams at Renault Digital. I am very happy, I joined not long ago, and it's a great team. The second is that at night, when I'm not sleeping, I am the chief editor of InfoQ and InfoQ France, which today and yesterday covered all of Lean Camp in France. We are very proud to be a partner of Lean Camp in France for many years because I always see lots of great conferences and meet lots of extraordinary people. So for me, it's really a super nice thing. Now that I've said all that, let's stop chattering about nonsense, because my life doesn't interest you, and it only mildly interests me, and let's get to the heart of the matter. So I'll say it one last time, we're going to work with K.O.U.T. So get into teams, take one phone per team. You have K.O.U.T. IT, the PIN code to enter. Give your team a little name.
We will have lots of questions coming up along the way. The winning team will have the right to take one of the two books, generously offered by the Lean Camp France organization. It's more fun when there's something to win. It's always more fun when there are things to win.
And here we go. Is everyone ready? Is everyone ready?
Are you ready? Are you almost ready?
Are you ready?
There we go, I have lots of teams, great.
Alright, let's go. So, I will present the basics of Lean-Kanban and in particular the metrics around Lean-Kanban, through a little almost-true story. Okay, so before that, we'll go through some common basics, so we agree on a few fundamentals.
So the classic graphs. First, this is a Kanban. It's the Japanese ideogram. It's good to remind where it comes from.
And in the IT world, it has turned into something more like this, that is, a card. Objectively, at the base, at Toyota, the Kanban is a punched card that was used to measure stocks. And so in the IT world, it has translated into something quite close to a user story, which if you finally put on a nice board. And as a coach, what I like about Kanban is having lots of things around it. I like to have the 'who'. I like to know who uses it and who pulled the card. I like to have elements on complexity, I like to know how much it could bring in. I also like to know when... There is a class of service, I'll come back to that at the end. And what I particularly appreciate and which for me is mandatory, is this part here. That is, all the dates that explain when you moved from one state of your Kanban flow to another. It's very useful for everything that follows. In fact, it's the main element for everything that follows. If, like me, you are a fan of Post-its, it's really great. And that means that once you have finished your cards, you need to transfer all the dates into an Excel file or any other database. If you are more into digital, you have tools that do this very well. I won't name anyone, you probably know them all. Ah, there is one last element that is interesting about Kanban cards, it's that you can add lots of things to them. So I particularly like to have... Is this working? No, it's not working. Ah yes, it's this one. I like to have these kinds of little things, which are elements that provide additional visual indications. Typically, this, for me, is a blockage. It means that the card is blocked at one point or another in the flow.
Go ahead and take pictures, I feel like a rockstar.
Next step. We talked about Kanban as a card, we will talk about Kanban as a board. Kanban as a board is something that looks like this. So this is the starting stage. In fact, the perfect Kanban for me is one that has nothing in it. It's wonderful, no waste, nothing at all. So it's great. Generally, it looks more like this. And then suddenly, we say OK, well. And in fact, it will quickly look like this, meaning we will end up with lots of blockages. Alright, do you have any questions about this? I will avoid asking you too many questions because the timing is a bit tight. So, generally, a common board looks a bit like this. And then, as a coach, I tell myself, I have a first problem. And so, what is the problem? It's long, we only start in August. Are you ready? Are you ready? So, I will give you 90-second periods so you have time to discuss among yourselves. Oh yeah, it's made to be...
It's made for that. So the question will come, what is missing from this first Kanban board?
What are the shortcomings? What is missing from this first Kanban board that I showed you three seconds ago?
You should have it. There, this one.
These are the answers. Oh damn, you don't have them. So, red means no. Actually, it's perfect. Blue means service classes are missing. Yellow means work-in-progress limits. And green means rules.
It's perfect, service classes.
There is one or more.
The important thing is to have at least one.
Is it that you answered too quickly, I suppose? It's just a particular thing. Hey there! It's that it was good.
Great! I see lots of really good answers.
And so you have the board as I see it in the first version. So actually, what's missing from this board just before? In fact, two elements will be missing to meet the basic principle of Kanban. These are the first steps when setting up a Kanban model. Which are here work-in-progress limits. And what's interesting, we see them less clearly, here you have rules that explain how to move from one step to another. These are the essential points to start a Kanban. If you don't have them, you're not really doing Kanban. You're doing proto-Kanban. That's what some people call it. So that was the first element. I say bravo to the first teams who answered very, very well. The others, you still have a little time to succeed and win, don't worry.
Oh, I'm sorry.
That's the technique. Come on, let's continue. So we talked about the cards, we talked about the board, we're going to talk about the third essential element in terms of basics, which is the cumulative flow diagram. The cumulative flow diagram is a bit like the alpha and omega of any good Kanban approach.
Concretely, what do you see? You see all the elements of the workflow you've developed piling up over time. And so, they will progress over time. So, what does it show? It shows the evolution of the workflow over time. You have a little legend at the bottom.
In gray, it's the backlog. So, how many elements do you have in your backlog? And with the colors, you see how the different elements progress within it. This will allow you to tell a lot of things, and it's quite close to a burn-up chart, it's just that you see the different phases or steps in which your work items, so your features if we're in the IT world, go through.
The next element, which is my second favorite, that's why I showed it to you, is blocked items. Well, it's something we don't always do. It's actually quite close, in fact, it's calculated exactly the same way as a number of bugs. That is, at any given moment, you will look at how many items are blocked in your workflow. What's it for? It just tells you, OK, I have a lot of items we're working on and a certain number aren't moving anymore. You can set rules for this. Typically, if it's been in the same column for two days, we can consider it blocked. Or anyone can raise their hand and say 'I'm blocked' means 'it's blocked.' And so, you put a special post-it note. If you're using tools, you can even put special tags directly on your features for it to work. The issue is like bugs. If you have a large number of blocked items in your workflow, it means you have a problem.
The third, which actually takes two different forms, is what we call a cycle time diagram. Well, there are plenty of very specific discussion topics about cycle times, like whether we're talking about tag time, lead time, cycle time, but we're not going to get into that detail, for me it doesn't matter at all. Cycle time for me is the time that elapses between an item, between two phases of your workflow. The simplest in the IT world is between the moment I start developing and the moment it goes into production. Or it's tested by your PO or other fun stuff if you're doing agile.
What's it for?
It's the first element to discuss with your PO. And in this form, which is just a scatterplot, a cloud of points, you just see that here, the first items in the workflow took two days to get out. This one took a day. This one took six days. This one took five days. It's not very representative. But it allows you to start discussing. The second format, which is more interesting, is this one. You will take your points and make a very simple histogram of what the distribution of your different items is over time. And that, that's the basis. If you don't have that, you will never be able to do service classes. And the issue of service classes is completely out of stock. I'm telling you right now, I won't talk about service classes, except at the end if you want.
I think we've covered it, that's exactly it, the three main elements. So concretely, what diagrams do you have? And as a graphical analysis element, you have the CFD, you have blocked items, you have cycle times.
Are you happy so far? Did I tell you interesting things, all that? Yes, well. So that was the basics so we're all clear. Now, I'm going to tell you the story of a team that is almost true. It turns out that today, when I prepared the conference, this team didn't exist, I didn't know them. Since then, I've really met them, that's the funny part. And so, it's a magical team, they are wonderful people. Objectively, they are really wonderful.
And they get along very well, they've been doing agile for years, they've been doing Scrum, they're at the top. Then they say that agile is starting to block them a bit. And then they went to Lean as in France and they say, 'Ah, I'd like to try something new.' For example, if we tried to start implementing Kanban in our team. As a coach, today, you're sure, what's it for, why? If you pull an idea like that, it's not very interesting. But you're crazy, you want to experiment, it's a good idea.
And so the team's workflow is this one. It's a very simple workflow, it's roughly the one I showed you before. There's just one difference here, we've added an intermediate step, which is a bit what Romain Couturier was saying yesterday morning.
We are doing it and it's finished. This is the only difference compared to the previous element. So you have the entire backlog, you have what is ready, you have what is going into development, what is finished developing, etc. The difference between testing and acceptance is that testing is internal to the team and acceptance is done by any happy PO who is very much in love with their product.
And so, we are starting with a first joint step.
So, first sprint. First sprint, here is the result after 10 days. They call me and say, Stéphane, here is our first sprint, what do you think?
What do you think? That's what's funny. What's the problem? What is the problem when you arrive at something like this? I press a small button.
So, compared to the previous step, the first ones are at the forefront. Who is at the forefront? You are in the lead, but not by much, because Real and Ectra 1 are just behind you by between 3 and 5 points.
So, the next question is coming. So, what is the problem highlighted by this first CFD? You have four answers. Red, the backlog is too large. Blue, there are not enough testers. Yellow, the infrastructure is not ready. Green, the acceptance criteria are insufficient. Backlog too large. Lack of testers, infrastructure not ready, insufficient acceptance criteria. What is the correct answer? What is the problem?
There are not enough testers.
The blue one. Blue, there are not enough testers. So, what do we see? Backlog, ready, we are in development.
So, I'm coming back, I'm coming back. Red, backlog too large. Yellow, the infrastructure is not ready. Green, the acceptance conditions are insufficient. Backlog too large. Lack of testers, one item ready to go, insufficient acceptance conditions. What is the correct answer? What is the problem?
Testers are missing.
The blue one. Blue, testers are missing. So, what do we see? Backlog, ready, we are in development.
So I'm coming back, I'm coming back. Red, backlog too large. Blue, testers are missing. Yellow, the infrastructure is not ready. Green, the acceptance conditions are insufficient.
I think we're reaching the end. You have 35 seconds left.
It still doesn't want to.
I was going to say do a rollback, but I'm not convinced that would solve the problem.
I have 12 answers.
Attention, attention, we're reaching the end. 10 seconds left.
Red, backlog too large. Blue, lack of testers. Yellow, one item ready to go. Green, insufficient acceptance condition.
And the correct answer was the green one. Ah, why?
We'll go back.
The green answer is that the acceptance conditions are insufficient. What do we see?
What does the CFD allow us to show? What does the CFD show? Here, you have a backlog that keeps climbing, climbing, climbing. You have an element that goes into separation. And you start developing from the second day. You develop, develop, develop, then suddenly there's a blockage. Then you stay exactly at the same level of development, then you have a second blockage, then you actually stay with two blockages the whole time. Nothing is finished being developed. You can't finish the development. So concretely, you don't lack testers, you still haven't finished developing. So concretely, this is what a diagram, a CFD, is for in this type of case. In fact, what do you do as a coach or just as a team introspection? You go see the people. You have developments started, but you have nothing finished. This is the very opposite of the goal of doing Kanban. The goal is for it to get out. It's that you manage to release features, to release your work items. So, you will discuss with the developers. I'm not with my developers often enough, so I'll go see them. Why is it blocked? What do the developers say? It's not very clear. What is not clear? The feature, how we finish, how we know we're done, it's not clear.
The good... coach, but whether you're lean or otherwise, in fact, it's, okay, concretely, you don't have the acceptance conditions to know when you're done. You have an item blocked because you're missing an acceptance condition. So concretely, what is the problem? It's that the rules don't exist. You haven't set the rules, the team hasn't set the rules to move from one step to another. So you can't finish. What do we do in this case? It's quite simple. We set rules. We start discussing. We initiate a discussion with stakeholders about what the rules are that allow us to say we're done. It stops there. The CFD only allowed us to highlight this. Ah, the team is very happy, they say they will finally be able to move forward. We started sprint 2. And sprint 2 looks like this. So, I'll go into a bit more detail with you. Sprint 2 looks like this. So, what do you see? You see that here, your ready items suddenly collapse. Because you had a lot of things, you were sure they were ready, but in fact, they're not. So, you'd better bring it back down. Ah, yes, it's... Bravo!
Thank you!
There's color, it's wonderful. I won't tell you about the state of the first one when I was told, 'Oh no, but Stéphane, we can't see anything at all, I spent my weekend resizing all the colors so it would be good for those who are colorblind, those who don't see the...' There you go, that's the problem with a CFD, if you're colorblind, it quickly becomes unbearable. So what do we see on this magnificent CFD after 10 more days at the end of the second sprint? So the end of the first sprint is here, first action, it drops, the ready items suddenly decrease. You still have your elements here, then suddenly, hop, that's it, it's good, you managed to set your acceptance conditions, we start moving forward again. We continue to develop, the backlog goes up, you have features that are ready again, okay, that's not bad. Here you have a bit of white, which means the development is finished. Here, you are in testing. You have testing, you have testing. There's a blockage. You have testing that is finished. You have another blockage. Here, you have a lot of things that are finished. Then, all of a sudden, we finished a lot of development. And now, you have a lot of blockages again.
They call me as usual. Stéphane, we have the impression that something is wrong. In your opinion, what is it? Coach, what do we do? What is going to happen right now? Question! Go to K.O.U.T. Come on, we're starting again. I'll tell you the results of the previous one right away because it's important.
We were at Aubrac 1st.
L'Ectra has taken the lead. Oh wow, L'Ectra has taken the lead with 1900 points. They are burying everyone. The question seemed a bit difficult, so we'll try to ask a simpler question for this one. So, what's wrong with this... What's the problem?
Sorry, I'm pressing the button. Yes, what problem does this CFD highlight? I'll let you display it. So, as we were saying, in red, the backlog is too large. In blue, the WIP limits are not respected. In yellow, there aren't enough testers. In green, the business team is not available for acceptance testing. I repeat, red, backlog too large. Blue, the WIP limits are not respected. Yellow, there aren't enough testers. Green, business team not available.
This one, here? This means... No, he's not necessarily twiddling his thumbs. It just means that development is finished.
In the sprint, they finished the devs.
End of sprint, they finished all the devs.
I'll give you the two colors again. Red, backlog too large. Blue, WIP limit not respected. Yellow, not enough testers. Green, business team not available for acceptance testing.
You have 14 seconds left. Attention, attention.
I have 14 answers and I forgot to check how many teams I had. That's a shame. Are you all correct? Let's say you're all correct.
And so the correct answer is...
Ah! The correct answer was yellow, there aren't enough testers. So the why. Let's get into the why, that's where it gets interesting.
So the why is here. What do you see? We're doing graphical analysis. You have six items in the development section. And when you look at the progression, it goes up, up, up, but you only have one that is pulled into test. Objectively, and you have exactly the same issue here, you have items that are there, but you only have one that is pulled into test. And here, it holds, here, you see, there's still something that, as a coach, always shocks me, meaning here, you see you almost have a smooth flow, you just have one item here, then you just have one item there. What's strange is that you don't see this progression here.
The coach who is used to it, intuitively, it smells like testers who are not very available. What do we do? We'll start discussing with the team.
So you have six items that are at the end of development, but you don't have anything that is pulled into test. Why? Ah, the tester left for a critical project. Help, it's urgent, we need to take it quickly. So your team that was supposed to be self-organized, in which you had all the right skills, suddenly, one skill is missing. And so you can't pull the workflow. So what do you do? One suggestion among others. You can start by doing cross-testing. You do pair testing. A developer will test another developer's features. This allows you to move up a bit or accelerate. And then, use the tester when they are available to do a deeper test. And then, we'll try to recruit a new tester because as long as there is... This will allow us to go faster and advance value creation. There you go. And so that's really what this CFD tells you. The CFD only tells you that. Well, it only tells you that because you've discussed it; there could be other causes, other issues. But here, concretely, because you've discussed with the team, you can see that you have too many items in development, not enough in test, and so there is a problem in your value stream construction.
That was a very good retrospective, team. Thank you. Let's try to keep moving forward and move on to a new sprint. Phew! Oh wow, this is starting to hurt the eyes.
So, at the end of sprint 3, 30 days later, what do we see? Well, first, I think, wow, we see a lot of colors.
That's rather positive. We finally see some value. The yellow thing you have there is the stuff that's deployed. So there are things that have gone into deployment.
But there are still a lot of things that are blocked and then suddenly unblocked. But we keep one blocked, we don't really know why. Our issue from the previous sprint was the testers. Okay, we have a test curve that roughly matches the development format at the end. Not bad at all. Good.
In the recipe, there's something weird. Yeah, indeed, in the recipe, there might be something weird. So, you are the team. We can continue.
With a question. What is the problem here? Ectra is still ahead, but Justello has really caught up well. Who is Justello?
No, Justello. The Justello team. Hey there! We can tell that some teams are in good shape.
I don't see them. I'm sorry, I don't see them. No, I don't see them. No, no, I'm sorry, I don't see them. Come on, let's get going again. Hop, hop, hop. So, question. What's wrong with this CFD? Let's restart.
What's the CFD problem? So, careful, 4 answers. As usual, I'm not very innovative. The backlog is too large. WIP limits are not respected. There is no tester, the business is not available. If you think it's a repetition, it's indeed meant to be. I repeat, these are the same answers as last time. The backlog is too large, it's red. WIP limits are not respected, it's blue. In yellow, there are not enough testers. In green, the business is not available.
The business is not available.
Red, backlog too large. Blue, WIP not respected.
Green. No, yellow, not enough testers. Green, no business.
I should have one team left that hasn't answered yet.
Everyone has answered. "Hey there!" "Oh, but you've become real professionals!" Almost everyone answered correctly. Sorry for... So, the backlog is too large and probably an additional difficulty, but that's not the one for now. Objectively, regarding the workflow, the real immediate difficulty is not the size of the backlog. The difficulty is that we are not delivering to production. This is one of the first basics of the Lean approach. The challenge is to secure the client and thus deliver value. So, the size of the backlog is not a question for now. The question is that right now, you have a lot of elements in the production flow that are not delivering value, which have been objectively developed. You have all this that has been developed but is not yet tested by your business or not yet accepted. The team's first problem is this one. Okay? Hop! So, we discussed. So, we have a lot of elements blocked at the start of the sprint, it happens, that's great.
We have one element that remains blocked. And then, concretely, when we discuss with the team, because ultimately that's always the most interesting question when you look at graphs, it's not about looking at the graph. We're not here, I'm going to deliberately tackle the Lean Six Sigma and Black Belt specialists, the challenge is not the indicator, the challenge is what the indicator or graphical model allows you to do. And so, what does the graphical model allow you to do? It allows you to initiate a discussion with the team about what the root of the problem is. It's the 5 whys of the Lean approach. And so, what are the 5 whys? In fact, the business is not there. The team hasn't sufficiently communicated with the business about how to properly accept the functionality. And as a result... Move forward on a deployment mode. We're on sprints, but they remain very theoretical sprints. Okay? So, what is the right action or what is one of the possible actions if you are solving a problem? The challenge is to streamline acceptance and thus make the client more available. One hour a day, half a day, it doesn't matter. Regularly, the client is there to accept the delivered functionalities.
As a good coach, normally, after 3 sprints and nearly 30 days of development, My stance is to say, guys, now you should be almost autonomous. It's a good thing with the results we have here, it proves you are almost autonomous. And so, we can aim to go after 50 days.
Ah, a lot will happen in 50 days. In fact, over the additional 20 days. So, two sprints have passed. And my question will be completely different then. Because as a coach, I am almost out. The team has become autonomous; they have understood the way of working. And so, I will come back rather to ask them, but what have you done? Not to check the scores, but to try to challenge them, to try to make them progress even more. And see if they still need a coach or if they can manage on their own. So, after 50 days, here's what happened. I'll give you 30 seconds, one minute to try to understand and detail. I will help you detail. We stopped here.
We stopped here. End of the first, end of sprint 3. What do we see?
First level.
Second level, here you have a lot of elements around this that finish, that finish, that finish, but here you have a kind of plateau. As a coach, I have almost stepped out. The team has become autonomous; they have understood the way of working. And so, I will come back rather to ask them, but what have you done? Not to check the metrics, but to try to challenge them, to try to push them even further. And see if they still need a coach or if they can manage on their own. So, after 50 days, here is what happened. I’ll give you 30 seconds, one minute to try to understand and detail. I will help you detail. We stopped here. We stopped here. End of the first, end of sprint 3. What do we see?
First level.
Second level. Here, you have many elements around this that are finishing, finishing, finishing. But here, you have a sort of plateau.
You have already understood what will happen next.
Exactly. Ectra is still first. Racing 1985 is trailing by not much. There are 200 points. Cannes BE is at 2400, so they are just behind as well. Watch out, there is a challenge. And we are on the second-to-last question. So the next question is the... But what has the team done? What problems has the team solved on its own during these two sprints?
That’s a good question.
What problem has the team, the CFD, highlighted? And so, what has the team done to resolve these problems? So, I’ll go over it again. The backlog is too large; we reduce it. Developers are missing; we recruit some. Deployment is too slow; delivery every three days. SLAs are not defined; the team defines them.
What has the team done during these two sprints? I’ll read them again because we’re getting into somewhat touchy stuff. Red: the backlog is too large; we reduce it. Blue: developers are missing; we add some. Yellow: deployment is too slow; delivery every three days. Green: SLAs are not defined; we set them.
SLAs are not defined; the team defines them.
That’s green.
I’ll repeat one last time.
Red: the backlog is too large. The team reduces it. Blue: developers are missing; we recruit some. Yellow: deployment is too slow; we deliver every three days. Green: SLAs are unclear; we define them.
No, you cannot change your answer; that’s why you have 90 seconds. Oh dear!
So there were two correct answers.
So, what are the two elements we can see here?
Here, when you look, you have a backlog size that is extremely high. What is the team’s realization? You get here. You are here to start the ready phase; you have a monstrous stockpile. In fact, you are preparing waste.
The team’s growth or development pace will not allow working through the entire backlog in a reasonable timeframe. So, what is the right approach for the team on this? We reduce the backlog. We negotiate with the PO, with the stakeholders, to say that reasonably, it’s pointless to have a backlog like this. It’s just completely depressing for everyone. Yes.
Is the backlog the sprint backlog or the backlog?
It’s the product backlog.
The overall product backlog.
Yes.
What’s the point of doing it better than that? Afterward, it might take one more month, two more months to finalize.
And maybe your team doesn’t have two more months to do it. So instead of keeping a backlog where you don’t know what to do, you have one of the agile practices that says, if it’s in the... backlog and it will never be done, it’s better to remove it from the backlog.
That’s not always the case.
We agree. Okay, I accept.
Yes.
It could be a consequence of many improvements. In this case, the backlog is too large. The team says, OK, let’s cut it down. OK. I hear your objections.
No. No.
It’s psychological, and it’s especially a level of discussion. Now, the size of the backlog as such has little effect.
However, in terms of negotiation and discussion with stakeholders, it is important to establish what we will do in a reasonable timeframe. And so, reducing the backlog is an element to discuss with the client and say, you wanted all this, objectively, it’s not reasonable, we rescope and break it down. And maybe we’ll do it later. But concretely, we no longer need to have it present as a burden for the product. We can say, at some point, we have objectively finished the product. We are facing the 'what' and we will stop there. And that won’t prevent it from increasing at some point. That’s not the subject of this conference. So that’s the first element. It rises, it falls. Second element, here. What do we see here? We see that it’s flat.
Exactly. But again, these are elements that are quite clear. or quite standard in a way of operating when you work in a large company, or not for that matter. What do you have? Do you have rules or no rules with the infrastructure part on how to deploy. The challenge, again, is to deploy value regularly enough for the client. So if you haven't set the rules with your infrastructure, with your infrastructure teams on how you deploy, often you don't deploy. Ferrets are very good at that. A little hello done on purpose.
So if you don't have rules, what do you do? You start setting rules with the infrastructure on how to do deployment with the ops. And so you say that you may not need to deliver every day. You can, because it's sometimes complicated to deliver every day, you can say, we'll deliver every three days. And so you set a team rule with the operations saying, every three days, we will deliver. And so that will allow releasing value every three days. That's what creates the somewhat odd plateau shape you see here. Every three days, we will deliver an item. And so three days is a reasonable timeframe, it's a trade-off between what value I keep in stock versus the cost of my deployment.
It's a first step before doing something else. Okay? It seems to me that we've covered this first day of these 50 days and 5 sprints with a magnificent team that went from a pure scrum mode to a mode with some kanban elements. So we still have two or three interesting things to see to continue this discussion. that we've just initiated with the team, with the PO, with the stakeholders.
So the first element is the CFD. Actually, the CFD is a bit like a burn-up. And in fact, it's even very much like a burn-up. So here, I took something that looked like Excel to make beautiful graphs. So if you take your magnificent Excel, You have lots of super interesting things. You can add trend lines to a magnificent Excel file with graphs. And so, when you start adding trend lines, you can begin to approximate many things. You can actually draw lines. All other things being equal, if the team's pace remains the same, then if I wanted to release the entirety of my backlog that you see up there, it would take roughly the same amount of time. It's way off, you would need to almost double the element you have there. So you can start discussing with your client whether they are ready to invest that much to to do, to release. That's exactly what we do with a usual burn-up. The burn-up is really, given the trend, here's what we do. The fundamental difference is that here, you can work on both the construction model, production, and delivery. And that's what a CFD can be used for, to build this type of discussion.
Yes, so, regarding the question, on the y-axis, we have here the number, I call them work items. But actually, it can be anything. I prefer working at a unit level. For me, the challenge is to have features that are anyway fairly similar in size. If the teams are not mature, you use story points, t-shirt sizes which are more complicated to stack than story points, but it's not a big deal, or tasks, or whatever you want. Concretely, the challenge is to have a... An indicator, a uniform format for everything you measure in your flow. That's the only important point.
That was the first element. So, what is a CFD used for? It's used for that, to extrapolate end dates. A CFD will also help you work on your work-in-progress value. So imagine, or let's imagine, that compared to the first graph I showed you, you had a value assigned to each of your features. You want to know what the value in stock is. That is, what Don Reinertsen calls the cost of delay. So how much will it cost or what is the cost of releasing features? In fact, these are elements you will see very quickly. That's all your stock. It's all the items you've started working on and that are not yet deployed, available to the client or for the client. Yes.
You're right, that was my mistake. Thank you.
So once you have this element, you can very quickly—well, not very quickly—you calculate the sum of the values of each item. If you manage to do it, it's not always easy, let's be clear. And you're able to say, here's the cost or the amount that is in stock today. The challenge is rather that they decrease, which is a bit what you have here.
That's exactly what's happening with the team, by the way. The challenge of adopting a flow-based approach is to work on having the least amount of blocked value in progress.
In the end, there is no more backlog, but you could always...
Yes, because for movies, you can't have a...
That's it, exactly.
The last element with a CFD that you can start looking at is cycle times. So this is a first graphical representation, I'll come back to it just after. So ultimately, when you enter a model that becomes stable, meaning you achieve a certain stability in your production flow, which is the case here, when you look, if you draw lines, you are actually quite stable. That doesn't mean the stability is good or bad, it's just that objectively your system is becoming stable. Then you can start working on cycle times. You can look at how long it takes for you to go from an item here to an item that is finished being developed, put into testing, etc. The 'what it's used for' is more interesting than just presenting it. The 'what it's used for' is the element that allows making trade-offs with stakeholders. If here you see that it takes you 6 days, for an item ready to an item that is in testing, the PO who comes to see you or comes to see the team saying, 'I have this feature to release as soon as possible, what is the average time to release it, when can I have it?' The answer is, 'it takes you six days.' You see it directly. And then you start entering a dynamic where you can negotiate with your PO. You can negotiate with your stakeholders if you don't have a PO. Because when you are able to say, look, it takes us six days to release an item, suddenly, we can make... trade-offs, we'll remove this, we'll put that back, we can place another item on the right, we can place another item on the left. You can work on your product backlog, no longer in sprint mode, but in pull flow mode. This is more important than that, it takes me so much time to do it, I need it now.
We're getting to the last question. Watch out, this is going to be the challenge. Smooth flow. So, we call smooth flow, or I call smooth flow, the state of the system in which the flow moves towards stability and constancy. It's very, very dry. Concretely, what does that mean? It means that you have fairly little variability inside. You go from something where it's all over the place, it was the start, where you have big piles stacking up, moving in all directions, to something where, on average, it doesn't move too much.
What is this smooth flow used for? Why try to tend towards smooth flow?
See you on K.O.U.T. This is the last question.
This is to make you think. Ectra is still in first place, but Racing 1985 is very, very closely allied. I remind you that there is a book at stake for the team.
Come on, why do we look for a smooth flow in the CFD part? What is the purpose of achieving a smooth flow in CFD? Four possible answers.
First, red, it's prettier. In blue, it facilitates predictability. In yellow, the client is happy. In green, the team is happy. I repeat, red is prettier, blue predictability, yellow client happy, green the team is happy.
Blue.
I have 12 answers; I see you are very, very motivated.
What is blue? Predictability. It facilitates predictability.
I think we must be right. We are right!
This question is too easy.
And yes, the stake of smooth flow is predictability.
The stake of smooth flow is predictability. So, continuous flow, actually, what is it? What is smooth flow? It is a state of the system in which you have a continuous and stable delivery of work items. What is the blue? Predictability. This makes predictability easier.
I think we have to be good. We are good! Oh! This question is too easy.
And yes, the challenge of smooth flow is predictability.
The challenge of smooth flow is predictability. So, continuous flow, actually, what is it? What is smooth flow? It's a system state in which you have continuous and stable delivery of work items.
That's why I really like the faucet principle. The principle of a faucet is that when you open it, you have a continuous flow. When you open a faucet too hard, which happens to me sometimes at home, you get a huge splash and you're completely soaked. Then suddenly, you have no water left. Then you're really annoyed and it comes back. It's not very practical, nor for the client. In this case, I'm the client. I don't like being all wet. Afterwards, I feel like I'm wet. It's unpleasant.
The challenge is to avoid blocking value. Again, the challenge of Lean is to avoid waste and to release value as quickly as possible. Predictability is the challenge of smooth flow. Smooth flow allows you to achieve predictability. And predictability... It will make your clients happy. If you are able to say on average, here's how long it will take me to deliver your work items, it ties into the discussion we had or that I had a few minutes ago about how we deliver items and what a CFD allows us to say. And so for that, maybe I actually have one last question left.
We're going to get into service classes.
And we'll connect with cycle times. So if I take the examples we had previously, We'll work on a cycle time that goes from start in dev to deployed. That's one vision of cycle time. Not everyone has the same visions, etc. Difference between the size. Time, cycle, time, tag, time, blah blah blah. So let's come back to that. If we make a scatter plot only on the last 15 days of the sprint, You see something that looks like this. So this point here is probably off, it's most likely the last point from the previous series. Okay?
From this scatter plot, you will be able to build a model like this one. Which suddenly is much more readable, because you've gone from a scatter plot, So each point is a work item from the workflow with the exit date or the time it took to deliver it. You can start grouping it. Excel does this very well, but all the tools on the market do it rather well too. And so when you get to something like this, it's already not bad, but it's still a bit too broad. So the challenge is to get into service classes. Who knows what a service class is?
Yes, there are two or three. I'll come back to it very quickly. A service class is what allows you to type a work item, a feature, and discuss with one of the stakeholders to give it a different cost, for example, or a different processing time. And/or, by the way. Or many other elements in terms of quality, etc. So here, we can start to get into, okay, we see that there are big scatter plots and all, but it's still a bit messy.
Let's add a complementary element, because I had a great team. That was doing Scrum, so with a Scrum team, we quickly get information like t-shirt sizes. T-shirt sizes are rather simple. So we'll say we have three t-shirt sizes, in disgusting green something that looks like small, we have a light blue that's very hard to see, the one that's here, and we have a very dark blue, the one that's here.
Okay? Oh well, suddenly, we can start to have another level of discussion. What is this level of discussion? We'll finally get there with my big clogs here.
That's the next big question.
Next.
Next. Go on.
So my next big question on K.O.U.T.
I have no participation from K.O.U.T. I'm telling you right now. ECTRA is still first. Racing BE is still hot on their heels. Watch out, watch out. Cambon BE is starting to gain some ground. There are 100 points difference. Aubrac, who is fourth and a bit far behind, I have to tell you. So let's move on to the next question. Next. What can we tell our client with this diagram? With a magnificent diagram like this, what are we going to say?
Red, it takes more time. Blue, on average, it takes less than 6 days to deliver a size M. Yellow. Size L takes too long. Green, we can deliver S sizes in less than a day. I repeat, red, it takes more time.
Blue, on average, it takes less than 6 days to deliver a size M. Yellow, M, M, M like mom. Yellow, size L takes too long, like L, long. Green, we can deliver S sizes in less than a day.
I think you're in good shape.
Well done!
Great! Are we almost done?
The answer was number 2. On average, it takes less than 6 days to deliver a size M. The winner, the winners, the winning team is therefore Racing 1985. You can come see me later, but don't close your laptop, otherwise I won't see that it's you, I'll be a little sad. Not being able to give the books that the LKFR Organizing Team is offering you. How?
We agree on that. We agree on that, the L has a very long tail. But is it too long?
Exactly. So concretely, what will an element like this one say? A magnificent cycle time like this one. In fact, you will just be able to say very simple things to your client. And I like saying things that aren't stupid as such; it's just that they are very simple to read. On average, we are able to deliver S-sized items in less than 4 days. If you give me something we consider an S, it will be out in 4 days.
That's it. On average, actually, it's not on average, in all cases, we have M-sized items that come out here in less than 6 days. And on average, we deliver them more in 3 to 4 days than in 5 to 6.
And when it's L, we see that it's too big. Maybe that's a problem. But maybe it's a problem we can address with the client. For now, we can only say that an L takes more time. There is too much variability or there is very significant variability with L-sized items.
And concretely, it's already not bad to be able to tell the client, when you give me something of size L, I don't know when I'll be able to deliver it because it's a bit complicated. Maybe we can work together on how to break it down, simplify it, and fit into another service class. And so we arrive at a service class with elements or initial elements of service class by working with these cycle time diagrams that are already somewhat customized. We can start to say if you deliver an S to me tomorrow and you want it in less than 4 days, Well, listen, let's add 20% because you consider it an urgent request. Well, that's very good. If we can add a 20% markup on the development cost, let's add a 20% markup if it's important to you.
Do you want to process M-sized items faster? Okay, let's see what we can do to process M-sized items faster. How do we fit into... the expedite lanes, what we generally call an emergency lane, etc. Here, we start to get into the real discussion, and it's not an ethereal discussion; it's a discussion based on data specific to your team. This obviously implies that your team doesn't change every two days because otherwise, you'll break your system. These are still some basic predicates or basic assumptions to succeed with this kind of tool. I think I've finished with the service class part. Yes. So let's do a quick conclusion. To summarize everything you've been working with so far.
You could have tons of graphs when you do Lean Kanban or Kanban or Lean. I will only keep three. The challenge is not to have graphs for the sake of graphs, but to have graphs that will be useful to you. And so, the three key indicators for me are the CFD, blockages, and cycle times. These are fairly narrow graphs. So, the really nice thing is that you can even put them above your board. You print them every day, you print them every week. It's a good projection tool for the whole team and even for clients who come to see the team. Here's how we work. Transparency. It's very simple to do. You don't need anything. Even if you have no tools, no complicated technology, it's simple to implement. At worst, it's a post-it, an Excel file, and extracting the elements. If you need them, I'll give them to you. Otherwise, you build them, they'll be in your colors, which will be nicer.
And really, the important point is that you are only focusing on elements of the workflow. And for me, that's the important point. In fact, the size of your t-shirts, the size of your stories, we don't care. At least, as a coach, I'm not interested. What interests me is knowing how many you have in stock. If you want to count sizes, it's fine to count sizes. What interests me is whether we manage to deliver value. What is the size of the value? That's another question. A CFD should... represent your workflow elements that progress over time. Objectively, when you develop, you could take your post-it, put it on your screen, and when you're done, take your post-it and put it on your neighbor's screen who needs to move to the next step. Or move it, because normally it's pull flow. Anyway, let's move on. I think I've covered everything. So I'll leave you... Yeah, so now, I'm going to leave... Yes, I'll finish with one last point.
Graphical analysis in Kanban, as in financial analysis, is not a science. Let's be clear, it's only graphical analysis.
There is no scientific element; there are some scientific elements on the flow theory behind it, but it's not a science in the strict sense. It's a tool to start a discussion. And so, these are tools that allow you to pique intuition and identify blockages. The goal, once again, of Lean is to identify all blockages, remove the blockages, and all elements of waste. A blockage is a particular element of waste. And so, once again, and like with everyone, it's very simple.
But it's not that easy.
With that, if you want to go further, I've left you... Pablo Pernaut recently wrote two articles about CFDs that have nothing to do with what I've talked about, but they're quite funny. They're CFDs explained to my 5- or 8-year-old kid, I don't remember, with cookies. And I found that really funny. And I think it's still a very good alternative approach to explaining CFDs. And on InfoQ, you'll find a book called Priming Kanban, which covers the different steps. For those who were here last year, I did a workshop on this. There you go. I'm done. If you have any questions, don't hesitate. I'm still here for you. And I think we kept to the timing, which is really great.