Host Intro (Gene Kim)

The first presentation of the day is from the amazing team at BMW. Ralf Waltram used to be the VP of IT for R&D, but he has recently taken over VP of IT for production. So he is no longer responsible for the seven-year design process. He is now responsible for almost every aspect that enables the production of millions of cars per year.

He will be co-presenting with Dr. Frank Ramsak, head of architecture and IT governance. Over the last three years, they have been on this tireless journey to modernize the ways of working across all of BMW.

I met them last year at DevOps Enterprise London, and when they told me about what they have been able to achieve, I knew immediately that this was a talk that needed to be presented here. I think the quote that best sets the stage for what they have done is this: "This work that we are doing is responsible for the biggest change to how BMW does business in the last 20 years." With that, Team BMW.

---

Opening Video

The future of driving. Nothing to be afraid of. Because we are working on safer cars for a safer tomorrow, with large-scale data-driven development, at the BMW Autonomous Driving Campus.

---

Ralf Waltram

Thank you. Good morning, everybody. We both are so excited being here at the third and final day of this great DevOps Enterprise Summit here in Las Vegas. And we are so glad to share with you our story about getting DevOps, BizDevOps, and our journey to 100% agile. And as most of you know, DevOps can be also very spooky sometimes, but it is definitely nothing to be afraid of.

My name is Ralf, and as Gene mentioned, I am responsible with my team for IT DevOps in the area of logistics and production, and I am together here with Frank.

---

Dr. Frank Ramsak

Good morning also from my side. I am Frank. I am head of architecture, innovation, and technology within IT governance. What we want to share with you is, I think, really one of the greatest opportunities that I had over my career in BMW: to drive this transformation we want to share with you.

To start this, we set some context. We hope that you are aware of the BMW brand: the ultimate driving machine, or sheer driving pleasure. We are the world's leading premium car manufacturer and provider of premium mobility services. We have 135,000 employees worldwide. Last year, we sold short of 2.5 million vehicles. In the times of electrification, I think it is important to note that by the end of this year we will have 500,000 electrified cars, either fully electrified like the i3 or one of our many plug-in hybrids, on the streets. With this, we are also leading in the automotive industry.

What is probably not that familiar to you is that we already have more than 12 million connected cars out there, because we were the first automotive manufacturer shipping SIM cards per standard, and this gave us a good chance to really provide connected services to our customers.

When we are talking about the automotive industry and you talk about IT, you always have two sides. The one thing is the IT within the product and around the product: for example, the control units for the engines, entertainment, navigation systems, up to the backends for connected services. This is what is in the realm of our development division, and we call it Connected Company.

Ralf and I are from corporate IT, the group IT, and we are responsible for all the processes from the early phase of research, development, purchasing, production, sales, and after-sales. We also have a regulated area with BMW Bank. Supporting all these processes is the responsibility of BMW Group IT. We are 5,500 employees worldwide. Headquarters are in Munich, but at all major plant sites and national sales companies we have locations there, so we have a global footprint.

We are, I would say, a grown-up startup. We have a landscape of almost 5,000 active applications. We have 30,000 servers, 100 petabytes of data, almost doubling every one and a half years. As the head of architecture, I can tell you this is an asset and sometimes it is a burden, because we have all technologies over the last 40 years in use somewhere. The only thing I can guarantee you is that we do not use punch cards anymore, so that is a good thing.

This sets the scene. But when we want to talk about our journey, I think it is important to understand the starting point. Let us do a time warp back to before 2016. You have to understand that BMW by heart is a project-driven company. All the great products you see in the streets are the results of projects. There is a holy milestone in our company called start of production, SOP. As a consequence, all our corporate IT was also project-driven, and we had a very sophisticated ISO-certified process model, project-oriented. As Taylorism is big in the automotive industry, we had 40-plus roles, most of them ending with manager, because internally we did not do the real work; we just managed externals to do the real work.

