Die ersten Versicherer, die in Deutschland agile Projekte umsetzten, haben in den frühen 2000ern mit eXtreme Programming begonnen. So auch die LV 1871, die sich Unterstützung von einem der weltweit führenden Experten geholt hat: Kent Beck - der amerikanische Softwareentwickler und Autor von "Extreme Programming. Das Manifest" - gilt als einer der Pioniere der Softwareentwicklung und kam für vier Wochen zum Münchner Versicherer, um ihn vor Ort beim Aufbau agiler Strukturen zu unterstützen. Durch die Weitergabe seines Expertenwissens konnten die Softwareentwickler der LV 1871 erste agile Prozesse im Unternehmen integrieren, lange bevor der Agilitätsbegriff zum großen Thema in der Branche wurde.

Bei der Softwareentwicklung durch eXtreme Programming lag der Fokus bei der LV 1871 weniger auf dem organisatorischen Framework als auf den Arbeitstechniken wie Test First oder Continuous Integration. Den Rahmen dafür bildete das klassische, etablierte Multi-Projektmanagement.

Agiles Arbeiten und klassisches Multiprojekt-Management - kann das zusammenpassen? Es kann zumindest eine Zwischenstation auf dem Weg zum agilen Unternehmen sein, vor allem bei denjenigen, die einen evolutionären Weg beschreiten wollen. In der Versicherungsbranche ist die Koexistenz von agilen Methoden und Multiprojekt-Management durchaus verbreitet. Doch welche Herausforderungen, welche Auswirkungen und welche Verbesserungen bringt die Entscheidung für agiles Arbeiten mit sich?

Multiprojekt-Management liefert wichtige Informationen

Ob Projekt- oder IT-Teams selbstorganisiert arbeiten oder nicht: Die Unternehmensleitung muss bei neuen Herausforderungen wissen, worauf sie sich einlässt. Kosten und Dauer von Projekten sind wichtige Fixpunkte, die vorab zu klären sind. Und es muss deutlich herausgearbeitet werden, worauf die Geschäftsleitung im Gegenzug zur Initiierung neuer Projekte verzichten muss, das heißt, welche Vorhaben dafür zurückgefahren oder sogar beendet werden müssen. Ziel ist eine realistische Einschätzung, wie sich die Mittel eines Unternehmens bestmöglich einsetzen lassen, um die Unternehmensziele zu erreichen.

Dieses Ziel ist allerdings oft schwer zu erreichen. Der Grund dafür ist die meist komplexe Beziehung zwischen der Projektgruppe und den einzelnen Teams beziehungsweise Mitarbeitern, die die benötigten Teilergebnisse liefern. Auf Basis von Ressourcen, deren Verfügbarkeit, deren Know-how und dem geschätzten Aufwand in Personentagen versucht das klassische Multiprojekt-Management zu einer guten Einschätzung zu gelangen.

Grenzen des klassischen Multiprojekt-Managements

Klassischerweise legt das Multiprojekt-Management die unabhängig voneinander geplanten und eingereichten Projekte übereinander und prüft, ob diese Planungen auch in Summe funktionieren. In der Regel ist das jedoch nicht der Fall. Greifen Projekte auf die gleichen Mitarbeiter oder Teams zu, sind diese überplant. Dann wird versucht, diese Überplanungen durch Priorisierung, Verlängerung und Verschiebung der Projekte aufzulösen. Das Hauptproblem ist dabei in vielen Fällen, dass das planende Management-Team die oben genannten Beziehungen und Abhängigkeiten nicht in ihrer Gesamtheit überblicken kann. Doch was lässt sich gegen diese mangelnde Detailkenntnis unternehmen?

Gesamtplanung durch die Mitarbeiterteams

Hier lohnt sich ein Blick auf Skalierungsmodelle für Agilität wie LeSS (Large Scale Scrum) oder SAFe (Scaled Agile framework): Im PI-Planning (Program Increment Planning) des Scaled Agile Framework ist es Sache der agilen Teams, nicht nur ihre eigene Planung, sondern auch mehrmals im Jahr die Gesamtplanung aller Teams unter Berücksichtigung der bestehenden Abhängigkeiten zu erarbeiten. Die Aufwandschätzungen der Projekte im Vorfeld können damit sogar gröber ausfallen, da sie zusammen mit ihrem Strategiebeitrag nur noch die Basis für die Priorisierung durch die Geschäftsleitung bilden. Daran anschließend findet für jedes Projekt eine sogenannte Feature-Konferenz statt, in der die Projekte pro agiles Team in kleinere Einheiten heruntergebrochen werden, auf deren Basis dann eine gute Gesamtplanung erfolgen kann.

Mittlerweile arbeiten beim Münchner Versicherer 14 agile Teams an der Entwicklung der IT-Systemlandschaft, die ihren Input aus 20 bis 30 verschiedenen Projektgruppen bekommen. Ziel des regelmäßigen PI-Plannings ist es, die Abhängigkeiten zwischen den Features in den Teams deutlich herauszuarbeiten und so eine effiziente Planung für die nächsten Monate zu schaffen.

Die Gesamtplanung durch die Mitarbeiter brachte eine Reihe positiver Effekte: Die Mitarbeiter sind stolz auf ihre Konferenz und ihre professionelle Planungsarbeit. Durch diesen optimierten Prozess ist die Qualität der Planung gestiegen. Dies führt zu einem höheren Vertrauen in die Machbarkeit der Aufgaben und steigert damit noch einmal das Mitarbeiter-Commitment.

Doch das Wichtigste ist: Die Arbeit an den Projekten wurde beschleunigt und vereinfacht. Um das auch in Zukunft zu gewährleisten, müssen wir das agile Arbeiten konsequent weiterentwickeln. So ist das PI-Planning ein sehr wirkungsvolles Element agilen Arbeitens, aber kein Allheilmittel. Neue Projektteams, die mit Design Thinking arbeiten, liefern ihre Erkenntnisse fortlaufend, andere Bereiche müssen auf das analysierte Kundenverhalten nahezu in Echtzeit reagieren. Hierfür sind drei oder fünf Planungszyklen pro Jahr nicht ausreichend. Auch ist das Ziel des Vorgehens nicht, möglichst viele Abhängigkeiten aufzuzeigen. Das eigentliche Ziel ist es, sich so aufzustellen, dass es möglichst wenige Abhängigkeiten gibt.

Die größte Herausforderung ist deshalb, die IT-Systemlandschaft so umzugestalten und weiterzuentwickeln, dass viele End-to-end-Teams gebildet werden können, ohne in den oft äußerst langlebigen IT-Systemen technische Schulden anzuhäufen. Denn nur durch langfristige Erfolge können agile Methoden in Teams zur stetigen Weiterentwicklung von Unternehmen innerhalb und außerhalb der Versicherungsbranche beitragen.