The management departments of automakers are facing challenging times. In addition to day-to-day operations, there is a need to establish strategic guidelines for the product portfolio and organizational structure to ensure business success both today and in the future. These strategic decisions must be made in the context of emerging players, global trade disputes, crises (e.g., COVID-19), and trends such as connectivity, autonomous driving, sharing/subscription services, and electrification.
When it comes to autonomous driving (AD), the question is not whether it will impact the business, but rather how it will impact it and how to respond as an established global player. Automakers must decide between “fast-following” and “early-adoption” strategies, “make-or-buy” scenarios for hardware and software components, and strategic partnerships or cross-company collaboration. Either way, autonomous driving has a significant impact on product development management.
The challenges of developing autonomous driving are defined by the following characteristics:
- In conjunction with a major strategic transformation involving high investment costs (e.g., powertrain electrification, new business models such as car sharing)
- A complex global market environment with new, emerging competitors and potential partners
- Continuously and dynamically changing legal regulations regarding product safety
- New levels of technical complexity in terms of sensor technology, data processing, and type approval
- High levels of cross-functional interdependencies within AD functions and with respect to other vehicle functions
- Limited experience and expertise in the industrialization of large-scale autonomous systems
The challenges outlined cannot be addressed solely through traditional product development approaches; rather, they require agile practices. These practices focus on iterative prioritization and delivery, flexible resource allocation through the separation of technical and disciplinary leadership, and continuous improvement via inspect-and-adapt methods. They address the unknown aspects of large-scale autonomous systems and facilitate adjustments to strategic direction. However, they lack proven approaches for efficiently managing the tremendous complexity of hardware and software, the wide range of interfaces with development partners, and methods for complying with required safety regulations (e.g., ISO 26262). Consequently, it is recommended to adhere to traditional product development approaches, such as systems engineering. Our experience has shown that classical practices—such as clear responsibility for product architecture or approval, a maturity-oriented, top-down development approach (from the complete vehicle down to the component level), defined governance and reporting structures, and proven cooperation models with internal and external interface partners—are crucial elements for managing complexity and establishing processes to meet the requirements for homologating an autonomous vehicle. The challenge is to select the appropriate practices from both worlds in order to establish an integrated hybrid working model. This article provides insights and guidelines for successfully navigating the transformation from a traditional, systems engineering-oriented driver assistance development department to an organization capable of delivering autonomous driving.
Figure 1 shows the content of this article. A successful organizational transformation begins with defining the organizational structure, which is the focus of the first part of this article. It describes five design principles for an organization focused on delivering autonomous driving and seven critical artifacts for steering the transformation and product development.
The second part describes the planning of the transformation and the six success factors that should be considered during this transformation.
Content and structure of the article.
Part 1: Definition of an Organization for Autonomous Driving
As outlined in the introduction, autonomous driving cannot be developed using solely a traditional or systems engineering-oriented organizational structure. Before the transformation begins, a clear vision of the organization and its operating model should be developed. As proposed, a hybrid model that uses agile principles and incorporates traditional best practices can work well. How should the organization be structured? What artifacts are needed to keep the organization on track while maintaining speed?
In our experience, frameworks for agile scaling, such as SAFe or LeSS, provide valuable guidance. Nevertheless, we agree on two main reasons why they should be viewed only as a starting point for tailoring an organizational structure:
- They are generic (suitable for all kinds of industries) and are not designed specifically for the development of a mechatronic system with highly complex and safety-critical software and hardware components.
- They do not take into account the company’s legacy and the ecosystem that needs to be considered
Therefore, this chapter will provide design principles for tailoring an organizational structure and a set of artifacts that are helpful in determining the detailed design of the working model.
Design Principles for an Organization to Deliver Autonomous Driving
The organization’s design should be based on the five design principles shown in Figure 2.
The five design principles are described in the following paragraphs:
- Separate responsibility for product value (What) and development efficiency (How)
- Structure the DEV organization based on product architecture and development tasks
- Establish technical communities to promote interconnected learning
- Establish strong and centralized support functions
- Establish dedicated roles to ensure clear lines of communication with vehicle project and development partners
Principle 1: Separate responsibility for product value and development efficiency
The first principle of organizational design addresses the overarching structure of the organization. To ensure flexibility and speed, the organization should separate the “what” from the “how” by establishing separate Product Owner (PO) and Development (DEV) teams. The PO organization focuses on optimizing product value, while the DEV organization focuses on development efficiency. By separating leadership responsibilities, speed can be achieved. The technical leader (PO) ensures that the output is clearly defined and prioritized. The disciplinary leader (DEV) ensures the efficiency of output generation. Especially in multi-product development, flexibility is achieved through the easy and rapid reallocation of development resources in response to changes in requirements and priorities. If the DEV is sufficiently structured, development tasks can change frequently without the need to make adjustments to the teams or disciplinary leadership. “Old” roles such as Function Owner or Software Engineer can usually be mapped and integrated into this scenario.
Principle 2: Structure the DEV organization based on product architecture and development tasks
The development organization shall ensure that its development workforce operates with maximum efficiency. This can be achieved by implementing a structure that takes into account product architecture and the development task. An agile working model is best suited for developing the software stack, given the high level of uncertainty and interdependencies inherent in autonomous driving technology. The agile teams that thrive in this working model should be structured in accordance with the product architecture. The architecture should account for customer features, as well as software services that provide the foundation for implementing those features. Teams should be cross-disciplinary and have end-to-end responsibility for their functional scope (development, testing, industrialization, planning, and coordination with stakeholders). With regard to hardware development (e.g., sensors, control units) and the management of function procurement (e.g., AUTOSAR platforms) within the DEV organization, we recommend the use of hybrid or classical working models; one example is a top-down V-model approach that incorporates iterative processes, particularly at the implementation level. Hybrid and classical working models enable more precise and detailed planning through work packages and deadlines, which are more suitable approaches for these development tasks.
Principle 3: Establish technical communities to foster interconnected learning
The “task” of developing autonomous driving is characterized by its enormous technological novelty and complexity (e.g., time-synchronized sensor data fusion).
Therefore, the organizational structure should support a focus on critical technology and the ability to incorporate and adapt to new insights. This is achieved by institutionalizing overarching technical communities.
Technical communities should operate independently of the development teams within the DEV organization and take personal responsibility for topics such as architecture, verification, safety, and critical sensors. They should ensure that enabling infrastructure and critical development artifacts (e.g., product architecture) are available. This orthogonal design fosters synergy effects between the teams within the DEV organization.
Each community should consist of one leader and several specialized members from the cross-functional development teams. By separating disciplinary and technical leadership, the DEV organization remains lean, and the premise that lessons learned are shared within the development teams is ensured. This structure also ensures that the “traditional” and established roles necessary for delivering safety-critical systems—such as system integrators, simulation engineers, and test engineers—are taken into account and integrated.
Principle 4: Establish strong and centralized enabling functions
Three basic enabling functions are required for the development of autonomous driving: “processes and methods,” “IT infrastructure,” and “integration and verification.” To ensure that these functions are implemented in a sustainable manner, we recommend establishing centralized and powerful departments within the organization or creating mandated communities with clearly defined responsibilities.
The “Processes and Methods” unit ensures the definition and improvement of the working model and ensures compliance with development processes. It provides general development tools (e.g., backlog management) and is responsible for aligning agile and traditional processes such as development planning, requirements management, and defect resolution management. Furthermore, it ensures that the development processes comply with standards such as Automotive SPICE and ISO 26262 (standard on functional safety).
The “IT infrastructure” should provide an integrated and scalable toolset for continuous delivery and data-driven development. The four main challenges in setting up the IT infrastructure are as follows:
- Training algorithms requires processing huge amounts of data
- Development and test sites are decentralized and located around the world
- Software functions must be continuously integrated and verified on test and target systems
- Safety regulations and product complexity require consistent traceability across models and tools
A consistent strategy that is fully implemented is needed to address these challenges. Therefore, we recommend establishing a centralized department with strong and experienced
leadership capable of scaling up an infrastructure that operates globally and is seamlessly interconnected both internally and with the company’s and its partners’ systems.
The “Integration and Verification” department ensures that the maturity and quality of the product are continuously verified. In addition to other supporting functions, it is responsible for establishing and maintaining robust integration and verification processes and tools, enabling early and rapid feedback loops. Furthermore, it provides a reliable test infrastructure (e.g., software-in-the-loop and hardware-in-the-loop systems, test fleets).
Principle 5: Establish dedicated roles to ensure clear interfaces with vehicle project and development partners
The success of autonomous driving product development depends heavily on the extent to which it is coordinated with partners (both internal and external) and on how well the product integrates with the rest of the vehicle (e.g., user interface, braking system). Therefore, the working model and organizational structure should clearly assign responsibilities for managing the interfaces between the vehicle project organization and other development partners (e.g., centers of competence (CoCs), modular kits, or suppliers).
“Interface managers” plan and facilitate communication between partners and roles within the AD development working model. With regard to the vehicle project and development partners with minor dependencies, they must ensure the early exchange of relevant development information (e.g., requirements or project schedules). As for development partners and CoCs with major dependencies, they must proactively manage and coordinate collaborative activities (e.g., concept or toolchain validation workshops). If these roles are not well integrated into the organizational structure and do not have sufficient influence, there is a high risk that the expected product maturity will not be achieved—whether when integrating functionalities (software or hardware) from different suppliers or when integrating the entire system. We have learned from various projects that assigning dedicated roles within each development team for key interactions—such as vehicle integration—is a reliable approach.
Artifacts for Leading Autonomous Driving Development
The complexity of autonomous driving products requires a more systematic approach than is needed in software-only agile projects. Therefore, it is crucial to establish a consistent methodology and the right tools to guide product development in tandem with organizational design.
Figure 3 provides an overview of the artifacts that, in our experience, are essential for enabling fast and flexible development that is still capable of meeting the defined goals for quality, safety, and budget. The artifacts are described below.
Strategic Vision
The strategic vision outlines the product to be developed. It defines strategic goals, the set of functionalities, decisions regarding partnerships, and “make or buy” decisions for major product areas.
(Sub-)Product and Development Area Backlogs
The product backlog is a hierarchical breakdown of the work that needs to be implemented to realize the product vision. It breaks down the strategic goals into defined levels (e.g., epics, features, maturity grades, user stories). The items in the product backlog can be represented in different backlogs (views), depending on roles and responsibilities (e.g., sub-products, development areas). The product backlog should have a defined interface in accordance with the release plan and the development roadmap. Additionally, it provides valuable data for product status reports.
Development Roadmap
The development roadmap is the long-term plan (covering the entire project duration) that includes goals, critical results, maturity gates, and other synchronization points relevant to product delivery. It enables prioritization within release planning and coordination with external departments. Due to the complexity of a multi-project environment and its interconnection with the release plan and product backlog, a clear framework is required when distinguishing between planning tools and methodologies.
Release Plan
The release plan is the mid-term plan (~1–6 months) for product delivery. It defines a specific level of the product backlog and every work item that should be delivered in the next (1–3) releases. Story point estimation helps verify the feasibility of the plan during the planning phase. Release planning must involve most stakeholders, including the product owner, enabler communities, and teams. Therefore, it is crucial to establish a robust and efficient release planning process to ensure consistent prioritization and clarify interdependencies.
Sprint Backlog
The sprint backlog provides an overview of all work items planned for a sprint; it can be defined by team, sub-product, or development area. Each backlog item is reviewed during the sprint review at the end of each sprint. It is common practice to break down the sprint items in the sprint backlog into a physical backlog for each sprint and team.
In addition to agile project planning artifacts, it is important to implement tools that provide transparency into the performance of the working model and the progress of product delivery.
Organizational Improvement Board
The organizational improvement board visualizes and manages all measures, ranging from “inspect and adapt” activities (e.g., retrospective sessions, employee surveys) to improving the efficiency of product delivery. It consolidates best practices, impediments, and improvement measures.
Lean Product Status Report
The product status report consolidates all relevant information for evaluating the progress of product development. It provides transparency regarding the progress of hardware and software development as well as enabling functions. The report identifies areas where management may need to make decisions and take action, and can be used to communicate with internal partners. Its content should be based on data from project planning artifacts, development KPIs—such as maturity growth, test coverage, or defect resolution—and risk assessments that focus on high-risk components, supplier performance, or production readiness. It should be lean and automated as much as possible.
Part 2: Transforming an Organization for Autonomous Driving
The previous chapters provided recommendations for the design of the organization and described the artifacts needed to guide the development of a complex product such as autonomous driving. However, how can this organization be implemented? What should be considered when transforming a traditional development organization into an agile-driven hybrid organization? What pitfalls should be avoided when scaling up the new approach? How can continuous improvement be ensured?
Based on our experience in transforming organizations, the transformation process can be divided into three phases:
- Phase 1: Organizational Design & Transformation Strategy
- Phase 2: Ramp-up of the working model
- Phase 3: Continuous operations with inspect-and-adapt activities
This framework can also be used to determine the status of a transformation currently underway and the steps needed to eventually get back on track.
In Phase 1, the organization’s target vision is developed by tailoring its structure and operating model to align with the target conditions. Of course, this is based on existing and effective approaches, processes, and practices. In addition, the transformation strategy—which defines the goals, scope, resources, and timeline for the transformation—is developed and approved by management.
Phase 2 focuses on scaling up the hybrid work model. It supports a step-by-step increase in the number of agile teams. Experienced coaches empower new roles and facilitate the development of defined practices and agile project management artifacts to support the new work model.
Once the ramp-up is complete, the transformation moves into the inspect and adapt phase (phase 3). This phase establishes a continuous cycle of improvement. Regular retrospectives at various levels of the organization bring obstacles to light and enable the design and implementation of new work practices.
This three-phase approach may be generic and straightforward. Nevertheless, it helps to maintain focus while tackling the transformation. Moreover, the task of building a well-functioning agile organization capable of delivering autonomous driving is challenging, complex, and adventurous. Based on our experience developing complex products using both agile and traditional approaches, we have identified six success factors that contribute to and shape a successful transformation:
- Align the transformation with the delivery of the overall product
- Avoid “big-bang” approaches and build on existing work practices and processes
- Implement a change that is visible
- Ensure strong and lasting support from top management
- Empower people at all levels through training, coaching, and change management tools
- Establish a sustainable “inspect and adapt” process
Align the transformation with the vehicle’s delivery
One of the challenges of the transformation is the immense degree to which it is integrated into day-to-day operations. This can be compared to open-heart surgery. Therefore, the pace of a vehicle project should serve as the driving force for the transformation. Figure 4 provides a recommendation for how the ramp-up can be aligned with the delivery of the overall product. Planning should be focused to ensure that critical milestones of the lead vehicle project are safely achieved. When planning the transformation, it is crucial to strike the right balance between the time required to develop the new working model and a rapid focus on operational delivery. Furthermore, it can be useful to consider different scenarios for the final feature set, given that the pace at which rapid development goals will be achieved will not be clear during the initial stages of the transformation.
Technical development should be aligned with the architecture development of the overall product to create a cohesive AD architecture and product offering. This phase should also be used to ramp up the agile organization in terms of its working model, continuous development, and infrastructure. As soon as the AD architecture is defined, the first cross-functional teams should begin planning and developing basic features. Approximately 2.5 years prior to the final delivery for SOP of the lead derivative, the organization should be scaled up so that it can deliver feature increments on a sprint-by-sprint basis.
Avoid a “big bang” approach and build on existing work practices and processes
One outcome of defining the transformation strategy should be the target vision—an outline of the organization at the end of the transformation and the number of employees who will be part of it. This vision should serve as a guiding principle for implementation from the very beginning. Nevertheless, it is even more important to examine the structure and mechanisms that enable the sustainable scaling and ramp-up of the working model. Additionally, it is important to focus on which aspects to retain, particularly with regard to delivery, critical structures, roles, and processes. Implementing the new working model requires a great deal of learning, flexibility, and adaptation from the organization. New roles, methodologies, and procedures must be taught and further defined. Therefore, it is recommended to avoid a “big bang” approach and to scale the working model using a step-by-step approach. This will also reduce the risk of rejection by recipients and delays in delivery caused by a slowdown in work pace. This defined approach can be illustrated by the mechanism of cell division in microbiology. This will ensure the continuous spread of knowledge and experience regarding the product and the working model throughout the growing organization.
Implement a change that is visible
Although we recommend designing a transformation that avoids a “big bang” approach, this will be crucial to bringing about visible change that reflects the success of the transformation. This means proposing a working model and organizational structure that is clearly distinct from the “old” way of doing business. This can be achieved through various measures:
- Creating new roles, meetings, and processes from scratch.
- Defining an organizational structure that separates disciplinary and technical leadership.
- Creating a work environment (tools and office design) that supports the new way of working.
- Hiring people with experience working under the new work model (including leadership roles).
Ensure strong and lasting support from top management
As with any major change initiative, the support of top management is a critical factor. It is important to recognize that the implementation of a working model will also be influenced by management’s behavior and communication. There are certain aspects of the transformation that require top management to act as a driving force, rather than merely as a superficial supporter of the change. Combined with transparent communication that promotes the working model, the pace of the transformation will increase dramatically. Without this, the transformation will struggle to succeed.
A distinctive feature of this type of transformation is that the new working model will compete with other ways of working within the company. Combined with the fact that it takes time for productivity to ramp up, this competition will put pressure on the new organization. It is the responsibility of top management to relieve the teams of “destructive pressure” and to allow constructive pressure to work in their favor.
Empower people at all levels through training, coaching, and change management initiatives
As mentioned earlier, the agile working model defines a new and adapted set of roles, principles, and processes. These new or updated ways of working must be embedded within the organization. When designing the empowerment strategy, it is important to consider all levels of the process, from top management to key roles such as product owners, technical business leads, Scrum Masters, and feature teams. Each role requires appropriate and ongoing training and coaching to solidify and improve the working model. Both should be tailored to specific roles and avoid so-called “feel-good management.” This requires coaches with extensive experience in the agile development of complex products. It is recommended that coaches and trainers understand the requirements of serial development to ensure that their coaching produces practical solutions focused on the ability to deliver. In addition to training and coaching, tailored change management measures are needed to embed cultural change within the new organization.
Establish a sustainable “inspect and adapt” process
One of the key principles of agile product development is the pursuit of continuous improvement toward perfection. To implement this principle, establishing an effective inspect-and-adapt process is a critical success factor. Most scaled agile blueprints define a set of events and artifacts, such as retrospectives and impediment boards. These are useful and will facilitate continuous improvement. Nevertheless, our experience has shown that a comprehensive approach to a scaled transformation goes beyond what is typically found in a scaled agile context. For the latter, it is important to establish a process that allows for inspection and adaptation across different layers of the working model. Impediments and measures should inevitably be transparent and flow smoothly between different layers. When designing that process, it is important to consider that improvement measures can range from small changes—such as altering the format of a regular meeting—to major changes, such as updating the organizational structure or implementing a process involving many stakeholders.
Conclusion
The development of autonomous driving is one of the biggest challenges facing automotive companies today. When OEMs decide to develop autonomous driving with a significant in-house development component, this requires a profound transformation of their organization. Developing a mechatronic
system with highly complex software functions requires an organization that can deliver flexibly and effectively. Therefore, we recommend establishing a hybrid working model based on strong agile practices, without neglecting traditional approaches such as systems engineering. Before the transformation is implemented, the new organizational structure must be designed. We recommend developing a clear vision for the new organization. The organizational design can draw inspiration from agile frameworks and should be built on the working practices of the core business. Five design principles support the organizational design process. The organization should have synchronized working models tailored to the development task and clear interfaces with vehicle projects and development partners.
Furthermore, the organization should foster a technical focus, learning, and a strong sense of responsibility for enablers, such as data management and the toolchain. We recommend a step-by-step transformation strategy that also incorporates a clear roadmap of artifacts to guide product development. These artifacts should provide transparency regarding development priorities, enable continuous delivery, and identify opportunities to optimize the operating model. The ramp-up should be aligned with the development of the lead derivative and supported by experts with experience in vehicle industrialization and scaling agile development practices. The success factors described in Chapter 2 provide guidance to help avoid further pitfalls inherent in this complex transformation. We are confident that it will be possible to transition to the third phase of the transformation—continuous operation with a robust “inspect and adapt” mode—once these recommendations are followed. This will empower OEMs to deliver the AD product on time for the target SOP and prepare them for the upcoming challenges of developing complex software functions integrated into the vehicle and its ecosystem.
[fl_builder_insert_layout id=”13888″]
