Agilität im Wortsinne – quirlig, flexibel, wendig, und obendrein der Sprint: Beides sei mit dem «Wasserfall», also dem Arbeiten nach dem Produktentwicklungsprozess PEP mit seinen Meilensteinen nicht vereinbar. Das hören wir häufiger. 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 eines «Hybrids». Es ist auch eine Bedingung dafür, Agile als Methode außerhalb der Softwareentwicklung erfolgreich einzusetzen.

Neben unzähligen Softwareprojekten gibt es eine sich ständig beschleunigende Zahl mechatronischer Projekte jeglicher Komplexität, die stark von der Agilen Methode profitieren. Sie breitet sich häufig viral in Unternehmen aus, weil andere Teams angesichts dieses Erfolgs selbst so arbeiten wollen. Trotz aller positiven Erfahrung gibt es dennoch Irritation und starke Vorbehalte gerade bei den Unternehmen, die gut beschriebene Abläufe und Prozesse installiert haben und häufig viel Aufwand in den Produktentwicklungsprozess (PEP) gesteckt haben.

Woher resultieren diese Vorbehalte?

Sie entstehen häufig aufgrund der sehr strikt formulierten Statements in der klassischen Scrum-Literatur und von Scrum-Trainern, die man frei interpretiert so zusammen fassen könnte: «Get rid of your processes, scrum is all you need to satisfy your customer.»

Zudem liefern Suchmaschinen beim Schlagwort «Scrum» oder «Agile» sofort den Hinweis auf das «Agile Manifesto» und dessen vier schwer verdauliche Kernsätze:

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
2. Funktionierende Software ist wichtiger als umfassende Dokumentation
3. Zusammenarbeit mit dem Auftraggeber ist wichtiger als Vertragsverhandlung
4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Auf Organisationen, die Scrum bisher nicht kennen oder noch keine eigenen Erfahrungen damit gemacht haben, wirken solche Sätze oft abschreckend. Sie halten es für undenkbar, Teams loslaufen zu lassen, ohne den genauen Weg zum Ziel zu kennen und ohne klare Indikatoren und Handhabe den Erfolg der Unternehmung im Voraus abzuschätzen.

Regelmäßig werden wir als Agile Coaches von PMO-Verantwortlichen vor dem Start agiler Projekte zur Seite genommen, um uns mit dem PEP des Unternehmens vertraut zu machen. Diese Gelegenheit nutzen wir gerne: Details des PEPs zu kennen ist wichtig, um die bisherigen Abläufe der Teams zu verstehen. Vor allem aber ist es wichtig, um über die latent vorhandenen Hindernisse und Vorbehalte im Zusammenhang mit der

Agilen Produktentwicklung zu sprechen. Gerade die PMO-Verantwortlichen sind wichtige Stakeholder, die den Erfolg oder Misserfolg der agilen Produktentwicklung mitbestimmen.

Denn selbst nach eingehender Beschäftigung mit der Theorie von Agile und Scrum bleiben offensichtliche Zielkonflikte bestehen:

– Freiraum geben und das Arbeitspaket vom Team im Sprint bestimmen lassen: Wie sollen so vorgegebene Endtermine und Milestonevereinbarungen gehalten werden?
– Das Feedback des Kunden nach jedem Sprint einholen und ihn das Endprodukt nachjustieren lassen: Wie passt das mit einem klaren Pflichten- und Lastenheft zusammen?
– Das Strukturieren von Backlogplanung, Sprintplanung, Dailys, Demos und Retros, das fast einen ganzen Tag erfordert: Wie soll das zusätzlich in die ohnehin schon vollgepackte Woche mit Regelmeetings, Reviews und Reporting passen?

Diese Liste kann noch um einiges verlängert werden.