Hello everybody and thank you for joining us on this Friday morning. We are excited to welcome you to our webinar where we will get to explore the power of integrating modular and agile in product development. In this session we will explore why we need to integrate modular and agile even further in product development and outline some of the most significant benefits to be achieved by doing so. Following that we will be presenting our view on how to successfully integrate modular and agile but we are also curious to hear of any learnings that you might have. Whether you're just starting on your journey of integrating modular and agile or looking to refine your existing processes we would like to talk further to you about how to integrate these two approaches and hopefully also inspire you with case studies like Tesla's impressive results in revolutionizing a somehow conservative industry. My name is Mernes and I'm an expert in modularization and with me today I have Henrik who is an expert within agile and innovation. Together we will explore the integration of modular and agile in product development with you to achieve exponential impact. So again thank you for joining in and let's get started. Wonderful. Tesla they release hardware chains 20 to 27 times per week per model. That is completely insane and really got us wondering what are they doing? How are they challenging a very traditional manufacturing value chain? And what can what are they doing? How are they challenging a very traditional manufacturing value chain? And what can ordinary companies learn from them? Ordinary companies are experiencing a complexity explosion and it will only get worse. Customers more frequently demand new things. Customers they don't need stuff but they need their problems solved. Digital consumer devices and AI also creates a lot of high buyer and user experiences or expectation also in B2B. Competitions come from new angles. Competitions come from new angles. Many corporate entrepreneurs or entrepreneurs are out there and to add to that we have employees that want to work from everywhere. So the job is for companies not to respond to that. The job is to thrive in that environment. It's to take the lead. Both modular and agile break down complexity and neither of them are new concepts. Modular breaks the complexity breaks down complexity or the structural dimension of complexity with decoupling development, reuse of designs, fixed interfaces. Agile breaks down the time dimension with fixed sprint cadence, small accountable teams, impact demos and continuous deployment. Companies are at different maturity levels on modular and agile. That's pretty natural. But we also notice that there are often, it's often like a that's two different camps that are different. It's like it's two different camps that talk different languages. The modular camp is all about content engineering and problem solving. And the agile camp is a little content agnostic, you could say project manager focused and oftentimes some would say full of inexperienced agile coaches. Few companies master it like Tesla, but integrating the two can create exponential impact. It is almost obvious to us that getting those two different camps working seamless together will create valuable benefits. We think companies need a common operating model across modular and agile. This is what we'll dive in today. But first, we hope you play along at least a little bit. We would like you to answer three questions on a 1-5 scale. The answers come out pretty pretty soon. And we would like you to answer fast. The first thought that comes to mind is 100 % anonymous and nothing will be captured. The first question goes like this. How good is your company at modular? And five is very good. Five is very good. And one is not too good. But we would love to have some answers here. Just initial thoughts, reflections from your side on how good you are at modular. So are you doing any modularization at your company currently? How good are you in doing so? And what do we expect to see here, Henrik, from the poll here? Actually, already now, this looks sort of a little bit average, I would say. Yes. Average to low. Let's have the next question, right? Yes. Thank you for your fast answer. And we will do it super fast. Also, the next one. Yes. How good is your company at agile? Agile. Meaning working in agile? Sprints. Demo sessions. Demo sessions. So are you working, your way of working, is that agile? Or is it more classical? Waterfall. Waterfall. Waterfall-ish. We would also like to get some input on that from your side. Just vote. No binding answers. So, OSP, that is also pretty much average here. So, average to low. Average to low. But, and then? We have a final question. How good is your company at integrating modular and agile? Let's see. Thinking about integrating the two ways of working, the two approaches. Getting the two camps to work together seamlessly. Exactly. Or is it more kind of siloed? So, some part of your organization are doing modular, doing it great. And other parts are doing it great on agile, but they do not talk together. That is actually what we do see here in the poll result. That you are fairly good, average good on modular and agile, but the majority of you actually do not think about integrating modular. modular and agile, and agile, and agile, and agile. Exactly. And how come? Interesting. How come? Yeah, let's, that's exactly what we will dive into now. And I think, uh. So, let's talk a little bit about the benefits of focusing on integrating modular and agile, right? Wonderful. Let's do that. Shouldn't we do that? Why don't you do that? I do that. Thank you, Henry. So, there are six main benefits. that we do see when integrating modular and agile. First, you will be able to gain increased development efficiency and speed. Disting modules and clear interfaces allow development teams to develop and release independently and with a minimum of coordination and complexity waste. Having this in place in your development organization is always a good idea, but particularly so if your solution teams work at different, you will be able to work at different clock speed. Second, by integrating modular and agile, you will also be able to gain higher customer satisfaction. Due to simpler products and user experiences that are easier to comprehend, along with the possibility of customers to independently upgrade or customize specific parts of the product, you will gain a higher perceived product value and thereby the likelihood of higher customer satisfaction. look at the home audio company Sonos for instance, which continuously launches new functionality and new speakers to allow customers to upgrade and customize their setup to fit individual needs. That is for sure one of the reasons for their huge success. Next come shorter time between new market releases. By breaking down products into smaller modules, businesses can accelerate product development and release modules independently in shorter cycles. Look at hearing aid companies. Renewing and improving their products on a weekly or monthly basis, rather than introducing a new model every three or four years, is what keeps customers selecting their products over their competitors. Simply because their products are faster, better, and maybe also cheaper. What you can also achieve by integrating modular and agile is enhanced product performance. Modular and agile promote superior design and testing practices because issues can be isolated and improved separately without affecting the entire system. This results in high quality products with minimal defects. And yes, you should also take non intended use into account, even though it is difficult. Another great benefit is the reduced lifecycle and supply chain costs. Due to a higher degree of reusability, lifecycle and supply chain costs are lowered. And reuse is really the key to boosting economies of scale and helping development teams focus on exactly what brings value to the customer. Finally, by integrating modular and agile, you can the customer and achieve increased adaptability. Agile modular enable businesses to adapt swiftly and efficiently to evolving issues or customer needs by adjusting or introducing new features to existing modules, rather than redesigning the complete product. For instance, it was much easier and faster just to replace the player module from tape to CD, rather than redesigning the entire car. We hope that you also agree that these six mentioned benefits are some of the most significant ones, and that some of them are what you aspire to achieve within your organization. So, now let's talk a little bit about how to integrate modular and agile. For most innovators and developers like yourself, the modular and agile benefits are not hard to understand. The hard part is really how to go about it and how to make improvements from the current maturity level. In many instances, modularity and product architecture are viewed as a somehow static engineering discipline, separate from the dynamic discipline of agile development and continuous releases. And in addition, it is often, like Henrik just said in the beginning, people with different mindsets who sit in either camp. This needs to be changed. This needs to be changed. So, here comes our view on how to get a stronger integration of modular and agile. First, decompose into smaller units. Breaking development projects and the solution into smaller units facilitates rapid development, while the architectural overview makes it possible for everyone to understand how each component and how each component and each module contribute value to the entire product or portfolio. Extremely complex modular frameworks can delay development, rather than support it. So, be aware of not building a new engineering bureaucracy or a slow decision hierarchy. Instead, focus on essential value-adding product features, extreme reuse of modules, and the ability to scale. And minimize dependencies and delegate decision power. Second, revolve around customer needs. It is often an advantage to revolve a modular approach around customer needs and functionality, rather than technical components or material types. This ensures that development teams remain end-to-end focused on delivering exceptional customer experiences, and that they do not get lost in the technical weeds or inside-out thinking. In one of our projects from the healthcare industry, we centered around maneuverability, imaging, ergonomics, etc., and mirrored that with equal numbers of module teams responsible for developing the different modules to meet customers' job to be done. However, clearly defined interface roles are are essential for efficient collaboration between module teams, while interface management enables effective integration and mitigates the risk of delays or unpleasant surprises further down the value chain. But there's more, right, Henrik? There is a little bit more. And the next thing we would like to say here is that you need to ensure diverse skills in your teams to get better. solutions. What you need is like, we call it T-shaped people. You have a depth and you have a breadth, I don't know what you call it in English, a breadth, a T-shape, in other words, with unique SME, but also curious about other perspectives. Those teams are able to fix problems together, and they're not sort of representing any department, so it's not about that. Each module team has to have every skill required to make decisions independently. and fast, and that autonomy, and fast, and that autonomy has to be promoted by leaders. The whole team must be committed towards customer and business targets, a little bit like said by Marinus, not just the commercial person in the team. Then we also get a lot better decisions. Use continuous integration tests. continuous integration test cadence throughout the development linked to the sprints. You have the sprint structure. It's just to use it. If you don't test something after burning a certain amount of hours, the risk of failure or waste increases, so that's why. Testing should cover technical and commercial assumptions in a real world setting, so you get valid, you know, feedback. A lot of engineering companies, they favor technical testing tests. But due to the rising complexity that often involves people systems, the focus on commercial testing often needs to be increased. Joint demo sessions create participation and invite all to suggest improvements. So often we have experienced that, or so often we have experienced that the best inputs, they don't really come from the most senior person or the most talkative person necessarily, Let's tie the knot and get back to Tesla. Many myths surround Tesla. A lot of them come from the colorful nature of its founder and his clan of followers. But it's indisputable that Tesla has revolutionized a very large and conservative industry. They make attractive EVs cheaper and more profitable than anybody else. Their market cap is bigger than the 10 next biggest automotives combined. So what are some of their key enablers? Module teams, they have full customer value accountability. They have digital self-management. In Tesla, data is your boss. Everybody and all module teams, they have access to live customer and vehicle performance data. You know, you know, you know, you know, you know, you know, you know, and a lot of companies, this kind of information is sifted through layers of middle managers and gatekeepers. Of course, information is power. And it's also powerful internal political agendas, etc, etc. All of that is in the open in Tesla, so that the developers, and the people who are who need to know, they can act fast. They have highly, highly automated testing and integration of modules. They make accept criteria and digital test scripts first, and then they start developing. Then they have their famous or lately famous on box production process, which is based on modular DevOps thinking. A hundred year old manufacturing and assembly process have they have completely changed it. That is that is big stuff. They have DevOps teams sitting on the factory floor within 10 meters of module assembly. In many companies, it's hard to even get developers to even get developers to visit the production area. And now a couple of issues that are more organizational and people related. They have slim hierarchical structures. It's not who you are that matters, but it's what you do, what your hands can do, what your mind can do. And worth mentioning also this big vision, the 1000 year plan that motivates the brightest young people to walk the extra and the agile and agile and the agile and the agile and the integration of the two. What have you tried that could inspire others on this call. And what questions would you still like more perspectives on maybe something we can comment to or somebody on the chat. So please, you know, think a little bit about this. Write a couple of comments in the chat. And then we hope to get a little conversation going. Please, please help us along here. Thanks. Thanks. Thank you. So while we are waiting on some interesting insights from you guys out there, we could obviously talk a lot about agile or modularization as such, because there's a lot of dimensions to agile and modular or modularization. But we would love to talk with you guys. So hopefully some of you would like to inspire us, inspire the audience with some of your learnings or maybe some of your challenges that you have out there. Because what we do see is basically what we also saw in the poll, that some are working with agile and agile methodologies working on that. And others, typically developers or engineers, are working with modularization and all the great benefits that you can achieve there. Also, ask us a question. Maybe we can answer them. Maybe we can't. Let's see. What else can we say? What else can we say? So it's orienting the module towards the value. That is really something we've tried quite a lot that works. It's, of course, a lot easier if you have big projects, like you're building a train or a wind turbine. You need to break up your product architecture. And you do that. You just follow the product architecture when you break up your your projects, not follow the organizational architecture. That's what we've seen the other thing as well. So we have a question. And we can't read the question totally here because it's zoomed too much. Thank you for that. Yeah, there's a question here. Say, what would be the best way to fix interfaces when new generation of products are constantly growing? And that, I mean, now we just assume the context and the understanding of that question. So first of all, the interfaces, at least between modules and also the module teams, needs to be fixed. But when we are saying fixed, we also mean agreed. So you are allowed to change interfaces over time. Also, when you get new generations or want to launch new generations, with new technology and all that, that requires new interfaces, so fixed interfaces are agreed interfaces between module teams, but also the technical aspects. So that would be the best way kind of. So to fix interfaces is to agree on interfaces, having that in your architecture very clearly defined. Yeah, when the new generation of products constantly growing in size. Yeah. Then we have another question. It's a challenge to create cross -functional teams in small organizations. Yes. That's true, of course. If the projects are so small. Is it true? No, I mean, I mean, if you have a small organization, I would assume that you are cross-functional just by being a small organization. Let's put a different, if it's a small product that doesn't require a lot of effort. Definitely. I don't know if that is what is meant, because if it's a really small, my project is to go and fetch a cup of coffee. You know, I don't set up a cross-functional team to that. I pour the coffee, I drink the coffee, I take the, you know, these are things that would be, if it was a much more complicated task, would be split out on a lot of people. So, of course, if the job at hand is small, then people are wearing more hats, I guess. And then we have a final question that we have time to kind of address here. So, if we see any regional or cultural challenges also globally when integrating module and agile. Absolutely. And yes, we do. One perspective, I mean, is of course that, you know, in Northern Europe, the power distance is very low. So that means people take a lot of responsibility. Yeah. On the other hand, I've seen, you know, working with people in the Middle East and India, in Germany, far away, that, you know, everybody likes to have impact on what they do. So, so, so, but I think both agile and modular is very much being on the same page in terms of mindset and the approach. And obviously, and we all know that there's different cultures, there's different ways of working. So you need to fit that integration or that application of agile and modular mindsets to that specific context. Obviously, that's, I mean, that's the easy answer, right? But it's really about agreeing again, back to the interface, agreeing on how to work, how to develop, how to allow that module teams do decisions by themselves and develop the module or the solution that customers actually need. You have a lot of really good and difficult questions here. more perspectives. I don't know. When handling pure hardware products far away from software in highly traditional businesses, if the market is not demanding high frequency of new products and features, which of the principles to prioritize first agile or modularization? Do you answer that? I would say both. I mean, even though you're not having a high frequency in new products, launches or features or all that, working agile, agile, meaning that you are testing, you are testing your assumptions on what the customer actually need. So working in an agile way in this setting here allows you to de-risk your projects even further than just assuming and then building in a modular way and then assume that this is the way that the product should be and then failing in the end. Yeah, I would say on that note, I think it's really about because like, we also said in the beginning modular and agile are both de-risking methods. So it's really a little bit about assessing where is the risk? What kind of risk is it? Commercial technical? How big is the risk? They probably help answer that question. Yes. I think we do see a lot of more great questions here, and maybe we will just get back to you specifically answering those questions if we may. But for now, I can see the time is running. So before ending this session, we would actually like to give you our view on possible next steps. So no matter where you are on your modular journey, integrating modular and agile, we have some steps here that we would like to present and some suggested actions as we do see it. So first of all, you should develop a shared and profound understanding of the potential benefits by integrating modular and agile and make reuse and simplicity in product development cool. Implement a modular architecture framework or simplify the existing one and mirror that with the organizational setup. You should also focus on the customer journeys and align cross-functional teams towards shared customer objectives, knowing what the customer wants. Then you should think about your potential improvement journey in a modular and agile way, meaning focus on the first small solution that will deliver end-to-end value. And finally, be curious. The world is big. The world is big. So look at what is already out there. And obviously, all these steps comes with a lot of suggested actions, but we will let you dive into that after today. And we hope you would like to discuss these even further together with your leadership team with us. But for now, we would like to say thank you for your time and attention. Please reach out if you have any questions or reflections to share because we would love to discuss how to create an even bigger business impact by integrating modular and agile at your place. We're nerds. Yes, we are. You like these conversations. That said, have a fantastic Friday and a fantastic Easter. And good luck with your improvements. Thank you for joining in. Thanks for joining. Bye-bye. Bye-bye.