Wenn die agilen Teams das Multiprojektmanagement übernehmen

“Agile Teams und (klassisches) Multiprojektmanagement? Typisch für diese traditionellen Unternehmen, die schaffen es einfach nicht, wirklich agil zu werden…” — so ähnlich lauteten die Kommentare zur englischen Version dieses Artikels.
Hmm, ich finde, ganz so einfach ist die Sache nicht. Wenn ich mich mit Kollegen aus der Versicherungs- oder anderen Branchen unterhalte, scheint die Koexistenz dieser beiden Muster recht weit verbreitet zu sein. Und meist sind es diejenigen Unternehmen, die einen evolutionären Weg in Richtung Agilität eingeschlagen haben.
In der LV 1871 führten wir unsere ersten agilen Projekte auf Basis von eXtreme Programming durch, den Rahmen bildete unser damaliges klassisches Multiprojektmanagement. Ich halte diese Kombination nicht für grundsätzlich falsch. Die Unternehmensleitung will — wenn eine neue Herausforderung im Raum steht — wissen, worauf sie sich einlässt: Kosten, Dauer, und worauf sie im Gegenzug verzichten muss, d.h. welche Vorhaben dafür zurückgefahren oder beendet werden müssen. Es geht um die Einschätzung, wie man die Mittel des Unternehmens bestmöglich einsetzt, um die strategischen Unternehmensziele zu erreichen.
Das ist eine recht herausfordernde Fragestellung, da es meist eine komplexe m-zu-n-Beziehung zwischen den Projekten und den Mitarbeitern oder Teams gibt, die die benötigten Teil-Ergebnisse liefern können. Das klassische Projektmanagement versucht, dies auf Basis von Ressourcen, deren Verfügbarkeit, deren Know-How und dem geschätzten Aufwand in Personentagen zu beantworten.
Das Multiprojektmanagement hatte seine Grenzen…
Und es stimmt, das hat bei uns nicht sehr gut funktioniert: Nach dem Einreichen der Projekte gab es erst mal viele Überplanungen, die wir dann durch Priorisierung, Verlängerung und Verschiebung von Projekten aufzulösen suchten. Das Hauptproblem war aber, dass das planende Management-Team die ganzen Abhängigkeiten niemals überblicken konnte.
Entsprechend wenig ernst genommen wurde diese Gesamt-Planung von den Projektteams, die regelmäßig durch neu auftauchende Abhängigkeiten zu anderen Teams aufgehalten wurden.
..und wir wollten agiler werden…
Als wir mehr und mehr Projekte mit Scrum/XP durchführten, wurde die Ineffizienz des Gesamtprozesses immer sichtbarer: Die Softwareentwickler hätten jeden Morgen an bis zu 5 Standup-Meetings teilnehmen müssen. Wir mussten etwas ändern.
…also bildeten wir dauerhafte stabile Scrum/XP-Teams
Wir bildeten feste Scrum/XP-Teams, von denen jedes für eine (oder mehrere) Komponenten der IT-Systemlandschaft verantwortlich war.
(Warum keine End-to-End-Teams, die unabhängig voneinander Versicherungsprodukte auf den Markt bringen können? Das ist ein unbestreitbar attraktives Zielbild, das für uns einige Risiken birgt. Mal sehen, wie weit wir in diese Richtung gehen können. Mein Artikel über die Softwareentwicklung in einer Lebensversicherung liefert einige Anhaltspunkte warum das so ist, weitere Posts zu diesem Thema sind in Arbeit).
Wie sollten wir also zu einer nützlichen und realistischen Planung kommen?
Um unser Planung nützlicher und realistischer hinzubekommen, haben wir uns dann die Frameworks zur Skalierung agiler Methoden angeschaut und das PI-Planning (Program Increment Planning) aus dem scaled agile framework (SAFe) herausgepickt.
Besonders hat uns daran gefallen, dass die Planung auf Basis der Inhalte durch die Mitarbeiter durchgeführt wird (anstelle auf Basis von Schätzzahlen durch das Management). Wir haben dieses Muster ein Stück weit auf unsere Bedürfnisse angepasst und ihm den neuen Namen ‘Schlachtplankonferenz’ (SPK) gegeben. Wir führen die SPK alle 4 Monate durch, arbeiten darin die Abhängigkeiten zwischen den Projekten und Teambacklogs heraus und kommen so zu einer Planung, die recht brauchbar ist.
Da man sich nicht so leicht vorstellen kann wie das Ganze abläuft, haben wir darüber eine kleine Video-Doku gedreht:
Unsere Teams sind auf dieses Vorgehen ziemlich stolz, aber jenseits des Motivationsaspekts gibt es noch eine Reihe weiterer positiver Effekte: Die Qualität der Planung ist natürlich gestiegen und damit das Mitarbeiter-Commitment und das Vertrauen in die Machbarkeit (80%, wie im Video zu sehen). Am allerwichtigsten aber: Wir sind schneller geworden! – weil es in den 4 Monaten deutlich weniger (unangenehme) Überraschungen für die Teams gibt, mit denen sie umgehen müssen.
Das ist natürlich nicht das Ende unserer Geschichte. Da immer weniger Dinge 4 Monate im Voraus geplant werden können, müssen wir uns weiterentwickeln…
(Siehe auch: ‘The ‘Do It principle: Why and how to be really agile’ )
Wir haben zwischenzeitlich wieder ein paar eher projekt-orientierte Teams, die mit Design Thinking und ähnlichen Methoden den Kunden noch stärker in den Mittelpunkt stellen als wir das bislang gemacht haben. Eines dieser Projekte führte zum Launch einer Online-Versicherungsplattform in Österreich (livv.at). Solche Projekte erfordern nahezu Echtzeit-Reaktion auf das analysierte Kundenverhalten.
Auf der anderen Seite sind für uns Projekte derzeit noch das einzige gut definierte Muster, mit dem wir die Weiterentwicklung des Unternehmens vorantreiben können. Wir glauben, dass wir den organisatorischen Overhead weiter reduzieren können, wenn wir einen Teil von ihnen durch kontinuierliche Arbeit an einem konkreten Kundennutzen ersetzen. (Dies ist wiederum inspiriert von den SAFe Value-Streams).
Die größte Herausforderung wird sein, die IT-Systemlandschaft so umzugestalten, dass wir viele End-to-End-Teams bilden können, ohne in unseren langlebigen Systemen technische Schulden anzuhäufen. Mehr dazu im oben schon erwähnten Artikel und in kommenden Blogposts...
PS: Wenn Du Erfahrung mit der Skalierung agiler Methoden hast und Lust, als Teil unseres internen Teams die Weiterentwicklung der LV 1871 zu einem agilen Unternehmen zu gestalten, freuen wir uns, wenn Du Dich bei uns meldest!