Waterfall was dominant. Project-driven. Even though we did some very good experiences applying agile methods to our projects, mostly it was waterfall, with all the issues I think you are familiar with. Our heroes were the project leads, always fighting the never-ending war about solving the magic triangle: content, time, and budget. In times of uncertainty and volatility in user requirements, this became challenging.

Our release weekends turned from fun to drama, because they sometimes started already on Wednesday to be finished by Monday morning with our major twice-a-year SAP releases. Last but not least, governance: good old direct and control, throwing out regulations that hardly anybody read and even fewer adhered to.

The question was, Ralf, in such circumstances, how can we really challenge the challenges of the automotive industry: autonomous driving, connectivity, electrification, shared?

---

Ralf Waltram

Definitely in 2016, a small group decided we had to change something. With digitalization, with autonomous driving, with all the new technology coming up to the market, we saw that we had to tackle three things: being in IT more flexible, bringing more speed to the IT products and to the business, and putting the focus again to the customer. With customer I mean the internal customer, the real users, and our external customers.

In 2016, we had been a bi-modal IT, a two-speed IT. We had waterfall and agile. We had 80% teams working in a waterfall world and 20% working already in an agile way. They had a lot of fun, but they were blocked by the waterfall people. Two releases, like Frank mentioned before, per year, and agile teams could release much faster.

So we said we needed to change something. We wanted to go away from bi-modal IT to our answer: 100% agile. We know it is a vision. At that time, it was clearly a vision. We said we were starting a journey, and we would not reach it over a weekend. It is not that you buy a book about agile or Scrum, give it to a team, read it over the weekend, and on Monday everybody is 100% agile. No. We started a big transformation process.

We tackled it in four dimensions. First, clearly finding out what is the right agile process we are using at BMW. But the process, the methodology, is not all in a 100% agile world. It is more. It is the structure, how you work. That is why we decided to reorganize and bring dev and ops people together at the lowest possibility: the feature team. Also, and we cover this later, we decided to go away from projects to a clear IT product portfolio.

Third, you need the right technology. You have to use the right technology to become 100% agile, which means we strive more, with the help of Frank's team in architecture, for microservices but also cloud-enabled technologies. Last but not least, a very important point for me is that we have to change the culture, because the culture in an agile world is totally different from a waterfall world. In agile, we focus more on openness and transparency with the daily Scrum events and the artifacts you all know in agile.

That is the way we started our transformation, and I can say to you, it is not always a straight path. I like this quote: if the path before you is clear, you are probably on someone else's. You should really see what is the next step, where you have to put a bit more pressure on it, or where you have to really think about what is next. We will tell you four milestones from our journey so far. We are now three years on our journey, and we will cover BizDevOps product portfolio, the agile working model, back to code, and user experience. Frank, can you start with BizDevOps product portfolio?

---

Dr. Frank Ramsak

This is an awkward term: BizDevOps product portfolio. What is it? Well, this disguises the greatest change that we experienced in BMW Group IT over the last 30 years, because it is effectively the end of projects.

Telling you before that BMW by heart is a project-driven company, we probably do not have to lecture you why product is the right way to go. But to tell our stakeholders, to tell our management, to tell our people that it is good to let loose of project, this was one of the hard things to cover. Of course, we had to tell our business it is not worth having the contract game at the beginning of each project, fighting for the best position about content, time, and budget all the time. This is not a common ground to solve the problems.

Even the boundaries, the wall of confusion within IT, between dev and operations: it is so ridiculous that at the point where the project really becomes effective, when you have the results, when the users first can really benefit from the results of your project, you are handing over responsibility to somebody else. How could you ever implement a fruitful inspect-and-adapt cycle if you are changing responsibilities? How should this work? This was our utmost belief, that really in our BMW culture, we had to change from projects to products. And we did this.

