Why And How Volvo Embraces Agile At Scale

“Across the world, automotive leaders are fighting to gain an advantage in the implementation of new technologies, such as autonomous driving, vehicle connectivity, electrification, and shared mobility.”

Heike Freund et al, McKinsey & Company

As cars steadily become “computers on wheels”, Agile management is spreading from software development to the whole firm. Last year, I wrote about Toyota here. Earlier this month, I interviewed Anna Sandberg, who is Head of Continuous Improvement & Change at Product Creation, Volvo Cars in Gotherburg, Sweden. Volvo Cars has around 40,000 employees and produces around 700,000 cars per year.

I began by asking Anna about her role in the Agile journey at Volvo Cars.

Anna Sandberg: My arrival at Volvo Cars in September 2017 coincided with a decision by Volvo top management to embrace Agile development in software. Initially, my job was to lead the implementation of Agile in the software community. But after six months, my assignment expanded to cover the whole product range, both hardware and software.

Volvo understood that cars were becoming “computers on wheels”. We needed methods that were suitable to that purpose. We had been trying to develop the physical car and then add the software later. We saw that to build these “computers on wheels,” we needed to develop the software and hardware at the same time in an integrated fashion. Initially it was hard to get people to understand this shift. Even today, we need to keep reminding ourselves of this necessity.

Like many companies, Volvo Cars had for some years had a bottom-up Agile movement. There were individuals and software teams that had been attracted to Agile for many years. But Volvo Cars hadn’t managed to scale those efforts. A couple of initiatives had been started, including training in Scrum. But the activity was scattered and it wasn’t happening in a coordinated fashion at scale.

Agile At Ericsson And In Academia

SD: You had come to Volvo Cars from the Swedish networking and telecommunications firm: Ericsson. How do the experiences compare?

AS: My experience with Agile at Ericsson began around 2005 when we realized that we had to develop software quite differently from the traditional waterfall way of working with big plans and specifications. That simply didn’t work in software development. So, we began to implement the basics of Agile. At that time, there weren’t any formalized frameworks for Agile at scale, such as the Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS). So Ericsson invented its own scaled framework with all the cumbersomeness that that meant.

I was part of several Agile transformations within Ericsson. In the process, I learned how to lead change, any kind of change actually. In Ericsson, the change was in an Agile context where most of the problems were dependent on software.

In 2006, I also finalized my industrial doctoral thesis entitled “Making Software Process Improvements Happen” with my professor Lars Mathiassen who helped me reflect, analyze, and understand how change happens. The main conclusion was that we need a lot of different tactics to make change happen in practice. It is not enough to know theory if we can’t make it happen in practice. Over the years, I have continued to research and understand more tactics to make change happen. In 2013, I became an associate professor on the same topic. I am constantly learning new tactics.

Agile management has been implemented over the last 15 years in the software development world. I don’t know anything better than Agile. I don’t hear anything better than Agile. I don’t see anything better than Agile coming along in future. I believe that Agile is likely to be the way forward. I am of course constantly looking into what is new but the practical question for now is: how do we combine thinking around Agile and Lean with value flows and do this in the best way?

In Ericsson, Agile happened slowly over a longer period. If I compare that experience with automotive at Volvo Cars, we are implementing the transformation much faster and on a larger scale. In part, that’s because we aren’t the first ones to go Agile. We are fairly early in implementing Agile as compared to some other big automotive firms, but not compared with the world at large.

The Scene At Volvo Cars In September 2017

SD: What did you find when you arrived at Volvo Cars in 2017?

AS: Top management at Volvo Cars saw that they had to do something about scaling Agile. They had been looking into the different methods. They had made decision to go for SAFe in early 2017.

We recognized that we couldn’t develop something new for each product, for each project, for each model of car. We needed to be able to develop things that could be utilized for many new models. We saw that we needed to organize ourselves into what we called “product streams.” That’s why we started an initiative that we called “Agile Product Streams”.

SD: How far was the top management involved?

AS: We had strong top management commitment to and involvement in the transformation. At the outset, the lead champion was the Chief Technology Officer (CTO), one of the top managers in the Executive Management Team (EMT). There were frequent discussions and collaboration with all the CTO’s leadership team.

The Goal Of The Agile Transformation

SD: What was the objective of the Agile transformation?

