Unbossers Podcast
This show and everything else we Unbossers do is created to help professionals elevate corporate cultures. Our approach is immensely pragmatic. Our content is influenced and inspired by a collective of seasoned executives and experts with real experiences, successes and failures in:
- building meaningful organizations, making ‘doing good’ the constant
- with strong, responsible teams, delivering on their promises
- that focus on the customer
- Embrace transparency and inclusiveness in the workplace
- help each other and grow together cross team borders
- and promote peace, safety and connection in every interaction
Unbossers Podcast
The Lean Tech Manifesto: Grasp the full benefits of Agile at Scale, with Theodo co-founder Fabrice Bernhard
Ever wondered how a childhood memory can shape your career? Join us as Fabrice, co-founder of Teodo, shares a fascinating story from his youth—a car fire that ignited his passion for tech reliability. 30 years later Fabrice is the co-founder of Teodo a tech consultancy powerhouse with 700 employees doing groundbreaking work in the energy sector and beyond, including their successful development of TF1's - French Television - streaming platform.
Get ready to uncover the transformative principles of Agile and Lean Thinking that revolutionized software development and manufacturing. Fabrice and I trace these methodologies back to their origins, emphasizing their humanist vision that empowers teams to innovate and enhance efficiency. We highlight the shift from traditional waterfall methods to Agile's customer-centric approach, enriched by Lean's intelligent waste reduction. Hear stories of triumph and pitfalls and learn how these principles drive value creation through real-world examples.
Scaling agile practices is no small feat. We explore the complexities of implementing methodologies like Scrum across large organizations and how Amazon’s restructuring played a pivotal role in minimizing dependencies. Fabrice shares insights into maintaining agile's essence as companies expand, focusing on customer value and lean thinking to foster a responsive learning environment. Discover how reducing interdependencies can unleash growth potential, and why cultural shifts that view problems as opportunities are crucial for building a resilient, innovative organization.
Fantastic and we're live. Good morning Fabrice. How are you?
Speaker 2:You had a good morning I had a good morning. I mean, it's starting with you, so it's great.
Speaker 1:It's always good to start with a compliment. I like to start these conversations with some personal questions so that the audience gets to know you a little bit from a different perspective. I got about seven cards here in my hand. Each each card has a personal question, so you just say a number, from one to seven, and I'll pick the card and read the question I'm, I will pick three.
Speaker 2:One, pick three.
Speaker 1:One, two, three. What is?
Speaker 2:a memory you keep holding on to, and why? Wow, that's a deep question.
Speaker 1:You can take your time. It could be any memory, yeah.
Speaker 2:What is a memory you keep holding on to and why the thing? I Okay the phrasing of the question, which is like keeping, keep holding on to Like something you will never forget.
Speaker 1:Something you haven't forgotten yet, and why?
Speaker 2:It's. I mean I could answer in so many ways. One of the spontaneous answers I one of my oldest memories ever, which is extremely old, it will probably never disappear is I must be full and the neighbor closes the car and the car starts burning. A fire comes out of the engine. Oh wow, and I don't know, it was like quite spectacular. You know, you're four year old and you're looking at I don't know. I was playing in the street and and just like, just closing the car quite strongly, like makes it start fire, fire. So I, I, and why am I holding on to that? I guess it was like probably one of the most spectacular things I saw when I was four yeah, I can imagine, but it's also, I think I'm trying to put too much meaning for me in that memory.
Speaker 2:But there's also this idea that the technology was not as reliable as I believed yeah, maybe that's where your mission, uh intake, uh, started.
Speaker 1:Um, that's a, that's an exciting memory to hold on to. I mean, I think I would have remembered that as well. I got a similar one, uh, well, not as spectacular, but I remember, um, swimming in a swimming pool and, you know, diving, and then, at one point, not finding the surface anymore. So, having this near drowning experience, oh wow, that's incredible, yeah, and I think I was about six, seven, oh, wow, and uh, I think the reason I keep holding on to it is there's still a fear today if I, if I dive of, I always, I always remember. I need to make sure that I know where the surface is. That's, yeah, memories is a strange thing, because do you remember the actual event or do you remember the last time you remembered it? You know, do you know that theory about memories?
Speaker 1:So the theory is that you actually don't really remember the event, but you remember the last time you remembered it.
Speaker 2:I mean, what is what is so? I wouldn't be able to answer which, which of which, but what is clear is that, yeah, I, yeah, I mean I remember that one because it's first it probably struck me a lot, and then it's been, and it has come back often like it's. It's a really interesting one okay.
Speaker 1:So we already learned that your mission to make tech better started at four years old. Maybe fast forward about 30 years later. You're one of the co-founders of Teodo. What is Teodo and what do we need to know about Teodo?
Speaker 2:So, teodo, we're a tech consultancy, so we build digital products for a wide range of companies. Really, we work with startups, we work with successful scale-ups and we work with a lot of large organizations in almost every industry financial services, aerospace, pharma, health, etc. And so we're about 700 people now spread. So most, most of the team is in par, but we also have two offices, one in London, one in Casablanca, and we've been doing this for about 15 years now already, building tech products ever since, and I guess I mean the reason I'm here is because we had a few epiphanies in our in our journey, and one was really discovery of agile and uh, and then the.
Speaker 1:The next one was the discovery of lean thinking um, what is one product that you guys built, by the way, 700 people, that's like. That's like big, that's, that's impressive. Um, what is one, one product that you've built or helped build with teodo in the past 15 years that you're really proud of?
Speaker 2:uh, um, I mean, we've built so many products and I'm actually, fortunately, very proud of most of them. One. I could give you a lot of examples, but I think there's two types of pride. One is when you're very happy about the impact of what you've done or how ingenious the product was. When you're very happy about the impact of what you've done or how ingenious the product was and I know we've done some stuff in the energy space, um, which which I I find fascinating.
Speaker 2:So we've we've used machine learning to help avoid accidents when you know you're drilling for oil, your drilling for oil. We've used sensors and digital connectivity to reduce the consumption of oil tankers, with quite significant impact, probably because not enough people have tried to optimize it before. And then the other types of products that are a source of pride are often also, like the most the more the public ones, because, for example, if I like two recent products we've been working on, one is the new streaming platform of TF1. So that's very widely used. It's been a huge success for them, and so it's easy to point at it. If you're in France, you know, of course, course, the tv channel, and, and so you've heard about that product.
Speaker 1:Even I, not being a frenchman, I know tfr. Yeah, I've got.
Speaker 2:I've got one even better for you. Um, uh. So we've been working with a large uh, a large organization that runs most of the ski stations in France. So rebuilding the mobile app of a lot of ski stations, wow.
Speaker 1:Yeah, I'll be using that next year probably.
Speaker 2:Exactly, if you're one of these people that go to France to ski, then you might be using apps Okay.
Speaker 1:Well, that also gives a little bit of context why we're here. Uh, this book that you've recently released, the lean tech manifesto congratulations, by the way. Learn the secrets of tech leaders to grasp the full benefits of Agile at scale. So I'm guessing we're going to dive into some words that are widely used but also often misused, so I'd like to start with some very simple definitions. When you talk about Agile, what do you mean?
Speaker 2:It's a very good question and it's not that easy to answer and I guess I'm going to try a decently long answer. So one thing the good thing about agile is at least there's a kind of definition, because the word agile really becomes popular in 2001 when a few pioneers in software engineering, who were frustrated by the way large organizations and consultancies were building software, starting thinking about alternative ways of building software. So that's really. The first important element of context is this you know, the current way of building software was what was called waterfall or vcycle, so something that was very, very processed, very bureaucratic and that was leading not only to disenfranchised teams on the ground but also like spectacular failures. So that was kind of the state of the art. There's one project I'm talking about in the book which is about late 90s, like late 90s, early 2000s where the UK tried to build the UK Benefits Agency, tried to build a card to pay people who needed social benefits and they basically wasted £800 million on a project that actually never really came out. So that was kind of the state of the art and against that state of the art, different people from different kind of backgrounds came to get thought about different ways of working and came together in February 2001 in a resort in Utah and tried to find the common principles that they shared. And they found four principles and they called these four principles together the Agile Manifesto, actually the Manifesto for Agile Software Development.
Speaker 2:And so when we talk about agile, it really starts here. It starts when these, when, like about 12-ish people, a dozen people came together and identified four principles that were really at the heart of working in a better way, so more in a better way. So that's the start of Agile and that really then spread. And of course, today Agile has become so popular that people put a lot of meaning behind it. But I think when you listen to what people understand when they use the word agile, they really understand two things. There's this humanist vision of empowered teams that are more autonomous to create value, and then there's a more, let's say, business vision of innovating very fast to out-compete the market. But when people use the word agile, they usually mean either one or one of the two or a combination of the two so maybe for the listeners and and um to be 100% complete.
Speaker 1:So the four principles that you're talking about are customer collaboration over contract negotiation, individuals and interactions over processes and tools, working software over comprehensive documentation and responding to change over following a plan. Probably because in the projects like the one you mentioned from the uk benefits, they've spent so much time and money on contract negotiations, on processes and tools, on writing comprehensive documentation and following a rigid plan that it cost 100 million pounds but they didn't get to a working software.
Speaker 2:This example, by the way, I mean I use it in the book because it's been audited by the UK government, so you can actually have a lot of information about what happened. And the reality is always more complex on the ground and they actually did a lot of things in the good direction, but the complexity of the project was such that the few things they didn't do, kind of like you know, led to the collapse so that's agile four principles.
Speaker 1:Um, you have your humanistic side and getting faster to the market side. On the other hand, you talk a lot about lean thinking. What is lean thinking?
Speaker 2:so lean thinking is um is a word that really appeared in the 90s, um, and it's, it's been, it's been coined, uh, invented by a few people, a few management scientists we could call them working at MIT and who were working on this research project of understanding why some factories, some manufacturing plants but they were looking at car manufacturing so why some car factories were so much more productive and efficient than others.
Speaker 2:And they researched that for, I think, five years and identified that the Japanese car factories, but actually really one company, toyota was completely outperforming the others, and it was doing so because it was really engaging the collective intelligence of the workers in the factories much better than any other competitor. And so this really sparked a movement in manufacturing where, of course, all the competitors said we want the same thing, why are we spending 10 times the manpower to build the same car? And because one of the symptoms of this much smarter factory, in a way, one of the symptoms of Toyota having such smarter factories, was that they had less people working in the factory and they had less inventory. So one of their ideas when they were trying to find a name to explain that, they came up with the word lean because the factory was much leaner, much less waste.
Speaker 2:That's where the name comes from. That's where the name comes from. That's where the name comes from. Uh, interestingly enough, I I I heard the backstories one of the competitors was fragile, um. Well, I'm glad it lost um, because one of the ideas they wanted to also express was that it was a very it was a very um difficult system to um to sustain, so it was like constant effort to stay lean. So in a way, it was also fragile and, uh, interestingly enough, they didn't think about the word agile at the time could have been probably another, another option. And then so that that's where the word comes from, and so, in a way, you could define in thinking as the study of the ways of working that are so different at your time and how to adapt them to other industries and other companies, and so that that could be a definition of lean.
Speaker 1:Lean has become go ahead.
Speaker 2:This. This was in the 90s, so it's been, it's been around for now, you know, 35 years and and so, of course, one of the consequences is it's been used and abused and and, of course, with such a word and with such a promise less, less waste. It was used by a lot of consultancies to do cost cutting in companies, so it has, in certain contexts where it's been used to do some harmful things to companies, it has a bad reputation, but we love lean thinking because if you go back to actually the roots, it does reduce waste, but in a way that is actually again, I think, very much in line with what I was saying about Agile, with this humanist vision of developing people and engaging the intelligence to then get the business vision of going faster and with less waste.
Speaker 1:Okay, so we've covered the definition of Agile. We've covered the definition of agile. We've covered the definition of lean thinking. Your book starts from the situation where you had this agile revelation when you were growing, teodo, and you mentioned that you went all in on agile. What does that mean when a company goes all in on Agile?
Speaker 2:For us it was very practical because we were doing software engineering. So for us, agile methodologies such as Scrum or Extreme Programming were very well adapted to our business. And going all in means that when you look at these methodologies, you see a lot of good ideas and you start doing a bit of pick and choose and going all in is actually deciding to. Okay, I will read the book, I will do the training and I will make the effort of understanding the whole system and then applying it completely and not just parts of it. That's quite important because actually the people who design the systems I've put a lot of thinking and efforts into designing them. I'm talking about good systems and if you only try a part of the system, well, you lose the benefit of the whole thing.
Speaker 1:So for us it for us as an example. Sorry to interrupt. If you take agile scrum methodology, that foresees a number of patterns, some meeting patterns to do planning, to do stand-ups, to do retrospectives. It has a number of core roles that the system needs to have and what you often see in companies is that they say, well, this meeting ritual we'll skip, we'll focus on this meeting ritual, but we actually don't need that role, we'll replace it by a traditional manager. That's what you mean with not applying the full system as it was designed you mean with not applying the full system as it was designed.
Speaker 2:Yeah, and I think and again, I'm not saying that because that's one of the it's an argument that can be badly used. You know you could say, oh, you need to, like you know, follow the system in a completely and, and you know, potentially in a stupid way. But what I was saying is, at the time, with our understanding that was still quite junior of these methodologies, doing really scrum by the book was a way to get the benefits of the whole thinking that had been put into the system. And then, as we started understanding the why behind some of these rituals and rules, then we were able to do continuous improvement and adapted probably better to our needs, etc. But the reality was what was really good for us is when we decided to go all in. We didn't have enough understanding to actually know how to adapt things. So it was better to actually do everything as prescribed, realize it worked and then realize why it worked and then start doing a bit of continuous improvement.
Speaker 1:I get it. But then, at a certain point, TODO continues to grow and you hit the limits of Agile. What hit the limits of Agile? What are the limits of Agile?
Speaker 2:so the reality I mean there was no limits inside the software engineering team. It was really working so well. It was day and night compared to what we were doing before. The client representing the business need was in the team. It was going fast. There was continuous improvement. For us, it was what Scrum and Extreme Programming and DevOps IDs have brought to. That software engineering team was amazing. That software engineering team was amazing Really. It was giving us better outcomes, better products, happier clients and happier teams. So I guess what it really did to us was give us the conviction that sometimes, when things were difficult, there was a different way of working hidden somewhere that we didn't know about, that we could adopt to really improve things. And that's what agile mythologies have done to the software engineering team.
Speaker 2:However, the limit is not really a limit in the sense that Scrum never promised that. It was a framework to run a company. At the time, the question was what is the equivalent framework that would really improve things that we could apply at the company level? What is also the framework that would really change things that we could apply at the company level? One is also the framework that would really change things that we could apply on very big projects, where it's not about one team but really about three, four, five teams. So these were the questions we were asking ourselves. These were questions that the agile movement was not answering at the time. And yeah, that's basically the limit it's just. At the time it was really clear that agile methodologies were designed for one small software team and if you looked at the whole company or if you looked at a project involving 5 or 10 teams, then you needed to look for a different answer.
Speaker 1:Is it also related to a phenomenon that you often see happening in organizations that a software team or the IT department goes into this agile adventure and they find that it improves the way they work, but they have a lot of challenges involving their business partners in that agile way of thinking and that you somehow end up with this half-pregnant state of being right With one foot in agile and then one foot in the classical corporate bureaucracy? Is that related to the limits that you've just described?
Speaker 2:yeah, it's a good example, but this is I would put it in the in the category of multi-team project, because when, when you know, when agile was working incredibly well for us, the business stakeholder was in the team. So what you're describing in larger organizations is that first you have multiple teams, so the business stakeholder and the tech engineering team are not in the same place, they're not working together full time, and that's one constraint. And then the other constraint is often there's not one business decision maker, there's a whole organization with multiple stakeholders, with different constraints, different needs, and so these are really two big constraints that mean that the agile principle of customer collaboration over contract negotiation doesn't work anymore. And if you look, at the extreme programming.
Speaker 1:Why doesn't it work anymore? Because the customer is no longer part of the team.
Speaker 2:Exactly. Extreme programming says customer collaboration over contract negotiation means the customer is in the team. Scrum means the customer is in the team. Scrum says the customer is the product owner. So we've done that and it's amazing. It's incredible and we, you know, it was also the you know, still the early days of digital transformation. So we would be able to say to, like you know the leader of a small business, we would say you are the product owner.
Speaker 2:And, of course, if you have the leader of the small business as the product owner, you get the full benefits of agile, because they know what their business needs. They have a really good understanding of you know what what they need in terms of digital to catch up with competitors and all they need is a team of engineers around them to think about the product together. And that's where you get the best of Agile. When you're in a large organization and you can't have the CEO in the team for multiple reasons One, maybe the CEO doesn't even know what the product is about. So the people who actually know what you need, well, there's not one person but, like you know, five or six, and the size of the and the complexity of the organization means it can't really be sold by one team of three engineers but you need, like you know, 30, 40 engineers. That's when you can't just say, okay, let's collaborate with a customer, because you're like, which customer and which team gets to collaborate with a customer? And what about the other teams?
Speaker 1:Okay, so the problem is clear. In the book, you present a solution without disclosing all the secrets of the book. What is the? What is the?
Speaker 2:the essence of the solution that you found through experimentation and experience well, I I'll start by this example, because I think it's a good one, and then probably, like you know, explain how we generalize it.
Speaker 2:But on that typical example, which is how do I get this magic of having the customer in the team at very large scale?
Speaker 2:And I mean first, there's no perfect answer.
Speaker 2:But when you, when you study lean thinking, you realize that one, you know one really important principle and it's actually defined as the first principle in the book lean thinking is value for the customer. So the idea is, instead of saying, okay, we'll rely on customer collaboration to get to build the right product, you acknowledge that you can't just put the CEO in the team and that's going to work. So you're saying, but what we can do is really clarify the north star of value for the customer. Make sure that we have this shared understanding of our collective objective, which is creating more value for the customer. Make sure that we understand the challenges that we're facing to create more value for the customer and then design the organization in a way that communicates, and design the organization in a way that teams on the ground know how they contribute to that value for the customer, a way that teams on the ground know how they contribute to that value for the customer, and so that's how you get some of the benefits of this agile customer collaboration, but at any size of organization.
Speaker 1:Yeah, so practically, that would mean that, instead of kicking off a project directly by collaborating with the customer and almost immediately start drawing what the customer thinks he needs, you spend more time in identifying the actual value that you want to create, together with a couple of representatives that are representatives of the customer.
Speaker 2:One thing I would be mindful of is to not make it a sequential process. Often one of the benefits of a large organization is that you exist, so you already have products, so you're already providing value for the customer, so there's no need to stop everything and, you know, be like. We need to understand value for the customer. So there's also something about lean thinking, because it's really it comes from very large organizations where it's very much more dynamic, which is which is, you know how do we improve the current state and typically what you know to be practical and when we're talking about this, you know principle of value for the customer.
Speaker 2:It's about going for the leadership team to go much more on the shop floor, because often what you realize is you know you're taken by all the needs of a large organization and you spend less and less time on the ground and you start not really seeing anymore what customers like, what customers don't like. You start also being disconnected from the challenges of the teams on the ground working on the product and and having this discipline of going very often on the shop floor talking to the people that are really like building the value helps really improve your understanding of what value for the customer is. So that would really be. Step one is to say uh, you know, if you want to lead with value for the customer, that means that leadership team needs to have a very good understanding of what that value is, which means being much more on the ground where the value is already created. Because, to take you know, I'm reacting to you saying, okay, we should, should stop and do some upfront design.
Speaker 1:Yeah, which is true, fantastic. No, I love your correction.
Speaker 2:Yeah, but it's the dynamic situation when you arrive in the organization is that they already have a product. Yeah, they already know what they're doing, but probably leadership team has a less good understanding than what they believe, they start having misconceptions about the reality that you try to break by bringing the leadership team on the shop floor.
Speaker 1:So that's, that would be really like one very practical example. I love that because then it becomes a dynamic and social learning process. Um, when they are on the shop floor and they're just on the job, learning from each other, rather than going into these half-day brainstorm and workshop sessions and trying to reinvent the the wheel. So exactly, and thank you thank you for the correction.
Speaker 2:I'll give you two amazing examples. I mean we you know I could give you our example. So we look, we look at the products we build. We leadership team Benoit, my co-founder, and I we go on the ground, we look at the products that we build. We look at the code that is being written.
Speaker 2:But, to give a probably more convincing example, jeff Bezos really spends one week every year. I mean used to spend one week every year. I mean he used to spend one week every year. One year he would be in customer service. One year he would be in fulfillment centers and really doing the job, really doing the job. And on Monday I was spending time with Mark Renetto, who was like senior vice president of worldwide operations, and he was telling me how he was like stowing products in in the, in the fact, in the fulfillment center. And now we have discovered that you know the, the barcode readers usually often had not enough battery. So that's, that's what he means is really like doing the job that you know that the worker on the ground is doing, to understand how some of the ideas that you have about what is happening are actually not perfectly right.
Speaker 1:Okay, so that's leading with value for the customer. Then you write in your Lean Tech manifesto a tech enabled network of teams over individuals and interactions over processes and tools, which is the agile principle number two individuals, interactions over process and tools. And you say, no, it needs to be a tech enabled network of teams. What do you mean with that?
Speaker 2:And first I mean just a small correction. One thing that the book does is reorder the Agile manifesto. Okay, because one thing you learn when you start studying Lean, lean thinking is that it all starts with the customer, and in the Agile manifesto the customer is the principal number three. So we did reorder that.
Speaker 1:So it's first the customer, then the teams, then the teams. Yeah, makes sense.
Speaker 2:It's a very you know what it could be a philosophical debate. Lean thinking has chosen their side, which is customer first and creating values for the customer through the development of people. So it's a very it's a very humanistic vision of work. It's a very pro people, uh, vision of work, but always at the service of more value for the customer, to make sure that the organization stays aligned.
Speaker 1:That's the common ideal that the teams need to get out of their comfort zone, which they need to do if they want to develop themselves. If there's no such ideal that they can strive for, far less people will be triggered and called for action, and so they will not develop themselves. So I, I, I, completely yeah, and what's the purpose of an organization?
Speaker 2:um, it's, it's, it's it's to is for the people in the organization to build something together.
Speaker 1:An organization is a context in which people with a common goal come together because they cannot manifest that goal and realize that goal by themselves. And that's the. Yeah, fully agree. So a tech-enabled network of teams that triggers me. What do you mean with that?
Speaker 2:So that's so. Yes, so then, you know, looking at the Agile Manifesto and taking our you know, 10, 12 years of experience of practicing Lean, growing our company and being coached by some of the best Lean experts in the world and studying tech giants you know, such as Amazon or Apple or the Linux organization very interesting too. We, we came up with ways to kind of reformulate the principles of the Agile Manifesto, which we thought were scale, compatible and on the individuals and interactions, one which is really the first principle of the Agile manifesto and it's really at the core of this humanist vision of Agile, of more autonomous teams. The question was how would you maintain that kind of autonomy when the organization becomes big and you start having dependencies in all directions and and basically you can't just say it's individual interactions and I don't care about the rest, because and I'll give you the simple mathematical argument is, the number of interactions grows to the square of the number of individuals. So you know, if you have well, I'm not sure about my math, but if you have three individuals, you basically have three potential interactions, but once you start having hundreds of individuals, you have like millions of potential interactions, or at least thousands, and one pattern. I realized that was very specific to tech, by the way, that you see in the Linux organization, that you see at Amazon, was this ability to redesign the organization to make it more distributed. You see it at Google too, and that was very fascinating and you know. So we dug into it and we realized that, you know, using the technology, the teams were actually part of a bigger picture, but very autonomous on the ground because their interfaces with the rest of the organization were fully automated.
Speaker 2:And so this is a bit conceptual. So, to make it very concrete, the best example is probably Amazon. So Amazon early 2000s is this huge application, just like any other tech company. It's a lot of code. Everything is, you know, dependent of everything else and so, very concretely speaking, when a team needs to change a column in the database, they need to submit a request to the database. You know administrator team who meet once a month and decide whether the request is valid or not, and if it's valid but not well explained enough, then they say okay, come back in another month, improve your request and come back. So very bureaucratic way of trying to coordinate different teams.
Speaker 2:They have another such system for like transverse projects. So if you need. So basically, you need for your business target. As a team, you need to work and you need to improve things in different places. So you need to convince the other teams to work on your objective. So for that, there's this huge process where you make a request for transverse kind of funding and all these requests come together once a quarter. There's this huge meeting where all the directors of Amazon look at all the transverse projects and decide which ones are going to be prioritized and which ones are going to be postponed. And what is incredible for the teams on the ground is they're waiting. So they've been preparing this for almost a quarter. They're waiting for the outcome, and the outcome can often be sorry. Not only does your project not get prioritized so good luck for your business objective, because the project you need for that is not okay but on top of that, you know some of the time you have needs to be invested on somebody else's transverse project, and so people really hated it. They have no autonomy. They could not, you know they just they had to work on somebody else's objective and they were not allowed to work on their own objective. So and this typical of a large organization and a large bureaucracy and because you have to deal with all these dependencies and it's very, very difficult.
Speaker 2:The genius of Jeff Bezos at the time is when people were starting to say, oh, we need better communication. He said you know what? We need less communication. Because you know, communication is the symptom of all these dependencies and we need to reduce these dependencies, these interconnections between all the teams. And so the solution was a technological solution, not just, but very much. So they decided to basically re-architecture the whole code into what they call the service-oriented architecture, basically make it much more modular, assign a team for each module and then design interfaces that were such high quality between these teams.
Speaker 2:In tech, you call these APIs or application programming interface, and so make sure that these interfaces are so well designed that when people need to use the interface, they don't need to call you to understand it. So you reduce the dependency. All of a sudden I'm like, oh, I need the data of that team. Well, I don't need to call them, I don't need to do a meeting, I don't need to convince a manager, no, I just connect to the API and that's it.
Speaker 2:And that was really a game changer for Amazon and that really unlocked the growth from 2000 to quite a few more years. And it's incredible because it's also the early inspiration for the cloud, because you can imagine that some of the teams were like, oh, I still need to send a paper request when I need a new server, why don't I have an API to request a new server? And they were like, wow, we're the only ones in the world where you just get a new server on demand. Maybe that's a product that the rest of the world needs, and that was the start of servers on demand. Maybe that's a product that the rest of the world needs and that was the start of servers on demand, servers as a service, infrastructure as a service and that was really the beginning of the cloud back in 2003, 2005.
Speaker 1:Okay. So I think the problem that you sketched at Amazon, with all the managers coming together on this quarterly meeting, should sound very familiar for many people listening and then adding on to the root cause, or the perceived root cause is the communication is not good enough. We need more communication. So that sounds very familiar and it's enlightening to hear that. Then the solution was no, we need less communication.
Speaker 1:How can we use technology to decrease the interdependencies between the different teams? Decrease the interdependencies between the different teams? And so that's what you probably mean with a tech-enabled network of teams, that is, that you have all these teams working for the large part, independently on their own objectives, but they are connected to each other in a network through technology, like the APIs that you mentioned, wow. Network through technology, like the apis that you mentioned wow. We have two more to go. The agile manifesto principle is working software over comprehensive documentation, probably coming from the fact that we spend so much time documenting what we are trying to code and in the end, we have these great documents but the software is not working. You mentioned as a principle, write first time and just in time. Please explain.
Speaker 2:I mean, all of these principles are based on multiple books. Each it's a huge body of knowledge. On that one, what is very interesting is, first, working software was an amazing principle from Agile and the idea was really, you had these people who are spending so much time preparing to code but never coding. The actual value is created when you write the code. Agile was saying let's stop that. Let's deliver quickly. By the way, when we deliver quickly, we reduce complexity. So we tackle some of the challenges of quality and delivery, because you know, if you wait six months to release a piece of software, then you need to spend a lot of time at the end of these six months verifying that it doesn't have bugs. When you release software, you know every hour. Well, if there's a bug, you just revert to the previous hour software every hour. If there's a bug, you just revert to the previous hour and then you have to basically investigate why the additional hour of work introduced a bug. It's quite easy. That's a really, really good principle. This one scales up to a point, but there's a point at which it doesn't really tell you how to address very large, complex projects. When it comes to delivering at the very large and complex scale. Toyota is the best in the world. They've inspired manufacturing companies all over the world because they really went much further into what you need to do to produce higher quality and deliver more continuously. And so this again multiple books have been written about that, but the principles at Toyota are called Jidoka and, just in time and to avoid using a Japanese word, we translate it by write first time. And there's a lot of ideas that are captured by these two principles, but if I had to, you know, just give a few.
Speaker 2:Write first time is really the idea of doing what is now called in software a shift left of quality, so trying to do the quality check as early as possible. And then the question becomes what does early mean? So you look at the way value is produced in your organization and you look at where quality of the value is verified and you try to think could I do it earlier? Could I have QA, for example, qa at the end of process, qa meaning quality Quality assurance teams? Yeah, could.
Speaker 2:Maybe the product owner, if you work, for example, in Scrum, do the quality check assurance teams. So could maybe, like the product owner, if you work, for example, in Scrum, do the quality check. But could you actually like avoid the product owner, but even earlier, like how could the dev team do quality check? And then you come to the really the earliest part, which is how could the dev actually write code without defects the right first time? And and that pulls a lot of very good practices. Some are technical, like unit testing and test-driven development, etc. Some are also more about skills and human, human capability. So that's one idea.
Speaker 1:One idea is is also the main shift there in the mindset of the developer as well. Well, I'm, as again, I'm, I'm. I'm far away from the tech space, but in my experience the developers they develop with the knowledge that the code will be tested afterwards. So it's like they release it quite quickly and say, well, if there's any bugs, someone will pick it up and I will get it back and I will fix it then. And what you're saying is that there should be a change in mindset, that they try to develop code that has no bugs at all.
Speaker 2:So that's, that's, um, it's, that's yes, exactly so we're tackling the misconception that having a quality assurance team at the end improves quality. Yeah, I was speaking at the uxdx conference in dublin a few weeks ago. It was very interesting because the shared experience around that in the audience, everybody who said who went from having a QA team to removing it said the same thing, which is it improves quality.
Speaker 1:Removing the QA team?
Speaker 2:Yeah, removing the QA team improves quality and you mentioned one of the reasons is because an organization is, there is a dynamic system. So if you pay someone to check quality, then the other people say, okay, I'm not paid for to check quality. Well, on the other hand, if you like, stop paying for like one person to check quality. But you know, manage the organization, say quality is everyone's responsibility. Well, then you know, things move and people start caring about quality much earlier. I wonder if that's the same thing in factories.
Speaker 1:That's it's. I'm linking it to a project I'm working on on safety culture. You know the both the physical and the mental safety of people in factories. I wonder if the same principle applies to the health and safety teams, Because we have created health and safety teams that all the other employees think well, safety is a little bit less my responsibility because we have a team that makes sure that there's a rule in place. Yeah, sorry no, but there's a rule in place.
Speaker 2:Yeah, sorry, no, it's a really good point. And, by the way, in a factory, quality and safety are quite linked and so, yes, one of the ideas that is quite popular is about this right. First time, the idea in factories is that in a Toyota factory, and now in most factories, you have what is called an undone cord. So it's a. It's a. It's a cord or a big button that a worker on the ground can push to stop everything at once because there's a safety issue or a quality issue. And and and the management, um instruction is really clear when there's a safety or quality issue, we stop everything until we've addressed it. And that creates this, this, this mentality of saying, okay, this is everyone's responsibility. And why is it everyone's responsibility? Because Because if one person has a problem, everybody else has to stop working.
Speaker 2:So it's a very, very, very strong kind of cultural shift to say, okay, we're not just going to say quality is important, we're going to stop everyone. So we're going to stop the line if there's a quality issue or if there's a safety issue. So yes, yes that completely changes the way people look at quality and safety and just in time.
Speaker 1:What do you mean with that? In, in. So the thing is specifically in software.
Speaker 2:This is where you know we're really talking about the dynamic system, because if I say okay, you stop the line. Every time there's a quality issue well one, and you have there's no trade-off, then you just stop the line. Every time there's a quality issue and there's no trade-off, then you just stop the line all the time and then nothing happens. The very interesting thing is right. First time and just in time are really the two pillars of the Toyota production system. The idea is to put some tensions. There's a tension on quality, which is the priority, but there's a tension on quality, which is the priority, but there's also a tension on delivery. And really, so just in time is this idea that you're going to try to work as much as possible on what the real customer needs are. So you basically build a car only when somebody has decided to buy that car.
Speaker 2:So what does it mean in software? In software, people are not buying features at the end of the day, but kind of Because usually, why do we code? We code because some people in the organization have decided that it was worth investing in building a feature. And so the idea of just-in-time is you don't you work on one feature at a time and you put all the efforts into releasing it and you make sure that the organization kind of that feature flows through the organization. It's quite conceptual, but one big tool. There are ideas, there are practices and there are tools. The really key tool when we're talking about just-in-time is called the Kanban, and what is important is that the word Kanban has been used in our digital world for a while now but to describe anything that has columns.
Speaker 2:Yeah, it's a to-do list, so it's become basically a to-do list, it's become a Kanban, and that's missing some of the key aspects of what Kanban means at Toyota.
Speaker 1:Do you have time? Can you explain the key elements of Kanban in one or two minutes?
Speaker 2:Yeah, I can try Again. There's entire books about it. Kanban the idea is it's a tool that is used to connect what you're working on to the needs of the customer or the organization. But, yeah, so Kanban the idea is, you try. So it's a tool that is used to kind of connect what you're working on to the needs of the customer or the organization. And so basically you have these cards that represent, like, the current order. And so what we do in digital is we present these cards with little rectangles and columns, so Trello cards or Azure board cards, etc.
Speaker 2:But one of the key ideas is really to see, to visualize the bottlenecks in the organization. So there's three key things that you need to kind of make sure that your columns have, or they won't be helping you on finding the bottlenecks. So the first one is really the lead time. There's only one thing to do, that's. It's that one, so it's you know. In a way it's very simple. You just put the number of days on the card since the day that somebody decided to, you know, invest in that card. So I don't know if you you decide to.
Speaker 2:So it's a counter every day, plus one every day so I don't know if you decide to add, you decide to add the one click payment feature to your e-commerce website and you have the number of days since. You know, since leadership or the organization side, that was key and and and until today. The reason people don't do it is because the the information is often very painful. Yeah, indeed, it's hard to believe that you, that it's been 233 days, but it's a reality. And the idea is, if you see the number of days quite quickly, you will see this feature sending out that has been there for 232 days and that's a problem. So you can identify why. What happened? Can we dig into it? Can we understand? So it will identify some bottlenecks.
Speaker 2:Then the second thing which is very important is really to identify inventory, work, inventory. So in a factory, you walk around the factory. You see big piles of stuff. You go to the team and you're like, why is there such a big pile of stuff here? And they say, yeah, because the other team doesn't need them. Yet You're like, oh, that's interesting. So you've not been working on something that was like a good priority at the moment because the rest of the organization doesn't care In digital. You don't see that. You know it's hidden somewhere in a Google Drive folder or whatever GitHub. So the idea is to make it visual. So basically, you make sure that your columns are always split in two One column that says waiting for someone and a column that says being worked on. Again.
Speaker 1:It's a bit painful because you realize that all of your cards end up in the waiting column, but that's the reality, which proves the point that we earlier mentioned at Amazon, that there's so much dependencies that, in the end, work doesn't get done anymore.
Speaker 2:No, exactly. I mean you're trying to visualize the complexity of the organization and of course the complexity is high, so you start by visualizing a lot of problems.
Speaker 1:Yeah, and then one by one, by visualizing, you create awareness, you start thinking about solutions and then, one by one, you can hopefully improve the situation.
Speaker 2:I mean and we'll mention it later but of course there's a cultural requirement for that to work. And then the third thing so we've mentioned lead time on the card column that says waiting. And then the third one is actually these columns should correspond to resources. So typically in an organization the columns should be teams, because we're not really interested in the to-do list within the team. They can have to-do lists if they want, that's fine. But I mean what we need at the organization level is to see which team has too much work and which team doesn't have enough work and how they're dealing with the work inside the team. That's their scope of autonomy. And so when you see often in these columns you will see to do, doing, done. No, what you need is design team, dev team, translation team. Teams are really working independently from each other but actually depend on each other.
Speaker 1:Wow, Now that you've explained it. I don't think I've ever seen Canva applied correctly like you now explain us to do so. Thank you for the clarification, Fabrice. You're welcome. Let's move on to the last principle. In Agile it states responding to change over following a plan. I suppose that comes from the fact that if you're near a deadline and there is some very valuable change that you can make, you should be able to make that change because it creates more value, rather than to having to stick to the plan because that was the original plan. But you improve that principle by stating building a learning organization.
Speaker 2:It's not just about it's not improving. It's not improving, it's really scaling it, because the idea that is very good in Agile is well, the team on the ground knows best how the market is changing and how they need to react to it. The question is when you're a large organization, you want a team on the ground to be able to influence the whole organization instantly. The best example of that that we have is crowd effects when part of a crowd is starting to panic, so the whole crowd starts to panic, and we know that crowd effects usually have catastrophic consequences. So the question is how do you make sure that the organization is aware of the changes and how do you then make sure that the organization reacts, but reacts wisely, basically. So how do you respond to change wisely? And this is where the realized large organization. They have constraints that small teams don't have, but they can really compensate by actually you know, realize large organizations. They have constraints that small teams don't have, but they can really compensate by actually trying to be much more thoughtful. What you need to do as a large organization is to be much more thoughtful about it, because you can't change all the time, but you can definitely need to to to adapt. So building a learning organization was really a good way to capture what you know when you look at Amazon or when you look at Toyota, how they manage to continue innovating at very large scale.
Speaker 2:And so the first idea is staying very, very connected to the customer's needs to really understand how the market is changing. Because once you become this huge boat, it's very hard to realize that you should be turning left, and the temptation is, of course, to continue straight. And for that, what we've realized is the common thing of learning organizations is how okay they are with looking at problems. Right, and because, to come back to my story about Kanban, if you put a Kanban, it's a tool that shows a lot of problems. If your organization is uncomfortable with problems, it's, you know, step one. There's no need to even try the Kanban. So step one is really this Step one is making sure that the organization is comfortable with looking at problems. Um, so this is a huge culture shift. It has to come from the leadership team, um, and it has to be, you know, repeated, uh, continuously.
Speaker 1:and but, yes, you, because one, one key, key symptom you see in organizations are comfortable with problem is that the leaders ask about problems all the time and they really don't blame people who talk about problems yeah, yeah and it might be I think in my, in my book I, uh I I write that I don't know what the key ingredient of a successful organization is, but if I would have to name one, it is that everyone in the company is aware of all the problems that are in the company and nevertheless choose to continue to strive to do better, something like that. So, because in many companies, the problem freezes people. When a problem arises, people freeze, and what you're explaining, the situation that you're explaining, is that problems activate people.
Speaker 2:Problems are, you know, by default they're bad news, and in most organizations they are actually. You know risks, because if the organization is used to blaming someone and you know firing someone when there's a problem then discovering the problem puts you in the visor. So somebody is going to be shot at and it could be you because you discovered the problem. So so, yes, you need to, but in an organization where it's really clear that you know problems will not lead to punishment. On the contrary, leadership shows how interested and curious they are about problems and how valuable they find them, and for that, what is really important and difficult is to remember, because when you see a problem, it's to remember it existed before you saw it. When you see a problem is to remember it existed before you saw it. So seeing it is not the bad news. The bad news is what made the problem happen. Seeing it is the good news. Now you can finally react and improve on it. So there's this mind shift that needs to be done, as you say, for everyone in your organization. Once you have that that well, it's super powerful, because this means that, all of a sudden, every issue that your customer have bubble up or bubbles across the organization and these issues are such learning opportunities of where the market is going, and so that means. So that's really. Step one is you keep at scale, understanding that the market is moving and you have signals of where it's moving to. And then step two is how do you react wisely? And then the idea is, it's difficult but it's making sure that the organization builds on past learnings. We've already seen that something similar, we already reacted in a certain way, so maybe this time we need to react a bit better, etc. So that's really like the continuous improvement mindset and culture, and that relies, I would say, on a few things, but one is really documenting knowledge, and so one ID that we have in need thinking is we call them standards because we want to kind of counter the temptation to document processes, because often people document the process, but with the objective of making sure that then people follow the process. What you want is to document the best way to do something today, but with a clear moral contract that it can be improved if you find a better way or if you face a problem that's not been taken into account by the standard.
Speaker 2:The standard is more like a documentation of the knowledge and a training guide, it doesn't mean that you need to read it. There's this expectation that if you're working on something that has a standard, you should be aware of the standard. You should know the standard, but there's not this expectation that you should follow it stupidly. That's the difference. And then, one thing that is very important is Kaizen. So time dedicated to going deep into your work and it's often a time when you realize that the standards are not up to date anymore. So it's a moment for updating the standards. You find there's a new innovation oh wow, that should be included in the standard. Or the way systems have become more complicated, so this part of the standard. Or you know the way you know systems have become more complicated, so this part of the standard doesn't work anymore.
Speaker 1:There's often tension between the dedication to customer value and the dedication to Kaizen time.
Speaker 2:Well, it's if you're.
Speaker 1:If you're in a customer I mean in really customer-driven organizations somehow there's always a customer that needs something. Now that deprioritizes the time that was scheduled to do reflection and internal optimizations of the standards, don't you agree?
Speaker 2:No, I completely agree, and we're completely guilty of that, because our agile roots mean that the teams work in direct contact with the customer, and so they see the customer needs and the customer stress on a daily basis. So how do you insert kaizen into that? Yes, it's actually very challenging. It's a really good point, and I think that's I mean the lean thinking.
Speaker 2:Lean thinking would not be good if it didn't like account for these tensions, because the reason why people don't do it is because they're difficult, because you need to do two things at the same time. You need to deliver super high quality, but you need to deliver fast. You need to deliver value to the customer, but you need to have time for job introspection, and the idea is to do both in the right amount, and that I think capturing and and the idea is to do both in the right amount, um, and that I think capturing knowing that you need to do both is already step one, and step two, of course, is like trying to do the right amount of you know yeah, and probably if you visualize also those kaizen initiatives on your kanban board, you will quite quickly see that you're continuously deprioritizing them and that they're taking much longer than they should.
Speaker 1:And then that triggers the dialogue on how we can change the system to prevent that.
Speaker 2:But also, I think an important point I need to say is also, when you start doing it well, you realize that it's not one or the other. You realize that if you do super high quality, you actually start delivering faster. You realize that if you do amazing Kaizen, you actually start delivering faster value to the customer. So there is this kind of that's a very good point.
Speaker 1:Yeah, that's a trade-off we often make, like ah, but if we do Kaizen, we're not supporting our customers. But what you're saying is no, you will notice that doing Kaizen improves the quality that you deliver to your customers.
Speaker 2:That's, of course, the need. That requires long-term thinking, it requires a bit of patience, it requires investment, and it doesn't always work. That requires investment and it doesn't always work.
Speaker 1:So to wrap up, just some final questions, Fabrice. So obviously your target audience is people working in tech, I suppose for the book, but for me this was one of the most enlightening conversations about Agile and Lean that I ever had and I've had many. It's not like this is my first conversation, so I'm already super grateful for your time. Thank you. Why should non-tech people read your book?
Speaker 2:I first, thank you very much for saying that, and I think we have a perspective on lean thinking, which is something that is valuable for every organization in the world, which I think is a modern perspective, therefore valuable for, indeed probably everyone. And the tech side. Of course, we're taking examples from our industry, but software is eating the world, so every organization, every industry has now a very strong tech component within them and if they want to scale and remain agile, they need to build these technology enablers to distribute their organization. So, yeah, I think these are the two arguments we bring a modern perspective on lean thinking and we also bring the tech aspect that actually every organization in the world needs to look at.
Speaker 1:I will add a third one. I will add a third one. So the way you approach software is by acknowledging that it's a complex system. And how do you continue to improve a complex system in a way that you don't lose the speed and agility and actually an organization is also a complex system. So what I found is that the challenges that developers have in creating valuable software are very similar to the challenges that leaders have in creating a valuable organizational system.
Speaker 1:And so reading your book. Although the examples are focused mainly on software, they can also be applied to the organizational system, so that would be a third one that I'll add. Where can people buy the book?
Speaker 2:So it's on most online retailers Amazon, of course, for example, Bull in Belgium.
Speaker 1:Yeah, it's also available. Yeah, okay, well, and where can they find you?
Speaker 2:So you can find me on linkedin. Um, it's probably where the best place to find me.
Speaker 1:So my name is fabrice bernhardt it sounds like a german last name, my father's swiss. Ah, your father's was there. Well, again, fabrice, thank you so much. I can't wait to publish this conversation and send it to all my tech contacts and beyond here in Belgium, and I will strongly advise each and every one of them to listen to the conversation and to buy your book. Thank you so much.
Speaker 2:Thank you very much Nick there you go.
