Klassisch oder agil? Beides! Methodenmix im Projekt

Vor einiger Zeit wurde mir die Leitung eines Projekts zur Erstellung eines Stammdatensystems angeboten. Sofort drängte sich die Frage nach der passenden Methode auf: Bietet sich bei solch einem abteilungsübergreifenden Projekt eher agiles oder klassisches Vorgehen an? Das Problem in diesem konkreten Fall: die IT-Mitarbeitenden in unserem Projekt sahen im agilen die besten Erfolgsaussichten, Kolleg:innen aus dem Front- und Back-Office standen diesem Ansatz eher kritisch gegenüber. Aber warum auf eine Methode festlegen?

Die Lösung des Dilemmas fanden wir darin, vier Teilprojekte zu bilden:

• Ein Teilprojekt zur IT-Implementierung des Stammdaten-Kernsystems
• Ein Teilprojekt zur Entwicklung der IT-Architektur
• Zwei Teilprojekte zur Erstellung der Anforderungen aus dem Front- und Back-Office

Die beiden IT-lastigen Teilprojekte gingen agil vor. Die fachlichen Projekte lieferten zwar in Iterationen, wurden aber klassisch gemanagt. So waren alle Projektbeteiligten zufrieden. Die Herausforderung bestand nun darin, das Zusammenspiel der Teilprojekte zu definieren und erfolgreich zu gestalten.

Synchronisation – Verbinden Sie Zwischenergebnisse

Die Fachprojekte lieferten die Anforderungen und planten ihrerseits mit Meilensteinen. Wie in vielen klassischen Projekten waren Verzögerungen zu erwarten. In den IT-Teilprojekten wollten wir größere Verzögerungen dadurch vermeiden, dass neue und hoch zu priorisierende Anforderungen erst viel später in einen Sprint kommen, sonst wäre ein Vorteil der agilen Methodik ja hinfällig.

Wir entschieden uns deshalb, die Sprintlänge der agilen Projekte auf eine Woche festzulegen. So konnten wir die Teilprojekte relativ unabhängig voneinander planen – und es entstand maximal eine Woche Verzug bei der Implementierung von Anforderungen!

Priorisierung – und: wie begegne ich Silodenken?

Als weiteres Spannungsfeld gestaltete sich die Priorisierung der Anforderungen. Zwei Teilprojekte wollten ihre eigenen Anforderungen an die erste Stelle des IT-Backlogs setzen. Jahrelang „gepflegtes” Silodenken lässt sich leider nicht so leicht ablegen. Verfechter agiler Methoden werden jetzt zu Recht einwenden, dass der Grund für funktionsübergreifende Teams genau darin liegt: Silodenken zu überwinden. Die Überwindung dieses Denkens ist nicht einfach und braucht – wie alle Veränderungsprozesse – Zeit. Zeit, die wir in diesem Projekt nicht hatten.

Zum Glück konnten wir Product-Owner:innen für die Implementierung des Kernsystems gewinnen, welche von beiden Abteilungen sehr geschätzt wurden. Deren Seniorität ermöglichte es uns, die Entscheidung über die notwendige Priorisierung der User-Stories in seine Hände zu legen. Konflikte, die in den Sprint-Planning-Meetings zwischen den beiden fachlichen Projektleitern aufkamen, konnten wir so schnell lösen. Diese Kompetenz, die Konfliktpotentiale bei unterschiedlichem methodischen Vorgehen zu kennen, zu erkennen und zu lösen ist nach unserer Erfahrung ein entscheidendes Erfolgskriterium.

Berichtswesen – informieren Sie über Etappenziele

Jedes Projekt hat die Aufgabe, seine Auftraggeber:innen bzw. den Lenkungsausschuss über den Fortschritt des Projektes zu informieren. Unsere Herausforderung: Meilensteinberichte aus den fachlichen Projekten mit Burn-Down-Charts aus den agilen Projekten zu verbinden und diese einem Gremium zu präsentieren, das an das Management mit Meilensteinen gewöhnt ist.

Unsere Lösung: wir nutzten die User Stories des Backlogs, um (fachliche) Releases zu definieren. Diese Releases hatten erst einmal nichts mit den Sprint-Backlogs zu tun. Vielmehr wurde von den agilen Teams an Hand der Priorisierung des Produkt-Backlogs grob vorausgeplant, in welchem Sprint welche Anforderungen wahrscheinlich umgesetzt werden können. Mit diesem Konstrukt konnten wir die Anzahl der benötigten Sprints für ein fachliches Release bestimmen – und dieses dann in einen Meilenstein übersetzen. Die kurze Sprintdauer war hier besonders hilfreich, weil Verschiebungen von einem in den nächsten Sprint nur eine Woche Verzug bedeuteten.

Fazit

Am Ende stand ein erfolgreicher Abschluss des Projekts und die Zufriedenstellung aller beteiligten Stakeholder. Wesentliche Erfolgsfaktoren für unser Projekt waren dabei

• die gegenseitige Akzeptanz – auch für unterschiedliche methodische Vorgehensweisen
• die kurze Sprintlänge, die eine schnelle Reaktion der agilen Teams sicherstellte und
• die Akzeptanz des Produkt-Owners.

Ein positiver Nebeneffekt: die Fachbereiche hatten die Gelegenheit, agile Teams aktiv bei der Arbeit zu erleben. Die Offenheit gegenüber agilen Methoden war nach Abschluss des Projekts weitaus größer, künftige Diskussionen über die geeignete Projektmanagement-Methode deutlich entspannter.

Ist dieses Projekt nun eine Blaupause für alle meine weiteren Projekte geworden? Nein, dafür sind die Voraussetzungen in den Projekten und bei den beteiligten Personen zu unterschiedlich. Die Entscheidung, welche Methode für ein Projekt am erfolgversprechendsten ist, sollten Sie immer in der jeweiligen Situation entscheiden. Meiner Erfahrung nach stößt dieser hybride Ansatz des Projektmanagements auf große Zustimmung, wenn vor Projektstart die Rahmenbedingungen des Projektes sorgfältig analysiert wurden.

Ein Methodenmix innerhalb eines Projektes kann also sehr gut funktionieren!