Agile Transformation at Ericsson

Applying complex systems thinking, growing the agile mindset through storytelling, and visualizing the interplay; these are some of the things that drove the agile transformation at Ericsson. Having a leadership team that fully embraced agility, an independent group of agile coaches, and doing frequent retrospectives in the leadership team ensured that the transformation stayed on track.

Hendrik Esser, manager special projects at Ericsson, will talk about agile transformation experiences at Ericsson at Agile Summit Greece 2018. This conference will be held September 20 - 21 in Athens, Greece:

Addressing developers, team leaders, managers and executives, Agile Greece Summit brings together top class agile speakers and participants from around the world.

The conference theme is "Build great teams that can change the world". InfoQ will be covering this event with summaries, articles, and Q&As.

InfoQ interviewed Esser about how the agile transformation started, how complex systems thinking and practical storytelling were used to drive it, what worked and didn’t work in the transformation, practical techniques to make change happen, how agile impacts the way that managers deal with uncertainty, how they ensured that the agile transformation stayed on track, and his advice for agile coaches and for executives.

InfoQ: Can you elaborate on why there was a need to adopt agile, and how the agile transformation started at Ericsson?

Hendrik Esser: In the 1980s and 90s we saw a strong growth driven by globalization. To handle that growth we needed to learn how to satisfy many customers around the globe using many people in SW and HW development. Intranet and internet didn’t exist. So we put our best knowledge about how to build products into documents, printed them and shipped them to our product development sites. Really state-of-the-art at that time!

End of the 90s and in the 2000s we saw two things: internal communication and collaboration became easy and fast using our intranet, plus globalization coming to an end as the market for our products had reached the whole globe. Our written-down processes couldn’t cope with the spreading and digesting of new knowledge, and the dynamics created by the saturated market. The saturation means: the global market becomes "narrow", competition increases and that leads to the need for stronger customer focus again.

So in the early 2000s we started to use XP. Agile was not seen as an option for quite some time, as we couldn’t see how that approach could be scaled to a company of our size (I was at that time member of a leadership team for a 2000-people organization, that was distributed over seven sites internationally). However, in 2008 we started a new initiative to solve the biggest problems we had at that time. Those were Time to Market, Quality and Return on Investment. We invited the whole organization to participate. Some people tried out Scrum and found it to be very helpful. That triggered a series of workshops about how we could scale the ideas of agility and finally led to a strategy how to drive our large scale agile adoption.

InfoQ: In your talk you will explore how complex systems thinking and practical storytelling is used to drive the transformation. Can you elaborate?

Esser: Our agile transformation was pretty successful for an organization of our size. About 1 ½ years after we kicked it off, I was starting to wonder why we were successful and why some parts of our company were more successful than others. Joining the Agile Alliance‘s Supporting Agile Adoption initiative, I met Diana Larsen, Jutta Eckstein and later also Dave Snowden at a number of workshops and conferences, and I learned that a company/organization is a complex dynamic system of human beings. That means, that an agile transformation is a change of that organizational and human system and needs to be approached accordingly. It means, that any change you do will have side-effects. So you need to run change experiments, be ready to see and absorb what is emerging from the organization and adapt accordingly.

One important part of this is the "culture" we desire to have in the company. How do you convey culture? A not so good way is to try to convey culture via processes or policies. They are part of it, but they don’t really convey it. They don’t go to people’s hearts. We can see this in many companies with failed agile adoptions: "Agile is mindset" and if you can’t grow that mindset, you will not succeed, but just get stuck in changing processes. One way to grow the mindset is via experienced agile coaches, who act as masters, who guide the people. Another way to transport culture is via narratives, i.e. the stories we tell. These are the stories we hear in the corridors and at the coffee-corners. So one good change tool is to amplify the small emerging examples where a desired culture shows up, by conveying the stories of these examples. These stories should be not pure descriptions of "what happened and what did we do", but rather personal stories, that people can empathize with.

Here is an example story: In the beginning there was a big debate about "we are ready when we are ready". We used the narrative of "when a passenger misses the train he takes the next train". But we were struggling with this until our financial controller (!) said in a meeting: "Yes, but there is a difference between a metro and a commuter train: when I am going to the metro and I am about to miss it I know the next one will come in 5 minutes. But when I go to the commuter train and know the next one is only going in ½ hour, I start running!" That little narrative really helped to amplify the thinking that it very much depends on your release frequency.

