How agile working drives the development of electric vehicles and leads to the goal

The Electric Vehicle Architecture project commanded the respect of even the most highly qualified and experienced project participants. In addition to the challenge of completely rethinking the design of a car - if only because of the monolithic battery in the underbody - it was also necessary to understand objectives and conditions as variable variables and to successively integrate them into the development. For example, it was already clear at the start of the project that battery technology would continue to develop in large steps during the development phase and that the company's own work would have to be constantly adapted to the current status. An extremely ambitious time-to-market plan, high competitive pressure and the need to completely redefine customer requirements that had not yet been clearly defined, such as range, thermal comfort or top speed, also played their part in maximising the complexity of the project. And the newly gained free space - such as more room in the interior due to the cardan tunnel no longer being required - also demanded to be utilised intelligently.

It was therefore clear from the outset that new paths had to be taken for this project. It proved helpful that agile methods, including swarm organisations, were already supported by the Group management through a parallel initiative on leadership culture. The declared aim was to introduce new forms of collaboration. In line with the development of new technological potential, the aim was also to further develop the potential of corporate culture and collaboration. The project team quickly came up with the idea of using agile methods. Other development teams that had already gained initial agile experience recommended the consulting firm CO Improve, which specialises in the agile development of complex mechatronic products, for support.

They first organised an 'Agile Awareness Day' to discuss the topic of agility with the project managers at Mercedes-Benz AG for an entire day. The aim was for everyone involved to understand what an agile project means for the entire company and also for top management. CO Improve project manager Gerrit Gerland explains: "Especially in large and complicated corporate structures, creating a framework for agile working is a challenge. We had the opportunity to sharpen the perception of the need for change at director level and were thus able to create a kind of 'island for agile working' for this project". Against this background, it is understandable that the project team initially reacted somewhat cautiously to the proposal to implement the project using the agile Scrum method.

From the client's point of view, the idea of using a completely new working method for this highly complex task did not exactly sound like a simplification at first. The fact that the team nevertheless decided in favour of this approach was due not least to the persuasiveness of the team of consultants. Among other factors, the expertise of the CO Improve consultants was decisive for the customer, as they were able to point to a wide range of experience, including with demanding technological development projects. In addition, it quickly became clear that more complexity requires more agility and so there was a lot to do right after the go-ahead.

Everyone involved quickly realised that the task of introducing agile working methods on the scale of a complete vehicle development is not an everyday challenge. While agility often starts with individual pilot teams, it was clear from the outset that we were dealing with the transformation of an organisation the size of a medium-sized company. As a first step, it was therefore important to set up a transformation team to manage this process and to define and realise the necessary framework conditions. At the beginning, this team familiarised itself with the iterative Scrum method. The central elements of Scrum are clearly defined roles for all team members and the organisation of work in so-called "sprints", which repeatedly lead to a usable result. The so-called "product backlog", in which all requirements and goals are defined, serves as a guide. In consultation with the product owner, the team members select the tasks for each sprint from these comprehensive requirements that they are able to complete within the specified time. The team is supported by the "Scrum Master", who has the task of communicating the agile values and principles to the team, moderating the agile events and removing obstacles that prevent the team from working efficiently.

The team worked on the design of the agile organisation in parallel with the room design. The central task from the outset was to scale the agile project organisation. Based on the elements of existing scaling models such as LESS, Nexus and SAFe, a four-stage set-up from overall project management to simultaneous engineering teams was designed. The first new agile teams were formed on this basis. From the outset, it was important to have at least one pilot team at all levels, as the connection between the levels was a critical success factor. At the top level, the cross-functional project team was set up as a pilot. Below this, the teams that dealt with technology and production worked in an agile manner. Things then went even deeper in technology. Here, trades such as the interior and below that, for example, the cockpit team were set up as agile teams. By distributing the teams across all four levels, interaction within the scaling framework could be trialled and designed at a very early stage.

From coaching to self-organisation: 

agility applied in a differentiated way

