Hello Marcus.  Before we began, you mentioned that you're not really known at BMW as a SAFe follower. Not even you would call yourself that, right?

Yeah, exactly.  However, there are many SAFe followers at BMW right now.

So would you say that you are currently seeing an upward trend?

Definitely, I've mentioned some of this previously in various videos available online, so it's no secret.  The thing is, we didn't give any concrete instructions to the teams.  All we said was that we want to carry out Agile product development.  That was the starting point.  We said that we have IT products and that we wanted to bundle different systems into one product.  This one product is what is being worked on using Agile methods.  So far, so good.  However, this depends on which method the person responsible is using (e.g., Scrum or Kanban).  It also depends on whether the product is so big that it needs its own scaling framework.  The question of which one was something we left open.  Most areas are so big that they do actually need their own scaling framework.

So how did they decide?

In some areas, the issues seem to have solved themselves.  Some use LeSS, and some use SAFe more.

That's interesting.  I heard that a few people talking about LeSS and assumed that BMW went the other route.

Exactly.  We came to a crossroads and ended up going in a completely different direction - and all of that happened on its own.

In what way?

A few years ago, Craig Larman personally trained the whole team in self-driven development.  At the time, the approach was to build the whole thing according to a large LeSS.  So that's what we did.  It's changed since then, however.  We've scaled back Craig Larman's "by-the-book" method to some extent.  Once I'd gone through the training, I realized that the by-the-book approach is not always applicable.

Can you elaborate on that?  I want to write a book for people who are just getting into it.  What are the pure ideologies behind LeSS, and what are the difficulties in its application in a big company like BMW?

The main issue is that very little structure is given.  It's basically about applying Scrum, but on a large-scale.  That means the typical Scrum methodology with as little role definition and framework as possible.  LeSS provides as little framework as possible in contrast to SAFe, which offers as much framework as possible.

Exactly

That's the reason that I believe it may not work for our organization or product structure.  I think it works if you just want to develop a substantial software product. It's not for you if you have fifty different IT systems that you just happen to call "one product." This leads to a split in knowledge: one person who knows this and the other that.

Theoretically, I think the concept of the feature team is that everyone in the team can contribute to the product as a whole.  It's a great goal, but when I look at our products, the concept doesn't apply to us.  With so many different IT systems, not everyone can be involved in all areas.  Although we do have similar business processes, not everyone is able to understand all the process details in depth - even though our systems are bundled.  That's why this feature team doesn't work for us.

Some of the people I've interviewed have said things like, "SAFe is such a bridging technology" because it removes the apprehension of a more rigid company with its traditional organizational model and thinking structures.  Which means they can move toward agile collaboration. And all this on a very large scale.

Yes, that's true.

And that's why it's good that everything is so ingrained and that there are all these roles where you can choose your own targeted training.  It's also good, then that it's expensive.  Couldn't I then go from SAFe to LeSS?

No, I don't think so.  What you're describing now as an advantage - namely this familiarity - was always why I didn't adopt SAFe.

Could you go into more detail?

What I think will happen is that roles are just renamed.  Before they were called waterfall processes - now, they're called SAFe processes, and everyone will find their role there.  Everyone finds their box somehow.

...and just pick up where they left off

Exactly!  And you'll never move forward or grow.  So my philosophy was that if you want to leap into agility, you have to start with LeSS.  It creates a disruption but that's exactly what I want to achieve.  This is why we put our management through training.  They came out of the LeSS training three days later, completely disillusioned about our then current strategies.  But that's how you get people to think about the possibility of moving in that direction.

And did it work?

Sort of. We have department heads who now say, "We're not doing two releases a year anymore - we want 50 deployments a day!" Now everyone has to come up with ideas.  If the boss were to put out four releases instead of two, you could still carry it out manually - similarly to how you did it before.  But if they say they want you to deploy fifty times a day, you have to come up with a plan and automate that - you have no choice.  

In the meantime, people have already moving in that direction - even if we're still far away from where we or I wanted to be.

Has software development now become your main focus?

Yes

And in business? Is it important to you how marketing or sales are organized?  Or is there no Agile at all?

Yes, of course, they are also inspired by the spark we've created elsewhere within the company.  I've been invited to talk to them about how they can make their work more agile.

Do you think they want to really go through the process, or is it because it's currently modern and just want to give it a go?

No, they really do want to make the transition.  Obviously there are some that are interested due to it being "in", but generally speaking there is real interest coming from other departments.  You could say that the spark started in IT and radiates out into all processes because all processes involve IT.  It created an touchpoint, which is why the idea has caught on.

Does SAFe also exist internally or only on a very small scale? And have you seen any evidence of partisanship or similar?

No, there is no major partisanship.  Some people like to implement SAFe - they love their PI planning at the beginning of the quarter - which makes perfect sense.

