Agile transformation at leading manufacturer of household products

Sometimes change needs an initial impetus and someone to ignite this initial spark. In 2016, such a change started at our customer when a hardware development team began to try out agile approaches in product development. Agility was supposed to help develop better products and create more efficiency. The design manager at the time was the trailblazer. His good experience and prior knowledge, as well as his uncomplicated approach and his ability to motivate the team were the decisive sparks for the success of a pilot project.

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 so much attention from management that further agile teams were set up. This successful test balloon quickly paved the way for a workshop with R&D management to learn more about agile working. The management supported the change towards more agility from the very 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 and the Development Team. It was important to ensure an optimal start-up phase. This is why the external consultants from CO Improve took on the role of scrum master and agile coach on an interim basis.

After the successful start to the pilot project, the challenges of expanding 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 courses for employees were just as valuable here as the personal experiences of the agile-experienced employees and the already tried and 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 subject area from specialised departments had to be integrated into several agile processes. In this case, a core team and an extended team created the framework conditions for integrating specialists in an agile manner 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 "tripartite leadership" with two different focal points. One focal point had a more overarching and outward-looking focus, while the other focussed more on the development teams with a technically oriented role. The position of product manager was also integrated. This was necessary because the requirements profile for a product owner could not be fulfilled by individual persons, as this scope of tasks did not previously exist in the company. 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) in order to ensure smooth collaboration with the other members of the Scrum teams.

The problems caused by the lack of Scrum Masters in some teams were overcome by external interim solutions and rapid qualification measures for the company's own employees. It was precisely in this crucial phase that the CO Improve consultants were able to put their expertise to good use. 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 essential phase, but also a decisive motivational boost and the necessary incentive.

The hierarchical constellation of employees and group leaders was also broken up for the collaboration. Previously, the group leader was heavily involved in project work and therefore had little time for employee development. For this reason, a new role was created with the "design lead" as the first point of contact for technical questions. The group leader's task was now to coach the project with technical expertise, while the employees themselves made decisions about the components they were developing. The new setup resulted in a smooth acceptance of the roles. Self-organisation also came into play: a guild was formed with regular meetings that maintained the uniformity of the specialist discipline of construction. This type of exchange was also a model for other departments.

Once the roles of the individual teams had been consistently filled, it was now necessary to create a link to all teams. This overarching task could no longer be covered by the team's 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 and 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 for involving customers in product development at an early stage. This understanding of the customer had to be anchored in the development team, as the development engineers influence the design of the product with their decisions, which therefore have a direct impact on the customer. At the same time, this knowledge is useful for the entire product development team, whose common goal is derived from the customer's needs. The team members then no longer carry out assigned tasks, but create concrete added value for the customer on their own responsibility.

With the positive experiences from the development projects, it was a logical next step to successively set up the pre-development projects in an agile manner. As soon as several people were working on such a project, agile methods such as sprints were used. These were systematically expanded as soon as more employees were involved. Until all the 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 receive 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 towards the needs of agile teams with close proximity and the appropriate equipment.

Another learning: "Not every phase of product development requires the same level of agility," says Schönebeck, Senior Consultant at CO Improve. In the prototype and functional test development phases, the Scrum methodology proved to be oversized. To reduce the workload, the teams resorted to Kanban. Self-organisation was demonstrated here in order to select the right method for the requirements. This was also recognisable during the switch to working from home: productivity and efficiency remained constant.

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

The agile roles were mapped at various hierarchical levels for this purpose. Communication took place by means of rule coordination based on the sprint events. However, this did not restrict the competence of the POT, but rather more clearly defined the framework within which each project works 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 apparent that a simple adaptation of this project management system 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 designed, 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). As no blueprint of an existing framework was able to 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 required. Pure software projects tend to be orientated towards SAFe, while HW projects with a small software component tend to be orientated towards LeSS or Nexus.

Management and the board recognised the potential, so the organisational structure was also to be further developed in order to better support the projects. A concept was developed that placed the products at the centre. The key question here was how the value stream runs in development. New roles were created step by step and various departments, managers and employees were involved. Core teams were set up for the new developments, the specialised departments were dissolved and assigned to the product lines. The focus is now on development, where the value stream is created; the environment sees itself as a service and enabler for their projects.

"Both result dimensions of agility proved to be successful: on the one hand, high-performance, successful products were developed and, on the other, the new working methodology bore fruit," summarises Schönebeck. The Group is now able to develop better products and get closer to its customers. At the same time, the corporate culture is changing. In an agile model, the potential, creativity and expertise of employees can be more strongly activated thanks to the increased personal responsibility. This also improves the performance of the organisation. The changes in product development have also encouraged neighbouring areas to ask themselves how they can improve collaboration and alignment with the value stream. This helps to give a common direction to the change projects that have always existed in the company.

The introduction of agility through a pilot project at our customer was the start of a journey that can only lead to success in a targeted manner. To ensure that it was not just a short excursion, the decision was made to drive agility forward at all levels with professional support from CO Improve. The game changer here was the transformation team, which was able to create an overarching framework. Hardware and software projects benefited equally from agile working methods. However, it has also become clear that agile working places significantly different demands on employees and managers. This changeover does not happen ad hoc - it takes time and must be accompanied by agile leadership. During an agile transformation, a company goes through various phases that also involve adapting the organisational structure to the needs of agile working.