{"id":5635,"date":"2026-02-10T09:28:03","date_gmt":"2026-02-10T14:28:03","guid":{"rendered":"https:\/\/blog-alexis.monville.com\/en\/?p=5635"},"modified":"2026-02-11T01:24:56","modified_gmt":"2026-02-11T06:24:56","slug":"when-agile-scales-something-breaks","status":"publish","type":"post","link":"https:\/\/blog-alexis.monville.com\/en\/2026\/02\/10\/when-agile-scales-something-breaks\/","title":{"rendered":"When Agile Scales, Something Breaks"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">A conversation with Fabrice Bernhard<\/h2>\n\n\n\n<p>In this episode of <em>Le Podcast on Emerging Leadership<\/em>, I welcome <a href=\"https:\/\/www.linkedin.com\/in\/fabricebernhard\/\">Fabrice Bernhard<\/a>, co-founder and CTO of Theodo, and co-author of <em>The Lean Tech Manifesto<\/em>.<\/p>\n\n\n\n<p>Over the past decade, Theodo has grown from 10 people to more than 700, while maintaining speed, quality, and responsibility. In our conversation, Fabrice makes a provocative but thoughtful claim: all four values of the Agile Manifesto have a scale issue. Not because Agile is wrong, but because what works beautifully for small teams does not automatically work for large organizations.<\/p>\n\n\n\n<p>Together, we explore how Lean thinking helps preserve the <em>intention<\/em> of Agile while making it work at scale.<\/p>\n\n\n\n<iframe data-testid=\"embed-iframe\" style=\"border-radius:12px\" src=\"https:\/\/open.spotify.com\/embed\/episode\/5CYJKmOMKwcIykrCIk1qxA?utm_source=generator\" width=\"100%\" height=\"352\" frameBorder=\"0\" allowfullscreen=\"\" allow=\"autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture\" loading=\"lazy\"><\/iframe>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">In this episode, we discuss:<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Why Agile principles struggle when organizations grow<\/li>\n\n\n\n<li>The difference between \u201ccustomer collaboration\u201d and \u201cvalue for the customer\u201d<\/li>\n\n\n\n<li>How Amazon\u2019s API mandate enabled autonomy at scale<\/li>\n\n\n\n<li>Why architecture matters as much as culture when scaling<\/li>\n\n\n\n<li>What a tech-enabled network of teams really means<\/li>\n\n\n\n<li>How to start evolving a monolith without rewriting everything<\/li>\n\n\n\n<li>What it takes to build a true learning organization<\/li>\n\n\n\n<li>Why Lean is not only good for people, but also good for business<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">References mentioned in the episode:<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/www.goodreads.com\/book\/show\/210839038-the-lean-tech-manifesto\">The Lean Tech Manifesto<\/a> by Fabrice Bernhard and Beno\u00eet Charles-Lavauzelle<\/li>\n\n\n\n<li><a href=\"https:\/\/blog-alexis.monville.com\/en\/2026\/02\/04\/beyond-the-hype-industrializing-legacy-modernization-with-ai-lean\/\">Beyond the hype, industrializing legacy modernization with AI and Lean<\/a> by Alexis Monville<\/li>\n\n\n\n<li><a href=\"https:\/\/www.goodreads.com\/book\/show\/289467.Lean_Thinking\">Lean Thinking<\/a> by James P. Womack &amp; Daniel T. Jones<\/li>\n\n\n\n<li>About <a href=\"https:\/\/www.goodreads.com\/book\/show\/44135420-team-topologies\">Team Topologies<\/a> by Matthew Skelton &amp; Manuel Pais, you can also listen to the podcast episode with Manuel Pais: <a href=\"https:\/\/blog-alexis.monville.com\/en\/2025\/06\/02\/unlocking-flow-and-effectiveness-a-conversation-with-manuel-pais-co-author-of-team-topologies\/\" data-type=\"post\" data-id=\"5331\">Unlocking Flow and Effectiveness: A Conversation with Manuel Pais, Co-author of Team Topologies<\/a><\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-full\"><a href=\"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Le-Podcast-Quote-Fabrice-Bernhard.png?ssl=1\"><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" width=\"960\" height=\"540\" data-attachment-id=\"5636\" data-permalink=\"https:\/\/blog-alexis.monville.com\/en\/2026\/02\/10\/when-agile-scales-something-breaks\/le-podcast-quote-fabrice-bernhard\/\" data-orig-file=\"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Le-Podcast-Quote-Fabrice-Bernhard.png?fit=960%2C540&amp;ssl=1\" data-orig-size=\"960,540\" data-comments-opened=\"1\" data-image-meta=\"{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}\" data-image-title=\"Le Podcast &amp;#8211; Quote &amp;#8211; Fabrice Bernhard\" data-image-description=\"\" data-image-caption=\"\" data-large-file=\"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Le-Podcast-Quote-Fabrice-Bernhard.png?fit=960%2C540&amp;ssl=1\" src=\"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Le-Podcast-Quote-Fabrice-Bernhard.png?resize=960%2C540&#038;ssl=1\" alt=\"\" class=\"wp-image-5636\" srcset=\"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Le-Podcast-Quote-Fabrice-Bernhard.png?w=960&amp;ssl=1 960w, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Le-Podcast-Quote-Fabrice-Bernhard.png?resize=300%2C169&amp;ssl=1 300w, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Le-Podcast-Quote-Fabrice-Bernhard.png?resize=768%2C432&amp;ssl=1 768w\" sizes=\"auto, (max-width: 960px) 100vw, 960px\" \/><\/a><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Here is the transcript of the episode:<\/h2>\n\n\n\n<p><strong>Alexis:<\/strong><br>I\u2019m very happy to welcome Fabrice Bernhard. Fabrice is the CTO and co-founder of Theodo, the technology company co-founded with Beno\u00eet Charles-Lavauzelles. Over the past decade, they scaled Theodo from 10 people and 1 million dollars in 2012 to more than 700 people and 100 million in 2022. They are the authors of <em>The Lean Tech Manifesto<\/em>, a book that captures their experience of scaling an organization without sacrificing quality, engagement, or responsibility.<\/p>\n\n\n\n<p>Fabrice, welcome to <em>Le Podcast on Emerging Leadership<\/em>. How do you usually introduce yourself to someone you just met?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>I would say that my name is Fabrice Bernhard and I\u2019m the co-founder of Theodo. And if it\u2019s in a working environment, which I guess this is the case here, I would say that Theodo is an international tech consultancy based in London, Paris, Casablanca, and Cape Town.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>When I read the book, I was very surprised by one of the comments just at the beginning of the book that clearly encourages people to skip a chapter, not to read about that story. And I was very curious. Of course, I read the story, and I found that very interesting. So why that comment?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Yeah, it\u2019s a very interesting question. I think we wanted the book to be about Lean Tech, about our learnings and experience around adapting lean wisdom to the tech industry and tech organizations. We found that our story was a good introduction to that, to better understand the context and where we had arrived there. But we didn\u2019t think it was a necessary part. So that\u2019s what we wanted to convey, to really explain that you don\u2019t need to read our story to learn about Lean Tech.<\/p>\n\n\n\n<p>That being said, I completely understand your point. The story is a very good introduction and I think it provides valuable context to the book.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>When you look back, you were already a small company and you scaled quite a lot. What are the main points of the story you want to tell?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Yeah. I think in the scaling story, if you look at our bottlenecks to scaling, the first one was finding product-market fit. And finding product-market fit happened when we really deeply understood agility, agile methodologies, and we were able to bring them to larger corporates who were definitely struggling to adopt them on their own.<\/p>\n\n\n\n<p>So that\u2019s been the first step. And once we had product-market fit, that\u2019s when the scaling really started. And then the key bottleneck was, how can we scale our organization and maintain this agile culture that we love and that makes our difference to our clients while becoming much bigger, and therefore facing all the challenges that typical large organizations face, which lead them to becoming big, bureaucratic organizations.<\/p>\n\n\n\n<p>And that\u2019s when we met a lean coach who had been through a similar journey, who had loved Agile, had tried to apply it in a large organization and realized the limitations, the problems that Agile doesn\u2019t address when you\u2019re a large organization.<\/p>\n\n\n\n<p>He found Lean afterwards, found answers to all his questions in Lean thinking, and told us, you know what, I can also bring them to you and you\u2019ll see, it will be amazing. And so that\u2019s why we\u2019ve been on a Lean journey ever since. That was back in 2012, and we\u2019re now, what, in 2026. So that\u2019s already 14 years now.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah, it\u2019s very impressive because you mentioned something that a lot of people faced in the agile community. They were able to use the agile principles and the agile values as a team, as a small team, they were able to really improve the way they were working. But in the larger organization, it was not necessarily working. And you explained that very well, going back to the Agile Manifesto and looking at the pieces that are able to scale and the pieces that need a little bit of something else. Can you tell us a little bit about that first part?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>What is very interesting is the first question is, what is agility? And what the pioneers who wrote the Agile Manifesto did very well is give an answer. They wrote the Agile Manifesto, which was the shared understanding of what made an agile software development team agile.<\/p>\n\n\n\n<p>So you can always go back to this manifesto to understand what they meant by agility, which is very good. And so when you look at the principles, I think they make a lot of sense and they capture very well the essence of what it means to be agile.<\/p>\n\n\n\n<p>And then the analysis for us was to think, okay, why can\u2019t these principles work in a large organization? And when you take each value, each of the four values of the Agile Manifesto, and you try to imagine yourself as a leader of a large organization trying to lead with these principles, you realize all four of them have a scale issue.<\/p>\n\n\n\n<p>They all really capture what makes a small team very effective. And the idea is good, but these four ideas just don\u2019t scale.<\/p>\n\n\n\n<p>Two very simple examples. One is customer collaboration over contract negotiation. It makes a lot of sense, but in large organizations you start having two issues. One is you can\u2019t have the customer in every team, as Extreme Programming encourages to do, and which we did at Theodo. It was amazing. We had the customer in the team, and that created magic. But you can\u2019t have the customer in every team when the project starts requiring 10 or 20 teams.<\/p>\n\n\n\n<p>That\u2019s one side of the coin. And the other side of the coin is when you are working for large organizations, there\u2019s not one customer who really knows what they need. You start having multiple stakeholders with contradictory requirements, contradictory needs. And building a great product is really taking all of these into account, understanding the trade-offs, and then making hard decisions.<\/p>\n\n\n\n<p>And customer collaboration just doesn\u2019t tell you how to address both of these issues at scale. And what we thought is, does Lean thinking actually bring a principle that conveys the same kind of intention, but actually works at scale? And we found it.<\/p>\n\n\n\n<p>The first principle of Lean thinking is called \u201cValue for the customer.\u201d And for us, it addresses exactly that thing. It addresses the fact that as a leader of a large organization, you need to work very hard on clarifying and communicating all the time what value for the customer means for the whole organization and for each individual team in the organization.<\/p>\n\n\n\n<p>And that is very helpful. That is very powerful. That is in line with the intention of the Agile Manifesto. And it works at any scale because typically Toyota is very good at this and they have 300,000 employees. Amazon is very good at this and they\u2019ve got a million employees.<\/p>\n\n\n\n<p>So being obsessed with the customer is a very good principle that you will find in most organizations that feel agile and are very large. So that was one example. And then, depending on how long you want me to speak, I can give a second example.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Good.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Yeah. I could give you all four examples, but I\u2019ll just give two. And the second one, and I\u2019ll be shorter, is the core principle of the Agile Manifesto, which is individuals and interactions over processes and tools.<\/p>\n\n\n\n<p>And again, this idea that as a team you can rely on direct interactions to make things work is very important and very useful, but only possible at small scales.<\/p>\n\n\n\n<p>Because as soon as you grow the number of people that need to interact, the number of possible interactions grows to the square of the number of people. And you start having thousands or millions of possible interactions, which makes no sense.<\/p>\n\n\n\n<p>What we found in organizations that had managed to scale and keep some kind of agility is that they had been able to reorganize as a network of teams. So they had basically kept this team spirit by organizing themselves as autonomous teams.<\/p>\n\n\n\n<p>And then the question becomes, how do you manage to create an organization that works as a network of teams in a seamless way, where teams are able to have a strong form of autonomy despite being part of a very large organization?<\/p>\n\n\n\n<p>And we realized that all of the examples we looked at had technology as a key enabler of distributing the work and then reassembling it in a seamless way.<\/p>\n\n\n\n<p>So that\u2019s why we called the principle a tech-enabled network of teams. And as examples, we give Linux and we give Amazon, which we could talk a lot more about if you want, or you can read the book if you want to know more about it.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah. We have value for the customer, that\u2019s basically our guiding star. Tech-enabled network of teams, that\u2019s the foundation to make all those things work.<\/p>\n\n\n\n<p>If we go back to value for the customer for a second, what does that mean for a leader in an organization, whatever the size? What are the questions they should ask themselves?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Lean Tech is basically our own secret sauce. So what do we do internally? It means taking the time as a leadership team, on a regular basis, to actually think about that. What is value at the whole level of the organization?<\/p>\n\n\n\n<p>So that\u2019s one thing. Another thing is to confront that idea of value that you have with the reality of it. Because as soon as the organization grows, what you start having is a disconnect between what you think customers want and what customers actually want on the ground, and what teams on the ground are faced with.<\/p>\n\n\n\n<p>And so there\u2019s a key practice in Lean thinking called \u201cgo and see,\u201d or going to the gemba. Gemba being a Japanese word for where work really happens.<\/p>\n\n\n\n<p>And so that\u2019s a key practice of a leadership team in a Lean Tech organization, to often go and visit teams and be very curious, not judgmental, not reactive to issues, just really to observe how things work and confront your vision of what value is with the reality on the ground.<\/p>\n\n\n\n<p>So that\u2019s the second very important thing. And then there\u2019s a lot about communicating and empowering teams on value.<\/p>\n\n\n\n<p>A great way to communicate value is to build an Obeya. Obeya is another Japanese word that means a big room. And the key idea is that you display in your office, and it\u2019s much better if it\u2019s physical, you display your understanding of the value, your understanding of the key challenges to provide that value, the key learnings, the key recent learnings around that, the key next steps that need to be tackled.<\/p>\n\n\n\n<p>And that creates a lot of clarity and instant widespread sharing of what value means to the whole organization.<\/p>\n\n\n\n<p>And then there\u2019s a whole aspect, and that\u2019s a very popular aspect in the tech world, which is called team topology. So creating or redesigning the organization so that teams are aligned on the value. So identifying the value streams and making sure that the organization is organized around these value streams, so that teams know to which customer they\u2019re contributing and what kind of value they\u2019re contributing to that customer.<\/p>\n\n\n\n<p>So that everyone can be empowered on what is the value that they actually need to build and to deliver. And if they have the autonomy to do that, then they engineer themselves the solution to creating that value.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Do you have an example when you felt you articulated properly the value for the customer at a very high level, but when teams were maybe a little bit struggling with understanding the value, and you\u2019ve seen that moving from not understanding to already understanding?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Ah, it\u2019s a very interesting one. The first example that comes to my mind is not us, but somebody else.<\/p>\n\n\n\n<p>A very interesting organization asked us to come in and evaluate them using the Lean Tech framework.<\/p>\n\n\n\n<p>And one thing we realized is that for leadership, there was a very clear technical requirement around the latency of the product. The latency had to be below 50 milliseconds to be sellable as a home cinema product.<\/p>\n\n\n\n<p>All the studies had shown that if it was above 50 milliseconds, customers would notice it and would not be happy with it.<\/p>\n\n\n\n<p>When we went on the ground and we asked the teams if they knew about it, they said, \u201cNot really. We\u2019re aiming for 80 milliseconds. Fifty is impossible anyway, that\u2019s why we\u2019re aiming for 80.\u201d<\/p>\n\n\n\n<p>So we went back to the leadership team and we said, by the way, one thing we\u2019ve realized by going around is that the teams didn\u2019t know that it was a key part of the value for you to deliver under 50 milliseconds.<\/p>\n\n\n\n<p>The leadership team got a bit frustrated because for them they had made it very clear. And they hadn\u2019t made it very clear.<\/p>\n\n\n\n<p>What we said is: definitely not clear enough. Not obvious enough. Not unavoidable enough that the teams would have needed to raise the issue and say, \u201cGuys, we\u2019re not achieving these 50 milliseconds. What can we do?\u201d<\/p>\n\n\n\n<p>Instead, the disconnect between leadership and teams on the ground made it possible for teams who found achieving 50 milliseconds super hard to deprioritize that challenge.<\/p>\n\n\n\n<p>And that, I think, is a very interesting example that we see in every large organization. Some challenges are very hard. If they\u2019re not made super clear and obvious, quite naturally the organization will deprioritize them for easier things that they can do.<\/p>\n\n\n\n<p>And that, I think, is a harsh example of value for the customer. It\u2019s not just communicating, but it\u2019s also clarifying the priorities and making sure that when things get hard, people know they need to raise their hands and say, okay, we need help, rather than just reprioritize and work on something else.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah, it\u2019s an excellent example of communication not being a one-way street. You need to enable the other way, so people can raise their hand.<\/p>\n\n\n\n<p>I\u2019ve heard that a lot of times. When people are actually doing the work, it\u2019s very different. And you can be frustrated on both sides.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>And I think it was a very good example of frustrations on both sides. Leadership said, \u201cWe had made it clear.\u201d Teams on the ground said, \u201cYes, we heard it once, we raised the issue that it was hard, and nobody came to us.\u201d<\/p>\n\n\n\n<p>And therefore this conversation that should have happened on a regular basis happened maybe once and then never happened again.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah. Yeah. I\u2019m curious: did they succeed in either changing the goal or succeeding in the goal?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>I don\u2019t have the exact answer, so I have some guesses, but I prefer not to share them.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Okay. That\u2019s good.<\/p>\n\n\n\n<p>We discussed a little bit high-level value for the customer. That\u2019s great.<\/p>\n\n\n\n<p>You mentioned the tech-enabled network of teams. Can you unpack that for a second to define that? I know that you discussed team topologies and the idea of stream-aligned teams, and aligning teams on the value. A lot of people are trying to do that, and you can see how difficult it is when you\u2019re really trying.<\/p>\n\n\n\n<p>What is that tech-enabled network of teams you mentioned?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Yes. So it all started with trying to find how do you keep the magic of the agile principle, individuals and interactions, at scale.<\/p>\n\n\n\n<p>And clearly when we look at Amazon, what they did back in about 2000, they had the same issue that every large organization has. They had one big monolithic code base. Everyone that was contributing to it was treading on each other teams\u2019 feet.<\/p>\n\n\n\n<p>And therefore there was a huge challenge on how do we synchronize when one team needs to change something that impacts another team. How do we synchronize these changes?<\/p>\n\n\n\n<p>So they had these big synchronization meetings every quarter. And it was a big mess. And very good developers were starting to leave because they couldn\u2019t be bothered with so much bureaucracy.<\/p>\n\n\n\n<p>We\u2019ve seen that in large organizations, we\u2019ve seen that everywhere.<\/p>\n\n\n\n<p>What they did at Amazon at that moment is that there was this debate around maybe we need more communication or better communication.<\/p>\n\n\n\n<p>And Jeff Bezos had a very good intuition and said, no, we need less communication. The problem is that the teams are not autonomous enough. So we need to find a way for them to find that autonomy again.<\/p>\n\n\n\n<p>And so they started this very large program of creating APIs so that each team would not need to meet with another team. They would be able to interact with them through self-explanatory APIs. So very intuitive APIs, very reliable APIs.<\/p>\n\n\n\n<p>So that\u2019s often called the API mandate. It required a year and a half of investment for the first teams, and then probably became faster and faster for all the teams afterwards.<\/p>\n\n\n\n<p>And the end result was that the Amazon code base was completely broken down into modules. Each team had their own module. And every module, when it needed to interact with other modules, did it through very well-defined, very stable, reliable, intuitive APIs.<\/p>\n\n\n\n<p>And that completely transformed Amazon. It gave them this agility back and was definitely a foundation to their super fast growth for the following years and the following 20 years.<\/p>\n\n\n\n<p>And it was also the foundation for the invention of the cloud. Because once they realized that every dependency could be transformed into an API, the obvious idea was to say, okay, can we transform our dependency to getting a new server into an API, where you just need to say, \u201cPlease, I want a new server,\u201d and get it.<\/p>\n\n\n\n<p>So this is basically the story behind the principle of tech-enabled network of teams.<\/p>\n\n\n\n<p>And in this principle, we really mix two ideas. One is that the team needs to be autonomous.<\/p>\n\n\n\n<p>And from a people perspective, this means having a competent team leader able to help them when they have problems. And a key way to help is not to solve the problem, but to actually teach problem-solving skills.<\/p>\n\n\n\n<p>And so that\u2019s a key lean idea: a great team leader is a team leader that is competent and great at coaching problem-solving skills.<\/p>\n\n\n\n<p>So that was one aspect, the people aspect. And then there was a technical aspect.<\/p>\n\n\n\n<p>Because what we realized, and that\u2019s also what we see in traditional organizations, is that it\u2019s not just a people problem. It\u2019s also a technical challenge.<\/p>\n\n\n\n<p>You can try to reorganize as much as you want. If the underlying architecture is not modular enough, then you will still be stuck, whatever your organization.<\/p>\n\n\n\n<p>And that\u2019s why we added the tech-enabled part. Because we think without a big rework of your underlying technology, you will never get the agility that you are aiming for.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Okay. This is the part I believe a lot of people listening will be a little bit annoyed with. Because they will not know where to start.<\/p>\n\n\n\n<p>Let\u2019s say I have a big monolith. I need to grow the team. Now the team is too big. The monolith is too big. What can I do? I don\u2019t have the time to re-architect everything. Where do I start?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>I don\u2019t have a simple answer to that question, but we do have a lot of experience around that question.<\/p>\n\n\n\n<p>I think I\u2019m simplifying slightly when I say making the monolith modular, because we have a few examples where one of the key transformations was actually the deployment pipeline.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Mm-hmm.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>So moving to a deployment process that is much closer to trunk-based development. Investing heavily in automated testing. Investing in feature flagging.<\/p>\n\n\n\n<p>That is typically, I would say, the first thing I would start with. And I\u2019m not the only one to think that. Continuous deployment is clearly one great way to get there.<\/p>\n\n\n\n<p>And then the re-architecting would happen, but you can\u2019t do it all at once. I believe, and we\u2019ve done it quite a few times, you re-architect in a progressive way.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>And that\u2019s why it\u2019s hard. Because it requires very good architecting skills, tech design skills.<\/p>\n\n\n\n<p>And usually the leaders who are complaining about the lack of agility are often non-technical. So they don\u2019t understand that they have to put energy on that.<\/p>\n\n\n\n<p>And yeah, I guess if there\u2019s one key message here, it\u2019s that you cannot achieve agility just by addressing the people challenge. You also need to address the technical challenge.<\/p>\n\n\n\n<p>And that does require getting your hands dirty and trying to understand why the current tech landscape is not working.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>I like that because it gives a sense that it\u2019s possible. It will be step by step. There\u2019s a real investment. And you need real engineering skills. You cannot fake it on that part.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Yeah, no, of course. And to be honest, the outcome can be much better than what most people believe.<\/p>\n\n\n\n<p>We\u2019ve just delivered the new professional bank of LCL, which is a very large French bank. We did it in 10 months, and we had about 150 dependencies to the existing IT system.<\/p>\n\n\n\n<p>So it was a difficult project, with 150 dependencies. But once you know how to design the thing, once you have the delivery discipline, you can actually achieve the kind of speeds that you see in startups.<\/p>\n\n\n\n<p>And one good reason for that is that startups are not new anymore. Most of them also have legacy code they have to deal with. So they\u2019re not that much faster.<\/p>\n\n\n\n<p>With the right technical expertise and the right delivery discipline, you can deliver a whole new digital experience for a bank in 10 months.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>You spoke a little bit about learning. That\u2019s one of the foundations you talk about in the book, about building a learning organization. Can you tell us what you mean by that?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Yes. The way I restructured the Agile Manifesto, and this is a quick introduction, is that there\u2019s a leadership aspect, and this is value for the customer, lead with value for the customer.<\/p>\n\n\n\n<p>Then there\u2019s a management and working organization aspect. How do you make teams able to contribute? So that\u2019s tech-enabled network of teams.<\/p>\n\n\n\n<p>And then there\u2019s a whole body of knowledge around delivery and quality at scale. And this is what we call right first time and just in time, really leveraging the decades of experience of Toyota in producing much higher quality cars, super fast.<\/p>\n\n\n\n<p>But once you\u2019ve said all that, the key missing aspect is: how did Toyota get there, for example?<\/p>\n\n\n\n<p>There\u2019s an anecdote I love, and it\u2019s probably a bit imagined, but let\u2019s imagine Americans arriving in Japan in the eighties and asking Toyota, \u201cCan we visit your factories? Apparently you are so much more productive than us and we want to know why.\u201d<\/p>\n\n\n\n<p>And the Japanese would be like, \u201cYeah, sure, whatever.\u201d And the guys would come and they would try to understand everything. And then they would come back to the US, copy-paste it, and they would get some benefits, but they would also have issues.<\/p>\n\n\n\n<p>And they would go back to Japan and say, \u201cWe tried to do the same as you. We had issues here and here. Can you show us how you do it?\u201d<\/p>\n\n\n\n<p>And then they would look, and everything had changed.<\/p>\n\n\n\n<p>And that\u2019s the key aspect of Toyota. They didn\u2019t invent a great way of doing things. They invented the culture of continuous improvement. So whenever you come, the better way of doing things is changing.<\/p>\n\n\n\n<p>And that\u2019s the building a learning organization aspect. And that\u2019s, of course, the most exciting aspect of all. It\u2019s the one that has to do with innovation.<\/p>\n\n\n\n<p>If we want to dig a bit into what building a learning organization means, it means one key thing. If there\u2019s one thing to remember, it\u2019s creating a culture of problem solving.<\/p>\n\n\n\n<p>A culture where raising problems, identifying problems, is welcomed positively, and people are then supported and trained into problem solving them.<\/p>\n\n\n\n<p>And that\u2019s a very cultural aspect. And it starts at the top, with leaders showing that they will not react negatively to being told about problems.<\/p>\n\n\n\n<p>They might react negatively to people hiding problems.<\/p>\n\n\n\n<p>You are turning around the usual reaction to a problem. Showing a problem is positive. Hiding a problem is negative. And not analyzing a problem is potentially discouraged.<\/p>\n\n\n\n<p>What is encouraged is analyzing the problem. And if you don\u2019t have the skills, that\u2019s actually a skill. You can learn it. You can teach it.<\/p>\n\n\n\n<p>And that\u2019s really a key aspect. And that\u2019s something we do at Theodo ever since, I would say, 2012, when this lean coach started coaching us.<\/p>\n\n\n\n<p>We started having dojos on problem solving. And every week, the whole organization would meet on Monday at 12. One team would present a recent problem solving, and we would challenge them and give hints and advice on how to improve it.<\/p>\n\n\n\n<p>So the skill of problem solving became really at the heart of our culture. And I think that\u2019s probably the key foundation of a learning culture.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Excellent. I really encourage people to think about what happens when we ask that kind of question: \u201cWhat is the problem you are working on?\u201d<\/p>\n\n\n\n<p>And my first reaction to that was, \u201cI don\u2019t have any problem.\u201d The first reaction we have is to try to put aside all those things and say we are very successful and everything is going well.<\/p>\n\n\n\n<p>Except that means we are not improving and we are not learning. And going to that culture is really something.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>It is. It\u2019s very interesting because \u201cproblem\u201d has two definitions. And one of them is a scientific definition. And clearly what Theodo has done is adopt this scientific definition of problem, which is completely neutral, or rather positive.<\/p>\n\n\n\n<p>And that\u2019s important.<\/p>\n\n\n\n<p>There\u2019s also a very interesting reframe of what business means. It\u2019s as if you can look at business as trying to transform the world and bring a new solution to the world, etcetera. Or you can see it as things that were meant to happen but are not happening in the best way, because there\u2019s still a lot of waste.<\/p>\n\n\n\n<p>And it\u2019s a very different way of looking at business.<\/p>\n\n\n\n<p>And I think both are interesting and valid. And of course, the other way makes you start thinking, okay, customers have needs. Whether I\u2019m here or not, they would probably need that.<\/p>\n\n\n\n<p>And the question is, how can I provide it, and how can I provide it in a better way? And it\u2019s probably in the way I provide a solution to their need that there\u2019s a lot of waste along the way.<\/p>\n\n\n\n<p>How can I identify this waste, and how can I remove it?<\/p>\n\n\n\n<p>And of course, that\u2019s the most beautiful way of generating profit. Because if you respond to the need and seamlessly start reducing all the waste in responding to that need, you are generating profit while not changing anything for the customer.<\/p>\n\n\n\n<p>And what is even more interesting is that if reducing those wastes means you have done a lot of problem solving, which means you have actually found issues in the way you provide your work, then you probably improve the value for the customer at the same time.<\/p>\n\n\n\n<p>So you generate profit and improve value for the customer, all that in a seamless way for the customer.<\/p>\n\n\n\n<p>So this vision of business is very beautiful.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah. And I believe that core idea of already changing the mindset we have about how we already do the work, you alluded to that before.<\/p>\n\n\n\n<p>There are two big pillars that you are looking at: right first time and just in time. Could you give us examples of what it means?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>There\u2019s a really good example at the moment in AI coding. Actually, I posted about it on LinkedIn this morning.<\/p>\n\n\n\n<p>Typically now, if you do a bit of AI coding, the easy approach is to start chatting to code and say, \u201cCan you do this?\u201d \u201cNo, not exactly this.\u201d \u201cNo, not exactly this.\u201d \u201cMore like that.\u201d<\/p>\n\n\n\n<p>And there\u2019s another way, which is to actually work hard on the plan, on the specifications, and then give it all at once to Claude. And Claude then delivers the perfect result.<\/p>\n\n\n\n<p>And right first time would, of course, be the second option.<\/p>\n\n\n\n<p>And why is it so interesting? The second approach means you will have to learn a lot more. Because of course it will not be right the first times.<\/p>\n\n\n\n<p>So you\u2019ll start analyzing, okay, what did I miss in my instructions that made the AI not understand what I meant?<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>And so you\u2019re building intuitions on what works, what doesn\u2019t work, what AI needs, what are maybe the assumptions that you believe the AI would have but doesn\u2019t have, etcetera.<\/p>\n\n\n\n<p>So right first time is the idea that you aim for perfect quality. So it\u2019s an ideal.<\/p>\n\n\n\n<p>And to do that, you look for problems as early as possible. And then you analyze them in a systematic way to think, okay, how could I have avoided that defect? How could I have detected it earlier? How could I have avoided it?<\/p>\n\n\n\n<p>And this means you become much, much stronger. And of course, you deliver much better quality in the process.<\/p>\n\n\n\n<p>What we\u2019ve observed is that the more we detect and analyze defects super early on, and that is typically a very good promotion of unit testing and test-driven development, the less defects you have in production down the line.<\/p>\n\n\n\n<p>So that\u2019s one leg.<\/p>\n\n\n\n<p>And then of course, you mentioned the other leg, which is just in time.<\/p>\n\n\n\n<p>The reality is the better your quality, the less rework, and the more the value flows to the customer. So aiming for great quality means you will go faster.<\/p>\n\n\n\n<p>But then of course there\u2019s a whole aspect in a large organization. How do you deal with the complexity of multiple teams contributing to the same work?<\/p>\n\n\n\n<p>And this is where Toyota brings decades of experience in an approach called just in time, with a few key ideas. Some of them are single-piece flow and takt time and pull systems and kanban.<\/p>\n\n\n\n<p>But yeah, maybe I\u2019m going a bit further than your initial question.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>That\u2019s good. Let\u2019s go there.<\/p>\n\n\n\n<p>That idea of the one-piece flow, for example, is a very simple one, but often I see teams who are not really working as a team. Everybody works on his own thing, to the point where they develop very specific skills for those particular things.<\/p>\n\n\n\n<p>So it\u2019s the description of the opposite of the one-piece flow, and right?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Yeah, no, you\u2019re right. It\u2019s completely the opposite.<\/p>\n\n\n\n<p>An easy solution to single-piece flow, and they\u2019re not that easy, but typically Agile helps by having cross-disciplinary teams. And if the team is good and they\u2019re able to help each other, then in a way you have single-piece flow in the sense that the request arrives in the team and then it gets delivered by the team.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Mm-hmm.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>But that\u2019s important because it means that people within the team are able to help each other.<\/p>\n\n\n\n<p>And if, I don\u2019t know, there\u2019s someone who\u2019s much better at UX but there\u2019s no UX work at the moment, they might come and pair program with a software engineer to help the software engineer go faster.<\/p>\n\n\n\n<p>The other idea, which I think is simple to understand and very powerful, and actually not often implemented, is the idea to make sure that you deliver increments of value.<\/p>\n\n\n\n<p>So typically, imagine you\u2019re doing Scrum. You\u2019re working in sprints, and you have one epic, one full feature that could deliver value to the customer.<\/p>\n\n\n\n<p>But the team decides to work on two or three epics at the same time because they don\u2019t want to tread on each other\u2019s feet.<\/p>\n\n\n\n<p>At the end of the sprint, you have three features that are half done. So you have no value for the customer. You have no learning. You can\u2019t deploy anything in production. So your week has been, from a value point of view, completely wasted.<\/p>\n\n\n\n<p>If instead of three people working on three features and doing half of each, the three had worked on only one feature, you could say, if you sum three times half, they will do less.<\/p>\n\n\n\n<p>But the reality, in terms of value for the customer and for the organization, is that they\u2019re doing much more.<\/p>\n\n\n\n<p>Because at least at the end of the week, yes, it\u2019s hard, yes, they\u2019ve had to tread on each other\u2019s feet a bit, but they\u2019ve delivered one thing in production.<\/p>\n\n\n\n<p>They can get feedback. They can say, \u201cBy the way, for the next feature, you know what? I completely changed my mind.\u201d<\/p>\n\n\n\n<p>And that\u2019s a key idea of single-piece flow.<\/p>\n\n\n\n<p>But how many teams are working on three, four, five features in parallel? I would say most of the teams I\u2019ve ever met.<\/p>\n\n\n\n<p>And therefore single-piece flow is really a principle to fight against that urge of doing things in parallel to feel more productive, which actually destroys global productivity.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah. What I really like with those two principles you highlighted is that basically it forces those conversations. It forces people to learn. It forces people to collaborate. It forces people to know how to work on the code all at the same time.<\/p>\n\n\n\n<p>It forces a lot of those conversations we can avoid. But when we avoid them, we create a lot of waste. So it\u2019s very interesting to look at it in that way.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>I guess you\u2019ve summarized a key idea of Lean thinking, which is showing the problems that are uncomfortable, but that are key to being a better company.<\/p>\n\n\n\n<p>And then not seeing them as threats or depressing ideas, but seeing them as opportunities to problem solve and learn.<\/p>\n\n\n\n<p>And do a bit better, and then a bit more better, and a bit more.<\/p>\n\n\n\n<p>Not try to solve everything at once, except that things are the way they are. And the business is not dead yet.<\/p>\n\n\n\n<p>But it could definitely be improved, and it would definitely be better for the customer and the organization.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>I really enjoyed the book, and I encourage people to read it.<\/p>\n\n\n\n<p>We brushed a few things about the book, but there\u2019s a lot more to say and a lot more value in it.<\/p>\n\n\n\n<p>I love the way you explain the principles and provide examples from the tech industry, for those high-level principles that are not so obvious.<\/p>\n\n\n\n<p>What are the things you want to close with? You\u2019ve worked with Theodo for quite a long time now. Is it still exciting? Do you see things continue to evolve? Are you still a learning organization?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>To be completely transparent, one challenge we\u2019ve had has been COVID.<\/p>\n\n\n\n<p>COVID destroyed visual management because all of a sudden we were all working from home.<\/p>\n\n\n\n<p>And of course we had to find ways to work remotely. But our culture of really having all the indicators on the walls and giving a lot of visibility on what really mattered on every project was replaced by Notion and Miro.<\/p>\n\n\n\n<p>And we lost some of the impact of visual management.<\/p>\n\n\n\n<p>So that\u2019s been one of the learnings from the last few years. And that\u2019s not captured in the book because the book was finished in 2021\u20132022.<\/p>\n\n\n\n<p>But I think we really realized the impact in the last one or two years. And we\u2019ve been working hard on bringing visual management back.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>So that\u2019s a current, very specific but quite strategic challenge.<\/p>\n\n\n\n<p>And of course, the learnings now are how do you maintain this culture at even a larger scale.<\/p>\n\n\n\n<p>A lot of what I write happens when we were scaling from 100 to about 500, and now we\u2019re 700 and growing more. So that\u2019s going to be a very interesting challenge.<\/p>\n\n\n\n<p>It\u2019s very exciting.<\/p>\n\n\n\n<p>And the good thing about a learning culture and a lean culture where you find problems everywhere is that there\u2019s enough problems to learn from for centuries. So I\u2019m not worried about that.<\/p>\n\n\n\n<p>And AI, of course, adds another layer. Not only do you have all these promises, but you also have the market throwing innovations at you that change the game.<\/p>\n\n\n\n<p>Having a learning culture means you can adapt much faster than your competitors.<\/p>\n\n\n\n<p>Clearly, I can see how our Lean Tech culture has given us a huge advantage with the arrival of AI.<\/p>\n\n\n\n<p>We were better equipped as a large organization to frame that as an interesting problem, find places where AI could bring value right away, and experiment.<\/p>\n\n\n\n<p>And a good thing about using AI where it brings value is that you can measure the impact of your experiments.<\/p>\n\n\n\n<p>So now we already go three times faster than before, and we\u2019re aiming for ten times faster.<\/p>\n\n\n\n<p>So no, exciting times. I\u2019m not bored.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Yeah, that\u2019s very cool.<\/p>\n\n\n\n<p>I\u2019ll put a link to my attempt to explain what Quentin Plepl\u00e9 explained at Tech.Rocks about the factory you built using AI agents to modernize applications, because it\u2019s fascinating, and the learning loop that\u2019s built in to really improve the way it works.<\/p>\n\n\n\n<p>It\u2019s exciting times indeed.<\/p>\n\n\n\n<p>What is one question I should have asked you that I did not, that you would like to answer?<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>You didn\u2019t ask too much about AI, and I answered about AI nonetheless.<\/p>\n\n\n\n<p>That\u2019s fine.<\/p>\n\n\n\n<p>I guess one interesting question when you talk about agility and Lean and things like that is to talk about business.<\/p>\n\n\n\n<p>I think that\u2019s one thing that has weakened the agile community, not talking enough about business.<\/p>\n\n\n\n<p>At the end of the day, for a company, the key thing is: does that actually help us be a better business?<\/p>\n\n\n\n<p>So that\u2019s one question you could have asked.<\/p>\n\n\n\n<p>And the answer would be: we were doing 1 million in revenue back in 2012. We\u2019re doing over 100 million this year.<\/p>\n\n\n\n<p>The industry has been suffering the last few years, but we\u2019ve had a good year last year, and we\u2019re on track to have another good year this year.<\/p>\n\n\n\n<p>So yes, Lean Tech is great in terms of learning and people development, but it\u2019s also great for business.<\/p>\n\n\n\n<p>That\u2019s what makes it a very sustainable approach to adopt.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>And that\u2019s probably where people can really focus. If you can do it, maybe they can learn how to do it.<\/p>\n\n\n\n<p>That\u2019s very interesting.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>We are happy to share.<\/p>\n\n\n\n<p><strong>Alexis:<\/strong><br>Glad to hear that.<\/p>\n\n\n\n<p>Thank you very much for making the time to join me for this episode, and I\u2019ll talk to you soon.<\/p>\n\n\n\n<p><strong>Fabrice:<\/strong><br>Thank you very much. Talk to you soon too.<\/p>\n\n\n\n<p><strong>Alexis (outro):<\/strong><br>If this conversation resonated with you, I\u2019d really encourage you to share this episode with one or two people in your life. Someone you work with, someone you lead, or someone you are learning alongside.<\/p>\n\n\n\n<p>Your recommendations truly matter. They help this podcast reach people who could learn from these conversations and apply them in their own context.<\/p>\n\n\n\n<p>You can also find the full transcript of this episode in the companion blog post linked in the description. It\u2019s available on alexis.monville.com if you\u2019d like to revisit a specific moment or share it in written form.<\/p>\n\n\n\n<p><em>Le Podcast on Emerging Leadership<\/em> is supported by Pearlside. At Pearlside, we work with leaders and teams to create the conditions for responsibility, clarity, and impact to emerge.<\/p>\n\n\n\n<p>You can learn more at pearlside.fr. Thank you for listening.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A conversation with Fabrice Bernhard In this episode of Le Podcast on Emerging Leadership, I welcome Fabrice Bernhard, co-founder and CTO of Theodo, and co-author of The Lean Tech Manifesto. Over the past decade, Theodo has grown from 10 people to more than 700, while maintaining speed, quality, and responsibility. In our conversation, Fabrice makes [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":5640,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[1,811,1010],"tags":[],"class_list":["post-5635","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-all","category-podcast","category-le-podcast-season-five"],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Le-Podcast-Fabrice-Bernhard.png?fit=400%2C400&ssl=1","jetpack_shortlink":"https:\/\/wp.me\/paNjQG-1sT","jetpack-related-posts":[{"id":5656,"url":"https:\/\/blog-alexis.monville.com\/en\/2026\/02\/12\/the-scaling-trap-when-more-communication-actually-slows-you-down\/","url_meta":{"origin":5635,"position":0},"title":"The Scaling Trap: When More Communication Actually Slows You Down","author":"Alexis","date":"February 12, 2026","format":false,"excerpt":"We\u2019ve all been sold the same dream: \"Be Agile.\" We start with a small, scrappy team where everyone finishes each other's sentences, and the magic just happens. But then, success hits. You grow. Ten people become fifty. Fifty become five hundred. Suddenly, those \"individuals and interactions\" you valued so much\u2026","rel":"","context":"In &quot;General&quot;","block_context":{"text":"General","link":"https:\/\/blog-alexis.monville.com\/en\/category\/all\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Pearlside-Leadership-Slides-1-1.png?fit=960%2C540&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Pearlside-Leadership-Slides-1-1.png?fit=960%2C540&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Pearlside-Leadership-Slides-1-1.png?fit=960%2C540&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/Pearlside-Leadership-Slides-1-1.png?fit=960%2C540&ssl=1&resize=700%2C400 2x"},"classes":[]},{"id":1803,"url":"https:\/\/blog-alexis.monville.com\/en\/2014\/03\/10\/coaching-agile\/","url_meta":{"origin":5635,"position":1},"title":"Coaching Agile","author":"Alexis","date":"March 10, 2014","format":false,"excerpt":"Coaching Agile, le livre de r\u00e9f\u00e9rence de Rachel Davies et Liz Sedley est enfin traduit en fran\u00e7ais grace \u00e0 Fabrice Aimetti. Fabrice est connu pour ses nombreuses traductions d'articles et d'ouvrages traitant du coaching, des m\u00e9thodes agiles, du lean et plus g\u00e9n\u00e9ralement de ce qui touche aux organisations et aux\u2026","rel":"","context":"In &quot;livre&quot;","block_context":{"text":"livre","link":"https:\/\/blog-alexis.monville.com\/en\/category\/livre\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2014\/03\/title_page.png?fit=800%2C1200&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2014\/03\/title_page.png?fit=800%2C1200&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2014\/03\/title_page.png?fit=800%2C1200&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2014\/03\/title_page.png?fit=800%2C1200&ssl=1&resize=700%2C400 2x"},"classes":[]},{"id":2923,"url":"https:\/\/blog-alexis.monville.com\/en\/2019\/06\/30\/do-cultural-differences-influence-the-adoption-of-agile\/","url_meta":{"origin":5635,"position":2},"title":"Do Cultural Differences Really Block Agile Adoption?","author":"Alexis","date":"June 30, 2019","format":false,"excerpt":"In today\u2019s episode, J\u00e9r\u00f4me Bourgeon and I will explore the question of cultural differences and their influence on the adoption of agile.","rel":"","context":"In &quot;Le Podcast&quot;","block_context":{"text":"Le Podcast","link":"https:\/\/blog-alexis.monville.com\/en\/category\/podcast\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2019\/06\/Le-Podcast-Jerome.png?fit=400%2C400&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":1219,"url":"https:\/\/blog-alexis.monville.com\/en\/2011\/10\/02\/agiletour-bordeaux\/","url_meta":{"origin":5635,"position":3},"title":"AgileTour Bordeaux","author":"Alexis","date":"October 2, 2011","format":false,"excerpt":"L'AgileTour Bordeaux se d\u00e9roulera le 21 octobre 2011. Le programme\u00a0est enthousiasmant : Agile, Lean, Sky Castle Game, retours d'exp\u00e9rience, Kata, Coding Dojo, Espace ouvert, Billes rouges... Une occasion de d\u00e9couvrir et de partager sur les pratiques des organisations performantes. Pour vous inscrire, c'est ici ! \u00a0 Salle feedback Salle communication\u2026","rel":"","context":"In &quot;ayeba&quot;","block_context":{"text":"ayeba","link":"https:\/\/blog-alexis.monville.com\/en\/category\/ayeba\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/wp-content\/uploads\/sites\/2\/2011\/10\/agiletour-bordeaux-300x75.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":1675,"url":"https:\/\/blog-alexis.monville.com\/en\/2013\/11\/07\/richard-et-lopen-source\/","url_meta":{"origin":5635,"position":4},"title":"Richard and Open Source&#8230;","author":"Alexis","date":"November 7, 2013","format":false,"excerpt":"Do you know this guy? It's Richard Stallman , the initiator of the free software movement ( the gnu movement celebrates its 30th anniversary this year ). I use this picture of Richard Stallman in a presentation I gave on several occasions (AgileTour Brussels, Open World Forum, French Scrum User\u2026","rel":"","context":"In &quot;General&quot;","block_context":{"text":"General","link":"https:\/\/blog-alexis.monville.com\/en\/category\/all\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2015\/09\/201311rms-bw-scaled.jpeg?fit=1200%2C868&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2015\/09\/201311rms-bw-scaled.jpeg?fit=1200%2C868&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2015\/09\/201311rms-bw-scaled.jpeg?fit=1200%2C868&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2015\/09\/201311rms-bw-scaled.jpeg?fit=1200%2C868&ssl=1&resize=700%2C400 2x, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2015\/09\/201311rms-bw-scaled.jpeg?fit=1200%2C868&ssl=1&resize=1050%2C600 3x"},"classes":[]},{"id":5627,"url":"https:\/\/blog-alexis.monville.com\/en\/2026\/02\/04\/beyond-the-hype-industrializing-legacy-modernization-with-ai-lean\/","url_meta":{"origin":5635,"position":5},"title":"Beyond the Hype: Industrializing Legacy Modernization with AI &amp; Lean","author":"Alexis","date":"February 4, 2026","format":false,"excerpt":"We\u2019ve all been there: A \u201csimple\u201d legacy migration is estimated at 6 months. Two months in, the team discovers a web of hidden dependencies and implicit logic. The timeline balloons from 26 weeks to 70. The business loses faith. At the latest Tech Rocks Summit (Dec 2025), Quentin Plepl\u00e9 (CTO\u2026","rel":"","context":"In &quot;General&quot;","block_context":{"text":"General","link":"https:\/\/blog-alexis.monville.com\/en\/category\/all\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/LFA-Nurburgring-Package-05-1.jpg?fit=753%2C450&ssl=1&resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/LFA-Nurburgring-Package-05-1.jpg?fit=753%2C450&ssl=1&resize=350%2C200 1x, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/LFA-Nurburgring-Package-05-1.jpg?fit=753%2C450&ssl=1&resize=525%2C300 1.5x, https:\/\/i0.wp.com\/blog-alexis.monville.com\/en\/wp-content\/uploads\/sites\/2\/2026\/02\/LFA-Nurburgring-Package-05-1.jpg?fit=753%2C450&ssl=1&resize=700%2C400 2x"},"classes":[]}],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/posts\/5635","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/comments?post=5635"}],"version-history":[{"count":5,"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/posts\/5635\/revisions"}],"predecessor-version":[{"id":5655,"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/posts\/5635\/revisions\/5655"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/media\/5640"}],"wp:attachment":[{"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/media?parent=5635"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/categories?post=5635"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog-alexis.monville.com\/en\/wp-json\/wp\/v2\/tags?post=5635"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}