Andréa Provaglio - What Agile can learn from Lean Manufacturing (EN)

[00:00:06] Hello. Hello. And that's probably 50% of my French. Nice to meet you. My name is Andrea, Andrea Provaglio. Um, are you guys ready to start? Do you need a couple more minutes? You want a coffee, something? No. Just kidding. Um, thank you for being here. Um, the topic is a kind of unusual for this conference. Um, it's about the um, let's say, how you can coexist in a lean and agile environment together. And the reason why I decided to talk about this is because I'd like to share some experiences that I had in the last three years, four years, more or less, uh, with a client of mine. Because, you know, what I do for a living is this stuff. I'm an independent, uh, coach, consultant, whatever. Uh, and I don't expect you to read all that stuff, but you know, it's just to give you an idea of where my experience is coming from. Uh, you can see some of the clients I I worked with, uh, or still work with. And, um, and for you guys that have a fetish for badges, there's also a few certifications there. So, anyway, um, let's move on. Let me tell you why I'd like to share this story with you and hopefully, um, I don't, I don't know if you're in the mood. I know that the room is big, you are far away, but I do like to have a conversation with you, rather than just a presentation with questions at the end. So please feel free to interact, feel free to, to have a conversation. So, anyway, um, why am I here? Um, a little bit of background, uh, I spent about 20 years of my life in software development. Um, and I was, you know, helping people write software better. I worked for four years in the United States, in San Francisco, helping Silicon Valley to write a better software. Um, so that was, that's what I did for, for a while. Um, and then, as I say, I kind of became more interested in carbon-based life forms than silicon-based machines. And so I started to, to work with organizations. I started to, basically the questions I asked myself was, well, how come that some teams are so great and other teams are not so great, even though the conditions appear to be the same from the outside? And then from teams, I started working with organizations, and so what I do today is I'm a business agility advisor and coach. And I've always been independent all my life. I've always been a freelance. I enjoyed the freedom, I enjoyed the possibility to make my own choices and the possibility to say whatever I like to say, even when somebody gets disappointed. Um, but, as I was saying, in the last three years, among other clients, I've been working with an oil and gas company. I've been working with, with a company that produces this kind of devices that you see up there, that specifically is a gas regulator. And but it also produced a number of other things, all related to distribution of gas and oil. So, as you can imagine, it was kind of a interesting uh, travel for me, an interesting journey coming from software and ending up trying to uh help a company that creates physical stuff to become more agile. And that's why I wanted to, to share this experience with you and maybe you'll find it interesting as I did. Because I did learn something from them. Not just, I hope they learn something from me. I learned quite a lot from them also. It was an experience that helped me look at Agile from a different perspective. So, anyway, this company is a, is a very, is very much into Lean. This company have been doing Lean manufacturing seriously for the last 20 years. And it's not a small company. They have offices worldwide, it's a very complicated company. Uh, they have been through a number of acquisitions, so it's a very complicated business. But I've been doing, they've been doing Agile, sorry, Lean for two decades. They have Japanese senseis going into the company every month just to uh move on with, you know, continuous improvement and Kaizen and stuff like that. They use a number of different Lean techniques, Lean manufacturing techniques. And even their offices are Lean. Even the way the office is laid out, the way the pencils are on the dashboard, I mean, sorry, on the, on the whiteboard, everything is very, very, very Lean. It's a culture that they invested a lot on. It's a culture that is very, very integrated into, into their mindset, into their way of working. So, I was, I was in this situation, I was with this situation in which this very, very Lean company, uh, who did a number of things like it's just a simplification, of course, but they, they define value, they, they map the value stream, they optimize the value stream, they get feedback. So that's what they do. Uh, and that's the backbone of their business, but then they also wanted to be more agile, for whatever that means. And just to represent Agile, I chose the modern Agile perspective from Joshua Kerievsky. Um, as you can see up there, you know, it's about safety and delivering value and making people awesome, experimentation and so on, and so on, and so on. So, I was asking myself, okay, interesting challenge. How can we coexist in the same ecosystem if we have these two different perspectives? So, let me give you some, let me share some thought before we go into the details of what we've been doing. And one thing that I've learned as an Agile coach in the last 15 years as an Agile coach, is that it's much harder than we think for people to understand what Agile is. At at least these my experience, you might have a different perspective, but these my, my experience. Um, but let me ask you a question. How many of you are into software development? How many of you write software? Okay, quite a few. Yeah, thank you. Thank you. I I used to, as I mentioned. Um, so let me ask you another question. Um, have you ever tried to explain your mom what you do for a living?
[00:07:18] Have you ever tried to explain your mother? How did it go? Not good, eh? Yeah, the best I got from my mother after a few years, especially when she talks with other people, she she talks with other people about what I was doing 15 years ago. The best I got from her was, oh yeah, he works on the computer. Okay, that's the best answer that my mother was able to give. And that makes a lot of sense, I mean, makes a lot of sense because she's not, it's a very technical profession, it's very hard to understand what we do, especially because we don't see what we do. People don't see what we do. People just see other people, you know, typing on a keyboard. It's not like building something physical, it's not like building a gas regulator. If you build a gas regulator, you see what's going on. You see the different components, you see the supply chain, you see storage, you see things piling up. Uh, you see the bottlenecks. Thierry was talking earlier about finding out bottlenecks. If you, if you have a production line, it's very easy to to to see the bottlenecks because stuff starts piling up. It's not very hard. But for what we do in software development, it's very hard actually to understand from the outside what the hell do we do? Right? Very hard. People don't see what we do. They see the results. They see the effects. They see what happens when they use our software, and especially they see when our software doesn't work as expected. Okay? So when they see the outcome, they they they start understanding what we do. Well, I have another question for you. And the question is, why do you think Agile was born in the very specific industry of software development? Because I mean, it could have been born in any other industry, right? But Agile was born in the 90s in the software industry. Any idea? Any idea why?
[00:09:28] Don't be shy. It's harder for me to be here than for you to be there. Come on. Complexity. Complexity. Thank you. That's one possibility. Yes. So, by complexity, I assume you mean the fact that, um, things change constantly in a non-predictable way and we need to adapt to what we find or to what happens. Okay? Thank you.
[00:09:57] Uh, anybody else? Yes.
[00:10:00] Software development is a, is a younger field, so it has more room for, uh, more initiative and more way to innovate.
[00:10:09] Okay. So software development has, let's say, less, um, constraints than physical development, the development of physical products, so you can experiment more, you can innovate more, it's easier to to to invent new stuff because we don't have the physicality of of other products, right? If you want to to create a new car, you have to deal with the laws of physics. Okay? And that's why flying cars are not out there yet because there are this little thing called the laws of physics. But in software, you can do virtually everything inside your computer, right? So, that's another possibility. Yes, absolutely. I totally agree with you. So, and that's the idea. That's the idea. Agile was born in the, in the very specific industry of software development because that industry never existed before. In the history of humankind, there was never an industry that was based 100% on cognitive work.
[00:11:18] It was the first industry in the history of the human race in which we could forget about the laws of physics. Okay? We could, we can just invent, innovate, adapt, explore and react quickly to whatever happens. So that's why Agile was born there. So then again, I, as a guy coming from software development and doing a lot of Agile stuff, was asked to work with an industry that was using Lean. And Lean was created to manage the production of physical goods, to optimize the production of physical goods. Things that you can see, things that you can touch, that you can count, that you can manage. Something very, very, you you use the word complexity. I would say that this, if you, if we want to talk in for a second, okay? This is complicated. Okay? Everything that we do in a in mass production is a very, very, very complicated problem, very complicated. It's not complex. Hopefully, in a production environment, nothing generates surprises. In a complex environment, you get surprises all the time, and that's the reason why it's complex. Right? So, again, very, two very different worlds. And if we want to have a kind of a historical perspective from my point of view, so we had, um, Toyota production system in the 60s, and then Lean manufacturing, and then in the 80s we started seeing the first glimpse of a, of an industry based on software development. And then what we learned in Agile, we exported to other activities that are 100% based on cognitive work. Like marketing, like, as you can see, uh, research and development, HR. So the idea is, okay, we learn how to deal with complexity thanks to Agile, now we can export these learnings to something that is not software, but it's still complex, it's still intangible, and it's still based on cognitive work. So that's what I think that happened. And then ironically, now the, let's say, industrial production guys are becoming interested in Agile as well because they do have the problem that the world is changing too fast now. And the limitations imposed by the physical constraints are becoming a problem for them. So they need to acquire something from us. So, what I'm saying is that there are two different perspectives, and they are both very, very good. One is the perspective of the material production, of physical goods, a complicated environment, based mainly on labor work or automated work, but physical work anyway. And the other perspective is the perspective of cognitive work, complexity, and so on, and so on. However, and that is my experience working with this company, but not only this one, even other companies that are not a manufacturing company. There is a common metaphor uh that surrounds organizations. And the metaphor is, our organization is a very well oiled production machine. And you can see that from the way organizations are designed. Organizations are generally designed in an hierarchical way because that's how we manage a complex machine. When you drive your car, you use the pedals, you use the steering wheel, and maybe they shift, uh, but at the end of the day, those very simple movements that you make, they govern a very, very complicated machine. Right? You are at the top of the organization, which is your car, and then you have a number of subsystems that are governed by what you decide. And that's how people, um, a lot of people think about organizations, they even don't think about it. It's very integrated in the industrial mindset that we have acquired in the last century or and so on. Uh and so the point is that yes, we have these two different, let's say, stages, uh, but in my experience, we still think a lot of industrial stuff and we speak a little, and that's the speaker up there, we speak a little about Agile, but we think a lot in industrial terms. Um, I'll give you an example. Like this one. I'm sorry if the if the font is a bit small, maybe well, the screen is big, so. Um, this is a an actual email, uh, it was an article that came, that was uh Wired, yes, an article from Wired magazine. Uh, it's basically an email that leaked from a company. I'm not going to tell you the name, but you can do your research if you want. This is a FinTech company, and the, the email comes from the, uh, CEO of the company. This company was very young and very, uh, let's say, aggressive in the way they wanted to move on the market. And I'm just going to read this for you, with you. I want to emphasize the importance of reaching the agreed KPIs. Now if you think about it, a KPI is a key performance indicator. A KPI is showing how much people work, not how much value you produce. Okay, KPI by definition is the indication of work done, not value generated. Okay? But anyways, this guy was stressing the importance of meeting the KPIs. And if you don't, if you don't, your bonus will be taken away from you. Okay? So very much command and control, right? This guy is basically threatening people, you want your money, you have to work harder. And if you read the text, he's also surprised that people are not staying over the weekend to meet the KPIs. And I don't know, I don't know the organizations where you've been working, but, um, I've seen this kind of bad behavior a number of times, not only from this guy. Because then again, the idea is, we need to produce, we need to deliver and I'm controlling this production machine. Even though they claim they are Agile, because they talk about product owners and teams, but that's clearly just rebranding of other names. Right? So, they're not Agile at all, even though they claim to be. Anyway, things are not so bad after all because if you look at Agile well done and if you look at at Lean well done, they have one thing in common. They are both human-centric ways of working. It is true that Lean was designed more for industrial production and for the optimization of work. It is true that Agile was designed more for adaptability, complexity, cognitive work and so on, but they are still human-centric models. The the person is a very, very important component of Lean manufacturing. As it should be, by the way.
[00:19:20] So, there is hope, that's what I'm trying to say. There is hope.
[00:19:25] Um, how are we doing so far? Am I going too slow? Am I too boring? You want me to No, it's okay. Good. Okay, good.
[00:18:49] true that Lean was designed more for industrial production and for the optimization of work. It is true that Agile was designed more for adaptability, complexity, cognitive work and so on, but they are still human-centric models. The person is a very, very important component of lean manufacturing, as it should be, by the way.
[00:19:19] So, there is hope, that's what I'm trying to say. There is hope. Um, how are we doing so far? Am I going too slow? Am I too boring? Do you want no, it's okay. Good. Okay, good. I mean, I do have jokes, but maybe I will save the jokes for later. Okay.
[00:19:40] Okay, so what did we do with this organization? Um, we have been using Agile in this organization in a number of different situations. They do have an internal IT, so we used Agile there. Uh, we used Agile for some uh, marketing projects. We use Agile in a number of situations, but what I learned, the place where I learned more was when I worked with production lines. Now, these guys, as I told you, they they don't produce the Volkswagen Beetle, they produce oil and gas components. But the idea is, if you have a production line or an assembly line, what happens on the production line must be very efficient for the very simple reason. Because you don't produce one piece and then you are done, you have to produce hundreds, thousands or even more if you are producing like small devices like this microphone, for instance.
[00:20:39] You might want to produce 10,000 of these in one day. You might want to to be able to do that. So and that implies that you need a supply chain, that implies that you need storage and so on and so on and so on, and that implies that the process must be very efficient. Because even if you lose one second, but you want to produce 1,000 of this, you are losing 1,000 seconds. Okay? So and that's a loss of of uh productivity.
[00:21:09] So, that's why Lean is very, very keen on on trying to removing waste, removing bottlenecks and stuff like that. Because you don't produce just one, okay, you produce many physical goods. Which is different from software, right? In software, you don't write the same code over and over again. I hope for you. Right? I hope for you. Uh, do you remember the movie, uh, The Shining with Jack Nicholson? Remember the scene where with horror the wife discovers that he's been typing the same sentence all over again on a stack of paper? Remember? Okay? I don't remember what was the sentence, was like, uh, all work and no play makes something. Anyway. Remember the scene, okay, how I hope you don't write software like that. Right? I hope that you have to deliver, um, your application to 10 people, you don't write the application 10 times. I hope you don't do that. Right? But if you want to give 10 people these microphones, you need to make 10 microphones. So you need to optimize. Right? Now, the production line is basically a process. It's a process that at the end produces this microphone. So you have a process that creates a product. But then there's another process. Oh, and by the way, this process is lean. We never tried, we never had the the slightest idea of trying to introduce Agile on the production line. It makes no sense at all. Lean is a very, very mature uh, approach that has been around for 60 years and these guys know how to do Lean well. So where did we try to implement Agile? Well, in what I call the meta process, because the production line is not something that is created out of the blue.
[00:23:14] The production line, exactly because it has to be highly optimized, needs to be prototyped. We need to experiment, we need to fail, we need to try new solutions, we need to learn. So there is a meta process to generate the production line, which is the process that creates the product. And agility makes a lot of sense at that level, at the meta process level. Of course.
[00:23:41] But that requires a change in mindset in the people that are used to create these meta processes. Because in traditional manufacturing culture, the meta process to create the process is also Lean.
[00:23:56] It's not Agile. It's a Lean process.
[00:24:01] And so, we had some learning there.
[00:24:04] Some things that are extremely important in lean manufacturing are value delivery. So you want your production line to run smoothly, uh, with no bottlenecks, with no interruptions, guaranteeing quality. Quality is another important subject of production. Um, you don't want your uh,
[00:24:25] your products to be returned or you understand the concept of quality for a physical product. And there's another uh, component that is extremely important in Lean, not only because it it is ethical and first of all because it is ethical, but also because it affects the business. And that's safety. Safety of the workers. You don't want your people to get hurt on the production line. Number one, it's not ethical, and that's the most important thing. Number two, if people get hurt and they stay home from work, your production, your your um, let's say, as you would say in Agile, your velocity is going to suffer. Right? Because you have less people working on the production line. So safety is a very, very important concern for for Lean. Value delivery, quality and safety are extremely important. And I must say that when Lean is done well, Lean manufacturing is done well, all those three, these three aspects are very well taken care of. I also must say that in Agile, we are not very good at safety.
[00:25:37] We are very good in Agile at value delivery and Thierry was explaining how they mapped their value stream trying to find to find bottlenecks and stuff like that. Um, when we are careful in software development and we also pay a lot of attention to quality, if you are disciplined, and you do unit testing, test-driven development, continuous integration, acceptance testing. There is a there's a whole body of knowledge around introducing quality in non-tangible products like software. Okay?
[00:26:15] But safety, we need to talk more about that. And we'll get to that in a second. Anyway, um, let's talk about value delivery in uh, in Lean.
[00:26:28] As I mentioned, we need to optimize the value stream.
[00:26:33] Um, you need to avoid overloading.
[00:26:37] Then again, this is something that is very, very visible on a production line. If you see a worker with too much work to do, that is immediately visible. You see this person tired, you see this person making mistakes, you see this person hurting himself or herself. It is immediately visible when you overload your process or when you overload your people, immediately visible. Another aspect of good flow in in Lean, of course, is sharing knowledge. Um, because the more we understand, the more we know about the process, the more we can improve it. And finally, early defect detection. Uh, that's the reason why in the Toyota Production System, every worker has the authority and autonomy to stop the production line if quality degrades. Okay, they can stop the line. Everyone can stop the line if there is a quality issue. Immediately, immediately. And they do that for a very simple reason and that's the same thing for software. Uh, the cost of correcting a defect increases exponentially the more far you are from the point where the defect, where the defect was introduced. In other terms, fixing a bug when the software has been released to the users is incredibly more expensive than fixing the bug one minute later I wrote that code. And that's why we try to detect um defects as early as possible.
[00:28:20] In Agile, we try to do all of the above, as I just mentioned. Um, except that our work is generated 100% by cognitive work. The product is generated by cognitive work. And that means that we need to make it visible. We need and that's the reason why I loved Thierry's presentation and I loved that he showed sticky notes when he represented the value stream.
[00:28:50] It was not some kind of, you know, benchmark or graph, up, down, stuff like that. It was something very, very physical and tangible. It's it's much better to make intangible work visible using a physical medium rather than another intangible thing like a display. Okay, like a digital display.
[00:29:19] Um, and that's why I wrote in theory over there. You try to make it visible. But there are some tools that are not helping us.
[00:29:29] Being being Agile. I don't want to name names. Okay. Uh, it's not polite when I have a Microsoft in my hand. But we all know tools that are hiding information from you. Right? Especially Australian tools.
[00:29:49] Okay?
[00:29:51] They tend to hide information from you rather than making information visible. For instance. Quality is another interesting topic. Because as I said, in Lean, quality is really multidimensional. When they talk about quality, they're talking about the quality of the process, the quality of the product, the quality perceived by the user, the quality perceived by the worker. So they they talk about quality in a very holistic way. And then again, quality can be immediately observed, can be immediately checked, very very easy to do. Um, in Agile, quality is more elusive. It's not easy to for an intangible product to um, declare if the quality is sufficient. Well, of course, if your, if your software is not behaving as expected and generates incorrect results or generates problems to the users, clearly the quality is not so good.
[00:30:56] But there is a large grey area in software about quality. When you ask someone, okay, is this good enough?
[00:31:03] Different people can have different opinions.
[00:31:08] And in terms of technical quality, then again, in Agile software development, in theory, we have quality instilled and supported by the process that you choose. Um, if you use XP, for instance, extreme programming, extreme programming is very, very careful about guaranteeing quality, even pair programming. Pair programming is a way to guarantee quality. Because you have two people looking at the same code at the same time, so you are less likely to introduce defects than when you are alone. So it's it's a fast feedback loop, a quality control system. Okay, if you do it.
[00:31:55] Um, and then all the techniques that that we know, the technical stuff that we do. And that's exactly the thing.
[00:32:05] Um, one thing that Lean manufacturing can learn from Agile is the important of technical agility. As software developers, over the last 30 years, we have created a number of very sophisticated techniques to be able to be Agile at a technical level. So what does it mean to be Agile at the technical level? It means to be able to adapt to change gracefully. I like the term gracefully because it doesn't mean at zero cost, every time you change something is going to cost you something, but it can be horribly difficult and horribly expensive.
[00:32:49] Or it could be easier to do and not so expensive. So the whole point of technical agility is to be able to accept change gracefully. So things like um, mock objects, for instance, or inversion of control containers, all these techniques were designed by people who wanted to be able to accept change gracefully.
[00:33:17] And the reason why I chose that specific picture is because that's an example of a technically agile architectural solution. Uh, that's an office. Okay, you see the desks. And what you see on the ceiling are power cords. Okay?
[00:33:38] So that means that you can rearrange that office anytime you want. You don't have the power supplies, the power sockets on the floor or around the walls. If you can rearrange the tables anytime you want with very little cost and effort. All you have to do is to bring down the power cord where you want to put the the tables now. Period. You can have power and network connectivity everywhere. That's a technical solution. Probably it costed a bit more to implement that solution than than just having sockets on the wall, but it gives you technical agility. It means that you can change the the usage of that room at very little cost later. And that's the whole point about agility. You know that change is going to happen. You just don't know when. You don't know what. You don't know how much.
[00:34:39] Okay? Just three little things. You don't know when, you don't know what, you don't know how much. But change will arrive. If you are in an Agile environment. Okay, if you use Agile to deal with complexity. Mm. So technical agility is essential. And to be honest, um, the Lean manufacturing guys could learn um something from us. Because I, when I was working with the mechanics for instance, or the electricians uh, that would create the production lines, their approach is always to make
[00:35:19] uh, things as cheap as possible. But that doesn't mean that what you don't pay today, you will need to pay 10 times more later if you need to change something in your product. If the product changes, you need to change the production line. If it changes the production line is complicated, it's expensive, it takes a lot of time, you you lose something, right? So technical agility is something that they can learn from us.
[00:35:47] Ah, so lunch is at 1:45, right? So I'm very well aware that I'm standing between you and your food, so I will not run late, I promise. But safety is another interesting thing. As I mentioned, safety is critical in Lean. We don't want anybody to get hurt. Not immediately, or it could also be a professional illness like, for instance, ergonomic ergonomicity. Okay, letting people work in an ergonomic way.
[00:36:24] Because since we are creating the same product over and over again, people will need to make the same movement, for instance, hundreds of times every day. And we want to be sure that these movements that people are making is not hurting these people. Okay, so the ergonomics of work is very much important, not just the fact that I will not hurt myself in an accident. In Agile, that give me a lot of food for thought regarding regarding Agile because I don't think that in Agile we take good care of safety. Um, and the reason is very simple. Because we work with intangible products, because what we do is not visible. It is very, very easy to work in a non-safe in an unsafe environment. For instance, it is very, very easy to overload people with too much work. Because you don't see the work.
[00:37:28] If somebody tells you, even if you are doing Scrum and somebody tells you, and you are not using Scrum well, and somebody tells you, okay, we need these, you know, 10 features or these 20 user stories ready in this sprint. And you say, well, you know, our velocity is usually seven user story, now we need 20 this time. Okay? Um, it would be much different if every user story were a box, right? If it were a box, a physical box, you could say, well, you see, we don't have, we don't even know where to place those boxes. They're too many. Okay? But if they're just, you know, tickets in a in a tool that you use, it's very easy to overload people. It's very easy, uh, now that you're working remotely, it's very easy not to notice if somebody is not feeling well, if somebody is too stressed, is overwhelmed, because we don't talk now anymore, right?
[00:38:29] Um, on the workplace, we used to have coffee breaks together. We used to talk, how are you doing? How are things for you?
[00:38:37] Okay? But now, all we have is, you know, team calls, teams calls or Zoom or whatever you use, and it's all very efficient. And in some companies that I work with, I've seen people being in meetings, online meetings, you know, back to back every hour, you know, for three or four or five hours straight. So there is no longer the possibility for people to uh, share how they are, how they are doing. So we are definitely not taking good care of safety for knowledge workers. It's easy to overload them, it's easy to overlook uh, how they are. And so you get stress, you get burned out, burned out, you get anxiety, you get a number of uh, physical and psychological problems, because we don't take care of safety for them. And that's one thing I learned from Lean. Take care of people's safety.
[00:38:49] work with, I've seen people being in meetings, online meetings, you know, back to back every hour, you know, for three or four or five hours straight. So there is no longer the possibility for people to share how they are, how they are doing. So we are definitely not taking good care of safety for knowledge workers. It's easy to overload them, it's easy to overlook, uh, how they are. And so you get stress, you get burned out, burnout, you get anxiety, you get a number of, uh, physical and psychological problems, because we don't take care of safety for them. And that's one thing I learned from Lean. Take care of people's safety. That's one thing I learned from them, not them from me.
[00:39:40] So, uh, by the way, we don't have, I I I introduced a few slides here just in case you guys were interested. Uh, I'm going to skip very fast on these slides, but one of the problems that I had, as you, I don't know if you're trying if you're starting to understand the problem I had. The problem I had is that I was working with two different cultures. There is a culture of optimization, a culture of efficiency and so on. And there is another culture, which is a culture of adaptability, exploration, taking risks, not knowing what happens tomorrow. Okay. Two very different cultures. So, one of the problems that I had, uh, was to, how to, to improve understanding for each other. And so I I I started to think about metaphors, like metaphorical concepts. Um, because metaphors are very, very powerful. We think in terms of metaphors, we see the world in terms of metaphors. Like this metaphor is very popular.
[00:40:48] Do you get it? Yeah, time is money. Very popular metaphor. Okay. I don't know if you agree with it, but you have heard this metaphor time is money. Now, when somebody's saying time is money, they don't mean literally that time is money. Okay, you cannot pay your gas bill with time, you need to pay it with money. Okay, so time is not money. At the same time, people think of time as if it were money. That's why we have expressions like spending time. You spend your time. We have expressions like we invest our time. We have expressions like we waste time. Okay. These are all verbs that are economical verbs. Invest, spend, waste, something like, see? That's why people think in these terms and that means that they perceive reality through this metaphor. That they are investing time, they are spending time and so on and so on and so on. And when you see the world through certain lenses, then you act and you speak depending on your perception. And the way you you act and you speak influences the words that you use and so on and so on and so on. So it's kind of a loop, right, it's an infinite loop.
[00:42:14] So one thing I tried to do for them was to, uh, to try to create a language, a common language based on metaphors. To make sure that these two different cultures could start communicating at the same level. Now, I'm not going to go through all the stuff here, but if you want more information, I'll be happy to provide it, uh, just contact me on LinkedIn. I'll give you give you the references later. But anyway, I started to creating a common understanding using language. Uh, I'll give you an example. Um, people use the word team very lightly. Okay. Oh yes, we have a team working on that. Then you go looking and you see that the team is actually three guys that spend 30% of their time in different moments.
[00:43:07] In different moments, uh, working on something and they don't really interact. Because the that 30% they are never together. Okay. But we use the term team. Okay. Now, if we have a little discussion and we say, okay, listen, there is a work group. It's like, uh, like the the the workers you you you come in to renovate your house, sometimes you get the plumber, sometimes you get the electrician, okay, it's a work group. And another thing is a team, a team is like a sports team. They support each other, they work together, they play together, they suffer together, they win together. So, two different things. Just clarifying the metaphor, sport team, plumber, okay, is a way to, uh, to help understanding, mutual understanding. Uh, these slides are just zooming in in different aspects. We have organizational patterns, we have operational patterns, we have business patterns. Cultural and that's it. Then again, I just wanted to mention this briefly, but if you're interested in the topic, please feel free to contact me either here or on LinkedIn, which is the only social network I use. And I'll be happy to to interact. Um, so what did I learn about working with them? One thing I learned is that it is pointless to think in terms of dichotomies.
[00:44:38] Um, having these manicheistic approach, which means this is good, this is bad, uh, this is nice or this is, uh, um,
[00:44:49] This is nice, this is ugly and stuff like that. What you see on the screen is basically a I did a lookup on a on a search engine. I just typed lean versus agile. And you have like 1,000 articles on lean versus agile. There is no lean versus agile, there is lean and agile. Okay. And if you're smart, you can put them together. Okay. Uh, or you can use one or the other, but there is no, I mean, thinking in terms of one or the other is definitely not something that is helping understanding and using this stuff. The other thing, another thing I learned is people in lean and therefore, people with an industrial mindset and then again, the industrial mindset is much more ingrained into our society that we generally think. So, people in with this mindset, they think in terms of measuring stuff.
[00:45:47] Like, you know, KPIs. KPIs are great if you want to measure how many pieces come out of the production line per hour. Wonderful KPI. Okay. But they are never, never a direct representation of value. And so what we need to do is because in Agile we focus more on value delivered. Rather than stuff delivered. Okay. OKRs can work better in certain situations. Objectives and key results, I'm sure many of you have heard the term. But objective and key results are much more suited for cognitive workers than KPIs that were designed for machines. A KPI is a key performance indicator of a process. Okay. Your people are not process. The ideas, the intent, the ambitions, the experiments, they are not a process. You cannot use KPIs in that specific environment. The other thing is that when you set the expectations too early, which is another thing that the guys in Lean production are keen to do. Uh, like, yes, we need to, we need to redesign our production line, and we want to have our expected, uh, lead time, that's a technical term or whatever, and so on and so on and so on. Well, the problem is, when you, when you make all the important decisions at the beginning, um, there is not very much agility left. Because then, if you make all the important decisions at the beginning, then you are just a checklist of things to do. And I've seen this in software development as well. Um, I worked with a financial company. And another one was an energy company. They, they suffered from the same problem even though they are in different businesses. So, let me explain it like this. So, at some point somebody had a brilliant idea. And so they spent some time exploring this idea if it makes sense in terms of the market. And then they decided that yes, they want to fund to fund the idea. So they start to put together the project. They start to define the objectives of the project compared to the budget they want to spend. And then they start analyzing the problem in detail. And then at some point they engage IT. Okay. And then the IT department works Agile and so in this this area here. They do sprints, they do whatever they want, they're very agile here. And then the thing is put into final testing.
[00:48:41] And then it's delivered. And then it gets some results on the market. Okay. And then from here to there is 18 months.
[00:48:51] 18 months, that's the feedback loop. 18 months in a market, in a market that is moving at the speed that you can see. And agility was just here.
[00:49:02] That's where they had agility. And why is that? Because all the important decisions was made over there. They made all the important what they thought to be the important decisions over there, and these guys, they just get the grocery list.
[00:49:18] These guys, they just get a list of things they have to implement, period. And the experiment lasts 18 months. Okay. Not a wonderful example of agility. Hm. And so that's another thing that we I'm trying to teach actually both the lean people and the agile people. The other thing is that focusing over focusing on how much you produce has nothing to do with focusing on how much value you generate. I was reading an article a few days ago about an Australian bank that tried to adopt Agile five years ago.
[00:49:59] And um, it went horribly bad. Um, they one of the things that they tried to improve was their home loan service. And their competitors, smaller banks, usually they give you a loan in in seven days. Okay. So the process from application to get it alone is about seven days. These guys after their agile transformation took 51 days. Okay. Competition seven days, these guys 51 days. Okay. And it got worse when they tried to implement Agile.
[00:50:42] Why is that? Well, you have to read between the lines, but one statement that they made. One statement that the CEO was making, uh, during several interviews over the year. One statement was, yes,
[00:50:57] we have 10,000 Jira transactions per month. Okay.
[00:51:07] Completely pointless metric. It's not how much transactions you have per month in terms of Jira commits. Okay. It's about how much value you deliver at the end of the line. Right? You are measuring the wrong thing, you are measuring output, you are not measuring outcome. And by the way, that's also a metric that has very, very easy to to game. Okay. If you, if I say as a developer, if you, um, evaluate my performance based on Jira transactions, tell you what. I can have 10,000 Jira transactions per month per day. I can write a bot that generates Jira transactions, if that's how you evaluate me. Okay.
[00:51:57] So, that's another thing. And I think we are almost done.
[00:52:02] And the other important thing is management. That they need to to switch from the lean mindset, which is I am the expert, I know everything and I'm here to tell you what you have to do. From to switch from that to, I'm here to help you. Okay. If you are in a highly adaptive environment, the expert does not always have the solution. Because there could not be one right solution, there could be multiple different solutions. Equally good or equally bad. Okay. So the the expert approach works very, very well in a complicated system, in a complicated environment. But a supportive leadership style works much better in a complex environment because it allows for more, um,
[00:52:57] for a safer environment to experiment and to fail. So I'm done, basically. Uh, so what I tried to tell you is that lean and agile can they can coexist with different intents. Uh, lean is good for the production backbone, it's good for stabilization, even the formal organization is very good because it gives structure to the to the company. And then for everything else, uh, like informal people networks, learning, experimentation, knowledge sharing and so on and so on and so on. Agile works very well. And if I have to go back to the initial photo in my, uh, presentation, the gift exchange, I think these are the gifts. That the two different disciplines can exchange with each other. So, one thing that lean can give to, um, to to Agile is to, oh sorry, I
[00:53:58] No, it's good, it's good. One thing that Agile can learn can teach to, uh, to lean is be technically agile and have a different approach to, uh, to management. Sorry, I just pressed the wrong button. I'm, and and that's it basically. So, as I said, I'm very well aware that I'm standing between you and your lunch and I have no intention of getting in the way. So, thank you very much. I'll be around for questions even during lunchtime. And thanks a lot.

Transcript