Agiles Projektmanagement hat in den letzten Jahren Einzug in die Neuprodukt-Entwicklung auch jenseits der Software gehalten. Dabei wird die ursprüngliche Methode (z.B. Scrum) mal mehr mal weniger an die Besonderheiten der jeweiligen Industrie und an die Kultur des Unternehmens angepasst.
Es ist noch nicht abzusehen, ob und wenn ja wie sich die Methode schließlich bei der Entwicklung von physischen Produkten, Dienstleistungen und Geschäftsmodellen durchsetzen wird. Die Entwicklung des agilen Projektmanagements scheint derzeit seiner eigenen Spielregel zu folgen: schnell zu etwas Funktionierendem gelangen, dieses mit Anwendern testen, aus der Erfahrung lernen und die Methodik weiterentwickeln.

Dieser Erfahrungsbericht beschreibt einen solchen Lernzyklus des Einsatzes von agilem Projektmanagement in der Entwicklung von physischen Produkten.

In einem früheren Beitrag haben wir schon einmal ausgeführt, dass agiles Vorgehen insbesondere in einem ungewissen Projektumfeld einen hohen Nutzen stiftet. Agiles Projektmanagement müsste sich also besonders gut für die frühen Phasen der Entwicklung innovativer Produkte eignen. In der Softwareentwicklung liegt der Einsatzbereich agiler Methoden vornehmlich in der Entwicklungsphase und danach. Für die davor liegenden Analyse- und Konzeptionsphasen bieten Scrum & Co kaum methodische Unterstützung.
Sechs Projektteams aus zwei Unternehmen (eines aus dem Bereich Daten- und Energieübertragung, das andere ein Hersteller von Laborgeräten) haben sich gemeinsam mit five is der Herausforderung gestellt, Prinzipien und Werkzeuge aus dem agilen Methodenkoffer in den frühen Phasen (von der Idee bis zur Freigabe der Entwicklung) anzuwenden.