You are active at BMW.  Now, I'm interested in something else.  There's this American Tesla car manufacturer...

Yes, I've heard of them.

...which has a market share that all German car manufacturers and a bank could fit into.  Why don't you tell us a bit about that?  I'm a complete layman, so this will sound very general, but if I were to explain why Tesla is so successful, I'd say, "Well, they didn't build a car, but software or a computer with four wheels on it." So do you all look at Tesla and say, "If we don't put out 50 deployments a day, they're just going to eat us up because they're deploying live into cars while they're being driven!"  So how does that relate to you?  How does it affect your daily work?

Well, it depends.  There are people who take the threat very seriously.  There are others who don't perceive it as all that threatening because they focus more on the hardware.  As an automobile manufacturer, we've been producing hardware for over 100 years - this is what we're known for.  In this respect, new competitors tend to focus relatively quickly on the hardware, or perhaps ask themselves, "How does it drive?", that is, the handling.  You could then go on to make fun of the panel gap dimensions...

Exactly. Speaking of the gap dimensions at Tesla, I have a colleague who ordered a Tesla and will receive it sometime within the next two weeks.  He already knows exactly what aspects will be less than stellar.  He knows where to look, only to then say "I won't be taking this one, give me another one."

Yes, exactly.

So actually, you can just throw that whole thing away.  There are actual communities that focus on describing all the things that are wrong with the Teslas

That's not how we want to approach this.  Our attitude has been shaped by our former CEO from Kuenheim.  He is said to have walked across the yard to take a look at the 7s that were all next to each other in the factory.  He noticed that the trunk lids were all different heights and exclaimed "That is absolutely not ok!  That's not premium!  They all have to be aligned, please."  And since then, springs have been installed that will react to the car's weight and the weight of the car depends on the optional extras.  

That means you basically have a control loop in your parts list.  You determine the springs that are needed for each of the special parts or optional extras.  And all that just to make sure all trunk lids are the same height, right?  Well, I call that gap dimension specification - even though it's not something the customer needs to be concerned with.  They don't have two or three 7s sitting around.

..with different features

Exactly.  But you can see that someone is already in love with the hardware.

Does your complexity cause you to get in your own way?

Well, you build hardware for over 100 years, and within the last 20 years, software has been added to that little by little. That means you have a control unit there, another there, and another there.  When you're done, you end up with a network of thirty to forty control units in your car.  There is software everywhere and the control units all come from different suppliers.  An automobile manufacturer doesn't create that.

But that's what Tesla does because they don't do anything themselves.

The software does.

Ok, but the ECUs that come in the things they buy are all from outside sources.

The architecture at Tesla is fundamentally different.  There may be a few ECUs, but there is a central processing unit- the central computer - inside, which is what I'm getting at.

They only buy things they can connect to their software.

Exactly. It's like if you tried to put a floppy disk drive into a computer.  The drive has a small controller where the interface is specified, but you don't update its software.  What can be done with the floppy drive, is done via the interface.

But this is not really patented. So, you could plan a whole new car and say: "Well, we'll start with the software."

Yes, but you have to think like a software manufacturer, not like a hardware manufacturer. That is the whole problem. It's relatively difficult for a hardware manufacturer to become a software manufacturer. You have to completely change your thinking.

Looking at this from my perspective, I'd say that if you don't succeed, you'll lose your hold on the market. Is that something you all think about too? Or do you say, "No, in the end, people need four wheels and everything has to be well made", and the software is secondary?

There are those who think like that and others who don't. We'll see who comes out on top. It's difficult and we're only talking about the car right now. We haven't even begun to talk about the related services and the car as one element a in a large software platform.  Networked mobility services is one stage beyond that and that's what comes next.  That's pretty complex.

If you could give the Marcus of 15 years ago at BMW advice, what would he say? Would he advise you to be more agile because agility is what's needed for such a huge company?  

That's why I'm such a LeSS fan.  You start small and grow into the big.  You then have to get rid of the veneer to see what's underneath and rid the organization of dependencies. That's another downside of SAFe -  getting big too quickly, and you don't just want to manage the dependencies but get rid of them. So I want to choose architectures that decouple the dependencies from the systems.

But you have to start pretty high up with LeSS to make it work, right? You can't have SAFe without the "top-down" approach.

Yes, it's true that you need a top-down strategy. But in my opinion, this strategy should include starting small, so that you learn as you get bigger. If you go large-scale too quickly, this will cause problems.  Things become industrialized too quickly which might lead to industrializing Scrum to death.

There are some that say you can't scale an unkempt garden.  First, you have to weed everything so that you can start with a clean area on which to build your basic structures...

... and the systems, the architectures. These are all huge monolithic architectures where everything is connected to everything else. We build point-to-point interfaces in the systems, time, and again. There's nothing wrong with APIs or anything like that. When I need data from system B, I build an extra interface for that very data. There are no APIs to access it. That's why it's all intertwined like a big ball of spaghetti.