Another example: Our change strategy was to have a transition period of about one year: we would finish our currently running projects in the old way and - as people get out of those projects - give them a thorough agile training and let them start working on the new projects, that were run in the agile way. About six months into that transition period, some teams that were working on the old projects started to say: "Hey! Our colleagues working in the agile projects look much more happy! Can’t we get our agile training earlier?" A great story, which we amplified by re-telling it and using it as a reason to let them have the trainings earlier. It gave the whole transition more momentum and increased motivation.

InfoQ: Can you give examples of what worked and didn’t work in the transformation, and what you learned?

Esser: A thing that worked really well was how we approached the change: first training the leadership team, then run a "train the trainers - coach the coaches" camp for the people who were going to be the coaches. And then let these coaches be part of the local transition teams together with the managers to run trainings, coach the leaders and teams and discuss how to solve all the million day-to-day issues arising. The learning here is, that it starts with the leaders and you need well-educated and skillful coaches to make the transformation successful.

One thing that didn’t work out so well, was when we built cross-functional teams and tried to have nothing else. In the past we had a technology department with the technical experts and solution architects, a development department with the SW developers, a test department with the testers. We merged all of these organizations into one and made all teams truly cross-functional. We saw a very huge benefit of this. But then, about one year into the journey, we saw that innovation was going down and that our technical "mid- to long-range radar" was getting weaker. Who can take the future-looking technology discussions with customers? That was previously done by the technology department. Now we saw that the technology people were absorbed by the (more short-term focused) development teams.

So we learned that the work with these different time perspectives is hard to do in parallel/multitasking by the same people: for a cross-functional development team that is implementing a feature, a request to discuss something completely different about a future potential with a customer is perceived as a disturbance. And disturbances interrupt the flow. Our solution was to rebuild a technology department again - just much, much smaller than the one we had before - and purely focus on dynamic and mid- to long-range technology discussions. That introduces a handover, but reduces disturbance to the teams. For us, overall a positive "business case".

InfoQ: What practical techniques have you used to make change happen?

Esser: I think a good example is the way we changed our approach to planning. Right at the beginning of our agile transformation we re-organized, and my task was to build an organization called "Portfolio Management", which is a very light-weight agile "project/program office", if you will. Part of that was to transform the way we plan and forecast. Early we understood that estimates shouldn’t be (mis-)used any more as a "commitment", but as an expression of uncertainty and risk. And it should be owned by the team. The method we introduced was "uncertainty ranges", instead of one "precisely wrong" estimate like "we will deliver this on the 12th of October 10:30 am", we started saying "According to our current best knowledge we will deliver this between August and November". We would get a re-estimate after every sprint (continuous learning) and collect these new ranges from the teams to be able to compile an overall picture, that we can discuss with our business management. My organization was in charge of collecting the ranges from the teams.

As simple as it sounds, shifting from using single value estimates towards using ranges really changed the way people discussed. When you give just one value, people tend to take that as a commitment. When you give a range, people start asking questions. And that dialogue leads to a deeper common understanding of the situation, risks and uncertainties. Using ranges is mostly creating a change in the way we communicate and think.

Another example: when an organization has problems, we often look at the processes and we try to improve flow by tuning the process. In a dynamic business environment and a larger organization, that often doesn’t result in the wanted change in outcome. That is because in my experience usually the process is not the problem. Tell me a problem and I can find a good process to solve the problem. The issue is often in the interplay between people. So, a better way to visualize is to show the interplay instead of the process. A good practice I found here is as follows: draw a little customer on a whiteboard. Then give the pen to the people in the room and ask: with whom does the customer talk? People will draw the next person and make a line between the customer and that person. And then you "follow the rabbit into the hole": which person is that person talking to? And so on… In the end you can see who talks to whom to satisfy the customer need. Often, in large organizations, these pictures look very messy with lots and lots of roles, people who need to talk to or get approval from other people etc. That picture turns the discussion towards: how can we simplify this and improve flow and agility? And – voila! – you start to think differently.

InfoQ: How does agile impact the way that managers deal with uncertainty?

Esser: I would distinguish between (middle) managers and executives. In my experience executives are already confronted with a lot of uncertainty, ambiguity and dynamics. In most cases they got to their leadership position because they have proven to have a talent for navigating in such an environment. The issue is that not all people are the same, so there are people who are not used to dynamic environments, and some who even do not like to work in one. That’s neither bad nor good, it just is what it is. In all the turbulence, many executives like to work with people who can execute on strategies - or at least give you that feeling. What happens in reality very often is that there is a middle management that tries its best to create certainty by executing strategies and handling all the mess that is emerging through the dynamic environment. Upwards in the hierarchy and outside towards the customers people want to be perceived as reliable and trustworthy partners. In that dilemma, a tendency emerges to fake certainty and confidence in order to enhance the trust and confidence of customers and executives. Emotionally that can be very difficult to handle, as it causes a lot of stress.