Folgende Erfahrungen und Erkenntnisse haben wir dabei gewonnen:

  • Wie auch im klassischen Stage-Gate®-System gefordert, arbeiteten wir mit interdisziplinären Teams. Es war immer mindestens eine Person aus Entwicklung, Produktmanagement und Fertigungstechnik, im einen oder anderen Projekt auch noch aus dem Einkauf im Team. Die bislang in diesen Unternehmen gelebte Praxis war, dass zunächst die „Marktseite“ ein Lastenheft definiert, welches dann die „Technikseite“ zu einem Pflichtenheft vervollkommnet. Die agile Zusammenarbeit hat alle Teammitglieder „gezwungen“, sich gemeinsam sowohl mit den marktseitigen als auch den technischen Aspekten des Projekts intensiv auseinanderzusetzen. Das Werkzeug Innovation Project Canvas hat diesen Prozess massiv unterstützt und beschleunigt.
  • Aus den Ergebnissen der Arbeit mit dem Innovation Project Canvas haben die Projektteams ein Project Backlog aufgebaut und die wichtigsten Projektaufgaben priorisiert. Das Project Backlog bestand aus 3 Bereichen:
    • Product Backlog: Dieses beinhaltete alle für das Produkt relevanten Aspekte (z.B. Kundenbedürfnisse, Anforderungen, Spezifikationen, etc.). Zu Beginn der Projekte war dieses noch ziemlich leer.
    • Risikomanagement: Hier wurden alle notwendigen zu erarbeitenden Erkenntnisse (z.B. Aussagen zu möglichen Verletzungen von Patenten) gesammelt, welche die Ungewissheit beseitigen bzw. das Risiko des Projekts reduzieren sollten.
    • Rahmenbedingungen: Hier wurden vom Team getroffene Grundsatzentscheidungen (z.B. Mindestanforderungen an die Qualität) sowie Abgrenzungen (z.B. Fokussierung auf Europäischen Markt) festgehalten und somit immer im Blickfeld des Teams gehalten.
  • Kernelement des agilen Vorgehens waren jeweils Sprints (Takte) von 2 Wochen.
    • Jeder Sprint wurde mit einem Kick-off-Meeting gestartet. In diesem wurde zunächst geklärt, welcher Projektmitarbeiter wie viel Zeit in den 2 Wochen des Sprints in das Projekt investieren kann. Konnte eine Person weniger als einen Tag pro Woche einbringen, nahm dieses Projektmitglied an diesem Sprint nicht teil und war angehalten seine verfügbaren Zeiten im nächsten Sprint zu bündeln.
    • Unter Berücksichtigung der verfügbaren Ressourcen definierten die Projektteams die Ziele für den Sprint. Hierzu wurden nach dem Motto „das Wichtigste zuerst“ jene Aspekte gewählt, die das Projekt am schnellsten voran brachten. Zu jedem Ziel definierten die Teams außerdem, welche Qualität für die Zielerreichung notwendig ist (Definition of Done), und wer überprüfen soll, ob diese erreicht wurde. Diese Ziele wurden in ca. 10 bis 20 Teilergebnisse heruntergebrochen und auf einem physischen Sprint-Backlog aufgelistet. Manche Teams nutzten das Kanban-System des Sprint-Backlogs ständig, andere zogen es erst im Sprint-Review nach. Der empfundene Nutzen des Kanban-Systems hielt sich bei allen Teams in Grenzen.
    • Eine wichtige Erkenntnis aus den ersten Sprints war, dass jene Teams deutlich bessere Ergebnisse erzielten, die einen gemeinsamen Projektraum nutzten und einen Großteil der Projektarbeit koloziert in einem gemeinsamen Projektraum erledigten. Um diesen Effekt möglichst gut zu nutzen, reservierten sich einige Teams einzelne Tage (z.B. Dienstag und Donnerstag) als Projekttage. Die restliche Woche konnten die Teammitglieder ihrem Tagesgeschäft oder weiteren Projekten nachgehen.
      Die meisten Teams trafen sich dann zweimal pro Woche zu einem kurzen Standup-Meeting, um den Projektfortschritt auszutauschen und ggf. Probleme im Vorankommen zu lösen.
    • Im abschließenden Sprint-Review wurde das Ergebnis des Sprints überprüft. Neue Erkenntnisse aus den Aktivitäten des Sprints führten immer wieder zu neuen Einträgen im Project Backlog. Dieses wurde ebenfalls im Sprint-Review auf den neusten Stand gebracht.
      Das Project-Backlog bietet einen guten Blick nach vorne. Es eignet sich als physisches Werkzeug an der Wand, jedoch weniger gut zur Dokumentation. Einige Projektleiter haben die Elemente auf den Backlogs parallel in eine Excel-Liste übertragen und somit eine saubere Dokumentation gewährleistet.
    • Am Ende jedes Sprint-Reviews reflektierte das Team die Arbeitsweise des Sprints und überlegte, wie es noch besser und schneller zusammenarbeiten kann. Für den nächsten Sprint nahm sich das Team dann bestimmte Anpassungen oder Veränderungen der Arbeitsweise vor. Dies führte in den Teams sehr schnell zu einer Verbesserung der Zusammenarbeit. So wurde z.B. der Nutzen von kolozierter, zeitlich paralleler Zusammenarbeit in den ersten Sprints erkannt und in den darauf folgenden verbessert.
    • Bei der Vorstellung der Methodik ist das Instrument des Burndown-Charts gut angekommen. Allerdings mussten wir dann in der Praxis feststellen, dass ein Burndown-Chart in der Frühphase eher demoralisierend wirkte. Die Projektplanung war zu Beginn des Projekts noch vage. Vielfach war noch nicht einmal der zu beschreitende technologische Pfad bekannt. Im Hinblick auf den weiteren Projektverlauf kamen eher neue Aufgaben und Aktivitäten hinzu. Sprich: der Chart-Verlauf entsprach weniger einem Burn-down sondern viel mehr einem Pile-up.
      Das bedeutet nicht, dass auf eine Gesamtprojekt-Planung verzichtet wurde. Die Teams gaben sich aber mit einer sehr groben Planung zufrieden.

 

