Nach PEP wird der Kunden-/Marktwunsch häufig über den QFD-Ansatz als «Voice of the Customer» erfasst und über das Lasten- und Pflichtenheft in technische Parameter übersetzt. Er wird möglichst früh «eingefroren », um Loops zu vermeiden und damit eine effiziente und zielgerichtete Entwicklung zu erlauben.
Die agile Produktentwicklung hingegen fordert und ermöglicht in kurzer Taktung die Überprüfung, ob der «eingefrorene» Satz an Kundenwünschen auch tatsächlich noch dem ursprünglichen entspricht. Dafür werden Epics, Stories und Ergebnisforderungen mit einer möglichst exakten «Definition of Done»-Vorgabe für jeden Sprint aus dem Etappen- und Releaseplan in den Sprintplan übernommen und für die bevorstehenden 14 Tage priorisiert. Dabei ist das Feedback der Kunden aus der letzten Demonstration eingeflossen und wird direkt umgesetzt. Der Ansatz des PEPs, einen gut beschriebenen Satz von Kundenwünschen zu fordern und dann zu fixieren, ist durchaus nachvollziehbar. Das größte Risiko eines eingefrorenen Pflichtenhefts besteht aber darin, am Markt vorbeizuentwickeln. Agile Produktenwicklung entschärft dieses Risiko durch die ständige Beschäftigung mit dem wirklichen Kundenwunsch.

Beide Ansätze PEP und AGILE haben ihre Berechtigung – in der Ergänzung liegt die Kunst.

Kennst Du die Aussagen: „Agilität im Wortsinne – quirlig, flexibel, wendig. Das ist mit dem «Wasserfall», also dem Arbeiten nach dem Produktentwicklungsprozess PEP mit seinen starren Meilensteinen nicht vereinbar!“ Und offenbar hält es viele davon ab, sich mit dieser Methode ernsthaft auseinanderzusetzen. Die Erfahrung zeigt aber, dass sich der Produktentwicklungsprozess (PEP) und die agile Produktentwicklung ganz hervorragend ergänzen. Dass das Arbeiten in kurzen Iterationen einen Rahmen braucht, der sicherstellt, dass die Sprints zum SOP oder zum Messetermin zum Erfolg führen, ist nicht nur friedliche Koexistenz im Sinne eine «Hybrids». Es ist auch eine Bedingung dafür, Agile als Methode außerhalb der Softwareentwicklung erfolgreich einzusetzen.

Der PEP kann nicht die tägliche Arbeit abbilden. Versuche von Projektleitern, ihre Projektpläne auf Wochenebene runterzubrechen enden in komplexen, nicht mehr beherrschbaren Planungsdokumenten. Wir haben schon MS Project Pläne mit 2000 Aktivitäten gesehen. Der PEP überlässt diese nicht leichte Aufgabe den Projektleitern und Teams, die sie mit entsprechender Varianz mehr oder weniger gut wahrnehmen.
Die agile Produktentwicklung greift genau diese Schwachstelle des PEPs auf und bietet eine simple, aber sehr wirkungsvolle Unterstützung der Detailplanung für die Teams. PEP und agile Produktentwicklung ergänzen sich ideal.