The management departments of car manufacturers face challenging times. Beside day-to-day business, there is a need to establish strategic guidelines for product portfolio and organizational setup to ensure todays‘ and tomorrows‘ business successes. These strategic decisions must be taken within a context of emerging players, global trade disputes, crises (e.g., Covid-19) and trends like connectivity, autonomous driving, sharing/subscription services and electrification.

In the case of autonomous driving (AD), the question does not concern whether it will influence the business, but rather how it will influence and how to act as an established global player. Car manufacturers need to decide between fast following or early adapting strategies, make or buy scenarios for hardware and software components and strategic partnerships or cross-company collaboration. Either way, autonomous driving highly influences product development management.

Autonomous driving development challenges are specified by the following characteristics:

• In conjunction with a large strategical transformation associated with high investment costs (e.g., powertrain electrification, new business models such as car sharing)
• Complex global market environment with new rising competitors and potential partners
• Continuously and dynamically changing legal regulations for product safety
• New scaling of technical complexity in terms of sensor technology, data processing and homologation
• High cross-functional interdependencies within AD functions and with regard to other functions of the vehicle
• Limited experience and competencies with the industrialization of large-scale autonomous systems

The outlined challenges cannot only be tackled by way of classical approaches of product development, instead they require agile practices. The latter focus on iterative prioritization and delivery, flexible resource allocation by separation of technical and disciplinary leadership and continuous improvement through inspect and adapt methods. These practices address the unknown aspects of large-scale autonomous systems and enable easier adjustments of strategic directions. However, they lack proven approaches for efficiently handling the tremendous product complexity in hardware and software, the broad range of interfaces to the development partners and methods to comply to required safety regulations (e.g. ISO 26262). Consequently, it is recommended to adhere to classical product development approaches, such as Systems Engineering. Our experience showed us that classical practices such as clear responsibility for product architecture or approval, a maturity-oriented, top down development logic, from complete vehicle down to component level, defined governance and reporting structures, as well as proven cooperation models with internal & external interface partners are crucial elements to handle complexity and establish processes to comply with the requirements to homologate an autonomous vehicle. The challenge is to decide upon the appropriate practices from both worlds in order to establish an interwoven hybrid working model. This article gives insights and guidelines for mastering the transformation from a classical, Systems Engineering oriented driver assistance development department to an organization which can deliver autonomous driving.

Figure 1 shows the content of this article. A successful organizational transformation begins with the definition of the organizational setup, which forms the content 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 which should be considered during this transformation.

Part 1: Definition of an Organization for Autonomous Driving

As outlined in the introduction, autonomous driving cannot be developed with solely a classical or Systems Engineering oriented organization. Prior to the start of the transformation, a clear vision of the organization and its operating model should be designed. As proposed, a hybrid model using agile principles and incorporating classical good practices can work well. How should the organization be structured? Which artifacts are required to keep the organization with speed on track?

Our experience has been that frameworks for agile scaling, such as SAFe or LeSS, offer a valuable orientation. Nevertheless, we agree on two main reasons as to why they should only be seen as a starting point for the tailoring of an organizational setup:

• 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 consider the legacy of the company and the ecosystem that needs to be taken into account

Therefore, this chapter shall provide design principles for the tailoring of an organizational structure and a set of artifacts that are helpful in discerning the detailed design of the working model.

Design Principles for an Organization to Deliver Autonomous Driving

The design of the organization should be based on five design principles shown in Figure 2.

The five design principles are described in the following paragraphs:

1. Separate responsibility for product value (What) and development efficiency (How)
2. Structure the DEV organization based on product architecture and development task
3. Establish technical communities to foster cross-linked learning
4. Establish strong and centralized enabling functions
5. Install dedicated roles to ensure clear interfaces for the vehicle project and development partners

Principle 1: Separate responsibility for product value and development efficiency

The first principle for the organizational design addresses the overarching structure of the organization. In order to ensure flexibility and speed, the organization should separate the what and how by establishing a separate product owner (PO) and development organization (DEV). The PO organization focuses on the optimization of the product value, whilst the DEV organization focuses on development efficiency. By way of the separation of leadership responsibility, speed can be gained. The technical leader (PO) ensures that the output is clearly defined and prioritized. The disciplinary leader (DEV) ensures the efficiency of the output generation. Especially with regard to multi-product development, flexibility is gained through easy and fast reallocation of development resources based on alterations in requirements and prioritizations. If the DEV is structured sufficiently, the development tasks can change frequently without the need to make adjustments to the teams and 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 task

