Hybrid product development process

Agile working methods and agile leadership show their advantages especially in so-called complex projects, where the product requirements are not completely known or not sufficiently structured at the beginning of the project. Through iterative procedures and short-cycle feedback, uncertainty is reduced, requirements become clearer and technical risks are reduced.

Hybrid PDP - The combination of waterfall and agile

If the stage-gate system remains leading, but classic waterfall and agile working methods are allowed to be combined, forms of hybrid PDP emerge. We distinguish between 4 basic models.

Sequential use of agile and waterfall

The early phases of the PDP, typically requirements clarification and concept development, are carried out agilely according to Scrum. This approach is useful when there is a high degree of uncertainty about the customer or stakeholder requirements and/or the technical solution. In this case, the project team works with a dynamic product backlog instead of a static requirements specification. Through an iterative procedure, early delivery of product increments and short-cycle sprint reviews, the customer or stakeholder requirements are specified more precisely and the technical feasibility of the product concept is checked at the same time. Models and functional patterns emerge earlier. Requirements clarification and concept development take place simultaneously.

Once the product backlog and product concept have reached a high level of quality, the concept release quality gate is passed. The subsequent product development takes place in an interdisciplinary manner according to the classic waterfall approach.

This approach offers another advantage. The first phase can be carried out with a relatively small project team. This makes it easier to meet the requirements that Scrum places on a team: Team size 5-11, broad competence profile of each team member, full-time assignment to only one project. The product manager could take on the role of product owner. The development team would be staffed e.g. with a chief engineer supplemented by some development experts for the relevant domains, an industrial engineer, a project buyer and perhaps a customer service expert. As soon as significantly more resources are needed for the detailed work in the phases after concept approval, many companies find it easier to implement with a classic project core team. The project core team accesses the specialised departments that work on several projects at the same time. This also makes it much easier to involve specialists who are only needed selectively than with Scrum.

Parallel use of agile and waterfall after agile initial phase.

The initial phase of product development is carried out agilely as described above. Afterwards, the project team and stakeholders make a decision about which modules or components of the product should be developed classically according to waterfall and which should be developed agilely.

One option that is often found is to develop the product itself and the hardware modules according to waterfall and the software agilely. This is particularly suitable when software teams have already gained good experience with agile working methods in pure software development projects and the methodology is mastered. As already mentioned, good configuration management and a good release and integration plan for synchronising waterfall and agile development are crucial for success.

Another approach arises when the decision on the methodology is made based on the complexity of the development task according to the Stacey matrix. Modules, functions or components with high uncertainty regarding customer requirements are then developed agilely. All others are developed classically according to waterfall. This was the approach taken by a well-known car manufacturer in the development of its new generation of electric vehicles. For example, the design of the seats (known technology, clear requirements) required 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.

Parallel use of agile and waterfall after waterfall initial phase

This variant differs from the one described above only in that it should be started with two sequential initial phases in which conventional requirements and specifications are created. This variant is used either if the management specifies this procedure and does not allow an agile initial phase or if there is only a low level of uncertainty about customer and stakeholder requirements and the feasibility of the technical solution. Otherwise, work is carried out after concept approval as described above.

Complete agile working in a waterfall framework.

If the framework conditions for an agile way of working are in place and all those directly involved in the project can successfully use agile frameworks, it is possible to work in a fully agile way. Maintaining a waterfall framework can be done for different motivations: Management does not yet fully trust agile ways of working or simply wants to stick to what is known and continues to insist on quality gates. Or, as a supplier, the company is already further along with its agility than the client who wants to control the project via quality gates.

Conclusion

The PDP as a Stage-Gate-Model© is still indispensable for industrial companies with complex mechatronic products. The complexity of the product architecture, the interdependencies of the various mechatronic modules and components and the high investments in operating resources require simultaneous maturity development of the individual product components via defined sample stages. New hybrid solution approaches integrate agile working methods into a superordinate leading PDP and combine the best of both worlds.