AS: At the start, we talked about speed and responsiveness. We knew that things were going too slowly compared to changes in the automotive world. The automotive industry is currently going through a significant transformation that is being driven by changing consumer behaviors, technology shifts and digitization. Furthermore, there was also a concern about quality. In one of the platforms, the quality was at a level that we had never seen before. To handle this situation, we saw that we would have to do things differently. We knew we had to implement more modern management methods to handle the future development of our cars.

Volvo Cars Agile Framework

We have made a lot of progress. We have used the thinking of the Rogers Technology Curve in a very methodical and systematic way.

With everything we wanted to do, we tried to highlight the ones doing well somewhere (early majority). And everything we learned, we stored in our organizational memory, which was known as the Volvo Cars Agile Framework. It was really an evolution of SAFe, adapted for the automotive sector. This became then the base for the others when they started to implement and practice.

In that framework, we describe how we organize ourselves and the new roles, including the classic SAFe roles, Scrum Product Owners, Product Managers, Solution Managers, and so on. And of course, we identified a number of roles that we need to help us with procurement, manufacturing, and engineering in the automotive business.

Implementation Challenges

SD: Were there friction points?

AS: Of course, there was friction quite often. Change is difficult in part because of the many cross-dependencies between things. So, when someone realized that there was a need to use new way to do something and tried to change, they would find that their colleague on whose work they were to some extent dependent wasn’t necessarily ready to change at that time.

But in general, there was also satisfaction for those involved because people were able to take responsibility for the bigger picture of everything.

We decided to implement what we call the Program Increment Planning (PI) with a common cadence at weeks #10, #22, #37 and #49. We had everyone follow the same cadence. Today we have more than 70 different units and they all do planning at the same time in weeks #10, #22, #37 and #49.

Of course, in every planning review, we learn new things. We discuss the learnings and get all kinds of feedback. And we have to deal with the kinds of frictions that always accompany change.

One of the hardest parts concerns the managers, and the shift from not having one manager responsible for everything, but rather sharing that responsibility among several different roles, such as Scrum Master and Product Owner. In the end, they discover advantages from splitting the work because they can spend more time on strategic work.

The Evolution Of SAFe In Volvo Cars

SD: You are using an evolution of SAFe?

AS: The management team in software had decided, “Let’s go with SAFe,” after careful investigation of the available frameworks. An important point of this transition was that we educated people with intensive training. We spent more than 150,000 manhours in training people in different aspects of Agile. We also trained around 2,000 leaders in SAFe so that they would understand what is SAFe and how it works. We wanted people understanding both the mechanics and the mindshift changes involved in Agile. We had leaders discuss and practice the new types of behaviors and then understand the results of those behaviors.

The challenge is to release the potential of the teams. We saw early that the teams needed to be empowered and accountable. How can managers do that when they have been trained all their lives to command-and-control? There was a lot of learning in implementing new roles. It meant being patient with each other as we practiced. We will continue to practice for many years to come.

SD: Some firms and writers are critical of SAFe, suggesting that it has a top-down command-and-control spirit within it, which makes it difficult to implement with an Agile mindset. You are indicating that SAFe has been quite a positive experience for Volvo Cars?

AS: I have seen how difficult it is to implement Agile at scale when you don’t have an agreed approach to scaling. We need to realize that doing Agile at scale requires a lot of systematic thinking and discipline. It means we have to protect the principles around how we behave as leaders. If we do that right, then SAFe can help us. If we don’t do that, then any method will be cumbersome for us.

To be honest, I don’t know how to do Agile at scale without some kind of framework and hierarchy that helps us to decide and prioritize. So long as we do it an open and transparent manner, in a trusting collaborative environment, in which everyone is allowed to bring up problems, and give input, and where we can identify dependencies and see whether actions and resources match with commitments, and so on.

The bigger problem today is now that when we open everything up, we see that there are dependencies everywhere, and this appears cumbersome to everyone. Yet, in the past, the problems of dependencies were there but they were hidden and the issues sometimes would emerge very late when someone was test-driving the car somewhere in the world. And that can be very expensive.

Now we identify problems in the planning process before we start development. It’s cumbersome for people to sort out these dependencies in the planning processes. But on the other hand, the process eventually saves us a lot of money and we gain a lot of speed and of course improved quality for our customers.

‘Big Room’ Planning Meetings