In the Scrum teams, the CO Improve consultants initially took on the role of Scrum Master and supported the Product Owner in fulfilling his role in a "Scrum-compliant" manner. Gradually, these roles were then taken over by employees trained in agile methods themselves, so that after just one year, more than fifty development teams were able to work on the big goal in parallel. Their degree of agility was determined by the complexity of their tasks. For example, the design of the seats (known technology, clear requirements) required little agility and could be handled using conventional methods, while complex topics such as thermal management or crash behaviour (new technology, unclear requirements) required a particularly high degree of agility. As a result, a variety of different working methods were used - from conventional development to Kanban teams to comprehensive Scrum.

However, the new agility was not only a challenging learning task for the project teams. All other hierarchical levels also had to rethink their behaviour. It was also an experience for top management to adapt the leadership behaviour they had learned to the agile structure. Of course, it was clear that despite all the agility and, in particular, the major challenges, directors and the Executive Board remained responsible. Against this backdrop, giving the team maximum freedom and placing unlimited trust in them, even in tense situations, can indeed be an enormous challenge. Because in an agile culture, the management level primarily takes on the role of empowering employees to solve their tasks. This means strengthening personal responsibility, removing obstacles and creating the best possible framework conditions. Internalising this new self-image was also an exciting development task for the highest management levels. And it also sometimes required courage on the part of employees to defend certain convictions to the management level.

This cultural change would probably not have been possible if top management had not given their full support from the outset. What's more, the regular reviews of the transformation team, in which the directors were stakeholders, developed over time into a regular dialogue on leadership culture issues. A key factor was the expertise and seniority of the CO Improve consultants and, of course, the great openness and willingness to change right up to the highest levels of management at Mercedes-Benz AG.

However, there was also a considerable need for adaptation the other way round. For example, the usual Scrum routine of quickly and easily outlining results and agreements on flipcharts during reviews in addition to feedback proved to be unsuitable for meeting the high documentation and audit compliance requirements of a listed company. Conversely, the agile methods had to be adapted to meet the requirements of the organisation.

There was also a need for adaptation at an organisational level. For example, the division of specialists into several parallel projects, as practised in many companies, proved to be an obstacle to agility. If, for example, an application engineer is responsible for four projects at the same time and is therefore only available to the team for a quarter of his working time, this results in waiting times and delays. It can then become difficult for the team to actually achieve the sprint targets it has set itself. This is disappointing for everyone involved. And for the employees themselves, splitting their time between different tasks can also become a problem, blocking additional time and resources for switching between projects. In some areas, adjustments were therefore made to the division of tasks, which ultimately also brought improvements for people not directly involved in the project.

The customer quickly realised that its specialists were unable to fully assume the required roles due to their involvement in several projects. A disruptive factor that had to be eliminated, because: Agile work draws a large part of its efficiency from team cohesion, identification with the goals and the will to succeed. The resulting adjustment to the division of tasks led to a real leap in performance in many teams.

Over time, further structures were created in highly complex and interlinked individual topics. It quickly became clear how many people and teams were working on the new type of drive. In particular, the interconnectedness of the topics and the technical complexity required new approaches. In this field, the SAFe scaling approach was installed for a task area with over 100 people, a working method that quickly brought success through incremental and coordinated work.

This specific scaling, as well as the size and complexity of the overall project with up to 50 parallel agile teams with a total of several hundred employees, certainly represent an absolutely unique feature in the agilisation of a hardware project and went far beyond the usual pilot applications.

After just two years, the CO Improve project was fully handed over to the internal teams and has now been successfully completed. In mid-April, the EQS was the first vehicle from this project to be launched on the market. This is a success with which the employees of all involved company and management levels at Mercedes-Benz AG can identify one hundred per cent. The project has made a significant contribution to ensuring that the culture of cooperation within the Group has developed in line with the objectives. An intelligent hybrid structure has now been established within the company, in which simple tasks are handled conventionally and complex challenges in an agile manner.