ALL EYES ON AGILE...?

YOUNGER, FASTER, MORE DIGITAL. THE DEVELOPMENT OF SMART PRODUCTS CHANGES TEAMS AND PROCESSES IN THE R&D ORGANIZATION.

In search for suitable cooperation models, companies often resort to standard methods from the textbook on agile product development - and fail to do so. Because methods & tools alone are not enough. If you want to successfully transform your R&D team, you must first empower the organization itself.

In order to understand which phase of upheaval the R&D department is currently going through, it is worth first taking a look at another corporate function: For example, a VDI survey of HR managers shows that the proportion of classic engineers should fall from currently just under two-thirds to below 50 percent within the next five years - while at the same time the demand for IT specialists and IT engineers is rising massively. In the battle for the coveted IT experts, this initially means a special challenge for classic industrial companies. But building new skills alone is not enough. Efficient processes are only possible if companies manage to integrate them successfully into the existing development organization. The new requirements of a smart product development have to be considered:

  • NEW COMPETENCIES & METHODS
    As the proportion of software in products increases, so does the need for new competencies in R&D: software developers and similar functions introduce new ways of working and change the composition of teams and the culture in the development organization.
     
  • HIGHER COMPLEXITY OF THE SYSTEMS
    Smart products consist of a large number of physical and non-physical components, some of which have very different development times. This increases the complexity and coordination effort in the overall system.
     
  • SHORTER INNOVATION CYCLES
    Particularly in B2C-related industries, product updates take place at ever shorter intervals and thus place new demands on development speed.
     
  • CONSIDERATION OF THE ENTIRE PRODUCT LIFE CYCLE
    The software component in the products extends the development phase into ongoing operation. Resources in the development organization are thus tied to a product for much longer.

The pressure on companies to adapt their processes to these changed conditions of digital product development often promotes the adaptation of new tools and methods. Under the buzzword of “agile product development”, many of them rely on well-known frameworks from software development, such as Scrum, SAFe, LeSS or Nexus. However, the introduction of agile methods alone does not usually lead to better collaboration, as they are not transferable to most organizations one-to-one. Rather, the understanding of the cooperation between the individual roles in the development department must first be sharpened and the processes and organizational structures aligned accordingly.

DEVELOPMENT UNDER LABORATORY CONDITIONS

This begins with the organizational structure of development teams and their location within the company. Depending on the nature of the innovation project, it may make sense, for example, to outsource it from the existing organization, for example in the form of spin-offs of the core company. This is particularly the case if it is a fundamentally new technology, its development and the methods used could overtax the existing organization and thereby slow down the speed of development. Conversely, the functioning existing business can thus be protected against the risks of new developments. However, the central challenge with this type of approach is the re-integration of the outsourced area into the core organization after completion of the development and the achievement of synergy effects between the existing and the new development organization.

WITH COMMUNICATION AGAINST SILO FORMATION

In the case of the expansion of existing products by a software component, however, the main objective is to synchronize the development flows, which are synchronized in different ways, and to prevent the creation of silos within the development department. This requires a highly integrated approach with regular synchronization points between the individual disciplines. In development departments that are organized according to separate specialist teams, such as hardware, software or electronics development, this requires a high level of planning and communication effort. Cross-functional teams made up of specialists from the various disciplines provide a counter-draft to this and are thus able to fully implement smart components from start to finish. This not only increases transparency with regard to mutual dependencies in the development process - the development speed can also be substantially increased through parallel interdisciplinary work on individual components.

THE ORGANIZATION CHART FOLLOWS THE TASK

For most companies, this means a real paradigm shift: In smart product development, instead of a fixed development organization structured according to specialist terminology, a flexible organization of changing and interdisciplinary microgroups is used, which work together on a specific task for a limited period of time before they reassemble themselves. Therefore, it is no longer the technical orientation that is decisive for the team membership of an employee, but the task he or she is currently working on. This increases the dynamics of the development organization in two ways. On the one hand, team members switch between teams more frequently and faster. On the other hand, the individual development packages or increments are generally smaller in size, thus enabling more closely timed release cycles. Irrespective of the choice of individual methods, this flexibility is at the heart of agile product development.

ACCOMPANYING THE TRANSFORMATION SUCCESSFULLY

Not only for the organization as a whole, but also for the individual employees, this agile approach represents a radical break with familiar ways of working. In order not to lose them on the way to a new form of agile cooperation, companies and their managers must intensively accompany this transformation process. Five premises apply:

1. THE RIGHT WORKING METHOD FOR THE RIGHT PROCESS

Smart products consist of different components with sometimes very different development cycles. This makes it all the more important to find and adapt the appropriate method for each process type and each project. The motto “one does fit all” does not apply. While SCRUM, for example, provides a high added value for the software sector, it can be a hindrance in mechanical development.

2. DESCRIBE OBJECTIVES AND JUSTIFY METHODOLOGY

Agile methods must not only create added value for the company, for example in the form of shorter increments or release cycles - this added value must also be clearly communicated and justified to the employees. It must become clear that this is not just a change of method, but a new understanding of the product life cycle.

3. FIRST ADAPT - THEN QUALIFY

Training and qualification play a central role in this context. However, you can only train effectively if you know what. Because standard training courses work just as little as standard methods. Therefore, the following applies: first find the method, then adapt it and finally qualify it in a targeted manner. Individual training plans and department-specific training are key success factors.

4. STEP-BY-STEP INTRODUCTION

In order not to overtax the organization and its employees, it is advisable to gradually introduce new working methods in selected pilot teams. The experience gained there can then be used to transfer it to the other areas.

5. SHOW SUCCESS

At the same time, the pilot phase also creates visibility for the new methods in the organization and thus helps to reduce resistance and demonstrate the effectiveness of the processes used.

ACCOMPANYING THE TRANSFORMATION SUCCESSFULLY

Not only for the organization as a whole, but also for the individual employees, this agile approach represents a radical break with familiar ways of working. In order not to lose them on the way to a new form of agile cooperation, companies and their managers must intensively accompany this transformation process. Five premises apply:

1. THE RIGHT WORKING METHOD FOR THE RIGHT PROCESS

Smart products consist of different components with sometimes very different development cycles. This makes it all the more important to find and adapt the appropriate method for each process type and each project. The motto “one does fit all” does not apply. While SCRUM, for example, provides a high added value for the software sector, it can be a hindrance in mechanical development.

2. DESCRIBE OBJECTIVES AND JUSTIFY METHODOLOGY

Agile methods must not only create added value for the company, for example in the form of shorter increments or release cycles - this added value must also be clearly communicated and justified to the employees. It must become clear that this is not just a change of method, but a new understanding of the product life cycle.

3. FIRST ADAPT - THEN QUALIFY

Training and qualification play a central role in this context. However, you can only train effectively if you know what. Because standard training courses work just as little as standard methods. Therefore, the following applies: first find the method, then adapt it and finally qualify it in a targeted manner. Individual training plans and department-specific training are key success factors.

4. STEP-BY-STEP INTRODUCTION

In order not to overtax the organization and its employees, it is advisable to gradually introduce new working methods in selected pilot teams. The experience gained there can then be used to transfer it to the other areas.

5. SHOW SUCCESS

At the same time, the pilot phase also creates visibility for the new methods in the organization and thus helps to reduce resistance and demonstrate the effectiveness of the processes used.

BOTTOM LINE

This systematic approach makes it clear that agile product development involves more than the introduction of individual working methods. Rather, it is a matter of a holistic transformation of the R&D area. It includes structural and procedural changes, such as composition and communication within and between development teams, as well as the sensitization and qualification of individual employees.