Agile transformation at leading manufacturer of household products

Sometimes change needs an initial push and someone to ignite that initial spark. In 2016, such a change started at our client when a hardware development team began to try agile approaches in product development. Agility was supposed to help develop better products and create more efficiency. The igniting pioneer was the design manager at the time. His good experience and previous knowledge, but also his uncomplicated approach, as well as his gift for motivating the team extraordinarily, were the sparks for a pilot project that were decisive for success.

The first goals: To accelerate the development of a prototype through agile working and to integrate feedback into the ongoing development process and the corresponding iterations. This pilot project successfully developed a new core product for the company and generated management attention, so that further agile teams were set up. This successful test balloon paved the way for a workshop with R&D management to learn more about agile working. The management supported the change to more agility from the beginning and thus contributed significantly to the success. The successful pilot paved the way for a broader discussion of the topic.

As a result, the group brought in CO Improve to expand and professionalise agility in development. Especially at the start, it was important to consistently fill all roles with Scrum Masters, Product Owners or the Development Team. It was important to ensure an optimal start phase. That's why the external consultants from CO Improve took on the role of Scrum Master and agile coach on an interim basis.

Extend to other product development projects

After the successful start in the pilot project, the challenges of extending agile working methods to other product development projects in the company began. What worked well in the pilot thanks to the great commitment of a few convinced pioneers now had to be implemented on a larger scale with a good dose of persuasion. Awareness training for the employees was just as valuable here as the personal experiences from the circles of the agile-experienced employees and the already tested colleagues from the pilot team.

Another hurdle was the allocation of resources to the teams: In addition to permanent team members, overarching specialists for a topic area from specific specialist areas had to be integrated in several agile processes. Here, with a core team and an extended team, the framework conditions were created to integrate specialists in an agile way without being permanently integrated as a member of the core team.

Furthermore, the role of the product owner was based on a team solution, a so-called "trio" with two different focal points. One focus had a more overarching and externally oriented focus and the other was more on the development teams with a technically oriented role. In addition, the position of product manager was integrated. This was necessary because the requirement profile for a product owner could not be fulfilled by individual persons, as this scope of tasks did not exist in the company before. With the combination of knowledge and experience of product managers and project managers, the PO role could be filled well. However, clear rules had to be defined for this POT (Product Owner Team) to ensure smooth cooperation with the other members of the Scrum teams.

The problems of the lack of Scrum Masters in some teams were overcome by external interim solutions and rapid qualification measures of own employees. It was precisely in this decisive phase that the CO Improve consultants were able to bring their expertise to bear. By filling this important specialist role (Scrum Master), their experience came into its own. This not only gave the teams the necessary security in this essentially important phase, but also a decisive motivational boost and the necessary incentive.

The hierarchical constellation of staff and group leaders was also broken up for the cooperation. Previously, the group leader was heavily involved in the project work and thus had hardly any time for the further development of the employees. Therefore, a new role was created with the "design lead" as the first contact person for technical questions. The task of the group leader was now to coach in the project with technical expertise, while the staff made decisions for the components they were developing themselves. The new setup resulted in a smooth adoption of roles. The self-organisation also came into play: a guild was formed with regular meetings that preserved the uniformity of the specialist discipline of construction. This type of exchange was also a model for other departments.

Implementation of a transformation team

After the roles of the individual teams had been consistently filled, it was now necessary to create a connection to all teams. This overarching task could no longer be covered by the team-internal Scrum Masters. To support this, a transformation team was formed, consisting of team members, the HR department and managers. The task was to create additional framework conditions, set up further training programmes, revise the product development process and increase the attractiveness of the new roles.

The transformation team also provided important support, for example in the design of new processes on how customers can be involved in product development at an early stage. This understanding of the customer had to be anchored in the development team, because the development engineers influence the design of the product with their decisions, which thus have a direct impact on the customer. At the same time, this knowledge is meaningful for the entire product development team, whose common goal is derived from the customer's needs. The team members then no longer perform assigned tasks, but create concrete added value for the customer on their own responsibility.

