How agile working is driving the development of electric vehicles to its destination

The “Electric Vehicle Architecture” project commanded respect, even from its highly qualified and experienced project participants. This was attributable to the fact that, in addition to the challenge of completely rethinking a car’s design – if only because of the monolithic battery situated in the vehicle’s underbody – it was also necessary to understand objectives and conditions as fluid variables and to successively integrate these into the development process. For example, it was already clear from the project’s outset that battery technology would continue to develop in near quantum leaps during the development phase, and that the company’s own work would have to be constantly adapted to the latest technological standards. Extremely ambitious time-to-market planning, high-level competitive pressure and the necessity of as yet unspecified customer requirements – such as range, thermal comfort or top speed – were the icing on the cake in terms of the project’s complexity. And the newly gained spatial freedom – for example, more room in the interior due to the now obsolete cardan tunnel – demanded to be used intelligently.

The solution was essentially obvious

It was, therefore, clear from the outset that new paths had to be carved out for this project. It proved helpful that agile methods – including swarm organisation – were already supported by the corporate management function through a parallel initiative on leadership culture. The stated goal was to introduce new forms of cooperation. This is because, in identical fashion to the development of new sources of technological potential, the potential hidden within corporate culture and the opportunities for cooperation were also to be developed further. With that, the project team quickly came up with the idea of using agile methods. Other development teams that had already surfed their first wave of agile experience recommended the consulting firm CO Improve, which specialises in the agile development of complex mechatronic products, as a source of support.

Culture as a success factor

In a first move, an invitation was extended to an “Agile Awareness Day” to discuss the topic of agility for a full day with the project managers at Mercedes-Benz AG. All participants were to learn what an agile project means for the company as a whole, and for top management. CO Improve project manager Gerrit Gerland explains: “Especially in large and complicated corporate structures, creating framework conditions for agile working is a challenge. We had the chance to hone director-level awareness vis-a-vis the need for change and were thus able to create, if you will, an island for agile working for this project”. Against this backdrop, it is understandable that the project team reacted somewhat cautiously at first to the project’s proposed implementation with the agile method Scrum.

Change calls for courage

From the client’s point of view, the idea of using a completely new working method for this highly complex task did not sound like a form of simplification at the outset. The fact that the team nevertheless decided in favour of this approach was not least due to the persuasiveness of the consultant team. The decisive factor for the client was, among other aspects, the competence of the CO Improve consultants, because they were able to point to a wide range of experience that also included working on demanding technological development projects. Furthermore, it quickly became clear that more complexity requires more agility, and so there was plenty to do right after the kick-off.

Training on the job

All those involved quickly became aware that the task of introducing agile working methods on the scale of a complete vehicle development is not an everyday challenge either. While agility often begins with individual pilot teams, in this case, it was obvious from the beginning that the transformation of an organisation on par with the size of a medium-sized company was at stake. Therefore, it was important to set up a transformation team as a first step, which was to steer this process precisely and which had the task of defining and implementing the necessary framework conditions. From the get-go, this team became acquainted with the iterative Scrum method. 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 source of orientation. In consultation with the so-called “Product Owner”, the team members draw out the tasks that they can manage in the given time (and according to their experience) from these comprehensive requirements for each sprint. 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.

Free space and framework for a new style of working

To grant the new way of working a suitable framework, the transformation team also developed a new design concept for the pre-planned project space. For example, the usual walls were discarded and, instead, an open area with flexible elements was created. In addition, there was the so-called “Arena”, a type of amphitheatre with grandstands, where the teams met with stakeholders at regular intervals to present their work results, so-called “sprint reviews”. The flexibility underpinning this new agile way of working and thinking was thus also reflected in the working environment. It became a strong symbol of the new way of working. At the official inauguration of the new project space, the Executive Board was also enthusiastic.

Clear structures and responsibilities

