 All right, I'm between you and the lunch break. I know that. I will entertain you with a number of stories. Okay, good. So I'm having to be here on this conference because this is actually my first conference or first conference day that is really looking into business agility. And this is one of the topics that are very close to my heart because we had an entire transformation which started from an IT, R&D product. You can't hear me? Can you, is it better now? The door, okay, good. So we started in R&D and it grew very fast beyond R&D because what we really saw is that just changing product development doesn't do the trick. So I'm going to share a bit of our journey and some stories and some lessons learned. Apart from my role at Erics, where I have a leadership career and at the moment I'm working as an internal consultant helping a larger business unit of 11,000 people, I'm also working as a volunteer for the Agile Alliance. And there I'm heading a program for trying to help the world to become more agile. What we will look at, I will talk a bit about how we kicked off the transformation, then showing you some more concrete things, how we were driving the system change, how we were changing the way we work and organize and especially because this is maybe the most tricky thing is how we changed mindset or how we approach change in mindset. So let's get going. The case I'm talking about. This is an organization and we started Beth Bernie in 2008. It's a 2000 people organization distributed globally. So we were developing two products in this organization in six countries around the globe. We had a very healthy business situation but we were very dissatisfied and I will come to that in a minute. But this is a very high level overview. So you see the six sites internationally distributed with department and group structures and so on. Then we had staff functions like I was the head of an organization for systems and technology. So we would look into requirements, innovation, incubation, product architecture and so on. And then how do we, because the company is active in 187 markets. So how do we capture all these needs from customers? For that we have a product management organization that's this red thing here and they are capturing all these needs from the world. They make a backlog or requirements out of that one and they would interact with us. So this is the core ecosystem I would say how we were developing the product, how we were organizing the product. So the interesting thing is how did we kick off the transformation? Well, we had an observation. I said the business situation was good. Our product was selling really, really well. We had very good profits on the thing but there was one observation. So here you see our product management and our development organization and it would go roughly like this. And some point in time, product management would give us a scope for the next product release. And based on that scope that they would give us, we would start planning the project. So setting the milestones. The thing that was clear already at that time was of course the delivery milestone. Usually you get a delivery date. And we would start looking into how can we make the delivery date, what do we need to study and implement and you see that here theoretically this was the good old water full time. Testing should only start when everything is there. So here we started already in the old mindset. Do some compromises. What do you think happened? People change their mind, new stuff comes in, we need to start replanning. And that happens several times. And you see that the overlap of implementation and testing is getting bigger. And you see that on the delivery date we start to see we are not going to be able to finish all our testing. So we start making a bit compromises on our quality. What do you think happens next? More stuff, more changes, boom, we blow the deadline, everybody is upset. The product managers say you never live up to your commitments. We complain to the product managers that they are all the time changing their mind and we cannot jump that fast and so on. So total mess in 2008. So okay, this is not good. We need to change it. So all wanted position, what is it? So we were sitting there in the leadership team and we were thinking, where do we want to be? So first of all, we said we want to ensure that we timely invest into the right things. It should be the right things because we had been selling or developing stuff that was never really sold, nobody was using it. That's not good. So we need to have the right things and we need to in time invest into this one. Not too early and not too late because we had also developed functionality that was needed in the market, but only in five years. So it was lying there, nobody was using it. We produce functionality in the most efficient way. Okay, efficiency is something that we always should strive for and we all can sing a song about that. I think, and then we ensure a quick return on investment. So once the product is out there, we need to have a good return on investment. Okay, good. So that was the one in position 2008 and we were sitting there in the leadership team and we said, well, let's do this together because we there in the leadership team, we are too far away from where the action really is. So how can we invite our friends and family? You could say into this turn. So what we did was we created seven work streams to look into all different aspects of what could go wrong here. So we were looking into how do we plan projects, how do we make scopes, how do we develop functionality and all these kinds of things. And we were inviting our product management, our finance and our HR into these work streams. So the interesting thing what happened then was that within a few months, we had 140 people from this 2000 people organization joining happily into these work streams. So we made it open for everybody to join in and they were really, really active and they created within four months more than 600 slides of new process descriptions. So now you can say, oh my God, 600 slides of new process descriptions isn't that horrible and that's actually the moment when we said, oh, now it's going maybe too far. But just think about 140 volunteers from the organization having the passion to really improve things forward. So that actually was a very good thing. We did not make use of all these 600 slides later on but that was another thing, the activation was the thing. And to integrate all the findings, we had monthly face-to-face leadership team workshops of one to two days where we were really discussing, okay, what have we learned now? What have we found out? What have we heard? And for example, Agile was at that time in the beginning, we said Agile doesn't work in a large company like ours. I was one of the persons saying in the 2000 people organization there's no proof one that this can work. But then some of these 140 volunteers, they said, but can't we try Scrum for just a few sprints and see what that works? And they made a trial and they said, but this is working very well for us. So we started to find that agility maybe is a part of our answer. We don't know how to scale it but that's another problem. Okay, so yeah, after five months then we had this stroke of insight. Okay, we had started with this one position and then we saw all these volunteers and all the passion of people and then we understood a big thing and that is we have to add another thing. This is not only a process change, it's a change in mindset. It has so much to do with people, how people are activated, how they think and so on. So we added a fourth element in this one which is we trust in teams and people. This is a strong message to the management because now seeing all those 140 people creating these proposals, we can really see we trust them, we can trust them, they have a lot of energy. I mean to change the whole organization system. So meaning product development, product management, finance, HR, it everywhere. Okay, so part two, how do we drive now when we discovered that we need to drive system change? How do you drive the system change? This was 2008 into 2009. So this was middle 2009 that it is now a good time. So how do you drive system change? And this has been a thing that we have been looking at quite intensely. So traditionally the way we approach change is like this. We look at our organization and we see all the infrastructure there, the departments and we see the processes, like what's flowing, what's not flowing. So whenever there is a problem in our organization, what we do is we look at, okay, do we need to build a new department for a new thing? Or if there's not enough flow, should we build another lane on the motorway or another motorway exit or something like this? So this is the traditional way how we have been approaching change. What's missing in this picture? Directions, planning. There is another important thing I'm after here because when you zoom into this thing, it looks like this. What's missing in this picture is the direct view of the people. So when you zoom into this one, you're confronted with people are inhabiting this architecture. Our departments are not just there, they are existing of people, you beings who are interacting with each other and who are doing stuff. And those people, I mean, in this picture here, I mean, the bus driver is working, the taxi driver is working. Those people, you can't really say what they are doing. I mean, maybe some come from work, some go to work, some go shopping, some go to a restaurant and so on. If you want to control this mass of people, how do you do this? You can do it the traditional way, making an agreement with each and every of these persons on yearly goals, what you should achieve and what you should not achieve and so on. Will this do the trick? Likely not, we all have the experience that it does work because there is another phenomenon here that you see and that is self-organization. People are self-organizing. Sometimes you say you need more self-organization. Good news is self-organization is always there. Whether you like it or not. And self-organization is always an optimization thing. So you see, for example, these pedestrian areas that got overcrowded. So people saw, okay, what do we do? They make more use of the space that's available. They are optimizing it by self-organization. So this is the phenomena that are happening. And then the question is, how can we still work with this complexity, the masses of people, the society in our organization? So how do drive change in such a complex system? And there is probably some of you have heard about the Kineppen framework from Dave Snowden. If you haven't, it's a very, very good thing to look at. So what we learned from this one, what does complexity really mean? The characteristics of a complex system is you can't really predict what's going to happen here. Predictability is not there. And things emerge via self-organization because of the fact that this is self-organization, organizing, things just emerge, patterns emerge, how people behave, and your results emerge. And to thrive, to really do the work here, we need to experiment. We need to have an approach of trying things out and seeing whether they work. So we need to look at this system. We need to see what does that tell us, what we see. Define a change experiment because maybe we want to see some other patterns emerging. So for example, we don't want people to use these parts of the street. So maybe we need to make an experiment what happens if we put walls up here and the traffic light turns red. There are walls coming up here or something like this. You have to divide an experiment, take the change actions and see what is then the behavior. Is it getting better and if not, you abandon the experiment and try something. So an agile transformation, an agile with a small a, because we are not talking about the agile manifesto agile, we talk about agility as a phenomenon. This information is an emergent change. It's the result of something, of the change in the society in your companies. Okay, so then how can we actually address, how can we define, how can we find system change experiments? What are the levers that we have in our organizations? And that leads to the question, what can we really manage? What can be influenced in our companies? So what do we manage? First thing that comes to mind is, oh, we are a people manager. We are managing people. But what is it really about people that we can influence? People are not robots. Behavior, motivation, exactly. So there's two things we found. You can influence about people. One thing is behavior. You can influence behavior by giving feedback, by giving coaching, by giving feedback, by communicating company values and things like this and so on. Then you can change, of course, capabilities of people by giving them coachings, by giving them trainings. You can change the capabilities of teams by changing the diversity on the team or adding new people with other skills and so on. So you can influence those things. And then there's two more things you can influence and those are the obvious ones that we have been using very much in the past, processes and structures. And this is our cozy corner. Show me the problem and I can tell you the process to fix your problem. So this is not difficult. This is the difficult. And because we have in the past always focused on the architectural side of things, we have forgotten about this and then that's why the mindset changed us. And there is another interesting thing about this one. Those four are correlated. They are influencing each other. So change of process and the behavior of people changes. A quick example, at Ericsson, we have a trouble report handling process which is classifying trouble reports according to the severity, A, B, C, D, other classes. Then on the structure side of this, we have a KPIs that are saying for an A priority for our report, you have 48 hours for B priority, you have 72 hours and so on. And on the structure side, you might have even incentive scheme that says you get a reward for solving your A priority TRs in 48 hours. What do you think is the emerging behavior out of that system? Let's say an A priority TR comes in, an engineer looks at the thing and says, oh my God, this is not going to be solvable in 48 hours. What will this person, how will this person behave? What do you think? Oh, I think actually, this is not in our subsystem, it's in the neighboring subsystem. So I forward the trouble report to my colleagues over there. Or things like, oh, I need to reach out to the trouble report issuer because maybe he did a mistake when classifying the thing. Maybe it's a B priority, not an A priority. So instead of putting the energy in solving the thing, the behavior is that you are trying to get rid of it. And you have maybe seen similar things in your companies, the side effects of these things. So to work on this one actively, we have created this tool that you can use. You can use a whiteboard or flip charts, assemble a team of people who want to look at this thing. And what you do is you put the four constraints, the four things you can influence in your company into the four corners. Then you maybe put some arrows there. So you remember, oh, if I tune something here, something there might happen unexpectedly. And then you have in the center, your desired state, your one position, you can also use this tool for analyzing a problem. And what you do basically is you think about, okay, what behaviors help me to reach my desired state? What behaviors do we see today that are not helpful for reaching the desired state? What processes do we need to reach our desired state? And what processes are supporting the wanted behaviors to emerge? So you really think the whole thing through. Okay, so two more things now in this talk. I will first talk a bit about the boring, not boring, but the obvious things about structures and processes. And then I will show you a thing about the mindset change. And that will be a bit of a longer story. So let's get going on the process part. Process and structures. So on our way to agility, we changed almost everything. That's what we found. So let's look at the core operation flow. So we have created three main programs to do our product development. An early phases program, a feature implementation program and the release program. And what they were actually doing was the mission of the early phases program was to deliver planning data to be able to plan scenarios and support product and sales decisions. Sometimes I had a discussion in the beginning. I was so unsure, are we doing the right things? Because people were saying, are you doing still upfront work? This is evil. Don't do upfront work. This is not agile and so on. And it took me a while until I understood, hey, this is very agile because we don't want these people to implement stuff that's not needed. And we need to scan the market and understand what do things need. And when our customer representatives meet the customer, they need to be able to tell them something about when can we deliver something? We need to be able to make a business case. How much will, how do we price the thing? And there needs to be some process around how we are coming to this data. So this was the mission of this early phase program. Then the feature implementation program, the biggest of the programs, deliver features that are integrated into the product. And then the release program would have the mission to deliver the product releases that can be rolled out globally. Maybe here, submit or offer flow chart picture. So here you see that new requests from the market are coming in arbitrarily and they are done in a very short study, usually one to two weeks to deliver planning data. And then some of them are going into sort of execution later on. So you have something like this for one feature, you study and do a very high level design, you design and implement and test. We integrate of course continuously and then verify it in the context of release and ship it out. And I think many companies in the meantime have come across very similar ways how to do this. So no very big miracle around this. Now when we look at the organization aspect of this, so we have the operational flow I'll just show you. But this is not all, then the product is still not there because still the product is to go to the 187 markets and then need to be deployed. So we said we need a deployment program as well. And there the mission really is past return on investment is to be possible to install and configure the product. And well you can see this a bit like an orchestra. So the different music players here but where is the conductor? Somehow you need something like in the classic times we called this the project office. Now we called it the portfolio handling office where we were combining a sort of agile project management office, the product management, the finance people looking into things like strategies, scenarios, performance dashboards, product lifecycle management, the release load maps, the feature backlog management that's a financial frame handling and all of that. So this was a bit the orchestrator and my task at that time was to set up this thing here in a distributed way because this cannot be an ivory tower separated from all of these. It needs to all go hand in hand. So how do we distribute it over the organization? Then you need to think about governance and then this picture indicates that this can be done in a very straightforward way. You just have an operations hearing group for each of these things where you are discussing the status quo and what should be done. And those hearing groups they were more having a mindset then of how can we help this thing to perform well? So it was not only a follow-up thing where people are going and reporting it was more like the solving problems kind of attitude in these hearing meetings that was a big change. Then of course the part of the governance is of course the daily stand-ups and the sprint demos. They are part of your governance. There you see what's going on, where you have your problems and what can you do about them. And then last but not least, we had formed a product steering group where we were managing the overall perspective of the program. And then of course management functions. I don't go through all the details. If you have a product program management for the thing, you have the teams, the feature teams, the cross-function feature teams. You need to build continuous integration channels and so on. So this was a bit the organization setup that we have taken. Then of course there are support functions that are also needed in this kind of transformation. And let's start with human resources. So it's often people who are forgotten when we are talking about agility or they are remembered when things go wrong. Like HR doesn't support us. So what did we do there? So the first thing that we changed was recruitment criteria because when we understood that this is a mindset change, we need to make this mindset change part of the recruitment criteria. And especially when we recruited new leaders, this was a very instrumental thing. So because we changed the whole organization, we re-recruited all leaders in the whole 2000 people organization. That was a tough, tough step. But due to that and due to the fact that we understood that we had agile mindset now as a recruitment criteria, it changed the organization very, very fast. Then we changed the career model. So in the past we had like software architects, system architects, we had a job role for software developer, a job role for software tester and so on. And what we said is when we now have these cross-functional teams where everybody should over time become able to do everything, this kind of role differentiation doesn't really, is not helpful for us. Also how do you change the career path from a software developer to a tester or vice versa? So what we did was we were collapsing this all into one role, the product developer. And we did something similar with the management. So we have line managers, but we also have agile coaches and so on. And that should not be different role descriptions, job roles, we all put them together into something you call the product development leader. We did a number of experiments, team feedback sessions, team maturity surveys, removal of annual performance ratings. We tried these things out with so and so success. Our problem mainly was that the group, human resources in Ericsson was changing over the years and whenever a senior executive is coming in with a different mindset, things might change. And this one here, for example, team feedback sessions, we could see that in the trial, some teams are mature enough to cope with it, but we are definitely lacking the coaching capabilities to help the teams to survive these team feedback sessions. So this is a coaching capability thing that stopped us from doing it further. Other things, we need to anchor all this change. So we need to talk to our unions and to the works councils and anchor it with them. And we were inviting everybody to improve HR-related things. And this is a relatively recent thing that is growing quite a lot. So we have Yemma groups, HR is reaching out to discuss things like the yearly development conversations, performance management, the thing that Todd was talking about earlier today. And we have things like the cultural sweet spot which was crowdsourced. So what do you think are wanted behaviors and desired behaviors and which are not helpful behaviors in our company? And so on. So lots of different things. Finance, yeah, there the question was how do we balance accounting rules because there is a legal environment around us with handling of financials, how to increase flexibility because at the end of the day we understood ideally we want to have the money where it adds most value. So what about doing yearly frames and yearly follow-ups? So one thing we did, we went from yearly frames and with a monthly follow-up and this was really just a monthly follow-up are you adhering to the frames and the plans towards quarterly something we call tactical planning. So now quarterly we have follow-up meetings but in those meetings it's not like are your figures in line with what we said in January? Now it's more like, okay, what have we found? How is everything going? Is there some new market demand there that we need to satisfy? So do we need to pull out money from one area and put it somewhere else? And all these kind of things. And we, finance for us was a strong enabler for more feedback groups. So for example, when we talk about estimates, early estimates, how good are we in early estimates? And this is a tricky question for us because we want to make business cases that hold, for example, and if we are too bad in early estimating, we are going to have a big problem. So what we did was we were creating financial structures that help us to compare what was the early estimate and what was the real outcome at the end. And by comparing this, we enabled the feedback group that helped us becoming better over the years. All right, so those were just highlights of things that we have changed on that side. Then I promise you to talk a bit about mindset change and now we are going to use the tool that I've shown to you before. And I would like to take one of the examples because there's many areas or domains within which we wanted to change mindset, but one was really in the way we run operations, how do we plan projects and so on. So my example is managing uncertainty. So when you take this and you think, okay, we want to deal professionally with uncertainty, what behaviors, capabilities, processes, structures do we need. So starting with behavior. Well, maybe the first thing is you want to behavior that people accept that uncertainty is always there. Predictability is there. So now if I come to you and say, okay, from tomorrow onwards you will accept that uncertainty is always there. You say, yes sir. And the leaders will say, oh, we had an all-embracing meeting. We told everybody the job is done. Do you think anything will change? No, this is a mindset change. So we need to find in this ecosystem other things that can help us. So this is really emerging from the system. You can't command people to think like that. So okay, we were sitting there, we were thinking how can we do this? So one thing we came across was maybe make our uncertainty visible because when something is visible it's harder to ignore it, right? And yeah, so then when it's visible we also need to talk about it. And for that we maybe need a communication structure and what we thought was okay, maybe we just put this into the terms of references of our governance meeting. So we show and discuss this uncertainty in the governance meetings. And by the way, the practical thing what we did, and I will explain that in a minute or a bit more maybe, is we went from precisely wrong estimates, like in the past we would have been saying we are going to deliver this feature on the 7th of October at 10 a.m. Which is a precisely wrong estimate. It's very precise but it's totally wrong. And we went into using ranges to express our uncertainty and our number of other things. Distributed planning on different levels. So we had the portfolio level planning, we had the team level planning, we had the planning level on each of the programs I was showing you. We said we need to have iterative development because only in iterative development, like in Agile using Scrum, we get frequently feedback and new updates on this range and by this we get current best knowledge information and so on. So lots of these things. So the first intervention, so this is just a sketch. So this is a sketch, what did we do out of this one? What's the trial, the experiment that we did? So this is the experiment. So okay, except that uncertainty is always there, it's here. Yeah, our product management is the biggest stakeholder when it comes to managing uncertainty. And they need to be on board first on the highest level to manage the 2000 people backlog in a good way. And because this was a new organization and the question is how can we help people to, you remember what was here? We said manage expectations, anticipate expectations, create uncertainty and deal with maybe also these negative surprise reactions. Why can't we commit earlier? We had a decision model that had a commitment decision. So there's a go decision, a delivery decision and in between simplified further, we provided a more customer oriented uncertainty if you were in the governance meetings. To work on this, we looked at what's actually the problem here. So maybe the problem is that product management needs to understand development better and developers need to understand product management better. Still they are not on the same page. So what could we do? Send the product management to product development courses and send the developers to product management courses? No, the only way to do it, and that was what we tried was lock them into a room, let them bang their heads together and solve their problem together. So we created a regular scenario meeting between development and product management. So this was half a day, once a month, where that top level of planning was sitting together and discussing what's going on. Okay, what emerged out of that one? Product development and development, a product management development starting to join forces. Hey, this is cool. So what actually happened? We created these meetings, these half day meetings and in the beginning there was of course quite a debate but after half a year already, we could see that the development would come into the meeting saying, oh, you guys in product management understood this is your priorities because that customer is waiting for this and this and actually we found here a problem with a feature because we have been too optimistic but here are the option A and B and C what we would propose to do now. And then maybe in the discussion, product management would say, but maybe here there's another insight from our side and then we would create an option D out of this one. But we would really come very prepared into that meeting. So this was really good. And as it's good, we needed to amplify it further. Now we make the experiment bigger and say now we push this to all the feature teams and we closely pair the product owner with the strategic product manager and give them the power to decide on a feature level on requirements. So they don't have to ask anybody for any permission on deciding things. What happened next? We don't need commitment decisions anymore. So now the product management can see all those ranges. They know, wake me up at two o'clock in the morning. I can tell you exactly what is the situation in the program and I can tell you what I can tell to the customer. Where do I need to lean out of the window and where am I safe with my statements? So this was a wonderful thing. So we made the commitment decisions optional. And this journey continues. So this will never end. Things are emerging out of your organization system. You have to be on your toes and run these little trials and experiment over and over again. And yeah, so one important thing is really we do a lot of retrospectives on operational level. So the scrum teams, they do retrospectives and they always look at what has worked, what has not worked and so on. What we also need to introduce and that's what we did, we need to make organizational retrospectives on leadership team level where we think about what patterns do we see emerging and is this what we want? Okay, in summary, the natural transformation is the emergent change of your organizational human system and now you maybe have a better idea of what I mean with that difficult sentence. To achieve full business agility, you need to nurture an agile mindset in all these functions. R&D, product management, HR, finance, source and sales. And the mindset is the guiding things, not the principles behind the agile manifesto because those principles, they don't help HR or finance. So then rather look into beyond budgeting principles when you talk with HR or finance people. Yeah, driving the change requires thinking about behaviors, capabilities, processes and structures and don't get stuck only looking into processes and structures because this is our comfort zone. Look into behaviors and capabilities. The reward is much, much higher if you look at those dimensions as well. And as the changes emerge into journey will have a lot of side effects. So frequent organization retrospectives are needed to stay on track. All right. So are there any questions? Actually, what time is it? Almost lunchtime. You, yeah. Good question. So with the uncertainty ranges, of course we say something like according to our current best knowledge, we can say we are going to deliver this between September and December. And we know the customer expects it or needs it in October. And this puts an urgency on the thing. So it tells us we have a risk in this thing. How can we minimize the risk? So the whole organization starts focusing on how can we make October happen? So, and this is how we accommodated the customer or making the customer happy perspective. So then you have discussions like, oh, do we need to add another team to that feature to speed it up? Would that help? Or are all these user stories that we have there planned at the moment are they all needed by October? Or is there some part that can be delivered in the next release? Those are, I mean, creativity unleashed. Whatever comes to your mind, do it. If you're totally off, then you can start screaming and crying or whatever. So all the emotional sides are very welcome. But at the end of the day, the facts are the facts. This is not going to happen. We'll stop. Then the question is, and that's why you have to have your product management on board. How do we now have a communication strategy towards our customer to tell the customer that this is not going to happen? And what can we offer instead? So we had a number of times this situation. For example, I had it once and this is one of the tricky things when you're developing a new product, for example. You have no history in estimating. So then you are very likely, very much off. And we had a clear customer commitment to a certain deadline already for a totally new product, which is crazy, but sometimes you have to do these kind of things because your competitors are making the same kind of, it's gamified. So what do you do? You lean out of the window, hope you are not falling out, and then you discover, oh my God, this is not going to happen. What helped us was, I mean, and we have always this customer representative organization in between R&D and the customer. And what we figured out was that's the moment when the customer representative organization should just do a step aside and we start directly working with the customer because in that particular case that I'm talking about, we just paired somewhat a technician from the customer with the product owner from us. They were looking through all the user stories and they were looking at, is really all of this needed in that time frame? And they came to a very good solution. And at the end, the beauty of that story is that at the end, the whole product delivery was something like half a year or even nine months late because we had been severely underestimated. It had a one year lead time and then you are six to nine months late, so almost double, you could say. But the customer was happy as hell because of the great collaboration with us. So speed and delivery deadlines are not the only thing on the planet. It's very much about people interaction and then knowing where do I lean out of the window when I have insights, better tell it now to the customer and find a way to get up forward how to solve the situation. And the traditional behavior is, oh my God, we have totally underestimated it. Where can I hide? And then we start lying and then maybe some people from development say, ah, this is not going to work out then some senior executives, but we have given this commitment. You have to replan this, you need to find a way and then you spend month, precious month in just trying to fix something that can't be fixed. So yes, yeah. So sometimes we had several countries, several teams in several countries working on the same feature and then we used the Scrum, Scrum approach. So we had a chief product owner and proxy product owner kind of set up to keep this together. And then this feature team was like a mini project team. Sorry, you first and then you can, yeah, for all of the team. The tool was made optional for all of the teams. Some teams continued using it because they liked it, but others did not. Yeah, but this is a self-organization and I mean, this is something I don't care from a portfolio perspective, I don't care. I just tell the teams, figure out how you do it. And if your multi Scrum team, feature team that is not co-located can't agree on one tool, you need to find another solution how you do it. So this is simply self-organization. You need to figure out. And usually my experience is whenever people are sitting together, they find something, how they do it. So I have no real negative experience on that one. But sometimes they don't agree on the same tool and then they find something and you had a question. So we've changed really a lot. The whole organization, we agree through all the leaders. Yeah, the transition approach was really that we had a trainer coach, the coaches. So the leaders had already an agile training at that point in time when we changed over. Then we were flying from all the locations. We were flying people into one site for three months. So we have identified people who should be able to train other people later on in agile Scrum product owners, Scrum master and so on. So we were flying them into Greece for three months together with the consulting company. They would do a super intensive three months training with these people, including video analysis and they are presenting and so on. So this was really tough. After the three months, they go back home to their home organization. And there they are part of a local transition team where they are working with the leadership team, the local leadership team and doing all these trainings. And the duty of that one was that because they have been sitting together for three months in one site, almost in a, not really vacation but a bit like unusual situation, they became friends. They are still a non-organized, self-organized agile coaching network today after almost 10 years and they have been gluing the thing together and they were helpful for keeping the whole thing somehow aligned. I once, in the very first version of this presentation, I called it iterations. And then somebody had, what was your iteration time span? And then this is emergence. So there is no iteration. That's why I renamed it in intervention because you need to do your organization retrospectives. You see what has emerged. And based on this, you say, okay, maybe now has the time has come to do an intervention. And especially in the beginning, when your agile mindset is not very developed, you're like, I mean, I'm an experienced project manager. I see the feature teams struggling with doing the project management part of that task. I think, I want to jump in. And then when is the moment to jump in? When, how long do you wait? And rather you should wait a little bit too long because if you're going into early, they don't have the learning and nothing will change. And this is, of course, a big thing in the beginning. That's why recruitment of the right leaders who can really stand this situation of letting go. Yeah, in the beginning, we had these organization retrospectives every month. And after two to three years, it was like half yearly. So this is roughly the rhythm at the moment. Half yearly, we have these retrospectives and organizational level. So, okay, that is another development, product lifecycle-wise. In the past, we had one major release per year, which was always six months, at least, delayed. And after this one, first of all, all releases were on time, not with all the scope that we were dreaming of. So we always made compromises on scope. But everything was on time. And of course, like the whole plan is going DevOps, we are also now looking into continuous release strategy. So our release cycles, one year went down to half a year. At the moment, we are more on the three-month period. And there are some organizations in Ericsson who are now on the monthly rhythm of product releases. But this is the thing with the range and having a clear delivery deadline. Because what people always were very much respecting was the delivery deadline. They did everything they could to deliver on that date. The thing is, rather, when we look between minimum and maximum range, and then the delivery was somewhere in between, we always had a tendency, we never achieved the minimum. People always put more work, they work until the last moment because they really want to perfect things. And that's a phenomenon, a social phenomenon. I have not cracked. So this is just giving the deadline and then there's another one. Are we differentiating people? Incentivite people. With incentives, so we only have team, or actually in the meantime, we don't have even team incentives. We have really organization incentives. So we want everybody to pursue the same goal. And also another related thing is measurements, performance measurements, and so on. We have been super cautious on measurements because all measurements create a lot of behavior. So measurements are very, very tricky. And that's why in the beginning, we did not do any measurements. We had a huge, we had a one year debate about what kind of measurements. And then from the top came, you have to measure your feature lead types and so on. And the thing is, of course, we can measure them because we have all the data, but we want to use the data for learning. So the moment you need to make these things public, it's a bit of a tricky thing. How do we manage performance? Yeah, well, one thing is a measurement, but the other thing is learning from the data we have. You see the difference? So we have tons of data, and of course we learn from the data we have. So we have been looking into what was the range estimates, how did the range develop? What was the delivery deadline? How, what came out at the end? And from this, we were learning and giving feedback to the people who were doing the original estimates. We were, in the beginning, we usually use planning factors. So if you have only an early phase estimate, and you usually multiply this by a miraculous factor that some experts know only to arrive at, this is roughly the ballpark figure where we, how much something really costs or how much effort it will really be. And we have been able to fine tune those factors over time. So we are using this. But for example, a good thing in performance, we had also, for example, who's responsible for the team velocity? That's often a performance figure that people use. And one thing we came across was that we, the leaders don't care about team velocity. The team velocity is a data point owned by the team, and it should be in the team's interest to increase the velocity. So, and actually that's what's happening. But the moment you make this public announced measurement, and you see, look, this team has a higher velocity than that team, you're screwing things up. You make the world an unsafe space, and then people will just start hiding to this stuff. So, yeah. For the development teams, they really liked. So we'll think for the architects, it was a bit tricky, and we had some detours on the architects. So first, we distributed the architects into the feature development teams. The problem was we did not have enough architects. So not in every team there could be one. And we figured out that you can't grow them. That passed. So there we rolled back actually, we were taking out some of the architects back again, again into a central architect organization, and said, okay, those architects are the architect mentors and coaches, architecture coaches for the teams. So those teams who don't have an architect, they need to develop one with the help of these architecture coaches. That was our approach. Success, so and so, some teams have developed that. We have more architects definitely than before, but it's still not so that we have an architect for every team. This is a special kind of people, it seems. It so much depends on what kind of product or what industry you're working on. You're absolutely right. One of the different, part of the definition of done on such a feature team is also training material and so on. So this is part of the delivery. It's not, I mean, that was also a thing we stumbled upon. Somewhere it says the only measure of progress is working software, and that's nonsense. Working software of course gives you a lot of feedback whether your software works correctly, but you need to also develop product documentation, training material, and all these kind of things. So all of that needs to be in the definition of done. So in that sense, and then the question is, how much, what features do you have that you can really develop in such short cycles Well, the feature might take several sprints, several months, but your release frequency can be maybe one stage. Then it's just slotted in into the release where it's needed. Okay, lunchtime.