 Today we are going to hear about Volvo Car Retail solution about their agile journey and I will just hand over the word to Jonas Sporong and Anders Franz. Thank you so much. I will start with introducing myself a little bit. I am Jonas Sporong, I am responsible for the development and delivery team at Volvo Car Retail Solutions and I've been working with IT, IT related work you might say, I am 96, so fairly old in the game, everything from raiders to cars to IT systems to water meter systems and so on. And I have taken part in two agile journeys and this is the second one on Volvo Car Retail Solutions, which we will tell you a little bit more about. And the first one was at Schenker, but I did a similar thing that we are doing here. So, over to you Anders. Yeah, my name is Anders Franz and I am an agile people coach and part of the agile people core team since a few months back. And I am a consultant since I think it's August 2020 at Volvo Car Retail Solutions or BCRS as we should say. And I have a history mainly in IT kind of joined between automotive and telecom and have been taking part in my role as a consultant I've been involved in a bunch of different agile transformations and things related to agility and customer centric ways of working. I think you will start Jonas since you have been, you represent more of your rest and me since I'm a consultant, you will take the lead in this, in this journey and in a few gaps. You are kind of the co driver for this journey. So, very much so, so let's get started let's get into it. Automotive is, as you probably know, is up for a big change. So we're looking at electric vehicles, autonomous vehicles, and the big chunk of digitalizations. So, everything is changing rapidly. We are aiming to sell more cars to then customer. And what this means is that Volvo is slowly starting to become a software company. And that's an interesting transformation I should say, which is rather fun to be in the middle of. To focus in a bit on Volvo car retail solutions. We have a vision of being 100 that 100% of our users should find our retail solutions easy to use and we aim to reduce the administration time for technicians and sales staff with 50%. And our mission is to create digital enterprise solutions for all of our stakeholders and customers. So, and we will integrate this with all the existing solutions in the Volvo cars global network solutions. So, we say that we are the digital engine. And what we mean with that is that we are kind of the spider in the Volvo car ecosystems. We are the digital engine. And a little bit of the figures, you always should have some figures. In the case. So we are 180 coworkers. We sit at Lindholm in Gothenburg. We have about 50 billion sec flows for our systems. And that's a hefty figure to throw around. And it's because all the car sales for three different markets flows through our systems. We are a subsidiary to Volvo car cooperation. And 200, 240,000 cars are sold for assistance every year. And 1 million work orders are made. Let's focus on our customers. On the greatest map, we could say that we are a global have a global footprint. But you see, there's not that many dots. So, we are only active in three different markets, it's Sweden, Norway and Japan. And kind of a big step there from Sweden, Norway to Japan. We are multi brand we have all vocal star in all four than a couple of other brands that runs is possible to do in our worst systems. As I mentioned, we are in the center of the ecosystem so Volvo finance Renault Nordic Volvo cars are all connected to us and we share a lot of data. That's kind of why we are where we are. The portfolio. If you make it simple, you can say everything you need to sell and to maintain a Volvo car. And a couple of other brands are in our portfolio. So, from customer care to sell the car. Until the wheel change and services the car. And here you see all the names of our different products in the portfolio. But it was in Volvo car retrosolution we should talk about it was how we develop software and how we do that in an agile way. So, our agile journey started in 2016. Some say 2014 but I think the footprint really started in 2016. So a need for change from the traditional project waterfall organization where management spend all the times time management and the percentage of how much work all the developer should do. So you can be Jonas you should spend 10% on doing that and 26% on that and and you see you see the concept. So that wasn't so effective. So we did the reorganization here in 2016. That's why I want to say that we started them. So kind of a classical project setup with a resource optimized mindset. Yeah, definitely. So that was. I talked to my predecessor about this, the self organizing part of choosing new teams. It was a big decision is it was very hard to make it work from the start, but it took a couple of circles and then you will set it out. In 2017, we continue focused on continuous integration continuous delivery, we set a target, which was 750 g five, which doesn't say anything for anyone outside of this data solution, I think, but g five was a milestone in our, in our process. We said then with this target that we should be able to deliver software 750 times a year, instead of three to four times which was before. So this was, yeah, this was a stretch target, but you get there eventually. In 2018, we realized that the developer organization was, yeah, basically throwing the software over the fence to to the operation organization. Not really, but you get your, I think we get the concept. The developer team wasn't really managing the operations of the other software they have built. So it was a bit of a friction between them. So we started preparing the organization for DevOps culture. 2019 we moved R&D together. So, and started delivering in a DevOps way instead. We had a rather strong team feeling with a flexible mindset and we, we hit 500 g five mark and during this year, which was good. I will show you a little bit of figures about that because it looks like this. Approximately roughly 500 releases. So you can see my pointer here. And I'm up with map this against the major incidents, which you can see in 2016 we have about 100 major incidents, so rather rapidly delivery to be honest, and three to four releases in 2019 we had only 20 major incidents and over 500 releases. So that's, it looks great doesn't it, more than 500 releases and only 20 major incidents. So, so why do we stop here? So what was the main reason for the major major incidents going down that rapidly was it related to the new ways of working I guess and maybe also related to the more frequent release schedule or it was a combination because when you, you make three or four releases a year, it's very hard to test everything. And we have test cycles that run for three or four weeks with all our stakeholders, maybe I should say customers instead of stakeholders running tests and we have several different databases and everything has to look the same and so it was very easy to make a mistake. We used that complexity with the frequent releases and of course we made a lot of effort in writing clean code, writing code, automated testing, release pipelines, those types of stuff was implemented. So reducing the scope of each release and making it more often, making it less of a big bang result in positive figures. Yeah, that's really well done. Yeah. So what we didn't stop here. So we saw at the end of 2019 that we still have something that slows us down and increase complexity. So. And the observation I joined the company around 2020 yes not was during the COVID pandemic which was a challenge of course but gradually we started to get a picture like this that the agile transformation was maybe done it's quite quite often the case is my experience that you, you want to build these autonomous teams and you focus very much on the teams as such, and then try to kind of turn the pyramid the classical pyramid that we all know and are used to upside down a bit too quickly. And I think that this needs to be a journey. So the observations around 2020 was that we had lots of teams and they were trying their best to work in an autonomous agile way. But there was a lack of alignment so these teams moved in slightly different ways so in a radically different ways different directions. And also the observation was that management was a bit confused in that because we often heard that but it's up to the teams to decide and then management sketch a bit lost so what is my role in this, if everything is up to the teams what what is my role here. And I think the same confusion from the team side as well because teams really need some management support. So it's, it's, I think that that is too big step too quickly from the old way to the new way often result in this kind of confusion is maybe a bad word but lack of alignment and difficulties, tensions. I think still today we are. Sometimes it's very hierarchical and sometimes it's the complete opposite. And it's not always very clear who has the mandate to decide what and how do we actually take decisions I think that's one of the things that we observed then and still observe that takes a lot of time to actually reach decisions and other decisions we make are they actually valid. You can always raise your hand and say that this is not valid unless you have a defined process for how we take decisions or who has the mandate to take decisions. So I think that what we what we need if you move to the next slide you must I was trying to switch myself here but I noticed you're the one who is presenting. So what we wanted to do around that time was just to kind of move back a bit not to build a system for which this pyramid can stand upside down. We need some kind of structures and some kind of system to support the agility and autonomy that we at the end want to build. When I joined there were a role it was a role called chief product owner. And but it was not fully implemented the mandate was not there and and it was, it was more or less on trial on us. It was tested to have to see if that role could fly. It wasn't really manifested well in the organization it didn't really fly so we we reinvested in those roles to kind of build this alignment between the teams, not as a dictatorship was more but more as a supporting function to to make sure that we start to align these teams. And there was also an investment made before I joined into putting all these different teams backlogs into one big backlog connect these backlogs to make sure that we had a portfolio the same priorities. So that was kind of the first step towards building a more structured system in which these autonomous teams could realize their work in a better way. So, and you can, you can show them the last animation as well there. So, again, we need to or we think that we need to build these temporary structures that enable autonomy so that we can be more agile and move faster. So we're trying to take a step back to the middle pyramid here, where management typically take part in changing the system and gradually turning it upside down by building these temporary structures, for instance, how do we take decisions in a in in the upside down pyramid what kind of system is needed to support that way of working. And we are somewhere in between here right now I would say. So, what I mean with this picture is that management need to take a big part in in this transformation it cannot only be up to the teams, and we cannot only be focusing on the direction up to the right. On the right side here we see that we have management team and they have a compass and road ahead and some stars that they want to to move the organization towards. And that requires an organization that is mature enough it's like team maturity you know you have this, if you believe in the Susan wheel and stuff then you know that you need a situation leadership to handle the team, depending on what kind of they are in. And the same thing goes for an organization so we need to have the right kind of leadership in throughout the organization and throughout this transformation or this agile journey. And at the bottom I have one of my favorite people Edward Deming to quotes. It's not enough for management to commit themselves to quality and productivity, they must know what it is that they must do such a responsibility cannot be delegated. And that kind of sums this up I think the previous picture with the two pyramids one the classical one on the upside down that you cannot just cannot just delegate that you need to take control of that journey to gradually build a system where you let go of control. And the others quote is, people are already doing their best the problems are with the system and only management can change the system and I think that is very true. We want to be in the right side of this picture where teams are autonomous and they can take lots of positions by themselves because that is much faster. But in order to build the prerequisites for that environment, we need management to know the system and to change the system gradually. And I think that is what we're trying to do now get more management involvement, understanding the system, noticing the tensions and acting accordingly to gradually move back to an autonomous company, autonomous teams that have the environment where they can act as we want them to act. They're kind of limited today, depending on that the context they're in doesn't allow for that. So just a comment there. Bear in mind that we're starting from a point from 2019 already had done a lot of things but the pendulum swings swing a little bit too far to the autonomous teams. So, but the results is still there, we still can deliver this every, every, every time we want and all the delivery pipelines and automation is still there and working. And the teams are still working so we are trying to enhance the machine to say even more. That's what we're doing with this tipping or tilting the triangle. Yeah, and I think there are, there are this results our current situation around 2020, there was quite a lot of tension in the organization because of this, and quite a lot of ways that we'll also move into so so try to eliminate that waste by building a more supportive system. So 2020 we continue to focus on the temporary structures as I showed in the previous picture by building a guiding team and if you're familiar with safe the scale agile framework there is a similar setup there called the lace team. So that is kind of a centralized way of trying to take big steps in a structured way to change the system. The guiding team needed to have strong sea level executive support so it's very close to the company board that is the top management of vcrs. And the mission for the guiding team is to continuously map out the current situation and the wanted position in the company and then make controlled small experiments in line towards the vision or the wanted state. So typically we gather all the tensions we could find in the company, main value stream mappings as we can see to the, to the bottom right here to map out what the system currently looks like, and then try to identify the most wasteful or the most tension intense structures we have, and then try to change the system in a controlled way and also measure what is the impact of this change that we're doing, did it actually help or didn't it help. Because we're in this complex environment. So if you have a data cannibin the cannibin framework, you know that you can't really pre plan that much, but you can have a hypothesis about what you think you can have a hypothesis about what you, what your actions, most likely will result will result in and then you have an inspected behavior also for change management. And another step we took was to implement portfolio management and that is very much centered around these roles the chief product owner roles. Since we have two value streams in the company to make major value streams, we have decided to have one for each value stream. And it also made sense we thought to have these accompanied by a chief architect to is very much. Guarding the technical aspects of the solution to make sure that we don't build additional technical debt because that has been the case for quite some time, depending on this lack of coordination between the teams. We also have an important role in this management. We also have a representative who's more has the business hat, and more of a customer a major customer context like a key count management role, you could say. And we also have a representative from the company board the top management team. And the, the role of this portfolio management is to coordinate, align these different agile teams to put together the portfolio strategy, the roadmap for the portfolio, and do that in a supporting way so it's, actually this is temporary structure we don't know currently it's needed, is it needed in two years or five years time we don't know we shouldn't have this structure unless it makes sense and today it makes perfect sense. I think the interaction of this change has come with a lot of benefits we come closer to to key stakeholders and talking about the right things. There's a separation between the company board, more now focusing more on the company's strategic long term issues have the portfolio management together with POS and teams focusing on the more technical product portfolio oriented things. And of course we need to have these continuous handshakes between the company board and the portfolio management and down to the teams or out into the teams depending on how you, you see the world. We also have the supporting functions down to the right because this is we see that the value in the company flows in this direction in the teams coordinated by my portfolio management and on the strategic level coordinated by the company board and then we have the strategy relations finance departments people department and engineering management that also support with a situational servant leadership. And we also have a few that's it's, we haven't made that many communities of practice yet we have one for the team coaches, grandmaster team coaches, and we're about to start up for architecture as well so so that is the more community based open ways of cooperating in company. Next one. And this is just a snapshot from the valley stream mapping that we performed about a year ago I think. And this is a way of mapping events between and start of an order until that software in this case is run out in for the customer. And then we could see that were there were quite a lot of long wait time dependencies between teams very many dependencies between team that made it difficult to have a high flow and short lead time. So this was kind of an eye opener I think we knew that there were lots of dependencies but through the valley stream mapping we could see how much it was. And then take that back to the guiding team that we had up and then started to focus on the next step to because we thought that this dependencies between teams that is something that really is really wasteful. So then we decided to take the next step on us. Yeah we did. Let's see. So dependencies dependencies we have As I said we have a lot of dependencies in both in the organization and also technical wise and architectural wise so we decided to focus a bit on that and as you have my time every dependency doubles your chance of being delayed or late. We can easily see that by trying to book a dinner for 10 people and agreeing on a date and a place to be to see that dependencies are not so so easy to fix. So we said, let's try to do the main driven organization and the main driven architecture. The benefit of that is that as you see in this picture, we have several red cars, red volvos and in our architecture today. We can, if you search in one system you'll get a certain type of data and if you search in another system you get another type of data, and you have a lot of dependency between the systems and between the markets and so on. So we said, we want to aim for domain driven architecture. And why not organize our own build an organization according to the same principles. So, organize them in different domains. This kind of a reversed way of thinking of Conway's law. So, hence the domain driven structure. In this picture we have mapped out, see where my point is, we have mapped out the big processes, sales to order order to deliver and deliver to repurchase and then a neighbor block on top of that. And all these little bubbles are different domains. So you see a big bubble here called sales and another big bubble called service. And inside that you have subdomains and even smaller blocks depending on how granular you want to be in your architecture and also your organization. This is kind of a way to think about organizations in ways of connected toward architecture, they will drive each other. So, we have implemented a couple of these bubbles, especially for sales and service, the core structure is currently, we're kind of currently building that part with customer and the vehicle and organization and so on are the bubbles where he's up in that in a box. The thought is that each and every bubble should have their own way of taking responsibility for their chunk of information, their own part of the process or the customer journey or how you want to slice it. So, clear interfaces, clear architecture structures and clear communication lines to stakeholders or wherever you need to communicate but is they can have complete control inside their bubble on what needs to be done. This is precious down the decision making and so on inside that. That's the thought. Our next step then, what do we do during this year we will focus on domain driven architectures and strange in the strategic process and introduction and work are okay. Okay ours that was hard to say today and improving the backlog structure. That's maybe. That's what we will do during this year. And the main driven stuff will continue a while, I think. And the strength and strategy process and interaction of okay our subjectives and key results are tightly connected of course and that's part of separating what was before. I mean the company board was very much involved in the actual portfolio management as well and that came a bit messy and maybe lacking long term strategic thinking so. So, one separating those or splitting them apart at least a bit with a bit different hats between portfolio management and company board that enables the possibility to have a longer scope in your strategic thinking and more focused strategic way of working. So we are elaborating or thinking about elaborating with introducing objectives and key results as a way to to put those strategic themes into action more or less within the organization. We plan to do that in a structured way, starting with a small thing and making that work in the organization and building understanding and awareness of why and what and how. And then gradually grow that way of working with objectives. Yeah, and also the improved backlog structure since since the backlog is kind of the veins and to say the spine in the company you could say what we saw is that the current backlog structure is kind of different sized bunches of work stacked on top of each other. And we think that each level in a backlog structure structure should mean different thing or less to build this cooperation between teams to have a. The strategic investments as part of the backlog for instance different parts of the company taking ownership for different levels of the backlog. So wait once again to build a structure within the company. And what comes next. We think, as I mentioned the domain, the main driven architecture will continue for a while. I mean, you don't rebuild the system that has been running for 30 years in a year. It will take a while, but the thing with it is you can do it in in small chunks. You have to speed up the decision making. We probably set some kind of goal for that, like decisions should be made in two days or something like that, regardless of the decision. And of course, shortly time and feedback loops. But we really don't know. I mean, that's next year, we only got halfway through this year so we will see. So, we are here learning so far. It is for us. It's a continuous year and a not the project. I mean we could easily stop that 2019 and being rather happy. We'll reach the gold and gold almost. I mean we're way beyond it now. But we saw more, more stuff needed to be done to be a really be fast and flexible. The importance of leadership. I mean, leaders are the only people in the organization that can change the process and organizational structures that you talked about. So they are important. Just as an example, honestly, the introduction of portfolio management. We are changing the system and making that team quite clear about the mandate and the boundaries they have. Now they can manage their own improvement work within that bubble. They are changing the system, letting go of control and building autonomy in that group and that is the gradual approach that this guiding team is working towards to to gradually changing the system and making it more autonomous but in a structured way. Yeah, definitely. I want to elaborate a bit about the word leadership. It's not only the formal leaders. We have more leaders than that in organization, product owners and team coaches and and architects are also type of leaders. But if you want to change the system, it might be necessary for the formal leadership. But that's more important than you might think that's our learning from the structure we had in 2019. Common clear objectives. I mean, you need to do to know where to go. Leadership scaling is very important. I see that if you have a manager who has 3040 employers under them, they don't have the time enough time to spend on each employer, and they really don't have the time to do improvement work. So, so a good scaling. And that means for all the leadership in organization. So product owners and team coaches and architections so on, it need we need to free time to be able to do this. And that's, that's rather hard, because you don't see the benefit from the start you can't measure it in in money right away over in time. So it's, it might be hard to convince management board that you need to focus on this. So to improve. You all have seen that picture with a man or drags a wagon with square wheels. I think that has been mean for the beginning of this year, really to visit to improve, but we get we get around wheels on the wagon eventually I think. I mean, I'm at the workshop today, where we focus a bit on how what can we stop doing and what do we need to start to and stop doing is under discussion and start doing is for sure to spend more time on this improvement. Continuous improvement stuff. Improvement culture is the topic of our list here. And I think actually worked on McDonald's for a couple of years, and they had saying that was clean as you go. Which means don't leave anything. If you see something lying around you just pick it up and throw it in a trash bin or clean down the countertop or whatever the small small things you can do. And that for me is the improvement culture. If you always think of something you can improve and you have that in as kind of the DNA in the culture in the company. You get a lot more done without kind of spending lots of time on rebuilding projects, build a bigger redesign projects and so on. So that's something we need to encourage the organization. Pre one pre one. If you focus on one thing at a time or at least few things at a time, then it's much, much faster. It's so easy to spread out your organization over where it's in or as like a thin layer, and you get nothing done. You get coordination and you're, it's like stuck in the mud. So that's, that's what we're trying to do with this particularly management and the common backlog and so on. And the last one is hard to work agile in a way, you know, in an ideal way in a non agile world. Our stakeholders and our situation is not really that agile as you want to be. I mean, it's the car industry. It's not that we have been doing this for 100 years. It is happening now for sure. And as you started to say you must the automotive industry is in this very interesting and rapid change. So I think that we in this area could take a big part in highlighting the ways that we see because of the non agile approach from context we are in. I think that's something to focus on in the future as well to lift that up to stakeholders to see to promote the benefits that the more agile mindset approach could have. Yeah, and of course they are, I mean, I realized that my statement was like they are dinosaurs but that's not what I mean. Well because are changing in big ways right now. So we have done a change a couple of years ago and they are doing it right now when we started a maybe a year ago and something like that so they are. They and us are the same I should say. So we will learn from each other the scale is much grander if you boarded 180 people. So that's the way do we have lots of interesting questions. I think we have a few ones in the chat but we can encourage everyone to. You can either ask questions because or you can put them in the chat. But I must say interesting journey you have in many ways you have come quite far I would say. But we have one question here. Maybe you answered that, but did you add all teams at the same time or gradually adding more and more teams to the value streaming. I mean in 2016 we did this big change where we basically split up the company into big chunks and sales and service. So, and then the team members got shows, whatever they wanted, which team they wanted to be. It was like a grand bazaar where the product owner stood and sold their product and people went and talked to them and gradually we set that framework there. And then, if the question was more for the domain. The domain architecture that we are doing now we are gradually implementing it, but from the structure we had before so we had kind of a base. It was set for a couple of years back and now we are splitting up those team in smaller boxes will be will be more autonomous, but we have a clear scope and a clear interface to each other. So that's against that answer the question I hope so. Great. I'm not sure if it clarifies but in the domain driven design initiative, we are moving teams from product teams to design to to domain teams gradually. That is what we're saying. Yeah. Thank you. I hope you can see and hear me now. Yeah. Thanks for a very good presentation. I was just going to ask about what the employees say about this how is the employee turnover and so on. Are you an attractive employer because of all this. I should say, yeah, I think, yeah, I think we are we had during the beginning of this year we had a bit of a higher retention rate because of the year two years before the corona thing. Then we have almost zero people leaving us for a couple of years and before that we have rather low retention rate I should say. I can't really measure this quarter because we are a bit tired right now so but before that I should say we are an attractive employer. So people like to work for us and we hear that from our consultants firms also. Yeah, it makes perfect sense it seems like like so. Yeah, but we could also say that we have frequent questionnaires where we follow the satisfaction of the employees and these changes that were presented have been very well received. The big one with the portfolio management has really made the life starting to make the life easier for product owners and for teams and we're gradually building a much more aligned way of looking at the future. Also this domain driven design is also very well received because each team is really struggling with all the dependencies so it is well received I would say. Of course it's always changed it's always changed right so so it takes some some time to get used to it and do it in a structured way but I think it's for good. Thanks for the answer. Yep. Great. We have one from Farhand. Are you following safe in this journey because he kind of thinks he hears the similar thoughts. No, we are not following safe and that has never been the approach and don't think anyone at VCRS thinks that safe is the big silver bullet of anything safe is contains lots of nice ways of seeing the world and there are good parts in safe but you also always needs to adapt the framework you use depending on the context. And I think we don't see any use for for kind of the big picture safe at VCRS. First we have the portfolio management part. It's inspired by parts of less and parts of safe and part of other frameworks out there so it's kind of taking the big picture, the big, the best pieces from from different frameworks and different experiences, we have from from our perspective and trying to fit that into what is best for VCRS right now right here so now we're not a safe company, safe oriented company. Thank you. And then Elena asks, what has been the bigger challenge when you face when it comes to reorient company cultures towards agility. That's a good question. I think, if I may, Jonas, I think one of the challenges is actually that we are in non agile context. So stakeholders interact with us in a more classical way. And that puts us in a situation where it is possible to always adapt that agile mindset I think it's it's been long before I started. When this journey started I think that that the large majority of the organization has been introduced to the agile mindset and it's it's quite it's well received and it's in the heart and soul of most employees I would say, but the context makes it difficult to to to act on that. Yeah, you're right. I mean, the question we have from the stakeholders is, when is it done and how much will it cost. And that's, that's a bit hard to answer. In an agile organization, so yeah, I agree. Yes, with us. He was with us at the start of the journey for this years. He might have another answer for how it was in the beginning. Any, any more questions. Yeah, we have one from right now. How much is the new ways of working align with product development and manufacturing and logistics. 100% software company. So everything we make isn't manufactured should say it will be delivered right when we wanted. So, I mean, if we had a cycle of if we were making software inside the car, I guess that the logistic and alignment with the production would be more interesting but I mean, when a developer has written a line of code and it runs through the tests, we can push it out in production in most other cases. Not all, not everything. We still have a big chunk of Oracle databases and stuff that which can be updated in real time. All our microservices and everything we're having national is kind of simple to do and that works really well within an agile mindset, I should say. I'm sorry, I answered the question. Did I? I hope so. I hope so. Otherwise, I'll ask you to rephrase it. I will answer it again. Thank you. How is agile mindset implemented into the financial control with governance. That's the same answer as previous we already know the non agile context and the financial part of that is, is not that agile as of now. Yeah, I should say that's the next speed bump for us. Yeah, and then Birgit has a comment. I don't know if maybe you want to say it. Yes, sure. So, I can imagine what what you said with the with the last comments, especially also with the classical waterfall approach a few years ago, and also the financial contractual part because I've been working on a supplier website for different we see us. Yeah organizations around the globe to develop the global e2e solution for for used cars. And yeah this was also from a contractual side. A massive piece of paper to get this master specifications and also racy metrics and and all that and that was also far. Yeah far away from an from an agile approach also to develop product or platform like this and yet it's great to see that VCS is has now made such a great journey what I saw since 2016. I imagine that you started it in in Gothenburg that there's some other VCS organizations around the globe will follow a similar approach. Yeah, yeah, definitely. So, I mean, I guess it's easy for us we sit in the same building, you know, even the same floor, we are only 180 per people so you can. That makes the journey a bit easier, and if you're situated across the globe with the people working from Finland and Norway and Switzerland and Australia and that will be a handful I guess to get this working. Thank you. What would be your suggestion to a team that wants to work agile but has dependencies to other things that work more waterfall based with Bing bag releases. There are two ways, actually, and one is the classical one of trying to to promote your way of working. The benefits of that and try to affect and change people who are most likely to change. That is one way that's kind of bottom up and then of course I think that for real change to happen it's back to the leadership and management support to make sure that make those changes together. So both convincing management with the benefits and continuously or in parallel trying to convince those teams to try to see that the benefits of your new way of working now. Thank you. And then Mattias brought to call Mattias all very broad comment and maybe you Mattias want to say something. Hey, what I heard Jonas mentioned my name while I was cooking lunch but I really didn't browse the discussion before so. Okay. Yeah, makes it difficult to answer. Yeah, I understand. I saw your name. I thought it was to say hello. Yeah. Hi. I'm curious about the journey and it's really nice to see that the journey continues and a lot of a lot of the things that we discussed in 2019 and 2020 are ongoing and happening. That's great. I think that picture I showed from the results actually you made that wasn't it. Yeah. Yeah, the data graphs there. Yeah. Great. Do we have any more questions than Jonas or Anders and they lost comments from your side. Maybe, maybe this. Thank you. Thank you for taking the time to listen to us and do if you have anything you want to ask or think about afterwards. Give us a call. Then I also say thank you a big thank you to Jonas and others I think it was really interesting to hear about your journey and as I said earlier I think you have come a little bit further than then than Mike, I thought you had so so it's really nice to see. Thanks for everyone to attending. We will have a short summer break and we will be back in August with these meetups and stories from reality. So thanks everyone for now.