In tandem with the developments in spatial design, the team worked on the conceptualisation of an agile organisation. The central task from the beginning was to scale the agile project organisation. In the end, and based on the elements of existing scaling models such as LESS, Nexus and also SAFe, a four-level 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 that, the teams working in an agile way dealt with technology and production. In engineering, things went even deeper. Here, disciplines such as “Interior” and below that, for example, the Cockpit Team, were set up as agile teams. By distributing the teams across all four levels, it was possible to rehearse and design the modes of interaction in the scaling framework at a very early stage. In the Scrum teams, the CO Improve consultants initially took on the role of Scrum Master and supported the Product Owner in filling his role in a “Scrum-friendly” manner. Gradually, these roles were assumed by employees trained in agile methods, so that after just one year, more than fifty development teams were able to work in parallel towards achieving the major goal. The degree of their agility was determined by the complexity of their tasks. For example, designing the seats (known technology, clear requirements) necessitated rather little agility and could be handled with conventional methods, while complex topics such as thermal management or crash behaviour (new technology, unclear requirements) demanded a particularly high degree of agility. Subsequently, a variety of different working methods were used – from conventional development to Kanban teams to comprehensive Scrum.

A corporate Group as a training camp

However, this new agility not only signalled a demanding learning task for the project teams. All other hierarchical levels also had to undergo a rethink. Thus, it was also an experience for top management to adapt the leadership behaviour they had learned to fit the agile design. Given that it was, of course, clear that despite all the agility (and, in particular, due to the great challenges involved), the Directors and the Board remained in charge. Against this backdrop, opening up maximum freedom for the team and showing unlimited trust – even in tense situations – can indeed be an enormous challenge. After all, 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 echelons of management. And it also, at times, required courage from employees to stand firm on certain convictions when going up against management.
This cultural change would probably not have been possible if top management had not given its full support from the beginning. And what is more: Regular reviews of the transformation team, in which the Directors were stakeholders, developed over time into a regular exchange on leadership culture issues. One major key was the expertise and seniority of the CO Improve consultants and, of course, the exceptional openness and willingness to change, right up to the highest management levels of Mercedes-Benz AG.

Shaping agility individually

But there was also a considerable need for adjustment in the opposite direction. For example, the usual Scrum routine – consisting of quickly and simply sketching out results and agreements on flipcharts during reviews, in addition to providing feedback – proved unsuitable for meeting the high demands stemming from documentation and audit security in a listed company. So here, 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 projects running in parallel, as practised in many companies, proved to be an obstacle to agility. If, for example, an application engineer is in charge of four projects at the same time and is, therefore, only available to the team with 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 goals they have set themselves. This is disappointing for everyone involved. And for the employee himself, the split between different tasks can also become an issue, blocking additional time and resources for switching between projects. In some areas, therefore, adjustments were worked out in the division of tasks, which ultimately brought about improvements even for those people not directly involved in the project. The client quickly realised that their specialists were not able to fully take on the required roles due to being involved in several projects. A disruptive factor that had to be eliminated, because: Agile work draws a large part of its performance from team cohesion, identification with the set goals and the will to succeed. The subsequent adjustment of task division brought about a real leap in performance in many teams.

Intelligent scaling to control the overall project

In highly complex and interlinked individual topics, further structures were created over time. And so 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, a working method was installed for a task area with over 100 people with the scaling approach SAFe, which quickly brought success via incremental and coordinated working. Not only this specific scaling, but also the size and complexity of the overall project – with at times up to 50 parallel agile teams comprising a total of several hundred employees – are certainly indicative of the truly special nature that characterises the “agilisation” of a hardware project, and which went far beyond the usual pilot applications.

Together to ensure agile success

After just two years, the CO Improve project was fully handed over to the internal teams and has since been successfully completed. In mid-April, the EQS was the first vehicle from this project to enjoy its market launch. This is a success with which the employees of all involved company and management levels of Mercedes-Benz AG can identify one hundred per cent. The project has thus made a significant contribution to the continuous development that drives the culture of cooperation within the Group in line with its objectives. In the meantime, an intelligent hybrid structure has been established in the company, in which simple tasks are handled conventionally and complex challenges are handled agilely.