What we did is basically bringing the business and the development and operation teams into one end-to-end responsibility for a product: for the creation, for the maintenance, and for the operation of a product. What is a product for us? We started with the value streams of the company, for example production. Then we used good old enterprise architecture techniques like business capabilities to define the realm. We have a logistics domain, to stay in the realm of production. Within this logistics domain, we have then a product, for example, for in-house logistics or for yard management. This covers all the IT, all the applications that need to be there so that this business capability is fulfilled. This is the end-to-end responsibility of this cross-functional BizDevOps product team.

We started this two and a half years ago. We now have a product portfolio out of 10 value streams, 50 domains, 270 products covering the whole space, as I mentioned before, from the early phase of research up to BMW Bank, captured in this one product portfolio. This is effective from the 1st of January of this year. We really stopped doing projects with the start of 2019.

You have to change everything in IT. You have to change the way you finance, the way you allocate resources to it. This was the hard work to do so. But you get this end-to-end responsibility, and this is so important. Even more, you get potential because for the first time you have a chance to get what we call a clear 360-degree view on what is going on in IT. Beforehand, you measured IT projects, you had operation KPIs, maintenance KPIs. How could you ever tell if you have all the resources to mitigate a certain risk? Some was done in projects, some is in maintenance. Now, linking everything within our IT to a product -- finance, headcounts, operational KPI, security, risk, technical debt -- you have all the numbers now to really make a decision on where to spend your resources, where it is best for the business.

This is how we changed the structure. We really went to products. But the question is now how do we work in this new structure, Ralf?

---

Ralf Waltram

That is a good point. When we started, we decided how is the way we want to work in an agile area. We defined it in three layers. First, and the very important point, is the feature team level. There we focused on using agile bandwidth. We did not decide to work in one model for the whole IT. We are using the complete bandwidth. It is fine that a product starts with Kanban, and if it is mature it goes to Scrum, and even higher to a scaled framework.

The second level is the product level. Here we want to use synergies between the products, from the principles, from the methodologies, from the processes, and how they are using the agile tool chain. Cross-product, between the domains, between the value streams Frank mentioned, we try as much decoupling as possible, and if we need, we use lean synchronization between these value streams.

We put focus on having one common structure and one common language. Every team speaks the same. But it is not a textbook. It is really a living framework where the agile masters contribute every week in every cycle. They get good things in, bad things out. So we share the good and bad practices.

As a manufacturer of cars, we are ISO certified, so it is very important that our framework is compliant, and we try to build it into our framework. Our framework should be right away compliant. We support this by an agile tool chain. One thing is giving the teams a working model, but also assisting them with the right tool chain. This is really a success story. We started two and a half years ago with establishing an agile tool chain, with Jira, Confluence, and the CI/CD pipelines. We focused on making a great offer, a great experience to the teams. We started with 100 in the first month. After one month, we had already 8,000 users on the agile tool chain. Now, two and a half years later, we have 70,000 users on our agile tool chain. Not only IT guys: because we are doing BizDevOps, business colleagues are also using our ATC very heavily, and I am really proud about this success story.

But one big thing is: if you have an agile working model, what is it about the skills you need for being agile?

---

Dr. Frank Ramsak

This is really a huge challenge. As I mentioned before, we were good in steering in 2016, and I think steering in agile is not really much good. In agile, it is about getting things done, not about steering. What we learned is that we have to increase our internal software engineering rate. We were starting below 30%. It is not our goal to match the digital champions. More than 80% internal software engineering is probably not feasible for us and probably does not make sense. But what we are aiming for is to achieve about 50% to 60% internal software engineering.

How do we get from the starting point here? We basically started with two initiatives. The first one is back to code. We encourage our people to lay MS Project aside and go back to coding. We gave them training methods. We gave them software engineering principles. For example, we have a back-to-code campus that is a three-month full-time training campus where we teach them to do enterprise-style Java cloud-native development. We take them from their current jobs, do this three months training, and then they go back, not to the old job because this would waste time. We bring them to feature teams where they really can code.

