Marie-Pia Ignace - Andon et flux, juste-à-temps et confiance mutuelle (fr)

[00:00:07] Hello. So I'm here to talk to you about Lean in the tech world and I hope it will be simple, applicable and that you will find it interesting.
[00:00:24] So one day I attended a role-playing game, well a kind of role-playing game, a "nice hacker" within a meeting, there were a certain number of people from the same large company of the CAC 40, all with executive roles, and so it had to be funny, and we told them, explain what superhero you are. And from this superhero, we will try to find out what job you do. These were people who knew each other very little. And so here it is, uh, what he had to say.
[00:00:50] It's my fault, it's always my fault! It's my fault when it doesn't work, it's my fault when we can't do something. Always my fault and life is not that simple.
[00:01:02] In a way, he was absolutely right. It's always his fault. So the notion of digital frustration within companies is something that is obvious today. Here is a survey that has just been released by a company called Next Think. So the third factor of turnover and professional burnout is the quality of digital tools made available to employees in the company. It's quite sad, isn't it? Because when we see people working in IT, in the infrastructure, etc., we see people who are nice, who want to give their best, who want to do things well, and the observation is that 20-40% of people who leave a company can leave it for reasons of digital tool quality.
[00:01:48] But what do the devs and ops say? So the same thing, I went to look a bit. What the ones and the others said, it seems that you are all passionate about your job, about the challenging things that exist, that it pulls you up, that it helps you get up in the morning and get out of bed. All this is really great. I don't know if it's your life and your personal situation. I met Jez Humble, so Jez Humble is someone who wrote The Lean Enterprise, who was doing a lot of things in terms of conceptual and practical terms on CICD, who is one of the founding fathers of the DevOps movement, so a gentleman who knows what he's talking about. And so, one day he told me, you know, the reason why, but really the reason why I got into DevOps is the following: My personal dream was on Friday at 5 PM, feet in the pool, a margarita in hand, and life is beautiful. But since I'm on the Ops side, on Friday at 5 PM, I say to myself, my God, my God, something's going to happen this weekend, it's going to end badly again, I'm going to have to get out of bed, I'm going to have to be available Saturday, Sunday, day, night. No, the weekend is not a nice time. And so he said to himself, I'm going to go towards DevOps like that, we're going to do things that will be well integrated, that will be put into production and I'll be quiet. Which means that finally, there are still three points of view that are quite complementary, which are that of the DSI, which they feel, and I told you about this banking DSI, but I also have the image of the DSI in a large French industrial company that told me, I don't have the curtain anymore, huh?
[00:03:10] Because every time I go there, I'm taken to task by everyone. So there you go. So that's the point of view of the manager who finds that it's not that easy to take care of IT. The point of view of the user who is still a bit sorry, who says, will my day start well? Am I going to be able to hold what I have to hold today because I don't have total confidence in what digital does for me. And then finally, the people in tech who can seem nice, smiling, relaxed, but who would love to have quiet weekends. So that's the convergence of the analyses. So I am a Lean Management expert. I started doing Lean in the IT world in 2005, so I am a dinosaur of Lean Management in IT. I brought together a whole team of people in the 2000s, including Régis Médidan, who spoke this morning, Cécile Dijoux, who spoke some time ago, etc. And so we tried to explore what Lean in IT was, and you know, Lean in IT is a question of car.
[00:04:10] Not necessarily in IT, but in any case, Lean is a car issue. So this is a Lexus, Lexus is the luxury brand of Toyota. It's a very beautiful, very beautiful entrepreneurial and industrial adventure. And so the first time I got interested in IT at Toyota, in fact, I very quickly came across the chief engineer of Lexus, who said at the time, we have 12 million lines of code embedded inside the car. And at the time, it was more than 10 years ago. Today, there are real background debates to find out if they have rather 50 or 100 million lines of code. So there you go, so it's an object that is both a digital object, and we know it with Tesla, it's an object that will be more and more digital. And then it's also an object that has an engine, wheels, a clutch, etc. And so it's an object that has 12 to 15,000 parts inside. So before being a digital object, it's a manufactured object, an assembly object, with 12 to 15,000 parts. And so one of the reasons why we have been interested in Toyota for a very long time is because at Toyota, we talk about total quality. That's an extremely recent ranking on the most reliable cars in 2022, with an extremely competent site called Vroomly, and Vroomly refers to several other large surveys also referring and being the main references today in this area. So the first most reliable car in 2022 is a Lexus, the second is a Toyota. Then you still have three Asians, then you finally have a European car, a European brand, you have Porsche. And then after that it goes up, it goes up, it goes up and it stops at 10 and at 10 there is still no French. So there you go, so we have today objects that make so 12 to 15,000 assembled parts, 50 or 100 million lines of code embedded, and which are considered to be the most reliable cars. That means that underlying, there is a production system that is extremely reliable. Both in the real and in the digital.
[00:06:08] So there, I'm not going to give you a lot of theory. That's not my objective, I'd rather we share cases and maybe share some concrete things to do. But it doesn't prevent a little bit of theory, so this is an extract from a publication of the Lean France Institute, which I co-created some time ago. And so the Lean France Institute has a component called Lean and Learn, I've put the QR code for you to access it. You can click on any word and you have a perfectly orthodox definition of what it represents. What is in it? So Lean is a house, this morning Regis talked about it, it's a house with a roof, pillars, a basement, all that is very good. So two important constructive principles, the one on the left which is in fact the just-in-time principle, and the one on the right which is the total quality principle. So they are absolutely indissociable. If we try to do just-in-time, we will only succeed because we will do total quality. There you go, so the two are extremely complementary.
[00:07:09] Just for info, when we talk about flow, flow, it's flow. The flow is a very small piece of what is surrounded in this very small block which is at the top left of the Lean house, huh? So after that there's the flow, the pulled flow, the piece by piece flow, the smoothed pulled flow, etc., there's a lot of theory around all that. And what I'm going to talk to you about is just a very small part of what's in the top right, in total quality, which is Andon. There you go, something that is really at the heart of the DNA of Lean systems, but which is only a very small part of that thing.
[00:07:44] So what is an Andon? It's extremely simple. An Andon is a system that says stop.
[00:07:50] We stop.
[00:07:52] We saw a defect, we stopped. We are not able to keep up, we stop. So the first takeaway from my presentation is to ask yourself, at what point do you consider that you are going to stop? And as we are in Lean, as we are in flow, as we are in just-in-time, well we are going to stop now, from the moment we see the defect. So really the Andon is just that, it's the defect stop.
[00:08:16] So, like all these systems, it looks extremely simple, and it's even simpler because it has to be manipulated by workers, so people who don't necessarily have enormous qualifications. I met an engineer who had supervised teams in the automotive industry in Germany, she put on her CV, I speak Turkish. I said, but how is that? You speak Turkish, she already spoke French, English, Italian, etc.
[00:08:37] Well yes, I work in Germany. You see, so in Germany, the workers are Turkish, so it's not that simple to exchange between people who speak different languages. But the Lean objects are simple objects. Lean, Andon, it's stop. So it's simple, at one point, I have a cord, we talk about the Andon cord, I have a cord, I pull on the cord, and this light that is there in green because everything is fine, well, it's going to turn red because it's going less well than we thought. Exactly now. I went to visit a Toyota factory in Japan with 6,000 people, which was in four blocks, the first block was welding and the last one the car came out, it was assembly, the car came out. So it's just in time, the car moves inside all this block and these 6,000 people who work. In the first block, there is a welder robot that stopped working, the operator who was monitoring the area pulled the Andon, after 10 minutes we were told, us visitors, listen, we're going to go see something else.
[00:09:31] We went to the last block, the factory stopped before our eyes. That is, we stop now.
[00:09:38] So we make sure that the quality problem becomes a problem that we want to address. Because 6,000 people who don't work, it's complicated.
[00:09:47] It's complicated to justify.
[00:09:49] So there you go, so I talk about my Andon stories to one of the people I coach, so he was, he is retired now, he was director of IT production for a large bank. We got along very well, we had done some really nice things together. And then one day I said to him, listen, maybe one day we could talk about Andon and the defect stop. And there, he is pressing the elevator button and he told me, not with us. No, it wouldn't be possible. We would stop everything. Well, at Toyota we stop everything, and there, in IT, we would stop everything. What do we find? We stopped more things than he thought. That was at his place. So file systems that fill up, fill up, fill up, setting up Andon systems around file systems that fill up, it allows us to avoid the incident. So there you go. So these teams did that, for a while, the availability of the IS had improved, so there were things at his place that worked, it was not at the scale of his entire organization, but in any case, it worked. The creation of environments. So here it was a different approach from Andon. So creating environments for dev, tests, pre-prod, prod, etc. environments took several weeks and sometimes several months before being able to obtain an environment. So he had in mind that we could have an organization more of the type assembly plant like at Toyota, and in that context, we said to ourselves, with this plant, at what speed could we go? And we said to ourselves, if we manage to deliver an environment in 7 days between the request and the availability, well, we will have the possibility, first of all, to serve the requesters much better, and especially to make disappear all the project management on the delivery of environments because for 7 days, there is no need for project management. The team can self-organize. So there you go, these people did a certain number of things, they arrived at the end of all that, but what they did was they created a kind of prototype environment, so a kind of prototype, a representative prototype of everything, and they ran it very regularly. And that allowed them to see at what point their creation of an environment encountered a defect, and based on that defect, they stopped the process at the point where they were, and they went looking for it. Because in fact, the environment was dependent on a lot of other external blocks that were constantly evolving, so going from version A to version B, and so everything that had been put in place to be able to generate the environments quickly could be found broken in one place. And so the Andon appeared, bang, we stopped at the defect, we corrected what needed to be corrected, we shared what we had understood with the team members and we could continue to maintain quality and speed on the creation of environments.
[00:12:20] Another completely different example is database encryption. So he had 10,000 databases to encrypt for cybersecurity reasons. So 10,000 is a lot, when we are in a Lean spirit, we say to ourselves, if I do 10,000 in two years. 2 years is 400 days, I would have to do 25 per day, approximately the calculation. What did I find? The first one after 2 years, it was still not out. So they understood that there was a process problem there, and so in fact, they drew a kind of theoretical process and they advanced the first base inside the theoretical process with a stop at each defect. And so we corrected at the point where we were stuck on database encryption. And then we advanced, we advanced, we advanced, in 4 months they debugged their process, and then they were able to start scaling up. So at the defect stop to be able to stabilize a new process, to master it within the company.
[00:13:07] If we talk about dev, this is someone I like very much, whose name is Emmanuel Chanon, he blogs much less now, but he has left quite a few traces on the internet. He works at Thales. He was at the time responsible for embedded IT of a piece of an airplane, from memory it was the landing gear. And so his big client was Airbus, but it was also people in the army. And so in fact, it's someone who was really a software engineer, extremely, extremely expert, I was very, very impressed by what he did. And so he had all these automatic test systems, and he had put his little guy there, his little guy who was connected to the system and as long as the integration stages went well, everything went well, and if something went wrong, in fact, the little guy changed color, and so there, the whole team stopped.
[00:14:00] That is, a signal was given and the whole team stopped. The whole dev team. And the dev team tried to understand what was going on. What do I have? Emmanuel's team was one day recognized by Airbus as being their best supplier that year. Because in fact, they were so good at the quality of what they delivered, that they passed very quickly there are processes of acceptance of the software for planes, we know it, we know it unfortunately. And so they passed the different stages so quickly, the quality was so good at the start, that Airbus identified them and named them this year their preferred supplier.
[00:14:38] So there you go, so this stop story. Stop, it's quite simple, but it already raises a first question. which is to know, are you able to see you trying to get out of the deadline you set for yourself? And are you able to see that what you are doing generates non-quality?
[00:14:57] And so that already requires a good knowledge of the job we are on. A good level of reflection. It may be necessary to work together to say this is good, this is not good, there you see there is a defect, hey this one, we thought it would be finished in half a day, a day, two days, three days, well we are not there at all. So you have to be able to see this gap.
[00:15:15] Lean talks a lot about gaps, to see this gap between the situation we imagined to be good and the real situation that is diverging. And to see that gap now. We stop when we see the defect.
[00:15:31] The second point is that once we have stopped, we will have to do something now.
[00:15:35] So we're not going to look at our system by sitting down and saying, what do we do? So we're going to do two possibilities. Either it's a rhythm problem, something really happened in the rhythm, a little help would allow us to get back to the right speed, and at that moment, oh sorry that's further. So the first thing is, what gives you the stop signal? It can be a personal analysis or a machine alert. The little man who was flashing in green or red, that's a machine alert. You have a lot of systems today that allow you to say no, the situation is not normal. I'm warning you right away. And so being alerted, you have to do something. And the other point, it can be a personal analysis, I know the system I'm working on, and then I'm telling myself, no, the system doesn't respond as I would like it to respond, I don't know, even if it's just not responding for example, that can be one of the elements. And so, seeing him, I can stop the system.
[00:16:27] Once we've done that, we're happy, we've stopped the whole thing, and then what do we do? And there we still enter into things a little more difficult, generally speaking, it can get complicated. I don't see why it would be a blocking point. In any case, the first answer is that we'll have to take care of it. But seriously take care of it. So to deal with it, there are two possibilities. So there is a possibility in which, in fact, well, in fact, we just need temporary help. We are stuck on something, we are not completely fast enough. If someone comes to give me a hand and unblocks me there, we will be able to get back into the normal cycle.
[00:17:05] Whatever that means. So it's just a need for temporary reinforcement. Well, very good. So we stop the system, we raise our hand, we have a help system, someone comes, says, wait, while you're dealing with that, I'll deal with this, we'll reconvene in 10 minutes, and then it will be good, you will be back on your own rhythm. There you go. That's easy. Can be in a more complex system.
[00:17:28] In which finally, well, it really stopped at a real defect that we didn't master very well, and we're going to have to find a way to address that defect and address it now. You know that the cost of the defect between the one that is addressed now and the one that is addressed when the customer sees it, it increases very exponentially. So we have every interest in stopping immediately.
[00:17:50] So we're going to talk about problem solving, so for those who are a little familiar with Lean, problem solving is something highly standardized, plan do check act. PDCA. In any case, we will have to implement it to truly understand what is the cause of this quality gap and what we will have to do to get out of it. Before launching the PDCA, the first thing we do is still try to do what we call protect the customer, if there's something we can do right away to get the system back up and running, we'll do it. We are not obliged to take our customer, our user hostage for our quality problems. However, we still have to try to understand what happened at some point or another. There is no magic, there are algorithms, there are a lot of things, but there is no magic in IT. So I'm going to give you an example. This one is nice. I don't know if you know Deming's bead game. Ah. Two, three.
[00:18:46] a colleague in our
[00:18:02] to understand the cause of this quality gap and what we will need to do to get out of it. Before launching the PDCA, the first thing we do is try to protect the customer; if there's something we can do right away to get the system back up and running, we'll do it. We don't have to hold our customer, our user, hostage over our quality problems. However, at some point, you have to try to understand what happened. There's no magic, there are algorithms, there are lots of things, but there's no magic in IT.
[00:18:33] So, I'm going to give you an example, this one is nice, I don't know if you know Deming's bead game. Ah! 2, 3.
[00:18:44] a colleague in our company for the story of Deming's beads
[00:18:50] Deming's beads. So, we have a kind of box with white beads and red beads, and then we have a palette, you see, the wooden plate with holes, and when you put the palette, in fact, in each hole of the palette, we're going to put a bead, and so we're going to put white beads and red beads. Well, that's what happened with this story of obtaining a certificate. Deming's game goes much further than that. But in this story of obtaining a certificate, in fact, uh, these are people who regularly need to obtain certificates, so they send their requests, and then they retrieve the certificate, when everything goes well, everything goes well. And then, sometimes, it doesn't go well. So we told them, we're giving it. If you don't get the right certificate, if you can't get the certificate, we'll give it to you. So obviously, it doesn't work. So the person, it's a Lean system, the person who comes, she says, "Well, wait, I'll show you how we do it," and then it works. And he understood. That lasted until the person who raised their hand said, "But you know, I do the same thing as you." Except for me, it doesn't work. So it's not a matter of gesture because I assure you, I do the same thing as you. Well, show me, so the guy does it, it works. Ah, you see, it works. Yes, but 5 minutes later, Andon, it doesn't work. And so there, the problem resolution led them to understand that in fact, they were sending their request to a system which then had two servers, two machines that delivered the certificates, and so, and then it was balanced between the two, eh? So sometimes it went to the left one, sometimes to the right one. When it went to the right, we got the certificate, when it went to the left, it didn't work. Because in fact, the left server was not updated like the right server. You see, so it's not the moon, but in any case, without an Andon system, we find ourselves facing an extremely frustrating system where sometimes it works, sometimes it doesn't, and we have no clue that allows you to know why or why not. So it's been some rather complicated days where we're constantly a bit uncertain, whether I'll succeed or not. So quality allows for calmer days nonetheless.
[00:20:45] So now, I'm going to tell you about another example which is more integrated, more complete, not just an anecdote. So we worked with an ESN which notably had teams doing testing for, I think it was an insurance company. So there, we have this whole team that constantly tests, tests, tests on behalf of the mutual insurance company, and you know, when you work in an ESN, you're not always absolutely certain to get complete satisfaction from your clients regarding the services we provide. And there, uh, there, it was a bit tense with threats of breaking the contract and going to see someone else. So what can we do from a lean perspective, we're going to look, we're going to look, we're going to launch, we're going to try to understand what's happening and in particular one of the points, so here it's the PDCA, so I know it's a bit small, but for you it's bigger for me. Uh, one of the annoying points was that the testers launched their tests and then declared anomalies, and one out of four times, they made mistakes in their anomaly declaration. Meaning it wasn't anomalies, it was software that was functioning as it was intended to function. But since they had declared the anomaly, there were then lots of cause investigations, it was an indicator, this anomaly rate, it was an indicator that, uh, that went into our SN's penalties, and so on. In short, all of that really bothered everyone. So, uh, this subject was addressed in the form of a PDCA, it's a relatively long PDCA. So the first thing we do is we're going to look for false anomalies, we're going to examine them, we're going to try to understand what the reason is for them being there, and finally, when we try to understand, four causes emerge. So, uh, you see, I told you I'd give you simple things, uh. There, uh, we're making crosses, huh. It's really, it's not the moon, huh. So we do our Pareto and then in our Pareto, the first thing is a functional misunderstanding, that is to say that our testers, ultimately, do not know how the system should respond. And not knowing that, they declare the anomaly. That's it. But there are other aspects, there's a bad, there are several software versions that coexist and so they're going to test the wrong version. Then, they don't know very well what has already been detected as an anomaly, so they will re-declare an anomaly on code that has already been declared as an anomaly. And finally, they have a web browser that has not been reinitialized, and so that will generate false alerts, false anomaly declarations. So, they have action plans for each of these four items. The incorrect use of the software version, that's a pretty classic action plan. Already known anomalies, that's a bit of communication among everyone. The web browser, we're going to bring it into the testers' work standards. But what are we going to do about the functional misunderstanding? And so there, they train, and it's the first Andon you see here, they train in this Andon technique. So you have, in fact, the testers who know that when they have a doubt about an anomaly, not an anomaly, they raise their hand, and there's an expert of this software who comes and helps them make the right decision between an anomaly and a non-anomaly. And he will do it as often as necessary, until there is a better understanding of the software's functioning by the testers. There you go. Which means they achieve a system that is much more performant, meaning they go from 24% false anomalies to 4%. So that's a relief for everyone, right? I mean, it's a relief for the client, it's a relief for the developer, it's a relief for the account manager in the ESN in question. We really manage to calm things down. But there, they decide to really enter these continuous improvement loops, they put in a second Andon system which, this time, is a bit different. And so, in which when the Andon is pulled, either because we detect this false anomaly error, or because we continue to have a doubt, we will enter a system that is a dojo. Are you familiar with the concept of dojo? So the dojo in martial arts, well, that's the place where you train to do martial arts. Uh, it works for small, medium, large, it works for white belts and black belts, it's really the place where you're going to train and you're going to train often with a master, at least when you have a certain level of expertise. And there, the dojo line, so it's the place where we're going to practice because in fact, we estimate, in terms of Lean, that learning in theory is much less effective than learning through practice. So in fact, we're going to team up with an expert on a specific subject, the one on which we pulled the Andon, and with the expert, we're going to better understand the system. So the time in the dojo, it's between 10 and 20 minutes, it's not very long, but we're going to better understand the system and since we're going to better understand the system, we're going to acquire competence and so we're going to be better afterwards on its environment. So there you have it. So we went from a problem resolution system for my certificate stories, which was, well, you had to see it, you had to look for it, you had to explore it, but it was quite easy, to something that will ultimately completely change relationships within the team, on the one hand regarding what it must achieve, that is, being able to detect anomalies, but real ones. On the other hand, regarding how it goes about doing it, and then regarding how it can continue to increase its skills. Because competence, it's like yogurts, there's an expiry date. That's it.
[00:26:02] So I found this for you because to give this conference, I took the time to go and look at what was being said in London, and I found that this conference was very good. So go ahead, it's Devops Enterprise Summit, you can find it quite easily by typing Excel. And so there are two curves, a blue one and a red one. So the blue is what they call the cycle time and the red is the number of times you pull the Andon. So the cycle time in Lean, I told you we want to be just in time, so time is really important. So there's the customer's time, it's the lead time, I ask, I get. That might have nothing to do with manufacturing time, but in any case, it's the deadline for the customer. There's the touch time, the time when someone in the company will work on the customer's request. Whatever that means, one minute for me, 5 minutes for him, 4 minutes for the other. There. And there's the cycle time. So the cycle time, that's the time it will take me to open a process that I have to do, go to the end of that process and return to the beginning of the process. When I train people who don't know much about Lean and who are a bit young, I take them to McDonald's. And in fact, at McDonald's, I ask them to look at the cycle time from "hello" to "hello." Because in fact, you have a certain amount of time to serve the customer. At McDonald's, it's well done. They quickly return to "hello." But in other companies, you have a certain amount of time to serve the customer and then you go do something else and after that you come back and you resume this activity for the customer. And so in fact, your cycle time, it's going to integrate everything, it's also going to integrate the time when we go and get paper at the other end of the building, or when we go into a meeting and so on, and we're going to realize that in fact, an operation that takes 10 minutes of touch time will take 1 hour 40 minutes of cycle time. And when we try to see the cycle time, sometimes, I assure you, we are very, very surprised by what we find. So, there it is. So the cycle time, so that means when I take my cloud, it's at what point do I stop, at what point is it finished, I return to the start of the next instruction. That's it, that's the cycle time. So what they explain, they really followed it, is that the less they pull the Andon, the longer the cycle time is.
[00:28:15] And so we progress over the weeks. So at the beginning they say, "Yeah, we pull the Andon, well, not much happens." So eventually they get a bit demotivated, they pull it less and the cycle time goes up like that. So they say, "No, we have to pull the Andon," so since they haven't done it for a while, they find, it's the red line that goes up, they find, they find something to do. And so the cycle time goes down. And there you go, and every time they let go, it goes up again, every time they put it back, it goes down again. So they probably need to be more consistent in how they pull the Andon, but in any case, that's what this curve explains. And they explain, in fact, that one of the reasons we have trouble pulling the Andon is that we see it as an element of personal negative evaluation. If I pull the Andon, it means I don't know how to do it, it means I'm bad, it means I'm not good, it means, etcetera. And so in fact, that's not at all the spirit in which it should be done. Nevertheless, and because that's how they experience it themselves, they have a little trouble showing it. At Toyota, they say that the real problem is not having a problem. So in fact, they will be very attentive to people who never pull the Andon. They say, well, if they don't pull it, it's because they're not interested in quality. That's just what it means. So there you go, but the Toyota system is often quite hidden in terms of vocabulary. So we don't have to be, or maybe we do, I don't know, but in any case, we can choose slightly simpler vocabularies. So there you have it, how are we going to manage to put ourselves in a situation as a team to pull the Andon? So if we go back to my Andon system, first we say stop, which means we understand the rhythm and we see the non-quality. We are capable of having our personal analysis, telling ourselves, "Well, uh, it's me who saw the quality problem," or "it's the system that alerts me to a quality problem." And we are going to put ourselves in a situation where we are capable of raising our hand to say, "I have a problem, I would like help." And there, I took uh a subject that I follow quite regularly, that's Google's Aristotle project. So at Google, they asked themselves what were the criteria that made a team perform well. And very quickly, they came to the following conclusion: it's not the fact that the team members are performant. So be all individually super performant. That being said, what matters within a team is, one, psychological safety. Am I, do I have psychological security within my team? Will I be able to explain that I am encountering a difficulty? That's the Andon, I raise my hand saying I need help. That's the first point. And they didn't do it at all because they were doing lean and so on. They did big Google-style studies by looking for data, confirming data, starting over and so on. So in any case, the Andon psychological safety. The second point is dependability. So there, it's the fact that we can say to ourselves, within my team, each of us is committed to producing something of quality. And I find that it also has a direct link with Andon because when we pull the Andon, it's because we say to ourselves, I want to produce something of quality. So there you have it, we are very clear. Then we are more, what is the structure in which I work, what are the processes, is all that clear? Then, does my work have meaning and what meaning, and then, do I have an impact and do I know it? There you have it. So that's the Aristotle project. on what makes a team a team that rocks.
[00:31:35] So there, if we want to go into these Andon systems, we really have to agree with each other on the fact that our sole interest, our sole motivation to set up the Andon system, is to better achieve what we need to achieve.
[00:31:49] It's to remove the thorns from our side that we will always have at one time or another because the bugs that we are going to correct, the incidents that will mobilize everyone, that we really don't want anymore, and that we really don't want anymore, we agree to say, "Here, I didn't understand how I should do it."
[00:32:13] Then, very good, we raised our hand. So how does that work? I've given you a few examples. Uh, but based on these examples, in fact, there are ultimately two different strategies, there's ad hoc help. I saw it, I really saw it in the Toyota factory, there's someone who pulls the Andon, there's a team leader who comes. And then, it's fascinating to watch cars being built, it's a chassis moving at a certain speed, the speed depending on the speed at which we buy cars. So the chassis moves forward and then the people, over a certain distance on the ground, will assemble in the car what they need to assemble. Here, the rearview mirrors, the other, the battery, the third, I don't know what. There you go, but everyone in turn will assemble what needs to be assembled on the car. And so the guy pulls the Andon, the light comes on, a team leader comes. So the person was working on the left, the team leader goes to the right, and in fact, he's going to take over part of the work that this person was supposed to do, but since he was a bit behind, he couldn't do it, so that when we get to the point where we hand it over to the next operator, the next operator gets the car in the planned state to be able to continue assembling his part of what needs to be done. So there you go, that's ad hoc help. So there you have it, that's ad hoc help, there's no need to make a... well, you have to make a system, but there's no need to make a super story about it, I don't know what, well, anyway, a movie, it's quite easy to set up. The second point then, is problem resolution with PDCA. So PDCA, it's more complicated, it's more demanding. Do you do PDCA?
[00:33:43] You know what it is, right?
[00:33:46] Problem resolution.
[00:33:48] Ah, retrospectives.
[00:33:50] No, not retrospectives.
[00:33:57] The problem is a performance gap, which means we already agree on its performance. That's the definition of the problem. As long as we don't have performance gaps, we have a concern. There, we have a concern. Oh, I'm annoyed, it's nagging. Yes, it's a concern, it's not a performance gap. So it's a performance gap that we're going to want to solve. So that means we're already a bit clear on its performance, which isn't very simple, huh. Uh, and we're going to say, well, frankly, usually I score goals and now I don't score anymore, so my performance is worse. And since it's worse, I'm going to try to solve something. There you go. So and it's resolved scientifically, huh, it's CM2 lessons to solve a problem, it's first to understand the situation, to look for the causes, and when we have found the causes, it's to act on the causes. But on the causes, huh, not on what we have in our heads and what we like, really on the causes we observed in the field. So it's scientific, we act on the causes. If by acting the problem is resolved, it's that we have found a solution. If by acting the problem is not resolved, it's that we can say that the action is not part of the solutions and we start over. There you go. So that's problem resolution, and at the end of problem resolution, we say, "Well, very good, what works, what doesn't work, what do I keep? Are there other problems I could still explore?" So there you go. So that's problem resolution. So problem resolution in a lean world, it happens now. So the retrospective, waiting 15 days to try to ask why we didn't manage to open a flow 15 days ago, it's going to be brainstorming, it won't be scientific. So problem resolution happens now, on the topics we've seen. So already in the morning, saying in the morning what yesterday's problems were, that's not bad, but it's not yet fully reactive. And the Andon, it's about saying, now, I see something and I want to be interested in it. What did we do in our code that prevented our automatic test battery from running?
[00:35:43] Globally, there are four origins of problems. We describe ourselves in the 4 Ms. So the people, the method, the machines and the material. Uh, when I told you the story of the certificates, we were typically on machine. The machine was not up to date, not being up to date, it returned, well, one of them not being up to date, it returned somewhat randomly certificates or no certificates. So that's an example. Uh, when we get to thinking about method elements and uh, when we get to entering the dojo, in fact, we are really in this cycle, that is to say that uh, we say to ourselves, we are on a system that we master poorly, we are going to try to improve our method until we fully understand how it works and we are going to reintegrate this knowledge into the entire set of collaborators. The one who learned the most is the one who explored the subject. So we learn more by exploring than by entering the dojo. Because we will have tested several hypotheses, read documentation in all directions until we understand what doesn't work, and so on. The one who is in the dojo, we have already pre-packaged the knowledge for him. So it's completely different. That's why in Lean, we say that we are only coaches because in fact, it's the one who finds the solution who learns, and the objective of the Lean coach is not for him to learn, it's to leave the knowledge to the person in front. So there you go. So we are really into craftsmanship. We're going to... I worked, well, my teams have been working for 5 years with a hyper-innovative, extremely smart ESN, etc. Uh, now their user stories are 2 hours long. Period. All the time. They have growth like that and perfect quality. So there you have it, something that they couldn't do at all 5 years ago. There's no limit to what we are capable of learning in our profession.
[00:37:34] So an example of expertise that I like, it's Stack Overflow. So Stack Overflow, that speaks to you more, right? So you can ask questions and then you have people who answer you, but very technical questions about software development. You have people who answer you. The first validated answer brings points to the person who answered, it's like in a video game. And so after a certain number of points, you get badges, and after a certain number of badges, you become superheroes. There you go, so it's a system where you have the possibility, in a certain way, to pull an Andon, you don't know how to do it, clack clack clack on Stack Overflow until you get the help system. So there you go, that's your Andon on your side. And on the other side, these are people who value their expertise because, well, they are able to answer complicated questions that come from all over the world. There you go, so that's an example of a very open help system that works on a community. I saw it implemented in a very artisanal way within teams of 60 people where people were confronted with situations they didn't know well, and so they would open a question and there were people who would answer the question. So the badge systems and so on within the company, they hadn't implemented them, but it was really this system. And everything that could be answered locally was a real benefit. Sometimes colleagues couldn't answer, and so there were experts who were there who could answer, and sometimes colleagues and experts couldn't, and you had to go up, it went up like that one day to IBM in America. You see, on increasingly precise and increasingly specialized subjects. The people who enter this system are people whose competence evolves enormously. But not theoretical competence because we read books, passed a QCM and obtained a certification, but competence through practice because we are confronted with situations that are increasingly complicated and that we are unable to answer. So that's on a personal level. The other benefit of the Andon system is that you integrate people who have high turnover. Which doesn't happen in the IT field, that's for sure. So when you have high turnover, people arrive with some technical skills, they tell you I know this, I know that, I know this, I know that, they don't know your system at all, though. The naming of your databases, the way of nothing, they know nothing about all that. So in fact, you're going to ask them to do things for which they will have a form of technical competence and an inability to work. So if they regularly raise their hand saying, "I don't understand what I need to do about this," you'll see a much faster increase in skills than if you tell them, "Go on, I'm letting you go, like the cat in the pool, we'll see if you learn to swim." There you go. So the Andon system. That's pretty much what I wanted to tell you about that.
[00:40:11] The key point is to think in terms of flow, and truly in terms of flow, in terms of problem flow. So how does my activity flow generate a flow of problems that I will solve until our quality of service, the quality of the products we deliver, is absolutely impeccable? And so we effectively exit, I'm sorry, the notion of retrospection, because retrospection is a batch and it's too late to understand the cause of quality problems.
[00:40:42] That's what I wanted to tell you today.
[00:40:45] Thank you.

Transcript (Translated)