After PEP, the customer’s/market demand is often captured as the “voice of the customer” via the QFD approach and translated into technical parameters via the specifications. It is “frozen” as early as possible to avoid loops and thus allow efficient and targeted development.
Agile product development, on the other hand, demands and enables a quick check to see whether the “frozen” set of customer wishes actually still corresponds to the original. For this purpose, epics, stories and result requirements are transferred from the stage and release plan to the sprint plan with a “definition of done” for each sprint that is as exact as possible and prioritised for the upcoming 14 days. Customer feedback from the last demonstration has been incorporated and is being implemented directly. The PDP’s approach of asking for a well-described set of customer requirements and then fixing them is quite understandable. However, the biggest risk of a frozen set of specifications is to develop past the market. Agile product development mitigates this risk by constantly dealing with the real customer requirements.

Both approaches, PEP and AGILE, have their justification – the art lies in complementing them.

Are you familiar with the statements: “Agility in the literal sense – lively, flexible, nimble. This is not compatible with the “waterfall“, i.e. working according to the product development process PEP with its rigid milestones!” And apparently it discourages many from taking this method seriously. But experience shows that the product development process (PEP) and agile product development complement each other perfectly. The fact that working in short iterations needs a framework that ensures that the sprints lead to success by the SOP or the trade fair deadline is not just peaceful coexistence in the sense of a “hybrid“. It is also a condition for successfully using Agile as a method outside of software development.

The PEP cannot map the daily work. Attempts by project managers to break down their project plans to weekly level end up in complex planning documents that are no longer manageable. We have seen MS Project plans with 2000 activities. The PEP leaves this not-so-easy task to the project managers and teams, who perform it more or less well with the appropriate variance.
Agile product development addresses exactly this weakness of the PEP and offers a simple but very effective support for detailed planning for the teams. PEP and agile product development complement each other ideally.