We had a very good pilot this spring. Currently, the first 30 colleagues are going through this campus, and we are planning to have 200-plus colleagues a year going through this campus. We are also doing coding dojos, building up the software engineering community within our organization, which is very important.

However, this is just one step. We need the software engineering skills very urgently. We did a second step and founded a joint venture last September, Critical TechWorks in Portugal, with two locations in Lisbon and Porto. In the last 13 months, we hired almost 600 software engineers, half of them working for the Connected Company, or for the engineering and development department, the other half working for us in corporate IT. They are doing full-stack software engineering in an agile method. It is such a great success story. They are very fast, high quality. They often outperform our traditional suppliers, and we will keep investing in them. This is a very good experience that we are having with Critical TechWorks.

What we eventually want to generate is really, I heard this term also here in one talk, this developer experience. We really want to make BMW a cool place for software engineers. But it is not only about developer experience, Ralf, it is also about...

---

Ralf Waltram

The user experience. As we mentioned, or as I mentioned before, we want to put more focus on the customer, the internal and the external. That is why we also started the initiative called UX Matters: User Experience Matters. I have two great examples with me from our legacy world. As you can see, one mainframe application. How many of you have still mainframe in their legacy landscape? Raise your hands, please. So a lot of you. You know the real dark mode, the mother of the dark mode.

The problem is that dark mode becomes fancy again, but it is still the old user experience, the UX from hell. We decided that this is not the way we want to treat user experience in the future, because a good user interface is like a joke: if you have to explain it, it is probably not a good one.

We focused really on bringing more UX skills into our teams, into the product ownerships and so on. Here you see new, modern user interfaces and workflows based on mobile applications. Why are we doing that? The old style was really from experts for experts. It needed long training, and still after training it was not fun to use. The new UX is very intuitive. It is from the real users or with the real users, and it is fun to use.

Probably you would ask, how are we doing that? Do we have a great PowerPoint presentation? Do we go to the product owner? No, we did the other way. We created a space, a real space to experience user-centered design. It starts with understanding the user, the real user, not the expert. Understand the needs or define the needs, design and prototype it, and get the user feedback instantly. Here it is in action. It is more than 500 square meter space. It is an open door full of software. Every team member can go in, walk in, and get help. It is easy access to professional UX support. Believe me, UX skill is different to our coding skill.

I am really glad we had the one-year anniversary at the beginning of this year, and already 80 product teams used our UX Life Center. They were really happy and delivering good and really great user experience in our new IT products to our business partners.

These are the four cornerstones or milestones we want to share with you. For us, it is still a journey. It is not ended. So far, it is a very successful journey. Sometimes spooky, as I mentioned, because not everything is fine at the beginning. But very important is: what is the business telling us about our BizDevOps journey, Frank?

---

Dr. Frank Ramsak

It is not that we tell about our success or not. It is about the business. We are not as mature, to be honest, as some of the companies I have seen here the last two days, which are measuring really DevOps performance, but we have feedback from our users. What we can see, where we really achieved a certain degree of our transformation, is that we are drastically down with time to market. Even in the SAP environment, we are down from two releases a year to almost two releases a month. This is very beneficial for our business units. We also improve in software quality, bringing down incidents, which is also highly appreciated by our business partners. User satisfaction goes up as we are investing, as Ralf just mentioned, in user experiences.

There is one thing that I really want to share with you: it is about the value of flexibility. In the automotive industry, we had this very challenging new CO2 legislation coming effective September last year, the WLTP. If you want to adhere to this and apply to this, you really have to change systems in R&D up to the car configurator that you are using as a customer, because we want to show you the individual CO2 footprint of the car you have configured. But if the legal requirements keep on changing all of the time, we would not have been able to meet the deadline if we would not have our agile working model. This was a great success. As a matter of fact, we were the only premium car manufacturer that had all our models WLTP-approved by the 1st of September of last year. This is also due to our contribution to the company.

