Methodenwechsel während des Projektlebenszyklus
Mit welcher Methodik machen wir eigentlich unser nächstes Projekt? Mit SAFe, Scrum oder Kanban? Vielleicht auch mit Lean Six Sigma, LeSS oder Extreme Programming? Diese Frage stellt sich immer wieder, und wie so oft ist die einzig richtige Antwort darauf das gute alte "kommt darauf an". Spannend ist aber das worauf es ankommt. Das können Erfahrungswerte, Vorlieben, Rahmenbedingungen oder Unternehmensstandards sein, es kann aber auch auf einen weiteren, oft unterschätzten Faktor ankommen - die jeweilige Phase des Projekt-Lebenszyklus.
Bevor wir darauf eingehen etwas Grundsätzliches: es macht grossen Sinn Arbeit nicht um Projekte sondern um Produktlinien zu gruppieren, da dadurch kontinuierliche Weiterentwicklung, DevOps und andere sinnvolle Dinge einfacher werden. Manchmal geht das aber nicht wirklich gut, etwa bei Legacy-Ablösungen, Auftragsarbeiten für externe Kunden oder Hardware-Produkten, die ja irgendwann in die Serienfertigung überführt werden. Hier machen Projekte meistens mehr Sinn, und um diese Fälle soll es hier gehen.
Am Anfang derartiger Vorhaben steht in der Regel eine Phase grosser Ergebnis-Offenheit. Es werden vor allem Hypothesen geprüft und Proofs of Concept, Prototypen und frühe MVPs erzeugt, zwischen deren Erstellung längere Pausen liegen können in denen Ergebnisse validiert, Make or Buy-Entscheidungen getroffen oder Budgets ausgehandelt werden. Hier können Design Thinking-Workhops Sinn machen, Design Sprints, Rapid Prototyping oder in Teilzeit betriebene Innovationsprojekte. Für voll ausgelastete Projektteams ist es meistens noch zu früh.
Erst wenn diese Vollauslastung möglich ist (z.B. nach Bestätigung der Bedarfshypothese, der Bestätigung der Machbarkeitshypothese und Bestätigung des Budgets) kann ein dazu passender Arbeitsmodus eingesetzt werden, wobei sich im Rahmen komplexer Vorhaben mehr und mehr iterative Ansätze wie Scrum, SAFe, XP oder LeSS durchsetzen. Neben den kontinuierlichen Lern- und Lieferzyklen bieten sie den Vorteil, dass ihre Regeltermine lange im Voraus festliegen, so dass Stakeholder und Nutzervertreter dann verfügbar sein können.
Gegen Ende wird diese regelmässige Verfügbarkeit von Stakeholdern und Nutzervertretern allerdings weniger wichtig. Da dann (bei richtig umgesetztem agilem Vorgehen) keine kritischen Entscheidungen oder Weiterentwicklungen mehr anstehen, sondern vor allem Restarbeiten umgesetzt und kleinere Optimierungen durchgeführt werden, gibt es zum Einen kaum noch wirkliche Neuerungen zu denen in Reviews Feedback gegeben werden kann, zum anderen werden die Ergebnisse eher kleinteilig, Detail-spezifisch oder technisch (z.B. bei Refactorings). Hier können Lean-Ansätze wie Kanban oder Six Sigma passend sein.
Sich auf die Idee der Methodenwechsel während des Projektlebenszyklus einzulassen kann aus mehreren Gründen sinnvoll sein. Nicht nur weil es den Arbeitsmodus den aktuellen Erfordernissen anpasst (statt das Umgekehrte zu versuchen), sondern auch weil es in Erinnerung ruft, dass Methoden kein Selbstzweck und keine Silberkugeln sind, und weil es daran erinnert, dass man auch spät im Projekt noch Scrum Master oder ähnliche Rollen braucht die regelmässig aus dem Hamsterrad heraustreten und Sinnfragen stellen (auch hier nochmal: nein, der Scrum Master macht sich nicht irgendwann selbst überflüssig).
Zum Schluss noch eine häufig gestellte Frage: ist so ein "häufiger" Methodenwechsel nicht teuer? Die Antwort darauf kann nur sein: umsonst ist er zwar nicht, ein Projekt über weite Strecken mit einer zu diesem Zeitpunkt nicht passenden Methodik zu betreiben ist im Zeifel aber viel teurer. Die Umstellung lohnt sich also.