The development organization shall provide a development workforce with maximum efficiency. The latter can be ensured by implementing a structure that considers product architecture and the development task. An agile working model works best for the development of the SW-stack, due to the strong uncertainty and interdependencies of autonomous driving technology. The agile teams thriving in this working model should be structured in accordance with the product architecture. The architecture should consider customer features, as well as SW-services that provide the basis for implementing the respective features. Teams should be cross-disciplinary and have an end-to-end responsibility for their functional scope (development, testing, industrialization, planning and synchronization with stakeholders). With regard to hardware development (e.g., sensors, control units) and the steering of function procurement (e.g., AUTOSAR platforms) within the DEV-organization, we recommend the application of hybrid or classical working models, e.g., of which a top down V-Model approach including iterative processes, especially on the level of implementation, is one example. Hybrid and classical working models enable more precise and detailed planning through work packages and deadlines, which are more suitable approaches to these development tasks.

Principle 3: Establish technical communities to foster cross-linked learning

The “task” of autonomous driving development is characterized by its enormous technological novelty and complexity (e.g., time-synchronized sensor-data fusion).

Therefore, the organizational structure should support the focus on critical technology and the ability to incorporate and adapt to learnings. This is achieved by the institutionalization of overarching technical communities.

Technical communities should act orthogonal to the development teams within the DEV-organization and incorporate personal responsibility with regard to topics like architecture, verification, safety or critical sensors. They should ensure that enabling infrastructure and critical development artifacts (e.g., product architecture) are available. The 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. Due to the separation of disciplinary and technical leadership, the DEV-organization is kept lean and the premise that learnings are transferred in the development teams is ensured. This setup also includes that the “old” and established roles necessary to deliver safety critical system, such as System Integrators, Simulation and Testing Engineers should be considered 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”. So as to safeguard that these functions are implemented sustainably we recommend the anchoring of centralized and powerful departments within the organization, or to establish mandated and clearly responsible communities.

The unit for “processes and methods” ensures the definition and improvement of the working model and secures development process conformity. It provides general development tools (e.g., backlog management) and is responsible for synchronizing the agile and classical processes such as development planning, requirements management or defect resolution management. Furthermore, it assures that the development processes conform to standards such as Automotive Spice and ISO26262 (Norm on Functional Safety).

The “IT-Infrastructure” ought to provide an integrated and scalable tool-landscape for continuous delivery and data driven development. The four main challenges for the setup of the IT-infrastructure are the following:

• training of algorithms requires the handling of huge amounts of data
• development and test sites are decentralized and spread globally
• SW-functions need to be continuously integrated and verified on test- and target-systems
• safety regulations and product complexity require consistent traceability between models and tools

A consistent strategy that is fully implemented is required in order to tackle these challenges. Therefore, we recommend the setup of a centralized department with strong and experienced

leadership, which is able to scale up an infrastructure that runs globally and is smoothly interconnected internally, as well as with attached systems of the company and partners.

The department for “integration and verification“ ensures that maturity and quality of the product are continuously verified. In addition to other supporting functions, it should setup and maintain robust integration and verification processes and tools, allowing for early and fast feedback loops. Furthermore, it provides a reliable test infrastructure (e.g. SW-/HW-in-the-loop, test-fleets).

Principle 5: Install dedicated roles to ensure clear interfaces to vehicle project and development partners

The success of autonomous driving product development is strongly dependent on the degree to which it is coordinated with partners (internal and external) and on how well the product integrates into the rest of the vehicle (e.g. user interface, brake system). Therefore, working model and organizational structure should clearly allocate responsibilities to manage the interfaces of the vehicle project organization and further development partners (e.g., center of competences (CoCs), modular kits or suppliers).

“Interface managers” plan and facilitate the exchange between partners and roles within the AD development working model. With regard to the vehicle project and development partners with minor dependencies, they need to guarantee an early exchange of relevant development information (e.g., requirements or project-schedules). As for development partners and CoCs with major dependencies, they need to manage and coordinate cooperation activities proactively (e.g., concept- or toolchain-validation-workshops). If these roles are not well embedded in the organizational setup and equipped with enough impact, a high risk occurs that the expected product maturity is not achieved, in the case of integrating functionalities (software or hardware) from different suppliers or whilst integrating the entire system. We learned from different projects that it is a reliable procedure to assign dedicated roles within each development team for key interactions, e.g. vehicle integration.

Artifacts for Leading Autonomous Driving Development

The product complexity of autonomous driving requires a more systematic approach then it is needed in SW-only agile projects. Therefore, it is crucial to build a consistent methodology and right tools to lead the product development parallel to the organizational design.

Figure 3 gives an overview of the artifacts that, to our experience, are essential for enabling a fast and flexible development which is still able to achieve the defined goals for quality, safety and budget. The artifacts are described below.

Strategic vision

The strategic vision defines the outline of the product to be developed. It defines strategic goals, the set of functionalities, decisions on cooperations and make or buy for major product scopes.

(Sub-)Product- and development area-backlogs