Der Mehrwert des agilen Vorgehens wurde von den Projektteam-Mitgliedern durchaus unterschiedlich gesehen: von Begeisterung bis Ablehnung war alles dabei.

  • Ziemlich einig waren sich die Projektteam-Mitglieder, dass die enge Zusammenarbeit unterschiedlicher Disziplinen in der frühen Phase zu einem besseren Verständnis der Projektziele, einem direkteren Informationsaustausch und damit zu einer Beschleunigung geführt hat. Ob dieser Nutzen jedoch dem agilen Vorgehen oder einfach nur einer besseren Projektorganisation zuzuschreiben wäre, bestand jedoch Uneinigkeit.
  • Von einigen Projektteam-Mitgliedern wurde angezweifelt, ob agiles Vorgehen mit der Effizienz einer sauberen Planung mithalten könne – vorausgesetzt das klassisch durchgeführte Projekt würde ähnlich vorteilhafte Rahmenbedingungen vorfinden, wie jene Pilotprojekte.
  • Jene Projektteams, die sich voll auf das agile Vorgehen einließen, berichteten von einem neuen, attraktiven „Projektgefühl“: motiviertes Miteinander und viel Eigeninitiative der Teammitglieder wurden in diesem Zusammenhang erwähnt, oder auch, dass es leicht gefallen sei diszipliniert zu arbeiten.

Alles in allem wurden die gemachten Erfahrungen als wertvoll bezeichnet. Die meisten Projektteams sprachen sich außerdem für weitere Pilot-Einsätze des agilen Vorgehens in der frühen Phase aus.

 

Unsere Erkenntnis aus diesen Pilotprojekten lautet:

  • Agiles Vorgehen funktioniert in der frühen Phase der Neuprodukt-Entwicklung. Es eignen sich aber längst nicht alle Aspekte und Instrumente aus der „Scrum-Welt“. Im Fokus erster agiler Gehversuche sollten folgende 3 Elemente stehen:
    • Im Zentrum des agilen Arbeitens steht eine – einem Herzschlag gleiche – Taktung der Projektarbeit. Vor jedem Takt / Sprint überlegt das Projektteam, welche Erkenntnisse bzw. Ergebnisse das Projekt am besten vorwärts bringen.
    • Diese setzt sich das Team als Ziele für den Takt, abhängig von der Ressourcenausstattung. Gemeinsam beschäftigen sich die Teammitglieder intensiv damit, welche Qualität das Ergebnis haben soll, damit das Ziel als erreicht zu werten ist. Dies gibt klare Orientierung und vermindert die Gefahr, dass zu aufwändig bzw. zu oberflächlich gearbeitet wird.
    • Aus der Erfahrung eines jeden Sprints schöpft das Projektteam Potenziale für die Verbesserung der weiteren Zusammenarbeit im Projekt. Schwierigkeiten, Unzufriedenheit oder fehlende Koordination und Kommunikation werden sehr früh erkannt und unmittelbar angegangen.
  • Wir haben mit mehreren Projektteams die Erfahrung gemacht, dass die „Scrum“-Sprache schlecht angekommen ist oder teilweise schon anders besetzt war. Wir empfehlen deshalb, die Begrifflichkeiten flexibel zu handhaben und nicht allzu missionarisch Begriffe wie „Sprints“, „Project-Owner“, „Scrum-Master“, etc. einzuführen.
  • Die erfolgreiche Einführung von agilem Projektmanagement in der frühen Phase von Neuprodukt-Projekten hängt nicht zuletzt vom Führungsstil des mittleren und oberen Managements ab. Das Projektteam muss das Projekt eigenverantwortlich, und ohne ständig Rechenschaft ablegen zu müssen, vorwärts treiben können. Ansonsten werden zwar der Form nach agile Instrumente genutzt, ein tatsächlich agiles Vorgehen und damit dessen Nutzen verhindert.

Wenn Sie mehr über agiles Stage-Gate® erfahren wollen, besuchen Sie eines der folgenden Seminare oder kontaktieren Sie uns direkt.