SD: So you have these big room planning meetings every quarter?

AS: This is what we call our Program Increment Planning. We have around 70 to 80 big room events at the same time. They are all in different landscapes, following a two-day procedure. When you have done it five or six times, you get better at it and can do it faster.

For two days, we follow a pretty intense agenda. In some cases, not everyone has the necessary data to resolve their dependencies. So we often have a lot of people running around in an effort to understand the way forward. But the end result is that we have a viable and committed plan for the upcoming 12 weeks.

SD: Critics of SAFe sometimes suggest that slicing the year up into four quarters implies predictability that doesn’t match reality in software. In fact, you keep discovering things as the work goes forward. So thinking you can plan ahead for a quarter is illusory. What is your experience?

AS: It’s true that things can never be exactly planned for a certain end-date. But a quarterly process is as good as anything else. That’s because we need to see and to prioritize a large number of items in order to see what we are actually going to do.

And then, of course, it’s not the only planning process. There are other processes where we plan in less detail for longer periods. We are still working on exactly how to do this, so as to have the right amount of innovation and improvements. We have not yet fully figured this out.

Agile In The Automotive Industry

SD: The automotive industry is striking for having strict calendar cycles. The next model will be delivered at a certain date, come what may. It is decided. It is fixed. It will happen then. “The new model must come out exactly two and a half years from now, that is to say, May 5, 2022.” How prominent is that thinking in Volvo Cars?

AS: This is true of all the automotive firms. The reason is that we have to plan production starts. We have to order everything that we will need so that we are ready for the start of production. All the materials have to be in place at the right time. We have to pre-order a long way in advance even as we try to do this as late as possible. Otherwise we risk running into massive problems with supply flows.

Consumers don’t want to spend a lot of time selecting the features they want and then wait ten months to get the car. They want to be sure they get all the good stuff in the car at the outset.

So we need to rethink what we do and how we do it and how we plan our work. This is ongoing in the car industry all around the world. In the car industry, there is a tradition of having to have everything locked down a year in advance. But in the future cars, when software is totally dominating, you know it will be out-of-date when it is delivered if development takes too long

Thus when we were developing the speech functions in the car, we found that we had installed functions that people didn’t use as expected. That was partly embarrassing and partly very educational for us. We saw that we had to change our development approach.

We also have to be collaborating with our partners. We can’t do everything ourselves. We collaborate with Google for instance. But we are also steadily doing more software in-house. We are more selective about which matters are strategic that we want to keep in-house. Of course, the software code is part of a much bigger system. So our partners also have to be part of the overall system.

The Status Of Agile At Volvo Cars

SD: So overall, what’s the status of the Agile journey at Volvo Cars?

AS: We officially ended the basic Agile transformation phase in December 2019, after two and a half years of Agile transformation work. But the Agile journey continues. We now say that we are entering the phase of “continuous improvement.” We will optimize and improve the system continuously. We will build up a system as we build up the teams, identifying impediments and seeing how to fix them, or escalate them so that they get fixed at the next level.

We are putting more emphasis on Lean thinking, with continuous improvement and flow. We value flow mapping. We are continuing to evolve the SAFe system. We expect to be exploring all aspects of Agile in more detail. We will be much more data-driven. We will have more performance dialogues on where we are going and discerning trends. We understand that we have lots of challenges in front of us to optimize the system that we now have in place.

SD: Is “Agile” a good word today in Volvo Cars?

AS: My take is that “Agile” has changed from being a bad word to a word that is accepted to explain what we are doing. It’s not controversial anymore. That’s where the journey has taken us. But we still have people who have not understood, or who hesitate, or who ask questions. But the majority have accepted the change and are trying to figure out the practical implications for themselves: “How do I act in the best way in this mode of operation and then make the change?”

We are now in a phase where we see problems, that is, opportunities for improvement, all over the place. We have come to realize that these problems are not the result of Agile. It is Agile that has enabled us to see all those problems as opportunities for improvement so that we can start acting to take advantage of them. That is our challenge.

Overall, we see ourselves as having just completed the basic steps in our Agile transformation journey. We are now pursuing continuous improvement. We are on a journey and we know the journey must continue. We like to say that we have made enough progress on Agile to understand the ways in which we are not yet Agile

And read also:

Agile Thinking At Toyota

The 12 Stages Of The Agile Transformation Journey