 Our next speaker, he is a very frequent speaker in all kind of conferences about agile themes. And he's also director of the Agile Alliance supporting Agile Adoption Initiative on a voluntary basis. It's an initiative to help companies with change. And he also works in a company that has a lot of changes these days, Ericsson. What kind of role you will have, you're not sure? It changes as well, but something about organizational transformation and coaching. Correct, yeah. Nice to have you here. Welcome. And give him a warm applause. Hendrik, yes, sir. Thanks. So, change has changed. We hear this so often. I was this week in Germany. Last week I was in Germany on some events that I was invited at some bigger companies. One was Bosch, you know, those. And the other one was Trumf. And they are all companies are really in the middle of the digital transformation, trying to understand, making sense of all the complexity that's raining on them. So, this is one of those super hot topics in the whole industry. And I really feel, especially with the theme of this conference, we are really hitting a nerve of many, many companies. So, I will talk about how applied system thinking helps you transforming your organization. And out of the conversations from last week, I would exchange this now with company. Because you don't want to change your organization structure only. You need to change more. And I will explain why. So, we will look into how we are driving change in companies. I will introduce you to a tool that helps you getting going on applying system thinking to drive change. And then, of course, it will not only be theory, it will be a lot of storytelling. So, I will look into our agile transformation at Ericsson. And on this example, I will explain you how the tool works. Yeah, let's get going. So, this is a typical thing that we do when we are trying to drive change in our companies. We are actually architecting them. There are some leaders in the company who are looking at the company and they are thinking, okay, what works well? What does not work so well? We want to change something and so on. And it's a bit like shown on this picture. We see maybe some bottlenecks that we want to resolve. So, we need to maybe build new streets or a new exit or deviations and all these kind of things. This is how we very often approach change. So, we find new architecture, new organization structures or whatever, maybe no processes to make the change happen. What's the problem here? What's missing on this picture? Well, when you zoom into this thing, it actually looks like this. There's a lot of people working in this company or running around in this architecture. The good news is people are self-organized. I've heard so many talks about, oh, we need to get our people being self-organized. Actually, they are already self-organized. You see this, I mean, people should walk on these kind of areas where pedestrians should walk, but they got congested. So, self-organized, they were starting to use the rest of the space on the street. So, they were optimizing the thing. Nobody told them to do it. Actually, it is maybe even forbidden to do it. But that's what they do. Self-organization works in our favor. If you would try from this helicopter perspective, tell every person here on this picture what they should do or not do, it's mission impossible. So, this is the kind of complexity we are dealing with in our organizations when we are trying to introduce changers or transform them. And that's why we need to really understand how complexity as a phenomenon works and how we can cope with it. So, the question is how can we approach complexity? So, approaching complexity, fortunately, we are not the first one. It's funny. When your eyes are opened, you start to see the world in a new light. And when I came across this one, I thought, maybe somebody has thought about this before. And then you open Google and you see tons of people for decades have been talking about complexity and trying to make sense of this. So, out of the many models that are existing, there's one that I think is working extremely well. And that's the Kinefen model, the Kinefen framework. Question, who of you knows the Kinefen framework? So, quite some I will very briefly go through. This is created by Dave Snowden. Dave Snowden is one of the guys who has been also in my Agile Alliance group. And he has in 2007 written an article in the Harvard Business Review about this one. Strongly recommended read. It's not long. It's simple and you get a lot from it. So, this is a sense-making framework. So, sense-making means you're confronted with a problem or a context and you need to think what am I doing? And over here on the bottom right corner, you have maybe the obvious problems. What you should do is you look at the problem. Then you say, I think, this is obvious. I've seen this a couple of times before. I know exactly what to do. So, you can categorize it and then you know what to do. You sense categorized response and then that's the domain of best practices. Cause and effect are in a very straight, simple relationship. If I let go of this presenter, I'll fall to the floor, very straight. Then things can become a bit more complicated. Cause and effect still there, but it's maybe like some machinery. You need to think a bit more. So, you cannot sense categorized response because you have not maybe seen it a thousand times. You need to analyze it. You need to think about this one. And that's the domain of good practices. Now, in this model there is an interesting phenomenon a property on the right-hand side that is not existing on the left-hand side of the model. And that property is the property of predictability. On the right-hand side, things are predictable. On the left-hand side, things are not predictable anymore. And then things start to become complex. Complex means cause and effect maybe are still somehow there, but you cannot say, if I do this, this will be the exact outcome. When you look back in history, you can say, I have taken that action and therefore that happened and that was the consequence and that's why I'm here today. That's possible looking back in hindsight, but it was not possible at that time to say, if I take this action, this will be the precise outcome. Spooky. So, how to deal with that? So, actually what Dave Snowden and a lot of people are saying, you need to start experimenting because there's no guaranteed outcome. So, you try something, you see whether what emerges out of your system, out of your organization, whether it's going into the right direction, if it goes into the right direction, you go further there, you amplify what you have done, if it goes into the wrong direction or it creates negative side effects, you dampen what you have done. And in that sense, your probe sense response means you look at your organization or your system you're dealing with, you try to make sense what I see, what does it tell me and then I formulate my experiment. And that's the domain of emergent practice. And then, of course, we have chaotic contexts where cause and effect are in whatever relationship you don't really know and predictability is completely gone. And there what you do is actually just act, do something, see whether it improves the situation if yes, go further into that direction, if not, you try something else. And that's the domain of novel practice. What is an agile transformation in which domain is it? Is it obvious because we have done it a thousand times? No. Because it's effects agile is mindset that what we say with Steve Denning, it's very much in a complex domain. If you're unlucky and you approach it in the wrong way, you can end up in chaos and that's what we don't want. So our challenge is to keep it in the complex and complicated domain. That's what we are trying to do. So in a nutshell, complexity is characterized by very low predictability. Cause and effect are only understood in hindsight and outcomes can't be exactly predicted, so they emerge. And therefore, a successful approach is experimentation with probe sense response. So emergence, how can we make things emerge? How can we increase the likelihood that our experiments are successful? So an agile transformation is an emergent change of your company's complex human system and a better approach than is to change that system. And then the question is how to formulate change experiments? How can we influence a human system in a company? And now I'm going from the broad to anything you can do with Kinefin into a concrete context of company transformations. Okay, how can we leverage? There is one thing that we can or need to understand when we talk about companies or societies in general and that's the phenomenon of constraints. So constraints, all societies have them and they're either set or they emerge. What does that mean? So if you want a crowd of people working together towards a constructive common goal, of course there are different viewpoints, opinions, views and so on and different interests maybe as well. And to combine those interests into one direction, you need to make contracts with each other. We call this civilization actually. So partly our governments are taking care of us in that sense that they have laws. It's not okay to kill your neighbor, for example. Helps the society to live peacefully together into a prosperous direction. But there are also these emergent rules, rules that nobody has ever written down but they are somehow existing. They emerged out of our system. Example, I don't know how many of you are sitting in landscape offices. If you're sitting in such an office, often there is some office etiquette that nobody has really written down but there is a certain way of behaving and that was just emerging out of the people sitting in that space. And our teams are often creating some strange, interesting procedures or habits. Nobody told them to do and it's not written down, it's just there. In a company usually we set and manage the constraints. And that's actually the lever that we have. Now the question is what are the constraints that we can address in our companies? What are we managing in our companies? So of course, right, we manage people. Our people are constrained. Oops, what's that? Now it gets... Twilight zone-ish. Our people constrained. We have been showing a lot on that question because why do we manage people? So actually what we found was this, what we are actually talking about when we talk about people is behavior and capabilities. Those are the things you can influence related to people. So you can influence behavior by giving feedback and many companies have this at least yearly routine of having feedback conversations with every employee. And in those conversations you can give feedback on I've seen this behavior and that was good and we like it and so on. And there's other things that we maybe need to talk about. And then of course capabilities. You can influence capabilities of the organization by giving people coachings and trainings. You can change the diversity on your team. You can change the number of people in your team and so on. So you can influence that. What else can we influence? Okay, the good old stuff. Processes. Show me the problem. Tell me the problem and I'll show you the process that solves my problem. So this is relatively easy to do and structures as well. An observation is maybe that the two lower ones are especially our cozy corners especially at our studies and so on. What we learn is that if we just analyze enough we can solve any problem. And our bias towards analysis drags us away from the complex domain into the complicated domain. So that's our cozy corner. And processes and structures are so easy for our analysis mind. The other two are a bit more difficult and that's why the two upper ones are very often forgotten when we are talking about change initiatives. An interesting phenomenon here also is that those four are forming a system in themselves. They are interdependent. So for example, the behavior changes because a new head of an organization is recruited. That new leader is appreciating different behaviors than the leader before. And all of a sudden people start adapting around this person. They will adapt their own behavior but they maybe also learn new things because this new leader is appreciating different stuff. They are starting to act in a different way. They are doing the processes differently or they are reshaping things and maybe also restructuring is starting to happen. So they are interdependent. So that has led to a tool that we have developed because system thinking to approach organizational change or company change is a tricky thing to learn and it's not so straightforward for us. So the help of a tool that helps us to do our first baby steps is very much needed and we developed this tool. So it's a two by two matrix where we put the different constraint domains for quadrants. Then you put some arrows there. Oh, let's not forget that they are interdependent. If I tweak something in one corner it affects the other corners. And then of course when we want to drive change we need to understand what are we going for. So you need to write into the middle something like your desired state. You can also use the tool for a problem analysis. So you can also think about what problem do I have that I want to resolve. Thinking a bit deeper, above the surface you see of course the behavior of people. But that behavior is just above the surface. Below the surface are things like mindset and attitude, values and needs. Many companies have company values. What they actually mean is they want to see certain behavior. But you can never say because I've seen this in that behavior this must have been the attitude of that person because you don't know that person. Capabilities above the surface you have competence, skills, number of people these kind of things. Below the surface you have things like hidden talent. On the process side you have things like processes, practices and tools. Below the surface you have maybe something like habits. And on the structure side you have organization structures, governance structures, compensation structures. Below the surface you have things like this informal networks. So what you're doing is probe, sense, respond. How good do I get a good probe out of my organization is by calling in a very diverse team. We need to have a lot of stories and insight and different viewpoints. And with this team you go to a whiteboard or take a flip chart and you draw this scheme here. And then you start thinking this is our desired state. So what behaviors would help us to reach this desired state? Then building on that what capabilities would help us building the desired state and what capabilities would help us to let the wanted behavior emerge? What processes do we need to reach the desired state and what processes would help us to get the wanted behaviors? What processes do we have actually today which are creating the unwanted behaviors? That's also a question you can ask. And what should we actually change then with them? And the same thing with structures. What kind of structures do we need to achieve our desired state? And then you have a normal learning cycle. Look at your system, at your organization. Analyze is my vision still valid? What supports my vision? What doesn't? Define a change experiment or an intervention as we call it. Take change actions and then observe what emerges and that's why also on a leadership team in a company retrospectives are so important. Because you need to continuously monitor what's emerging out of your organization and other things that emerge the thing that you want or not want. Okay, enough of theory. Let's look a bit into practically applying this and I wanted to show you the agile transformation. Intervention number one, 2008 or 2009. We didn't say we want to go agile of course because agile is just a means to an end, not the end itself. So what we actually wanted to achieve at that point in time was better customer satisfaction, better quality and a shorter time to market. We wanted to achieve and in our investigations how to achieve that we thought a key thing is that we have empowered teams. Teams who are empowered to take their decisions and so on decentralizing decision making and all these kind of things. Now we can say, okay on the behavior side we just tell the teams, okay from tomorrow onwards you are empowered. Okay and you are done? This will not work of course. So this tool tells us if I put something in one corner I need to support this by some things in the other corners. So let's think. Empower teams, first of all on the structure side it means cross functional teams. Now cross functional teams how can we really have cross functional teams for example by reorganizing. So what we did was we had in the past one department dealing with the system design, system architecture and these kind of things. So we had a software development department dealing with the software development and the test department dealing with the test and we said okay if we want to have cross functional teams we need to put all the teams really together in one department so we reorganize. Then of course we need to train and coach the teams in a proper way so we need to build capability. We said we want to use CRUM as a starting framework because this is from a process point of view very much helping us to learn agility and CRUM comes on the structure side with roles like CRUM master and product owner. This in itself you see all four quadrants are addressed is already a core system that supports each other and therefore this can be successful. It can be even more successful and that was another insight when the leaders are really buying into the things. So how can we get the leaders on board? That's by the way one thing with the agile alliance I see over and over again if the leaders are not on board it will be very hard to make your agile transformation role. So what we said is on the behavior side we become clear about expected leadership behaviors. I mean this is really a leadership team workshop where you are sitting down and you are putting on a power point slide what are my expected behaviors. And then another thing and that was coming out of the reorganization meant that none of the managers that we had before had exactly the same role in the future. So what we said is you know what if that's the case then we can also recruit all the leaders again. So that was for the leaders of course the amygdala was maybe very much triggered in that moment they were very much maybe in the fierce because they saw oh maybe I'm not the manager in the future anymore. Okay what happened actually that at the end 90 to 95 percent of the guys were still leaders but the recruitment process itself was like a very strong impulse to the organization because people needed to apply for a management position and in the application process the interview criteria the criteria for selecting leaders had changed and this process forced them to really understand that so that was a very strong thing. Then we as I said we have retrospectives not only on the scrum level but also for the leaders so they need to retrospect we are inviting scrum masters retrospective facilitators to the leadership teams to help the leaders to reflect on what's happening. The agile manifesto was giving us some insights into wanted behaviors we also wanted to have a better collaboration between development and product management. Typically these are two functions in this huge company and in the past the product managers were complaining to the developers that they never deliver any product project on time and the developers were complaining to the product managers that you're always changing your mind and all the time we are running after changing requirements you need to finally be stable in your requirements. So this conflict was of course not good so we wanted to do this and how we did this was pairing the product owners with the product manager and say you are one team and you need to agree to each other and drive your decisions. Then to facilitate that we introduced this called uncertainty management so this was our way of how to scale things. Scrum of Scrum doesn't work over a few teams if you have 50, 60, 70 teams you need something else and we use this in a nutshell this works like this instead of having one precisely wrong estimate like we will deliver this feature on the 11th of November at 3pm which is a precisely wrong estimate we started saying we will deliver this according to our current best knowledge between September and February and then after every sprint we are doing a bit of a re-estimate and if the range is shrinking this is a leading indicator that things are converging to what we wanted. If the range is shifting or becoming wider it's a leading indicator that this something that requires our attention and that created the conversations between the developers and the product management that were really needed. We introduced the decision model, we introduced new governance and we also introduced something around backlog coordination. This is a giant experiment and usually you should not do such big experiment in one go because the side effects of this can be really huge but our status quo was so different compared to where we wanted to be that this required such a big change. The preparation took about a year to discover all this to have it somewhat discussed with everybody that we wanted to discuss with and then we flipped the switch on the 1st of January 2010 and then things started happening. What emerged? First thing that emerged that there was full leadership support from day one. This was really spot on so our recruitment initiative and so on really yielded the effect. But there was another thing happening, the teams ignore committees. Those of you working in software development know that if you have screwed up a little subroutine and you have to rewrite it it's not a big thing. Refactoring a subroutine is not a big thing but if you messed up your system architecture that is super expensive. There's not so many people who are actually very good in understanding the total system architecture and all the concepts. Therefore we had in the past these committees. Those committees were the guardians or the shepherds of the architecture. The Scrum teams had learned that you're fully empowered, you're a self-contained team who are these committees or ignore them. Everybody can do architecture here as well. That was a moment where we said wait a second this is not going to work because if we mess up our architecture it will be horrible amount of money we need to put in to repair it. Another problem is that we don't have enough architects to supply an architect into each and every of the teams. It's a scarce resource so what's the thing we can do? What we said is first of all architects and committees are absolutely needed and we need to reinforce the role. On the other hand we also saw that the problem of the teams was that it's not good if you're working for six weeks on an architecture proposal then come to the review and the review committee tells you that everything you did in the last six weeks was maybe not so good and now you need to redo things. You need to do like this and that, six weeks wasted and so on. What we said is then from a behaviour point maybe architects and committees need to have more mentoring approach being with the team more frequently and help them to emerge the architecture. Some things may be missing here of course on the capability side it also means then we need to train the committees to do that and we had a number of workshops to accomplish this. So our system responded with this ignorance and to intervene with this unwanted thing we were in at least two to three of the quadrants we were trying to find action because then you have a much more powerful approach to resolving your problem. What happened next? Working software is the only progress indicator that's I think somewhere in the agile manifesto something like this is written and this is a phenomenon I've also seen in a lot of companies all of a sudden oh user manuals are not software so who needs those? This is not good of course so that means that from behaviour point of view we want that people are focusing on everything the customer gets not only code. On the structure side we said okay we need to have higher priority on non-code and that means we need to talk to the product owners so clarifying their role. What happened next? Okay collaboration development product management working very very well so the pairing of the product owner with the product manager letting them the space to take their own decisions in their domain really worked out extremely well but then teams started to diverge there was a discussion what is the better practice and who has the best practice. My agile is more agile than your agile what you just said is not agile so all of a sudden we had this agile religious word that is maybe something you also see in a lot of companies the thing was really that the teams felt empowered and we left to completely open how they want to work but then of course our teams have to integrate their stuff into a bigger solution and if every team has a different opinion how to do this and my approach to testing and continuous integration is better than yours and actually I think we should use this tool and not that tool then you create a big mess so there was a danger that we are sub-optimizing the end to end flow what to do so empowerment with inbound rates first of all that was the moment where we understood this constrained thing okay you are fully empowered and we left you maybe a little bit too much room in the beginning but now we need to narrow it a little bit down because we need to work as a society together to achieve a good result so on the process side we were clarifying which processes and tools are mandatory and which ones are optional and we were we have invited all the organization to join us and have that discussion together with us so it's not so that it's now completely coming from the top in the beginning maybe it still was but we are growing this further and we are building more and more communities so everybody has a say in what we are going to do and how we are going to do it and then we strengthened also the decision model to really have the definition of done a stronger end-to-end perspective what happened next teams want to be closer to the customers so this is by the way an interesting thing we didn't from the first day tell the people you have to be closer to the customers because people need to pull it if they don't want it really it's not good so let's not force them and now it emerges we were super happy about this one wow they want to be closer to customers let's help them let's link the teams into the communication between the product management and the customer and have some early customer interaction that we add to the processes and let's have early demos to the customers very very good what happened next teams are over committed to the customers so they have high stress level ok so the teams now in the customer meetings the customer tells them what they would like to have and until when they need it the teams are saying wow I really want to make you happy you are the customer and yes you will have it on that day so what happens with all people who are sitting in customer meetings they are over committed they are too blue-eyed when it comes to how much effort it will really be to accomplish the thing now in the past they could complain to the nasty stupid product manager how dare he that he sits in front of the customer over committing that much he should have known better now it was themselves they cannot turn around so what they were doing is working days and nights and weekends to make the customer happy which is not good of course but it's a strong learning so what we said is ok on the capability side we still need to do something we need to learn how to make realistic commitments and another thing which we are still working on right now is the topic of expectation management how from a process point of view how can we manage expectations somebody makes a promise to a customer how can we live up to that promise or reshape the promise as we go along and learn so one language is a very powerful tool so one thing that we are discussing is the concept of promise owner so who owns the promise where is the promise for filler if promise owner and promise for filler are not the same person maybe there needs to be a dialogue what structures might we need to facilitate that dialogue and so on that's the kind of thing we are discussing at the moment and the journey continues so results I said higher customer satisfaction market and quality from the first moment 100% of the product releases were on time since the change that was not because we are all of a sudden making everything happen that we said were dreaming of in the beginning but due to this uncertainty management and looking at these ranges all the time we are now able to have instead of the one super big bad surprise at the end of the project usually two months before the deadline we are going to work that's what happened a big bad surprise now we have micro bad surprises every week they are so micro that we can swallow them we know what to do we can talk to our customers and stakeholders so there is not this super giant bad surprise and that means that everybody is much more happy as well but we don't deliver everything that we were dreaming to do before but everything is on time and that was the most important thing because that was the contract our customers that timing is the most important thing 50% less defects found at the customer after the product release we had a lot of quality improvement initiatives that were purely driven by the target setting so we were our pre agile initiatives were always in the lower left corner in the structure corner always just incentivizing better quality and that never healed the wanted result now with the cross functional team agility and everything working together we get 50% less and last but not least we have much better decisions through significantly improved interactions so this collaboration culture has improved a lot so in summary our organizations are complex human systems and maybe you now got a bit more of a glimpse on how that looks and an agile transformation or transformation of any kind is an emergent change of this human system so you need to run system change experiments see what emerges and adapt via the next experiment and this ecosystem tool that I showed you helps you to analyze and identify fit for purpose and that's the important thing fit for purpose system change experiments and interventions thank you time for a couple of questions or do we have any questions yeah measurement that's a good thing measurement often creates behavior that was something we were really aware of in the beginning and that we were rather underdoing it when it comes to measurements of this kind of course being on time time to market quality metrics you have that anyhow things like this a measurement can work relatively simple because one thing you can do is a measurement of observation so if you assemble for example leadership team you can ask them what have you seen what is happening in your organizations and by this one what kind of dialogues do we do you over here in the coffee corners and so on and for me that is as a valid measurement as the hard core measurements that we have when it comes to quality so that's how we were observing this in the beginning also we had a lot of surveys team happiness surveys and so on until the moment that the team started to say guys please not another survey the weekly survey syndrome another question there in this thing that was a 2000 people organization I think it was six countries something like this more than a hundred teams overall so this was really really huge change another here this is it breaks my heart I mean one thing is Ericsson in the Swedish newspapers and one is Ericsson what's happening inside and I have a number of friends at Spotify for example they are part of the agile alliance group as well and when they hear what we are doing they were actually like wow this is cool so Ericsson is not only a conservative company we are doing a lot of these kind of things as well but will the company survive the big changes that you are in let's see what emerges out of the change initiatives that we have taken this is a serious situation for the company but I'm confident that we still have a very good chance to survive I mean this started in 2008 so we are now eight years into the transformation I would say that the Ericsson R&D is very much agile and we are moving beyond that like this system thinking is a big topic that we are trying to get the proper more proper grip on and so on and it's a bit like you know this Shu Hari kind of scheme where the Shu step is you are learning a practice by just executing the practice together with a coach and in the Ha step you are starting to internalize and start to build on that practice and start modifying it and that's what we can see in Ericsson also with Scrum we started with Scrum according to the book and after people really understood the idea of Scrum not the process the idea the mindset behind it they started modifying things and the same thing happened with uncertainty management for example so you can see how or retrospectives sometimes in the meantime a retrospective is not something yet that we have to call for it's something that just happens on the corridor and that's the kind of things you see how things are evolving further another question here this model has been presented now to a lot of it's part of also a training program that we run in Ericsson and some teams are using it in their retrospectives it has been used to make sense of employee feedback surveys and so on so it's just a tool you can use it or not use it it's optional but those who use it find better answers to the thing we need to stop there because we will soon have another presentation here at 10 past 11 about handling uncertainty in decision making processes so you can stay here listen to Donna Jones or you can go to Saga if you would like to do that okay thank you so much