When you adopt an agile mindset this stress goes down significantly; instead of playing the "game" described above, people together bite the bullet, and recognize total certainty is an illusion. So instead of giving each other the false feeling of control, people join forces to handle the uncertainty together. So the most important thing for executives and managers to do is to stop playing the "illusion of control game" and start creating an environment where it is safe to voice uncertainty and then constructively discuss how to deal with that. The funny thing here is, that that makes you much more trustworthy as you have a much more open atmosphere. And you arrive at better decisions as more perspectives and insights are shared.

InfoQ: How did you ensure that the agile transformation stayed on track?

Esser: Keeping a transformation on track is not an easy thing. There are many forces affecting the system that you are trying to change and will never be in control of. You can maybe control a few, in the best case, but even then there will be unexpected side-effects you will need to take care of.

From the agile transformation I was part of, I think there are three key factors that helped to keep it on track.

First, we had a leadership team on top of the organization that was fully embracing agility and thus driving agility all across the organization. These leaders are able to amplify agile narratives and practices and dampen the effects of non-agile influences. Our leadership team had an intensive agile training before the people in the organization ("let’s always be ½ step ahead in the leadership team").

The second important part was a self-organized, independent group of well-educated agile coaches, who were supporting the agile transformation within the local organizations.

And the third important part was frequent retrospectives in the leadership team, where we were sharing and absorbing what is emerging across the organization. That enabled us to decide on correcting measures/experiments if something started to go in the wrong direction.

InfoQ: What’s your advice for agile coaches and for executives?

Esser: I think a lot of agile coaches are idealists in a very positive sense, embracing the idea of servant leadership towards the teams they coach. But I have seen organizations where managers didn’t see the value-add of the agile coaches, because the main thing that was visible was their process facilitation, and they couldn’t answer the manager’s question of, "what have you achieved?" or "what is your value-add?" So my advice for agile coaches is, to not just be idealists in the service of your team, but also promote the outcome of your efforts. A good way to do that is to not only work towards the teams, but also towards management and the greater organization. (E.g. making management aware of thinking patterns.)

Agile is a mindset, and in our communities we often talk about cultural change. We discuss this with the leaders around us and somehow everybody agrees. But often, nothing really changes. That is because it is very difficult to make it tangible. In my experience, a better approach to this is to frame it as a "change in the way we think". A trick a magician performs on stage looks like a miracle to the audience. Generally, things can look like miracle until you are able to think differently. And often that is achieved by changing your perspective. So, to influence people and especially leaders, we need to offer new perspectives. I usually use two tools for that: different visualizations and a different "language", i.e. use different words.

My advice towards executives is: you can’t delegate that transformation. You need to be the change you want to see. As described before, an important leadership aspect is creating a safe environment where people are able to speak up without having to fear negative consequences. You want people to share their uncertainties and ideas and build on them. Getting there is hard work: you need to learn about agility, get it into your heart and really strengthen that part of your personality that is able to deal constructively with dynamics, uncertainty and surprises. It is a very rewarding journey, but you constantly need to reflect upon yourself; how you think and how you behave, and you need to have the maturity to challenge and change your own thinking and behavior, although that might sometimes feel counter-intuitive for you when you try it first ("That’s not what managers are expected to do!"). A good coach can help you with that journey.

And then a very practical thing: run organizational system retrospectives in your leadership team and take time for these. In the beginning of our transformation we spent more than 50% of our leadership team meetings on organizational system retrospection.

These were very important as we could discuss how we as leaders want to respond to what emerges out of the organization. An example is the difficult balance between empowering people, letting them make their own mistakes from which they can learn, and when the time has come to jump in. Having a sounding board with your colleagues, and hearing how everybody was struggling with that balance was very helpful.

Another example was the issue we found around innovation that I talked about before. We found that in one of the retrospectives, and started discussing what was going on. And that led to the re-establishment of a small technology unit.

About the Interviewee

Hendrik Esser works as manager special projects at Ericsson. He has more than 20 years of leadership experience in product development, leading small (20 people) to very large (>7000 people) organizations. He is one of the drivers of Ericsson’s enterprise transition, works as voluntary program director for the Agile Alliance’s Supporting Agile Adoption initiative and is a frequent speaker at international conferences and company events.