Fabrice Bernhard - Tech-enabled Network of Teams

[00:00:03] Good afternoon everyone. Um, I'm very happy to be here today to, um, talk to you about tech enable network of teams. It's the first time I'm talking talking about this topic in public, so I'm very excited. Um, and so my story starts quite a few years ago and it all starts during a lean study tour in Japan organized by Mike. So what is a lean study tour? You basically visit a lot of factories.
[00:00:33] Um, mostly Toyota factories and Toyota suppliers to try to understand what lean really is about at the source. So you see things like this, for example. Um, and of course it's like fascinating, very interesting.
[00:00:49] And, um, just for those who don't know who Mike is, he's, uh, the author of multiple, um, reference books on Lean. Um, for which he won the Shingo Award four times. So quite quite an expert in his topic. And, uh, so we were in the bus because one of the downsides of these study tours is you spend a lot of time bussing around from one factory to the other and Michael and I were having a debate, using our time to have a debate about the Agile Manifesto. And as you can see from the picture, which I'm very lucky I have, it was a tense debate.
[00:01:29] And basically, Michael was making the point that the Agile Manifesto is not scalable.
[00:01:37] Um, and I was, uh, being very defensive. Um, so my first point was that, uh, large, there are large organizations that are agile, so I didn't really understand his point.
[00:01:50] Uh, but actually, I think the main reason why, the reason I was so defensive about Agile is because I love Agile. Uh, I, you know, like probably many people here, I went through the transformation of working a more traditional way to like working a a truly agile way and and love the what it created in terms of team empowerment and of ingenuity that it created in the team. So I didn't want Agile to be, uh, not perfect.
[00:02:20] But Michael's point was right. Uh, there are agile cultures that have scaled, but his point was not that. His point was really that, uh, this was not that the Agile Manifesto was not helpful in that because its principles do not scale. So if you take each principle of the Agile Manifesto individually, you can make this whole experiment and realize, yes, this is not the kind of principle that I can use in a 100, 200, 300 people organization and further. To really help me define and and communicate what being Agile at such a scale is.
[00:02:54] And to be fair to him, I wouldn't have been in a lean study trip in this bus in the first place if, you know, we had found all the answers to scaling our own organization in the Agile Manifesto. Uh, but the reality is as soon as we hit a certain size, um, we could see that, you know, what we wanted to retain from this from Agile, we couldn't find in in in the manifesto and we had to look somewhere else.
[00:03:24] So that's how the journey to find, but because I'm quite a determined person, I wanted to prove Michael kind of wrong, uh, I started a journey to find principles that scale and are true to the spirit of the Agile Manifesto. To kind of show him that yes, okay, the Agile Manifesto itself doesn't scale, but there are ways to like tweak it, which makes it scalable. And this journey is ending now. Because I'm very proud to announce the release of a book that I wrote, the hardest thing I've ever done in my life, uh, which is coming out in the US on March 19th and in Europe on May 7th.
[00:04:02] So today, um, I want to like share a bit of that journey with you, uh, looking for principles that could help scale an agile culture. Um, and then focus really on one of them, uh, because that's what I was asked to do. Uh, and, um, and on that one, share with you the the the stories that I looked at, in particular, the story of Linux. And how they scaled collaboration with technology, and then finish by what does that actually mean in our own organizations.
[00:04:35] So, looking for principles to help scale an Agile culture, um, makes you, of course, start by asking the question, what does Agile mean? What is the essence of the Agile Manifesto? And for that, there's a very helpful resource, which is, uh, the about link on the Agile Manifesto website. Um, where it tells you the history and of of, you know, how it felt the day it was, I mean, the week it was drafted. And they say something very interesting. It says at the core, I believe, Agile methodologies are really about delivering good products to customers. By operating in an environment that actually acts as if people were the most important. Now, having been on a new journey for already quite a quite some time, that resonated so much with with what we had been learning and, you know, trying to to to implement at scale in our organization using lean thinking. And that's, uh, and I think that's what, you know, is really interesting about lean thinking is that it shares really the same purpose as as the Agile Manifesto. Here is, for example, like a, uh, uh, an anecdotal demonstration, but this is a passage from the lean strategy. And it says, Lean Thinking combats big company disease by spurring managerial thinking to provide meaningful work to people who work mindfully in order to always deliver better value for customers. So very, very similar wording to, uh, what you can find in the Agile Manifesto.
[00:05:57] This connection, this strong connection between Agile and Lean Thinking is not such a surprise. Uh, if you look at the history of Agile, Scrum is a big influence in the Agile movement. Sand was criticizing it quite a lot this morning, but I think it was, you know, one of the key, um, uh, forces in in spreading Agile around the world. And Scrum, when you look at the first paper in 1995, published by Ken Schwaber, he, um, quotes the, uh, a paper by Takeuchi and Nonaka called The New New Product Development Game, published in the Harvard Business Review in 1986. It's actually Takeuchi and Nonaka who, uh, coined the word Scrum to describe how, uh, innovative, uh, project team, innovation project teams in in some Japanese companies were working. Uh, and Takeuchi and Nonaka are actually Japanese, uh, professors, specialized in, I think, management, innovation management. And they've studied a lot of Japanese companies, including Toyota, here's a book by, uh, Takeuchi called Extreme Toyota. So you can see this, this, you know, lineage between, um, direct lineage between Lean and and and Agile. That is fairly well known. Uh, I think one thing that was maybe less less well known, at least for me, I discovered it along the journey, is that quite a few leading tech companies were also directly influenced by Lean and that even before Agile existed. I think the most, um, spectacular discovery for me was an interview by Steve Jobs. In, uh, old interview, it's uh, in 1990, he's at next and he explains his experience of being coached by Dr. Duran. It's an amazing interview and, uh, I need to give you some context to understand what it means. Um, the first part is, in terms of timing, this is, this is after Steve Jobs gets fired by, uh, from Apple.
[00:07:58] And it's an interesting time because Steve Jobs is somebody obsessed by quality, but before being fired by, uh, by Apple, he had already stepped down from the CEO role. And he had been replaced by, uh, Scully, I think, John Scully, uh, the former CEO of Pepsi. And one of the things you can see when you look a bit at the history of Apple at the time is that quality had downgraded. There had been some quality issues, batteries exploding and stuff like that. So I think probably when, when Steve Jobs quits Apple and starts next, his next company, um, I think there was for him probably a real curiosity in how he could achieve that the kind of standards of quality he was looking for, next positioning was really to create like amazing, super high-end computers. Um, and that's why he got interested in, uh, quality theory and got in contact with Dr. Duran. Dr. Duran is one of the two American quality experts that got sent to Japan, sorry, it's a long story, who got sent to Japan after World War II to help the reconstruction of Japan. And one of the two, so with with Deming, and so Deming and Duran were lecturing Japanese, uh, top executives, um, on what quality management is, and there what they were teaching at the time is very much credited for, uh, the, the, basically the start of lean thinking.
[00:09:23] At different Japanese companies, but in particular, Toyota. So, and of course, Duran had influenced these Japanese companies, but then he stayed in Japan, so learned from them and was clearly an expert in in principles that sound, you know, that are very close to lean thinking. And you can see how Steve Jobs was influenced by them and what he says is very, very strongly, um, in line with lean thinking, but also with in line with what we would consider Agile today. Another such strong connection is Amazon. So Amazon, that's probably better known. You can find in the letter to shareholders references to Kaizen, to like, uh, Japanese Sensei and and things like that. Um, there's a more, uh, now more obvious reference on that in the book Working Backwards where, um, Colin Bryar and Bill Carr tell the story of, uh, Jeff Bezos. Being on one of his customer service assignments. So you know, at Amazon, they have this culture of sending every top manager two days every two years to, uh, actually be in the customer service department. And, um, and this is a super interesting story, is that Jeff Bezos realizes that one of the customer support person gets a call about a product and immediately knows which product it is. And he asked, like, how how did you guess that the person was going to complain about this product? He's like, yeah, I know this product. I've already had a few complaints, there's a pattern, I can see that. And and and Jeff Bezos, who had been studying lean at the time, um, immediately made the connection with the concept of Andon and decided it was like crazy that somebody could actually know there was a problem on a product but not stop the appearance of that product on the website. So he created what he called the big red button. And it was like quite complicated to implement, but they did it, because Jeff Bezos must be quite convincing. And, um, and since then, actually, people in customer service can decide to like push the red button to stop selling a particular product if they can see a pattern of defects and, um, and that, of course, triggers a whole escalation so that the product teams then need to do something about that. Um, that went even further when in 2006, he actually hired a lean expert Mark as his SVP Worldwide Operations and Customer Service, really deploying lean, uh, in in all the operations of Amazon.
[00:11:57] So that's why, um, when you've studied both Agile and Lean Thinking, you can see that Lean Thinking is a very good candidate to find principles that share the purpose of the Agile Manifesto, While being battle tested for scale, because simply put, lean thinking is is the study of what Toyota is doing so amazingly well and there are 300,000 company, people company, so of course, um, this scales beyond one team of smart software engineers.
[00:12:26] So, using our 10 years of experience of scaling our own company using link thinking from 10 employees to like 700 people, what here are the principles I, uh, I found that I found relevant. So firstly,
[00:12:46] Firstly, when you're doing a lot of lean thinking and you see this Agile Manifesto, you realize that you should really put the customer first, so let's reorder the Agile Manifesto. That's probably like one of the first, the first influence of lean thinking. And then, looking at each principle, um, well, we can take the first principle of lean thinking, lean thinking is the second lean book by Dan Jones and Jim Womac.
[00:13:14] And that principle is value for the customer. And I think value for the customer is a great principle in terms of scaling what Agile Manifesto calls customer collaboration. Because this is a principle that works in a very, very large company. You know, you can lead on value for the customer. It's much harder to lead a one, you know, a 100,000 people company on customer collaboration because not everyone can collaborate with the customer.
[00:13:41] A second principle is, uh, is about working software. Working software, there's two ideas I find in working software, one that you should make software that, you know, works, doesn't have bugs, and one that, you know, you should you should iterate on short increments of working software that you can deploy in production. Um, well, when it comes to deploying, you know, produce much higher quality, much faster, the, you know, the state of the art is, is, uh, the Toyota production system. And for that, they have two principles called Jidoka and Jit, or right first time and just in time. And these are principles that have proven that they, I mean, they come, of course, with a lot of tools and systems around them to help you, um, scale delivery to a very large scale. Finally, for responding to change over following a plan.
[00:14:38] There's this idea that when you start growing, you want to scale the all the teams responding to change, but you don't want them to do to like, you know, reinvent the wheel all the time or take risks that could endanger the whole organization. And so for that, when you look at, uh, large organizations that managed to do something like that, they actually try to responding to change, but by building on previous learnings and external, uh, uh, knowledge, and that's what I translate by building a learning organization, which is basically the outcome of, uh,
[00:15:10] what happens when you really create a culture of Kaizen and standards in your, in your organization. Um, so unfortunately, I can't tell you much more about these three principles.
[00:15:25] Um, but of course, you can learn all about them in the book and you can already pre-order it if you want. Um, why? Because I today I was asked to focus on the one principle where I felt I had to look further than just lean thinking to come up with something that was like convincing. And that is individuals and interactions.
[00:15:51] And the reason I felt that, um, there was something different in the Agile world and in the tech world is that, you know, I I could see that there was something about team empowerment that I couldn't really see in in in at least what I knew in lean thinking as much. And so I decided to to to make the thought experiment of looking really for the the the kind of organizations that scale individuals and interaction in the most extreme way. And I thought, you know what, the most extreme organization in terms of scaling individuals and interactions are probably open source organizations. Because they're really like it's all voluntary people, really if there's too much bureaucracy, they'd run away. And, uh, and of course the most iconic open source project is Linux. So I decided to study the story of Linux.
[00:16:45] So Linux, a bit of background, starts in August 1991, there's this student called a finish student called Linus Torvalds who posts a message on the Minix news group saying, hey guys, I'm doing a free operating system, of course, this is not going to be commercial at all. What do you think?
[00:17:03] And, uh, you know, 30 years later, 55,000 people have contributed to the Linux kernel. And Linux powers all top 500 super computers in the world. Uh, the graph is the share of, uh, operating systems among the top 500 supercomputers, so the fastest, biggest, hugest supercomputers. Uh, and you can see it's reached 100% a few years ago already. Linux is 96% of the top 1 million web servers and through Android, actually powers 4 billion smartphone users.
[00:17:40] So scaling to the accumulated 55,000 contributors was not without its challenges, so of course for me that was the most interesting, is really understanding when the challenges happened and what what was done to address them.
[00:17:53] I found this poor picture of Linus. The first scaling crisis really hits in 1996, so five years after the beginning of the project.
[00:18:07] Um, the symptom is this admission by Linus that he's buried alive in email. Um, and it's really like, you know, the thing has scaled to I think already 100 contributors, like a few, like 100 or 200. And, um, and the, I mean, the way they're organized means that Linus is receiving all these emails, has to deal with them, and is like clearly, completely overwhelmed. Um, but they managed to address that, uh, by two changes. One is, uh, the introduction of a much more modular architecture. Um, and concretely, it's the introduction of the loadable kernel module architecture, which has really two main effects. One, it brings a lot of code out of the kernel, so that means that Linus doesn't have to look at it anymore. Um, and also makes it official that there's people dealing with modules and that also corresponds to the creation of the maintainer's role. So this idea that it's not like fully, uh, you know, everybody contributes randomly, all of a sudden, there's people that, you know, are empowered and and take a leadership on the team around the module.
[00:18:37] One is the introduction of a much more modular architecture. Um, and concretely, it's the introduction of the loadable cannibal modular architecture, which has really two main effects. One, it brings a lot of code out of the kernel, so that means that Linus doesn't have to look at it anymore. Um, and it also makes it official that there's people dealing with modules, and that also corresponds to the creation of the maintainers role. So this idea that it's not like fully you know, everybody contributes randomly.
[00:19:13] All of a sudden there's people that, you know, are empowered and and take a leadership on a team around the module.
[00:19:23] Uh, that works for approximately two years. And then there's a second, uh, um, crisis in 1998, where Linus gets very angry and then disappears for a few days. Um, yeah, the fact he's angry is probably not the symptom. The fact he disappears is like the big symptom. Um, and this, this is '98 and that inspires somebody in in the community, Larry Macvoy, to create BitKeeper. So BitKeeper is the precursor to Git, so it's a, it's a tool to, um, to help merge source code much better and a much more distributed way that was what was what was done at the time. At the time, I think they were still doing, um, email patches, huh?
[00:20:12] Um, and it's interesting, this is like the the first message by Larry who says, you know, we it would be great to have a tool that makes it possible for people to do part of the job. Um, BitKeeper doesn't get adopted right away, so actually the issues continue for about four years.
[00:20:30] Um, there's a lot of controversy around that, uh, because BitKeeper is not open source. And so a lot of people would prefer to actually, uh, um, create what they call a, um, deputy patch Penguin. But there's something very interesting in the reaction of Linus to that, because he he just sees like the bureaucracy being created by creating like assistants, etc. So he's looking for a very different solution. And that's why in 2002, he finally gets convinced that, um, BitKeeper is probably the thing that he should, uh, officially adopt. And so managed to convince the rest of the community and the situation, and and what is very interesting is that by adopting BitKeeper, the situation immediately improved. So before that, there were a lot of contributions lost, after that, no more.
[00:21:18] If you don't know BitKeeper, and if you wonder what it is, um, what happened is that in 2005, Larry, the creator of BitKeeper, threatened to revoke the free license of BitKeeper. And Linus got angry, so took a few weeks off and created a tool, you know, as a side project called Git to replace BitKeeper. I love this story because it just reminds you like, don't bother with Linus.
[00:21:47] And what is very interesting is that when you read, um, you know, the the the the interviews of Linus since then, his message is really clear is they'd not had any single scaling challenge since, like huge scaling challenge. It really worked. And so the question is what what are the learnings of like these two scaling challenges and and the way they addressed it.
[00:22:10] I think the first learning is is this idea of network of empowered teams. So this is an animation of contribution to Linux. And you can see there's this idea of like little blobs of people contributing in in certain spaces, then being merged together and then being merged like further together into in in into the main branch. So there's really this idea of, okay, at some point you need to create teams and you need to find a way to make them like, uh, uh, merge their contributions, uh, together to form, you know, to contribute to the bigger picture. And and this, this, uh, um, this, uh, network of teams works because it's helped by technologies that distribute collaboration between the teams. And in terms of technologies, in the story of Linus, I really see two standing out. There's the modular architecture that's really important to like design the work in a way that, you know, you can, yeah, uh, fence a bit the problem around teams. And then there's an amazing technology called Git to like then distribute the merging of this work back together and in in into the main branch.
[00:23:26] And, um, and then of course, once I had done like, you know, had these two realizations, I started looking for whether that was a pattern in in, you know, large organizations with Agile coaches. And it's very interesting because for me, like one of also of the most like self-organized agile organization, uh, uh, that is inspiring is Burdsorg, it's studied in Frederick Lalu's book called Reinventing Organization, and it's basically a network of 10,000 nurses in the Netherlands. Um, self-organized in little, uh, um, teams. Uh, and I think in Dutch means neighborhood teams, so basically is like neighborhood organization. Um, and when you, uh, read the the interviews, read the books, read the book, uh, it talks a lot about self-organization and and purpose, etc. But I was very happy because I got to meet Yos the block one weekend. And so I managed to like sit next to him at dinner and, you know, try to test my hypothesis. And he finally told me this information, which is that Yos and his co-founder, before actually creating Burdsorg, were working on the IT project of their former employer. And so his co-founder is actually a tech co-founder. And really one of the key enablers in Burdsorg is a tech platform that they created to reduce all the faff, all the, you know, all the administrative tasks that nurses usually have to do, were were doing at the competitors, and also a way to empower the the the teams of nurses on on their PNL. So, I was happy. I had my proof that tech was also key at Burdsorg.
[00:25:15] Um, and then of course, you can find it in other examples, uh, Amazon and its famous API mandate. Um, so it's a transformation that is now described in, uh, it used to be like this kind of internet legend, um, based on a on a blog post by a guy called Steve Yage. But now there's actually much more details about it in in Working Backwards by Colin Bryan, uh, McCarr, and you've got this amazing, uh, kind of quote, um, of Jeff Bezos that says, if you want Amazon to be a place where builders can build,
[00:25:47] we need to eliminate communication, not encourage it. And that's really like a, you know, it was really to counter the idea that people were saying, oh, there's so many issues, there's so many dependencies between teams, we need to like create more communication structures. And and Jeff Bezos' message was, actually, that's not what we need to do, we need to eliminate communication. And and how do we do it by making software teams build and clearly document a set of APIs for all the systems and services.
[00:26:18] Um, but you can also find it at Tesla, and Tesla, of course, is very interesting because it's, you know, you could call it the nemesis of Toyota. And Tesla has really, um, um, introduced a revolution in terms of car building, which is modular car architecture. And here you can see that what is very revolutionary is you've the car is actually split into three big parts that get built separately and then assembled.
[00:26:48] And that's very much, uh, that's very, very interesting, and of course, Toyota, being a good learning organization, has now introduced their new modular architecture.
[00:26:58] Um, and it's interesting enough, there's a book, uh, called Team of Teams by General Stanley McChrystal, who was in charge of the Joint Special Operations in Iraq. Um, and explains how, you know, they had this, this this amazing budget, and they had these amazing teams, but when when all these teams came together, they were so bureaucratic that they were always losing against the insurgents in Iraq. And he explains how he tried to transform this bureaucracy into more a team of teams, that was his word for that, and one of the key things he did, which is very interesting, is he introduced basically a daily standup of everyone. And of course, that was enabled by the fact that they had video teleconferencing technology, which, you know, nowadays doesn't seem, uh, that crazy, but we're talking about '91 in Iraq with war, so it must have cost them quite a lot in fiber cable, but it worked.
[00:27:54] So why is is, uh, this technology pattern, I think, so so much everywhere? It's because scaling individuals and interaction is really about keeping teams empowered.
[00:28:09] So you want to keep this this feeling that you have in an agile team of, you know, going fast, being autonomous, um, being able to really contribute to the value.
[00:28:20] Um, but as you scale, you get more and more dependent, more and more dependencies, uh, and, you know, necessary interactions with other teams, and that, you know, that is the the basically the challenge you have to fight against.
[00:28:36] And large agile organizations have solved that challenge with technology that enables them to actually cut a lot of these dependencies and enable the teams to then, you know, collaborate as a network without really like waiting for the others while each team stays empowered on their module. So, having said that,
[00:28:58] I decide to call that tech enabled network of teams.
[00:29:08] So concretely speaking, what does it mean to, um, try to introduce a principle of tech enable network of teams in your own organizations?
[00:29:18] So, um, well, firstly, let's not forget that there's the word team in the in the tech enabled network of teams. And so this is where we should not like jump on the technology, it's firstly about making sure we have good teams. Um, I love this quote by Bill Campbell, um, also known as the trillion-dollar coach because he coached Steve Jobs and and uh, Larry Page and uh, a lot of others. Um, I yeah, um, I think he coached Mark Zuckerberg or Sheryl Sandberg. So he's really the coach behind all the big tech companies and one of his big quotes is, work the team, then the problem.
[00:29:58] So quickly on this, I think if you want to have, uh, good teams, uh, they're the result of good supportive team leaders, and then good supportive team leaders are, this is our model, you can take it or not. Um, but I think good supportive team leaders are competent.
[00:30:18] Uh, I put the photo of Steve Jobs because this is amazing interview of Steve Jobs explaining how at some point Apple is scaling. So they're thinking, okay, maybe we should hire we should hire external managers, uh, professional managers. And and of course that was a and he explains how for them it was a disaster because they had these amazing engineers and these amazing engineers wanted to work for someone who they could learn from and they could not learn from a professional manager. So they went the much harder route of saying, okay, we'll need to grow managers out of our amazing engineers. And they're going to be very unhappy about that, but they're still going to be better managers. And that's going to be better for the whole organization. So clearly, a good team leader is somebody who's competent who can support the team members and and and teach them and, you know, improve their skills. A good supportive team leader is caring.
[00:31:13] Um, and, uh, this is the photo of Simon Sinek, who, you know, is big about caring. And I think one of the ideas that we found very inspiring from a book called nine lies about work is that a good team leader is spiky. So it's the idea is to say, we're not looking for somebody who's well rounded, we don't want like somebody who's amazing at tech and amazing at people and amazing at caring and at least a bit good at caring. Uh, but we want someone who's really strong on something, very, you know, who has, um,
[00:31:42] uh, a strong belief in something and and inspires people to follow him, follow them.
[00:31:54] Um, secondly, organized teams so that each team is empowered on value for the customer. I mean, this is really the big idea of of of modular architecture. Um, and it starts with the organization, um, I like even storming as a way to design a good modular organization. Um, there's also a cheeky reference to the fact that if you're interested in this, you should have been in the other conference, because this is Alberto and he's speaking right now. So yeah. I didn't put the picture too early in the conference because I didn't want you to all leave and go to the other conference.
[00:32:33] So now, now let's imagine that we have like, you know, good teams and, you know, put put in organized in a way that they can contribute to value for the customer in a meaningful way. Um, how do we enable seamless team collaboration, how do we create this network of teams? Well, we can use revolutionary technologies such as Git.
[00:32:52] Um, Google Docs, amazing. Uh, Notion, uh, Trello, Miro.
[00:33:02] Um, so you might be thinking, okay, what he was saying was quite interesting, but if the conclusion is that I have to use Google Docs, what the fuck am I doing here?
[00:33:13] Well, I think, I think, you know, in our world, now that we're big consumers of such real-time collaboration technologies, we don't realize the value they have. There's a lot of, there's a lot of industries out there that still have no clue that they exist, and don't know how to adopt them. Um, and also, I think reflecting on on on all those learnings around on that journey, I think it made me also respect more the technology and the value it brings. And typically, if you look at Git,
[00:33:46] once you realize how strong it is in terms of enabling network collaboration, then you're probably more critical of when you see a project doing 25 different repos. Because all of a sudden you see that, you know, you're not even using Git for what it is, which is a merging technology. And this is my personal opinion, but apparently Google, Meta, Microsoft, Twitter, Uber, all use a mono repo. So I think there there's probably something right in there. Um, that of course, if you start doing a lot of multi repo, I mean, this is a this is a complicated debate, but I would really push for mono repo because you you with multi repo, you lose this like network collaboration enabler.
[00:34:31] Um, again, when you think about the importance of network collaboration, you realize also the importance of it's not just a tool, it's the way you use it, and typically, you need to rethink about, uh, the the the design of of how you the design of the information that you store in these tools. Typically, here's an example of our template for analyzing defects that we use in Notion. And we iterated multiple times on that design because we realized that the initial designs were not self-service. So typically, somebody would have a defect, analyze it and analyze the defect, but they would be linked to, I don't know, a Trello, a Jira that nobody had access to. And all of a sudden, you lost the kind of network collaboration where teams are able to get the information in a self-service way. Because you had to call them and say, oh, can you like give me access to your Jira or whatever? So there's been a lot of like work on how could we make sure we get the relevant information all within that template, so we can actually, um, so people can actually use it without contacting the the creator.
[00:35:40] And finally, a big, uh, big topic, the modular architecture, so investing in designing, maintaining a modular architecture with robust APIs. I'm illustrating this with Stripe because I think Stripe really was quite breaking into in showing us what an amazing API can look like. Um, I'm not really sure what word there is the term for this, a product API or a product quality API. Um, but yes, there's something about making sure that the API is is is very well designed to make to make everything work.
[00:36:14] Uh, I can share you our experience, so, uh, clearly, we only build or adopt systems with good APIs now in your organizations. Uh, weirdly enough, there's still a few systems that don't have APIs. Uh, and that is now clearly a big red flag for us. And also, when you are looking at systems, the quality of the API is is is now a big argument for us.
[00:36:40] Um, this is unfortunately a true picture of our IT system, whereas you can see it's not fully modular. It's kind of not. Um, and of course, the use of these APIs allow us to sync all the data into a well-designed data warehouse, well-designed for the moment, I hope it we maintain that. Um, and that that brings a lot of value in terms of enabling teams everywhere to do stuff without relying on on without being independent on other teams. Um, one example I can give you, um, there's a there's quite a few small examples, but there's quite a few and I think they're very they're very rewarding. Of, um, teams coming up with ingenious initiatives without requiring prior approval of anyone of anyone else. I think the, um, the one, the one example I chose is, uh, is what the security team did. So they created a cockpit using a a script that connects to all the different IT systems and again, using the APIs, is able to detect if there's, uh, potential security issues. And what I find inspiring is, this enables them to flag issues, but not have to put a process, impose a process, like a security process to every team to check, oh, you know, have you done this like whatever security checklist because they they're able to consume the data and then just flag it when when necessary.
[00:38:09] And then I guess, um, the most spectacular example I can give you of, uh, modular architectures and how they can empower software teams, um, is linked to the COVID-19 lockdown. Uh, beautiful picture. Uh, less nice time, but anyway, um, so on the 19th of March 2020, uh, the government decides to, uh, implement a lockdown. And and there's really this question, how are we going to help the economy be resilient and they decide to give loans, I mean, guaranteed loans to to businesses. And so we ended up being tasked with building the platform with, you know, this idea of trying to deploy 300 billion euros. Of state guaranteed loans. And of course we were given five days to build that.
[00:39:04] Um, and, you know, the combination of going quickly and of course like the the the the inspiring mission, um, made us, you know, deliver the platform less than five days later. And it was it was not only like, uh, ready, but it was like, you know, scale ready. are going to help the economy be resilient and they decide to give loans, I mean guarantee loans to to businesses. And so we ended up being tasked with building the platform with, you know, this idea of trying to deploy 300 billion euros of state guaranteed loans. And of course, we were given five days to build that. Um, and, you know, the combination of going quickly and of course like the the the the inspiring mission, um, made us, you know, deliver the platform less than five days later. And it was it was not only like, uh, ready, but it was like, you know, scale ready. And, um, so we managed to put it in production and in less than 28 hours we had already, uh, uh, responded to 1 billion euros of loan requests. So that was quite amazing. Um, and of course, as a result, that success led to new demands and the number of teams increased. And you have all these like, you know, new features you have to build, et cetera, et cetera. And, um, and soon what you realize is that the deployment step is taking more days than it had taken to build and, you know, deploy the whole initial platform. So you you you were able to like, you know, create a very valuable platform in production in five days and all it takes you five days just to do Q&A on one feature. You're like, wow, you know, this this some something's gone wrong. Um, here you can see the graph of, uh, uh, our deployment frequency, which was about four, five a day. There were a lot of teams. Um, but, you know, not very frustrating to be waiting, I think, at least five or six days to sometimes, uh, deploy. And, so we it's very interesting by the way, because you you you end up in that situation in quite a, you know, boiling frog kind of way because you have to add features. And, um, it's only when really the situation becomes too bad that you're like, okay, we need to do something about this. So, time to react, take a step back from the pressure of delivery. Some problem solving and some of the reactions were more modular architecture, more service. Um, one interesting, uh, learning from that experience, by the way, was feature toggling to again, like, if you want to empower teams to deploy in production, you need to probably separate the idea of deploying technically from deploying, uh, uh, product-wise. So feature toggling was key there. And a lot more automated integration testing. Um, because you want to catch API changes, you want to catch dependency issues. And, and that really made a huge difference. Um, because quite quickly the deployment frequency went from five a day back to 40 a day.
[00:41:49] Um, and, uh, this is the loop the whole loop of this presentation because what I find quite, uh, quite interesting is that, um,
[00:42:01] reducing the the the the deployment time to increase frequency of of changes is basically the software equivalent of, uh, what I showed you on the first photo. So the first photo was a demonstration of Smed, Smed is, uh, is the acronym for single minute exchange of die, which is this lean, uh, concept of reworking hard on reducing the time it takes to change the machine. So for those who are not big lean expert, you have this huge machine and it produces, I don't know, some kind of part. And, uh, and and the question is, if you, if it takes you hours to like reconfigure the machine to create a new part, then you will not want to change the, uh, the machine often and that creates a huge flexibility issue and that has like ripple effects all across the the the the factory and then the company. And if you work on the contrary on making it super easy to reconfigure the machine, then you can change very frequently during the day and then you have huge flexibility. And so you can see the parallel between, you know, a big lean concept and, and I think a big devops concept here.
[00:43:20] And I guess that's, uh, for me, the take-home message. Um, is that, um, we love Agile. I'm saying we, I hope I'm, I hope I'm right. I love Agile, we love Agile. Because, and I think the reason we, we, you know, people who have adopted Agile, you know, love it and don't want to go back is because it really fosters this this like, you know, magic spark of ingenuity when, you know, in a small team, like creating more valuable, more creative solutions. Better solutions. Um, and, uh, Lean thinking is, is really a place where you can find time-tested principle to scale to benefit these benefits to a larger organization. Uh, and, and while sharing, while maintaining this the purpose of the Agile Manifesto. But you can also add to this tech innovation and to maintain the team empowerment as the organization grows.
[00:44:21] So, I hope, um, I've given you a few more ideas on how to grow your organization and maintain an Agile culture at scale. Um, because we need more organizations deploying ingenuity at scale. Thank you.
[00:44:45] And just a reminder, you can pre-order the book. Do you have any questions?
[00:44:52] Okay, first question, ah, do you need a, I don't need a mic.
[00:45:01] Uh, the starting point of your presentation was like, um, agile manifesto that it does it to the game. And I adopted the lean principles for the start and to explain to uh, to people why to adopt the agile culture. Can you give us some first line or tip?
[00:45:25] So, um, it's very interesting because I was wondering, you know, how much should I say about different things and I was asked to focus on on tech enabled network of teams and I think it was very a very good idea because it enables to go a bit deeper. And I hinted at why, um, individuals in interaction doesn't scale. Uh, I think this is, you know, the good illustration is that, uh, the number of interaction is, is a square of the number of individuals. So there's something not working if if you So that for this one, for individuals and interactions, I think the it's a bit of a simplistic argument, but I think it still captures the issue. Which is that number of interaction is a square of the number of individuals. So if you don't find a way to like cut through these interactions, which, you know, Jeff Bezos calls eliminating communication, you have something that doesn't work. I can try to of course, this is all in the book. Um, but I can try to do it quickly and, yeah, I'm gonna have a few minutes.
[00:46:31] So, customer collaboration, I think it's an interesting one, um, you know, what I love about my Agile experience is you have the customer in the team, it's something you find again in, uh,
[00:46:44] I think it's Ward Cunningham or Ken Beck, you know, who says in extreme programming, the client is in the team. The client is in the team. So the customer, so you really have this like intense collaboration. That's and that that's that's amazing. I think it's amazing. Um, now, thought experiment, you grow to a very large organization. Your customer is a very large organization. How do you create that collaboration? There are they are all going to be people that are not indirect contact with the customer. So there's, you know, again, you can use a bit of technology, you can use AB testing, experimentation platforms, a lot of things like that. Which enable a lot of people in the organization to have like a direct, uh, not contact, but let's say direct access to to what customers want. Um, but there's something about as a leader of the organization, you probably need something a bit slightly different because if you tell people, in this organization, I want everybody to collaborate with the customer, I'm pretty sure that a lot of people will be like, what do you mean, you know, it's it's, um, whereas if you say, you know, let's, in this organization, I want everybody to focus on value for the customer and see how they are related to this value for the customer. That that works.
[00:48:00] Um, uh, let's start with responding to change. Responding to change, um, I think an idea that is very interesting and I actually make the the the the comparison between Google and Amazon in the book. Is because Google and Amazon are both amazing at responding to change. Uh, Google is probably the first organization that made AB testing, uh, famous. Um, and then at the same time, when you look at how their success rate in terms of launching new products, it's not that amazing. And so I think there's something where when you're a very large organization, uh, you know, you need to build on on past learnings and past knowledge. And if you don't have that, then you either have teams that, you know, respond to change but actually have no impact on the whole organization because they're, you know, they're not influencing the whole organization, they're on their own. Or you have the top management trying to respond to change and because they're very far from the ground, they probably react too late, they probably react badly. So the question is really, how do you empower teams on the ground to respond to change in a way that they can then feed it back to the whole organization and not endanger the whole organization? And my answer to that is, if you have a strong learning organization, where you know that people are, you know, are are experimenting, so they're, you know, they're doing they're trying before they they they commit to changes, they they learn, they they also reuse past learnings, they they make sure they also learn about others what others are doing. Then you then you get that you get the the the benefit of responding to change in a large organization. And then working software, that's a bit of a harder one because, um,
[00:49:54] what is not what is not scalable in working software is is, uh, more the fact that it doesn't really address what happens when software becomes very complex. You know, if you tell someone, you know, I want you to release working software 40 times a day, and you're a thousand software engineers organization, that's going to be quite, uh, vague as a, as a, as a guideline. So you can say DevOps, you can say continuous deployment. What I like about saying right first time in just in time, is I think you can really see how DevOps and continuous deployment have learned a lot about these. So going back to the source, you, you broaden your your understanding.
[00:50:40] Does that answer your question?
[00:50:44] Any other questions?
[00:50:53] Well, timing was good.
[00:50:56] Thank you very much, uh, and looking forward to discussing this.

Transcript