The product backlog is the hierarchical breakdown of the work which needs to be implemented so as to deliver the product vision. It decomposes the strategic goals via defined levels (e.g., epics, features, maturity grades, user stories). The items of 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 planning (covering the entire project duration) including goals, critical results, maturity gates and further synchronization points relevant for 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 to release plan and product backlog, a clear concept is required when distinguishing planning tools and methodology.

Release plan

The release plan is the mid-term planning (~1 – 6 months) of the product delivery. It determines a defined level of product backlog and every work item that should be delivered in the next (1-3) releases. Story point estimation supports plausibility checks during the planning. The release planning needs to incorporate most stakeholders from product owner, enabler communities and teams. Therefore, it is crucial to set up a robust and efficient release planning process, in order to ensure consistent prioritization and the clarification of interdependencies.

Sprint Backlog

The sprint backlog is a view on all work items planned for a sprint, which can be specified per team, sub-product or development area. Each backlog item is evaluated in the sprint review at the end of each sprint. It is a common practice to further detail sprint items of the sprint backlog in a physical backlog per sprint and team.

Besides the agile project planning artifacts, it is important to implement tools for transparency on the performance of the working model and the progress of the product delivery.

Organizational improvement board

The organizational improvement board visualizes and manages all measures from inspect and adapt activities (e.g., retrospective events, employee surveys) to improving the efficiency of the product delivery. It consolidates good practices, impediments and improvement measures.

Lean product status report

The product status report consolidates all relevant information to evaluate the progress of product development. It offers transparency of the progress of hardware-, software-development and enabling functions. The report indicates areas of prospective decision and action on behalf of the management 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 which focus on high-risk parts, supplier performance or production readiness. It should be lean and automated as much as possible.

Part 2: Transformation of an Organization for Autonomous Driving

The previous chapters gave recommendations for the design of the organization and describedartifacts needed to steer the development of a complex product like autonomous driving. However, how can this organization be implemented? What should be considered when transforming a classical development organization into an agile driven hybrid organization? Which pitfalls should be avoided when ramping up the new approach? How to ensure continuous improvement?

According to 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 working model
• Phase 3: Continuous operations with inspect & adapt activities

This frame can also be used to determine the status of a currently conducted transformation and the measures necessary to eventually correct the course.

In phase 1 the target vision of the organization is created by tailoring the structure and the working model in accordance with the target conditions. Of course, this is based on existing and working approaches, processes, practices. Additionally, the transformation strategy that defines the goals, the scope, the resources, and the timeframe for the transformation is developed and approved by the management.

Phase 2 concentrates on the ramp up of the hybrid working model. It supports a step-by-step increase of agile teams. Experienced coaches empower new roles and facilitate the buildup of defined practices and agile project management artifacts to support the new working model.

Once the ramp-up is completed, the transformation passes into the inspect & adapt phase (phase 3). This phase establishes a continuous rhythm for improvement. Regular retrospectives on different levels of the organization make impediments visible and allow the design and implementation of new working practices.

This three phases approach may be generic and straightforward. Nevertheless, it helps to focus whilst tackling the transformation. Moreover, the assignment of building a well-functioning agile organization that can deliver autonomous driving is challenging, complex and adventurous. From our experience with the development of complex products following agile and classical approaches, we derived six success factors that make for and shape a successful transformation:

1. Align transformation to the delivery of the overall product
2. Avoid big-bang approaches and build on working practices/processes
3. Implement a change that is visible
4. Ensure a strong and lasting top management support
5. Empower people on all levels by training, coaching and change management tools
6. Establish a sustainable inspect and adapt process

Align transformation to the delivery of the vehicle

One of the challenges of the transformation is the immense degree to which it is integrated into the running business. This may be compared to an open-heart surgery. Therefore, the pulse of a vehicle project should be the driving sequence for the transformation. Figure 4 gives a recommendation for how the ramp-up can be aligned with the delivery of the overall product. The planning should be focused, in order for critical milestones of the lead vehicle project to be safely reached. When planning the transformation, it is pivotal to find the right balance between the time that is needed for the evolvement of the new working model and a fast focus on operational delivery. Furthermore, it can be useful to consider different scenarios for the final feature set, considering that the speed at which fast development goals will be achieved will not be clear during the initial stages of the transformation.

The technical development should be aligned with the architecture development of the overall product to create a harmonic AD architecture and product offering. This phase should also be used to ramp-up the agile organization in terms of working model, continuous development and infrastructure. As soon as the AD architecture is defined, first cross-functional teams should start with the planning and development of basic features. About 2,5 years prior to the last delivery for SOP of the lead derivate, the organization should be ramped up for it to deliver feature increments sprint wise.

Avoid big-bang approach and build on working practices/processes