But how did we achieve this, Ralf?

---

Ralf Waltram

Coming to the success factors, we picked out five of them. First of all, this transformation was self-organized. We did not hire a high-paid consultant showing us fancy slides, then try something out afterward and fail. No, it was self-organized. From the management team, from the feature teams, a small group started, and this is really focused on a small group of the willing people, the right people. Then you start defining an agile working model. Find your lighthouse products and show them to the business and to the other feature teams, and they will really get into this transformation.

We also started a small group of agile transformation agents, internal colleagues helping the teams in the transformation. Stick to your vision. We defined 100% agile, and in the beginning it sounded strange. But it is a vision. Stick to it, and we saw it -- or we will see it -- in our IT strategy version 2.0. We still have our vision 100% agile in there.

Finally, in the beginning I did not focus so much on this point: start with BizDevOps. Take your business departments into the transformation already at the beginning. Otherwise, they think the crazy IT guys found out a new buzzword and they are doing agile now. No, you have to really bring them into your journey from the beginning and do BizDevOps together.

These are the five success factors. But it is a journey, Frank, and we are not at the end so far. What is up next?

---

Dr. Frank Ramsak

You are right. We are not finished at all. Just four weeks ago, our board approved the next IT strategy 2.0, and we basically laid out the guardrails, the vision for the next three years to really support the BMW Group to become and stay the leading premium car manufacturer and service provider. We just want to highlight some of the challenges to you, where we seek advice and counseling and exchange with you.

Starting on the upper right: cloud first. Yes, this is architecture strategy that we have laid out, but it is not about the new things. It is about the legacy landscape. How do we transform this? What is our strategic cloud footprint? To find this out is a great challenge ahead of us. And this, at the same time, with minimum downtime. You have to imagine, we have to produce cars every minute. If the plants are broken, we will lose profit. So we have to do this in a very concise and careful way. This is a challenge ahead of us.

We mentioned back to code. I said we are in the beginning. We have to further ramp up the engineering skills within our organization. Fifty releases per day: we get so much feedback from our own people. Why is this? We do not need this. It is about really changing the way we do DevOps to the professional level we talked about over the last two days here, and to get to this level with automation in the deployment processes, automation in the tests. This is a challenge. We really have to bring this further in our organization.

Of course, API first: how do you do this in legacy? To do the right decoupling of the architecture, getting APIs in there is a very crucial part for us. To define this, to design this, is a challenge ahead of us. It is a very important journey still ahead of us. It will be, as the old one, a bit -- well, it will be fun, but it also will be hard times. But we are looking forward to it.

---

Ralf Waltram

Coming to a conclusion for you, if you want to take just five points out of this talk, some advice we want to share with you. First of all, be bold when you start your journey, or even if you are in journey. Stick to your vision. You cannot be too ambitious to name the goal like our 100% agile. Name it, and then stick to it.

Second, it will not be a five-star wellness cruise. There will be rough water in front of you. But it is worth starting the journey.

---

Dr. Frank Ramsak

And do so, stick to the agile method in your own journey. There is no such master plan you can follow. You have to apply inspect and adapt, and tell your management, tell your stakeholders in the business, and very important, tell your employees that this is an inspect-and-adapt style of doing transformation. Otherwise they will get afraid.

---

Ralf Waltram

Fourth, learn from other journeys. The DevOps Summit here is a great place to exchange the journeys. I was glad that I met the colleagues from Adidas last year in London, and we had a great exchange together with them about the DevOps platform and how to handle a DevOps platform. Use the opportunity to exchange with others about their journey and learn from them.

In the end, always have a good motto. Our motto is: enjoy it and enjoy IT. Watch how this looks like at BMW Group IT.

Thank you very much for your attention. Thank you very much. Thank you. Thanks.