So the takeaway from this is that I should start small and then see if I can reduce the dependencies. Are there a few things where you look back and think you did them wrong? Or where you began with a faulty theory that you didn't test? What kinds of things would you warn others about? 

Starting small is a good thing.  Back then, I was impressed by our ambitious strategy of setting up IT 100% Agile. It was such a huge commitment, top-down from the CIO to say they wanted to go full-Agile. In the beginning, there is a huge momentum, but it also automatically leads to a certain amount of expectation on the part of the organization. That means you have to implement it relatively quickly, which is where starting small comes in, as well as learning how to deal with expectations from above.  Ultimately, everything grows larger relatively quickly and results in processes, frameworks, and regulations.  All well-intentioned but probably wouldn't exist with organic growth.  But that would have taken decades as opposed to just a year.  In hindsight, I would definitely fight the impatience more.

And you have to be able to tolerate the fact that it takes as long as it takes. Some things may happen quickly and some things take a very, very long time.

Exactly! Especially when you choose such big and bold strategies - impatience is a by-product.  That's difficult to deal with.

Agility means being ready for anything and being more adaptable.  Since COVID-19 arrived on the scene in March, we've seen such an incredible shift in the market like no other that I've experienced.  Just how agile was BMW in its reaction to this?  Are you surprised at how well everyone took to the changes, or do you feel you could have reacted better had you been better prepared over the last ten years?

Without the shift towards agile working in IT over the last three to four years, we wouldn't have been able to adapt so quickly.  For example, our IT infrastructure is agile too, which means we could react quickly. It was no problem transitioning people over to working from home.  Of course, an increase in VPN connections was necessary, among other things.  We somehow managed to keep everything working, especially in terms of vehicle development. There was no production, so apparently it wasn't that important.  No supply chains, no production, and now customers because there were no car dealerships.  We continued our work in vehicle development because CAD was possible.  But that only works if you have a VPN connection and the right bandwidth - the infrastructure was really good.

When you hear what other car manufacturers are doing in the industry, are there things in terms of agility and Scaled Agile that you're a bit jealous of? Things where you go, oh, they're doing a good job what could we learn from that?

Well, we already mentioned Tesla. Going in that direction with this basic architecture - that would be something to strive for. Others, like VW, for example, are being proactive with their own operating system.   The strategy is to develop their cars more or less like a smartphone on wheels.  I find their strategic clarity very helpful.

If you read a book about scaling agility, what content would you like to see? What would you like to learn from such a book?

Examples and principles would be good. I would be careful with concrete frameworks and concrete help. Maybe that's why I like LeSS so much, because it's built on the principles which make everything very simple. But as I said, good examples would be very helpful.

What if you looked at this through the eyes of a complete beginner in this field. Would your answer change?

Maybe it would help if you not only described a target state (scaled agility in all it's glory) but also how to grow incrementally.  Sort of like a step-by-step guide from small to large scale. That could be helpful.

Is there a kind of classic LeSS like "LeSS for beginners" or something like that?

If there is, I haven't read it. I can't think of one. I like the online material that is available, but training is better than any book. Hands-on training cannot be replaced by a book.

Finally, I'd like to talk about Atlassian software and Agile scaling. Please describe the role of Atlassian software at BMW. Is it a side-note or essential? How did you deal with this combination operationally?

It's essential - it's already part of our core. Jira and Confluence are used for every product, in every team, and at all levels. We probably have one of the largest Jira and Confluence installations in Germany.

And how do you see its influence in the company? For example, when you talk to marketing or other compliance people, do they already work with it, or is it more like it's finding its feet there and just getting started?

It's already a part of the fabric. Everyone who works with IT (a substantial amount of people) or who needs something from IT, will use these tools - no requirements without issues. And documentation is done entirely in Confluence. No more word files.

How did you get there?

We provided a central installation. The product-oriented focus helped us here because up until that point, everything was always so project-oriented. The project picked up its project drive, created its documents, then it was finished and stored. In some cases, the teams also installed their Jira instances when they needed them and then removed them after the project was finished. Of course, this does not add value. In the end, we put up a central instance and said to everyone, "Help yourselves!" This is also provided free of charge.

There is no offsetting of charges, right?

Exactly, we operate a central instance.

And what about the performance? If you have such huge systems with so many users, that's not to be taken lightly.

This has always been a problem - at least in recent years. However, things have been going well in the cloud as of late.

Your own cloud, because Atlassian currently stops at 10,000 users.

Right, a cloud of our own.  

And COVID-19 and home office didn't make any difference?

Exactly, that was no problem.

Is there anything else you would like to share with the world?

Just this maybe: don't start with SAFe. At least that is my personal opinion.

Thanks for the interview, Marcus!