One output of the definition of the transformation strategy should be the target vision, the outline of the organization at the end of the transformation and how many employees shall be part of it. This vision should be a guiding principle for the implementation from the beginning. Nevertheless, it is even more important to look at the structure and the mechanisms that enable a sustainable scaling and ramp-up of the working model. Additionally, it is important to focus on what aspects to keep, especially with regard to delivery, critical structures, roles and processes. Implementing the new working model demands a lot of learning, flexibility and adaptation from the organization. New roles, methodologies and procedures must be trained and further specified. Therefore, it is recommended to avoid a big-bang approach and to scale the working model by way of a step-by-step approach. This will also reduce risks of rejection by recipients and delays of delivery by the slowdown of working speed. This defined approach can be illustrated by the mechanism of cell-division from microbiology. This will ensure the continuous spread of knowledge and experience regarding the product and working model across the growing organization.

Implement a change that is visible

Even though we recommend designing a transformation that avoids a big-bang approach, this will be crucial to establishing a visible change in accordance with the success of the transformation. This means pitching a working model and organizational structure that is clearly distinct from the “former” way of doing business. This can be achieved by different measures:

• Coining specifically new roles, meetings and processes.
• Defining an organizational structure that separates disciplinary and technical leadership.
• Creating a working environment (tools & office architecture) that supports the new way of working.
• Employing people with experience in working in the new working model (leadership as well).

Ensure a strong and lasting top management support

As is the case for any major change initiative, the support of top management is a critical factor. It should be considered that the implementation of a working model will be influenced also by management behavior and communication. There are certain aspects of the transformation that require the top management to act as a driving force, rather than just as a cosmetic supporter of the change. Combined with a transparent and pro-working model communication, the time of the transformation will increase dramatically. Without this, the transformation will have difficulties to succeed.

It is particular to this type of transformation that the new working model will be competing with the other ways of working in the company. In combination with the fact that the productivity ramp-up needs time, this competition will put pressure on the new organization. It is the top management’s responsibility to release “destructive pressure” from the teams and to let constructive pressure work for them.

Empower people on all levels by training, coaching and change management measures

As mentioned before, the agile working model defines a new and adapted set of roles, principles and processes. These new or updated ways of working must be anchored within the organization. When designing the concept for empowerment, it is important to consider all levels of the procedure, from top management to key roles such as product owners, technical business leads, scrum masters and feature teams. Each role needs appropriate and continuous training and coaching to solidify and improve the working model. Both should be focused on specific roles and avoid so-called feel-good management. This requires coaches with strong experience in agile development of complex products. It is recommended that coaches and trainers know the requirements of serial development, so as to guarantee a coaching that sketches solutions that are practical and focused on the ability to deliver. In addition to training and coaching, tailored change management measures are needed to anchor cultural change within the new organization.

Establish a sustainable inspect and adapt process

One of the key principles of agile product development is the striving for continuous improvement towards perfection. In order to implement this principle, it is a critical success factor to establish an effective inspect and adapt process. Most scaled agile blueprints define a set of events and artifacts, such as retrospective and impediment boards. They are useful and will facilitate continuous improvement. Nevertheless, our experience has shown that a comprehensive approach for a scaled transformation goes beyond the one found in scaled agile context. For the latter, it is important to establish a process that allows for inspection and adaptation on 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 measures can lead from small improvement measures, such as changing the format of a regular meeting, to big improvement measures like updating the organizational structure or implementing a process with many stakeholders.

Conclusion

The delivery of autonomous driving is one of the biggest challenges of automotive companies today. When OEMs decide to develop autonomous driving with a relevant own development share, this requires a profound transformation of their organization. Developing a mechatronic
system with highly complex software functions requires an organization that delivers flexibly and effectively. Therefore, we recommend establishing a hybrid working model based on strong agile practices, without neglecting classical approaches like Systems Engineering. Prior to the transformation being implemented, the new operating system has to be designed. We recommend developing a clear target vision of the new organization. The design of organization can be inspired by agile frameworks and should be built on working practices of the core business. Five design principles support the process of organizational design. The organization should have synchronized working models tailored to the development task and clear interfaces to vehicle projects and development partners.

Furthermore, the organization should foster technical focus, learning and a strong responsibility for enablers, such as data management and toolchain. We recommend a stepwise transformation strategy that also incorporates a clear roadmap of artifacts to lead product development. These artifacts should enable transparency on development priorities, the ability to deliver continuously and optimization potentials of the operating model. The ramp-up should be aligned with the development of the lead derivate and should be supported by experts experienced in the industrialization of vehicles and scaling of agile development practices. The success factors described in Chapter 2 offer an orientation, so as to avoid further pitfalls that are inherent to the complex transformation tackled. We are confident that it will be possible to transfer into the third transformation phase – 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 upcoming challenges of the development of complex SW-functions integrated into the vehicle and its ecosystem