Insights of Agile@Scale at BMW Group Autonomous Driving
Never ever have I imagined how a car manufacturing case study can create such an interesting learning experience that I am NOT part of but so inspired and closely followed for several years. Unfortunately I only captured puzzle pieces here and there in the past, but thanks to Konstantin Ribel and Michael Mai, this Mutli-year case study is finally here!
WHY CASE STUDY FROM AUTOMOTIVE INDUSTRY?
During visit to my friend in Unterschlie?heim, Munich back in 2018, by coincidence I drove by the brand new Autonomous Driving Campus of BMW, at that that I was practicing scaled agile and need some diversified views to validate some hypothesis, case studies that are:
a. across organization & industry with measurable outcome;
b. using other scaling frameworks beyond SAFe ;
c. neither theoretical nor superficial;
d. real learning with as little sugarcoating as possible
this short trip triggered the following question:
"wouldn't BMW need to organize itself with Agile@Scale to build complex applications and how did they do it?"
WHAT THIS CASE STUDY IS ABOUT?
Figure 1: Autonomous Driving Levels
For 100 years, BMW from Germany is known for bold design, mastery in mechanical engineering and lean manufacturing with the motto "Sheer Driving Pleasure". However, pressure from new disruptive competitors is rising, legislation towards Climate neutrality, "Internet-of-Things" and Electrification are creating new markets, strategically the company decided needs to shift to a software platform that enables autonomous driving (AD). The case study of "Huge LeSS Huge at BMW Group — Autonomous Driving" covered mid-2016 until October 2019, to create level 3 AD in one Department (ADD).
The main tasks was to create an efficient working model for developing complex AD open platform, which involved BMW Group, cooperation partners, and vendors. For a standard complexity Advanced Driver-Assistance Systems (ADAS) Electronic Control Unit (ECU), They usually have a team interfacing with one vendor to develop it. For the AD open platform and its multi-processor hardware design, we estimated 5-10 times greater complexity, several vendors, and cooperation partners. We further discovered that if we scaled this up linearly, we would probably need 10-15 6mes more people solely for the vendors’ project management interface, something had to change to improve it.
How to read this blog?
Hypothesis - my thoughts emerged during implementing scaled agile
"In the case study" - quoted or summarized from the BMW case study
"What we did" - my experience and reflection
"Validation of hypothesis" - summary
HYPOTHESIS 1
senior executives and managers must be trained very early on to really understand that Agile@Scale transformation is not another "thing" what people do, because it is about "evolution of complex adaptive system" that requires?their continuous engagement and behavioral change
Figure 2: Quote from Aesop
In the case study:
At the end of November 2016, creator of LeSS (large Scale Scrum) Larman has introduced the famous "Larman’s Laws" to the first executive engagement, he used English proverb “you are never a prophet in your own land” to explain that "culture follows structure" in large organizations.
"Large Scale (Agile) adoption involves big organizations and many minds with deeply rooted assumptions about how organizations should work. Successful adoption requires challenging these assumptions and simplifying the organizational structure, with all the explosive politics and “loss of face” that working across a big group entails. Adoption needs everyone to improve towards a shared goal"
In other words, we must gain alignment across different hierarchy levels.
A complex adaptive system is a system that is complex in that it is a dynamic network of interactions, but the behavior of the ensemble may not be predictable according to the behavior of the components. It is adaptive in that the individual and collective behavior mutate and self-organize corresponding to the change-initiating micro-event or collection of events.
Figure 3: How Organization Design Affects Behavior and Culture??
Jay Galbraith’s organizational design framework, the Star Model? shows the levers that managers can control, and as a result, can affect employee behavior. By choosing the desired behavior, managers can influence the organization's performance as well as its culture.
What we did:
we put it with paramount importance in practice to help leaders better understand why it is required to be trained in combined training courses together when possible, alternative, offer repetitive onboarding sessions in diverse format to help leaders understand "why" to address the common scheduling challenge. However this is not always a linear development, continuous coaching and support is required, to avoid old behavior strikes back and create coordination overhead.
Make those training easily accessible would be the next challenge and how to integrate to existing corporate offering or executive development programs.
Validation of hypothesis 1:
training and coaching for executives are a critical part that must be planned well in advance in an efficient and effective manner, but less theory more practical examples.
HYPOTHESIS 2
Line Organizational change is not a must-have at the start rather focus on value streams to get an End-to-End value delivered using change agents, who can later sustain the transformation incl. training, coaching & facilitation (e.g. Release Train Engineer), line organization evolves later
Figure 4: Line Organization Setup
In the case study:
Employees were not accustomed to directly talking to higher management without consulting their direct manager beforehand. Therefore, the risk that top-management would get filtered information instead of the real picture from Scrum Masters was considered harmful. To address these problems and create an environment where Scrum Masters can carry out their job as free as possible, scrum masters were asked to be part of a different line manager than team members. This decision led to place the Scrum Masters in the Competence and Coaching department.
There were three main departments within ADD. The PO, Area POs, and their supporting staff comprised the Product Owner department. All Product Developers and line managers were in the Development department. And the Competence and Coaching department contained all Scrum Masters, technical coaches, and additional standardization experts.
What we did:
领英推荐
Figure 5: Duel operating system in Scaled Agile Framework
compared to BMW which was a combined approach with both delivery and line organization, where we focused predominately on the value stream organization at the start, bringing cross-functional teams together, later evolved the line organization, most are kept as they are, some had fundamental changes, also considering vendor engagement, region and talent distribution, as well as strategic focus areas.
Validation of hypothesis 2:
There's no right or wrong, it really depends. Avoid conflict of interest between line and agile organization, one incentives for capability (develop people and systematic knowledge sharing) with predominately inwards view, the other own and maximize end-to-end value creation. take an incremental step, frequent change will result in change fatigue. RTE is a role that makes sense, who might start as change agent, but overtime grow to the coach and facilitator of the agile release train to sustain practices, and has clear process ownership.
HYPOTHESIS 3
Create as much as End-to-End Feature Team as possible to take responsibility
In the case study:
"One fascinating dynamic was that most developers did not consider contributing to solve build system issues. The reasons for that lie mostly in the organizational system in place before. Before, there was strong separation of responsibilities and accountabilities. Team A is responsible for road modeling, team B from braking, and so on, and also Team Z for the build scripts; and even a complete department dedicated to build-related issues. This enforced the mindset of
“it is not my job”
Given that the build is neither a product feature nor a technical detail within the product, who is responsible and why didn’t they act? Managers are responsible to create an environment that empowers teams to build the product and take accountability on removal of impediments that surpass the powers of the teams— therefore managers are accountable for the build."
Figure 6: System Dynamics of "Long-Living Branches"
The blame doesn’t work on root cause (missing whole product focus), it only highlights the complexity of the system, delayed feedback from the build system, developers’ focus on components rather than the product, insufficient software design, and missing meaningful component builds and tests. The corollary to Toyota’s “stop the line” philosophy: fix the root cause, was not realized by ADD’s managers or developers.
Modern product development of large, complex, and adaptive systems is no longer a maker of excellence on single-focus execution but a muli-learn/skill of quick adaptation on the product level goals.
What we did:
It would be a lie if I don't admit there're similar challenges, not every service is available out of the box, some business application services need to be created, and the problems are sometimes accumulated solutions from the past, it's not always possible to build feature team, instead we used Team Topologies to analysis and decide with the teams what is the best setup based on value stream, regional allocation, vendor mix and product lines.
The value stream and the tightly coupled applications and shortage on skilled talents have put some major impediments to make progress as we could have made.
Figure 7: Team Topologies
Validation of hypothesis 3:
Blame others is too easy, keep in mind that we are dealing with complex adaptive system Would one single manager, one developer from the other team or adoption of DevOps remove the issue of "it's not my job"? There's a fundamental misunderstanding of the system dynamics: Technology is only one part of the dynamic; people, organization, communication and processes are all contributing to it. "Neither managers nor developers learnt that putting a manager (or a tool) between responsibility and the teams degrades the process of taking ownership and responsibility for the whole product."
HYPOTHESIS 4
Everyone is trying the best to maximize the interest of components due to lack of clear purpose and incentives to encourage systematic thinking and behavior change unless reward system changes
In the case study:
The unchanged HR policy of personalized bonus system with focus on components and specialities contradicts the required skills of large-scale, adaptive products. Modern product development of large, complex, and adaptive systems is no longer a maker of excellence on single-focus execution but a muli-learn/skill of quick adaption on the product level goals. The HR managers, which are in a separate reporting line than ADD, discarded all arguments for a bonus system based on product success; they measured and rewarded local optimization by individual managers and developers, not global optimization.
The unchanged vendor-collaboration policies led to the same uninsightful execution of "thrown-over-the-wall" tasks. ADD didn’t acknowledge the possibilities of the changes in procurement processes, and instead just introduced a new middleman role to try to quick-fix the unskillful collaborations. For example, different wage agreements, independent HR policies, and more liberal processes, refused later in the transformation.
Figure 8: System Dynamic on "inflation of communities"
What we did:
It was recognized at the very start by C level that vendor and procurement process are both part of transformation, we have trained the procurement team with agile procurement process, KPIs and consolidated the vendor to create more sustainable yet flexible partnership for a joint success, while developing DevOps journey together with them. I have to admit that it was quite "straight-forward" to build Procurement KPIs but much more challenging to get sufficient data quality or discipline of applying those KPIs.
The HR function is perceived as a service and process unit, rather than "enable people success", creating awareness and rebrand HR to the next level would be something that must be linked to the agile strategy.
Validation of hypothesis 4:
"Respect People and Culture", encourage shared responsibility is not only a mindset shift but requires years of practice, leadership behavioral to encourage collaboration.
Figure 9: Comic Agile - the (hidden) big elephant in the room is HR
There're lot more valuable insights in the case study, for further information pls. check out here (estimated reading time 100 minutes)
Few memorable but important mentions:
Figure 9: Technical agility constrains organizational agility
One year later after passing by BMW Campus in Munich, I have visited SAFe Summit in 2019, Mik Kersten, creator of Lean Framework and Tasktop?has given a great keynote on how BMW site in Leipzig has inspired him to publish the book "From Project to Product". As a matter of fact, Lean Principles and Practices are essential part of Scaling Agile.
Figure 10: SAFe Summit Tasktop Keynote, San Diego 2019
Disclaimer: this blog is not a religious debate of "which Agile@Scale framework is better", but rather finding common patterns for large complex organizations to find their own path and sustain Business Agility. Information of the case study are public available, summary is only intended for learning purposes.
Source: LeSS, BMW, AZ Quotes, C. Larman and B. Vodde, Large-Scale Scrum, Addison-Wesley, 2016, Jaygalbraith.com, SAFe Summit 2019, Tasktop, Agile Comics, Scaled Agile Frameworks 5.0