Extension to pre-development projects

With the good experiences from the development projects, it was a logical next step to also set up the pre-development projects successively in an agile way. As soon as several people were working on such a project, agile methods such as sprints were used. These were systematically expanded from the point when more employees were involved. Until all roles of an agile team were filled and the Scrum framework could be fully implemented. These projects also benefited from the premise of agile working to create samples or prototypes in the sense of an MVP (Minimum Viable Product) as quickly as possible in order to be able to get direct feedback from customers on the product idea.

Another milestone in agile development was the move to a new building. The seating arrangement here no longer corresponded to the specialist functions, but was geared to the needs of agile teams with great spatial proximity and the corresponding equipment.

Another learning: "Not every phase of product development requires the same agility," says Schönebeck, lead consultant at CO Improve. In the development phases of prototype or functional testing, the Scrum methodology proved to be oversized. To reduce the effort, the teams resorted to Kanban. This showed self-organisation to select the appropriate method for the need. This was also evident in the changeover to home office: productivity and efficiency remained constant.

First scaling and synchronisation with the agile software development process

Already in the early stages of the transformation, it became clear to everyone involved that the management of content, information and decisions in projects has changed. Not only within a team, but also across teams. The product owners in particular found it difficult to make unambiguous joint decisions without higher-level control. The problem was solved by a first scaling level and the introduction of a higher-level PO.

For this purpose, the agile roles were mapped on different hierarchical levels. Communication took place through rule coordination, which was oriented towards the sprint events. However, this did not limit the competence of the POT, but rather defined the framework in which each project works more clearly and made cross-team collaboration, such as prioritising access to shared resources, more efficient. Experience with scaled agile approaches had already been gained in software development.

However, it quickly became clear that a simple adaptation of this project control from the software sector was not the best solution for mechatronics. The reasons for this can be found in the different framework conditions. Mechanics or hardware simply cannot be completely constructed, produced and tested every fortnight, as is possible in software with one function. Another driver was the networking of hardware-heavy projects (embedded software), which control a mechanical system, with pure software projects (cloud software). Since no blueprint of an existing framework could map this complexity in terms of content and processes, the participants decided to classify the projects across the board and design the scaling framework as needed. Pure software projects tend to be oriented towards SAFe, HW projects with a low software content tend to be oriented towards LeSS or Nexus.

The agile organisational structure

The management and the executive board recognised the potential, so that the structural organisation was subsequently to be further developed in order to be able to better support the projects. A concept was developed that placed the products at the centre. A decisive factor was the question of how the value stream runs in development. Step by step, new roles were created, different areas, managers and employees were involved. Core teams were founded for the new developments, the specialist departments were dissolved and assigned to the product lines. The focus is now on development, where the value stream originates; the environment sees itself as a service and enabler for their projects.

The benefits of agility

"Both result dimensions of agility proved to be successful: on the one hand, high-performance, successful products were developed, and on the other hand, the new work methodology bore fruit," Schönebeck sums up. The group now succeeds in developing better products and closer to the customer. At the same time, the corporate culture is changing. In an agile model, the potential, creativity and competence of the employees can be activated more strongly through more personal responsibility. This also improves the performance of the organisation. The changes in product development have also stimulated the adjacent areas to ask themselves how they can improve cooperation and alignment with the value stream. This helps to give a common direction to the change projects that are always already present in the company.

Conclusion

The introduction of agility through a pilot project at our client was the beginning of a journey that can only lead to success in a targeted manner. To ensure that it did not remain just a short excursion, it was decided to drive agility forward at all levels with professional support from CO Improve. The gamechanger here was the transformation team, with which overarching framework conditions could be created. Hardware and software projects benefited equally from agile ways of working. But it has also become clear that agile working places significantly different demands on employees and managers. This change does not happen ad hoc - it takes time and must be accompanied by agile leadership. In an agile transformation, a company goes through various phases that also concern the adaptation of the organisational structure to the needs of agile working.