Case study: Internal Product
at BMW Autonomous Driving
Case study: Internal Product
at BMW Autonomous Driving
INTRODUCTION
In the modern world, Agile is often considered a critical success factor, especially for product-centric and customer-centric companies. However, many people misunderstand Agile and build their structures, processes, and people management practices based on misconceptions about the critical success factors in designing Agile organizations.
Let's examine some aspects of one of the most remarkable examples of Agile adoption in an organization that almost everyone knows - BMW. Specifically, we will focus on the part of it that shapes our future and already now has a direct impact on our daily lives.
We will look at it from the perspective of the guidelines provided in the book “Designing Agile Organizations” (authors: Cesario Ramos and Ilia Pavlichenko) specifically concerning Shared Services and Internal Products.
Consequently, we aim to formulate a conclusion and provide recommendations for other companies that are considering comparable organizational solutions
BTW, you can find my Book Recommendations here.
Disclaimer
This experience report is written based on my best knowledge of the company gained during 1.5 years. As any human (not a machine), I could miss tiny details hidden deep inside due to the huge size of this corporation, which potentially could lead me to misinterpret some of the observations.
ORGANIZATION OVERVIEW
In this article, we will consider the organizational design of the Autonomous Driving Department (ADD) at BMW as of the years 2019-2020. And here, we will focus on one specific aspect – an Internal Product serving as a Service Unit to other Product Groups.
Note: for the sake of facilitating the learning from this case, we will examine only the essence – this describes a simplified organizational model of the ADD that focuses only on the elements and their interrelationships regarding the Shared Services and Internal Products
Balancing Cost and Quality in Car Feature Testing
The ADD included a Product Group (we will call it “The Main Product”) in which teams developed different sets of Car Features (e.g. Parking Assistant or Keep Lane) intended directly for a customer. Essentially, the customer could select most of these features while buying a car and some of those features would have their own price. This Product Group consisted of several Value Areas (called Requirement Areas at the ADD according to the LeSS Huge Framework) that developed these feature sets.
Most teams in this Product Group had a quite serious challenge because the testing of features would require many hours of testing them in a real car on the real road. This approach would be extremely expensive both effort- and time-wise.
Since the chosen Optimization Goal for the ADD was Adaptiveness, it required short feedback loops to ensure frequent learning from short and inexpensive adaptations (in many cases just experiments) thereby enabling effective risk management in an environment of huge uncertainties. A big part of uncertainties came from:
However, the feedback loop with real-world testing would be too long. A special technical solution was developed—the Simulation Platform. It allowed teams to perform most of the testing in a virtual environment simulating real cars and real roads. Definitely, some testing in the real-world conditions was still necessary yet it was sufficient when performed for the final verification only.
The Simulation Platform was developed by another Product Group—we will call it “the Internal Product”. The Internal Product and the Main Product had different Product Owners and Product Backlogs. They also had different dedicated teams.
The ADD included a Product Group (we will call it “The Main Product”) in which teams developed different sets of Car Features (e.g. Parking Assistant or Keep Lane) intended directly for a customer. Essentially, the customer could select most of these features while buying a car and some of those features would have their own price. This Product Group consisted of several Value Areas (called Requirement Areas at the ADD according to the LeSS Huge Framework) that developed these feature sets.
Most teams in this Product Group had a quite serious challenge because the testing of features would require many hours of testing them in a real car on the real road. This approach would be extremely expensive both effort- and time-wise.
Since the chosen Optimization Goal for the ADD was Adaptiveness, it required short feedback loops to ensure frequent learning from short and inexpensive adaptations (in many cases just experiments) thereby enabling effective risk management in an environment of huge uncertainties. A big part of uncertainties came from:
- The purely innovative nature of this product since teams developed something nobody has done yet.
- The extreme technical complexity.
- The emerging/strengthening requirements (e.g. safety standards).
However, the feedback loop with real-world testing would be too long. A special technical solution was developed—the Simulation Platform. It allowed teams to perform most of the testing in a virtual environment simulating real cars and real roads. Definitely, some testing in the real-world conditions was still necessary yet it was sufficient when performed for the final verification only.
The Simulation Platform was developed by another Product Group—we will call it “the Internal Product”. The Internal Product and the Main Product had different Product Owners and Product Backlogs. They also had different dedicated teams.
Decomposition of Functional Requirements and Design Parameters
Figure 1. Decomposition of Functional requirements and design parameters
The graphic above (figure 1) provides a simplified view of the decomposition of Functional Requirements and Design Parameters of the ADD as discussed above.
Here, we used the following terms from the book “Organization Design. Simplifying Complex Systems” by Nicolay Worren, 2018:
As shown in the picture below, the car-buying customers were the customers for the Value Areas of the Main Product. In turn, Teams of these Value Areas were customers for the Internal Product. The Main Product and the Internal Product had their own Product Owners managing the work done by these Product Groups separately.
Here, we used the following terms from the book “Organization Design. Simplifying Complex Systems” by Nicolay Worren, 2018:
- Functional Requirement – “A desired outcome that an organization or sub-unit should produce.“
- Design Parameter – “A specification of a role, unit, or process that will satisfy a Functional Requirement.”
As shown in the picture below, the car-buying customers were the customers for the Value Areas of the Main Product. In turn, Teams of these Value Areas were customers for the Internal Product. The Main Product and the Internal Product had their own Product Owners managing the work done by these Product Groups separately.
Organization Design. Simplifying Complex Systems
by Nicolay Worren
by Nicolay Worren
Figure 2. Customer product relationships.
CHECKING AGAINST GUIDELINE 10: Design Shared Services for Support
“
An Agile organization might want to balance its design between independence and centralization and introduce some shared services such as purchasing, sales, human operations, or marketing, to name a few. But be very suspicious about shared service activities that directly affect the product development outputs.
A service unit’s purpose is to support the product group’s operations.
A service unit’s purpose is to support the product group’s operations.
Functional Coupling and Operational Interdependencies
First, let’s assess the organizational set-up at the ADD against the existence of any interdependencies which could be considered as a red flag for separating the Internal Product from the Main Product, as outlined in the Agile Organization Design Guidelines mentioned earlier:
First, let’s assess the organizational set-up at the ADD against the existence of any interdependencies which could be considered as a red flag for separating the Internal Product from the Main Product, as outlined in the Agile Organization Design Guidelines mentioned earlier:
- Decouple Unit Functions (Guideline 3)
- Contain Reciprocal task interdependencies (Guideline 5)
Figure 3. Design Matrix.
The design matrix above (figure 3) shows the mapping between Design Parameters and Functional Requirements. The Internal Product team’s efforts to achieve their goals did not adversely affect the Main Product team’s ability to achieve their goals, and vice versa. This means that the two groups were not functionally coupled.
“
Reciprocal interdependence: When there is a frequent two-way dependency between the work of the teams. It is a symmetrical dependency. The work of one team is input for the other team, and vice versa, and there is uncertainty about how to accomplish the work, which makes frequent alignment necessary.
All the processes of teams in the Main Product mostly could run without interaction with the teams of Internal Product at all. When teams of the Main Product needed some change in the Simulation Platform, they could proceed to deliver their features independently using real-world testing until the change was done by the Internal Product. That was not a reciprocal type of interdependency.
Additional Dependency Perspectives
Now, let’s check the organization design of the ADD against Guideline 10: Design Shared Services For Support for such cases when there’s no functional coupling nor reciprocal interdependencies:
Now, let’s check the organization design of the ADD against Guideline 10: Design Shared Services For Support for such cases when there’s no functional coupling nor reciprocal interdependencies:
“
To make a more informed decision, consider the following additional dependency perspectives:
- The cost of development delay when the unit is a shared service
- The criticality and uncertainty of the dependency between the product group and the unit
We will look at the Risk Severity driven by the criticality of dependencies, and the cost of development delay is one of its main factors. On the other hand, we will look at the Risk Probability driven by the uncertainty of dependencies.
Figure 4. Risk assessment.
As shown in the diagram above (figure 4), the uncertainty of the dependency between the Main and Internal Products was rather low since in most cases, teams of the Main Product knew in advance the current capabilities of the Simulation Platform and could plan their work accordingly.
“
A dependency is critical when the shared service’s actions affect the product group’s important outcomes, such as customer satisfaction, revenue, or quality.
Designing [units with critical dependency] as a shared service puts a critical product success factor outside the product group’s direct control.
A third variable to consider is the cost of development delay.
Designing [units with critical dependency] as a shared service puts a critical product success factor outside the product group’s direct control.
A third variable to consider is the cost of development delay.
Even when the Simulation Platform did not cover the necessary cases yet, in most cases, the teams still could do real-world testing. Thereby, they still could deliver independently from the Internal Product. However, that would be quite expensive and time-consuming.
The Product Group developing the Simulation Platform had a significant impact on the total development cost of the Main Product.
Also, they made it possible for the Main Product to learn faster (thereby increasing their Adaptiveness) and reduced the cost of development delay. In such cases, the approach recommended in the book is to consider containing within the Main Product.
Furthermore, the separation of the Shared Services unit would make more obvious benefits should its services be shared by more than one client unit. In the case of the ADD, there was the only unit (Main Product) that benefited from the services of the Internal Product unit.
The Product Group developing the Simulation Platform had a significant impact on the total development cost of the Main Product.
Also, they made it possible for the Main Product to learn faster (thereby increasing their Adaptiveness) and reduced the cost of development delay. In such cases, the approach recommended in the book is to consider containing within the Main Product.
Furthermore, the separation of the Shared Services unit would make more obvious benefits should its services be shared by more than one client unit. In the case of the ADD, there was the only unit (Main Product) that benefited from the services of the Internal Product unit.
Checking Against Guideline About Internal Products
“
An internal product that does not have an end-user outside of the company likely does not have an independent profit responsibility.
In large organizations, it is common to have a few internal products (often called shared services), and that is perfectly fine — as long as the majority of the company’s outputs are real products.
Internal “products” may cause local optimizations at the expense of the whole.
In large organizations, it is common to have a few internal products (often called shared services), and that is perfectly fine — as long as the majority of the company’s outputs are real products.
Internal “products” may cause local optimizations at the expense of the whole.
Let’s now check the organizational solution in question against the recommendations provided above.
The teams developed the real product in the Main Product unit. They comprised the absolute majority of the employees of the ADD and respectively produced the majority of the ADD’s output.
From the other perspective, the teams of the Main Product were direct customers of the Internal Product — Simulation Platform. Additionally, the Internal Product’s goals served the purpose of the Main Product and they even had the same Optimization Goal for both units. Furthermore, there was a shared information environment established (mentioned earlier). So, while the possibility of conflicting goals still existed, that risk was to some extent mitigated.
On the flip side, the separation of the Internal Product drastically reduced the learning by its teams about the Main Product. They were unable to quickly and at a low-cost switch from their own tasks to help the teams of the Main Product. Moreover, due to having separate sources of priorities (product backlogs) for the Internal Product and the Main Product, it was hard even to identify whether that switch was needed to maximize value. Hence, there was significant room for improvement in Adaptiveness for maximizing value from the perspective of ADD as a whole.
The teams developed the real product in the Main Product unit. They comprised the absolute majority of the employees of the ADD and respectively produced the majority of the ADD’s output.
From the other perspective, the teams of the Main Product were direct customers of the Internal Product — Simulation Platform. Additionally, the Internal Product’s goals served the purpose of the Main Product and they even had the same Optimization Goal for both units. Furthermore, there was a shared information environment established (mentioned earlier). So, while the possibility of conflicting goals still existed, that risk was to some extent mitigated.
On the flip side, the separation of the Internal Product drastically reduced the learning by its teams about the Main Product. They were unable to quickly and at a low-cost switch from their own tasks to help the teams of the Main Product. Moreover, due to having separate sources of priorities (product backlogs) for the Internal Product and the Main Product, it was hard even to identify whether that switch was needed to maximize value. Hence, there was significant room for improvement in Adaptiveness for maximizing value from the perspective of ADD as a whole.
CONCLUSION
The decision made at the ADD to separate the Internal Product from the product group developing the Main Product contradicted at least the guideline provided in the book about containing the critical dependencies.
As a result, the Main Product ran risks of dramatically increasing the cost of development, cost of delay, and decreasing Adaptiveness due to failures in the Internal Product which was out of their control.
Furthermore, the Adaptiveness from the perspective of the ADD as a whole was constrained by this organizational solution since the teams working on the Internal Product could not switch to the Main Product quickly and at a low cost.
On the other hand, no clear benefits were stated or anticipated as a result of this separation.
Based on the experience of the ADD, we can make a suggestion to other companies that consider an option of separating internal products and shared services from product groups producing real products. Clear benefits must be identified and weighted against all the possible risks introduced by such a solution. If the risks outweigh, the unit should not be separated. The guidelines provided in the book can help with such consideration.
Designing Agile Organizations
In my courses, I do not just teach but help people truly understand the organization as a system with its natural, context-agnostic laws of organizational behaviors and high-level essential capabilities necessary to deal with the most common challenges of product organizations. Using this understanding, my students can identify the inconsistencies in their own organizational design and undertake a tailor-made re-design of their organizations towards the optimization goals within their specific context.
During the last several years, I predominantly focused on providing courses within my client companies and starting this year, I am giving public courses too.
During the last several years, I predominantly focused on providing courses within my client companies and starting this year, I am giving public courses too.
Learn more
Cookies help us deliver our content and services. By continuing to use the website, you agree to the use of cookies.
OK