Agiles Projektmanagement findet in immer mehr Versicherungsunternehmen Einzug in den Projektalltag. Der Autor dieses Erfahrungsberichts hat als Product Owner (PO) im Kontext Outputmanagement im Programm zur Einführung eines Leben-Bestandsführungssystems in zwei Teams eine solche, noch andauernde, Transformation ein Jahr lang begleitet. Seine Erfahrungen werden mit dem Wissen aus anderen Projekten der AAA verglichen und bewertet. Im ersten Teil dieser Serie geht es um die Vorüberlegungen und Initialisierung der Transformation. Der zweite Teil ist ein Bericht über die ersten Monate im agilen Umfeld, der letzte Teil behandelt Weiterentwicklungspotentiale.
In einem komplexen Umfeld, in dem Ziele und Anforderungen schwierig zu greifen sowie selten statisch sind und ein optimales Vorgehen zur Abarbeitung von Aufgaben nicht immer klar erkennbar ist, spielt Agilität seine Vorteile aus. Im iterativen Arbeitsprozess, der auf die Optimierung eines Produkts ausgerichtet ist, werden in kurzen Abständen Softwarepakete als sogenannte Inkremente entwickelt. Das Team holt sich sodann Feedback von seinen Stakeholdern ein und kann dieses wiederum über einen kurzen Planungshorizont in das Produkt einfließen lassen. Agile Frameworks wie beispielsweise Scrum dienen hierbei als Leitplanken und postulieren ein Mindset, das für das Gelingen von Agilität im Unternehmen etabliert werden muss.
Vor dem Start der Transformation wurde analysiert, ob Agilität für die vorhandenen Anforderungen überhaupt der richtige Projektdesignansatz ist. Für den Kunden war Agilität per se nichts Neues, da es im Hause schon einige Teams gab, die agil arbeiten. Entsprechend gab es vom Management die Vorgabe, das Programm ebenfalls agil aufzustellen. Unterstützt wurde dies beispielsweise durch einen internen Scrum Master, der Erfahrungen aus anderen Teams und Projekten mitbrachte. Gemeinsam mit dem Scrum Master wurden auf Teamebene Ziele der Transformation definiert: Liefertermine sollten zuverlässiger als bisher eingehalten werden können und der Fokus auf wesentliche Aufgaben geschärft werden durch methodische Unterstützung. Insgesamt ist es also wichtig, dass Agilität von oben gelebt wird und die Teams bei der Transformation unterstützt werden. Als einzelnes Team hat man ohne Rückhalt von der Projektorganisation wenig Chance, da viele teamübergreifende Prozesse im Sinne der Agilität aufeinander abgestimmt werden müssen. Auf der anderen Seite muss aber auch auf Teamebene geprüft werden, wie agile Methoden möglichst effizient eingesetzt werden können und was genau das Ziel der Transformation für das Team ist.
Vor allem in den ersten Wochen der Umstellung gab es häufig noch Reibungen und Unklarheiten bzgl. der Rollenverständnisse und der Abstimmungen mit anderen Teams. Einen eigenen Scrum Master gab es für das Team nicht, weshalb der PO die Rolle mit übernehmen musste. Diese Doppelbelastung ist vor allem am Anfang nicht zu unterschätzen, da hier viele Voraussetzungen für das spätere Gelingen gelegt werden. Der Fokus auf die originären PO-Aufgaben war deshalb nicht immer gegeben, da nebenbei viele Hindernisse aufgelöst und Prozesse etabliert werden mussten. Die Einbindung eines erfahrenen Scrum Masters hätte diese Reibungsverluste verringert. Konkret ging es am Anfang vor allem darum, sich gemeinsam mit dem Team der neuen Arbeitsweise und den Scrum-Events (Sprint, Planning, Daily, Review, Retrospektive) anzunähern. Das forderte Zeit und Geduld, da viele Kolleg*innen bis dato noch keine Erfahrungen mit Scrum hatten. Vor allem die Retrospektiven, in denen das Team die Arbeitsweise des letzten Sprints reflektiert, haben sich hier als Methode für einen kontinuierlichen Verbesserungsprozess als wertvoll erwiesen. Auch nach außen hin müssen die neuen Rollen und Arbeitsweisen verstanden und akzeptiert werden, d.h. nicht nur das eigene Team, sondern auch das Umfeld muss eingebunden werden. Dies betrifft Prozesse (Anforderungen mussten neuerdings über das Refinement, d.h. Abstimmung der Anforderungen, ins Team kommuniziert werden) und Planungen (Termine wurden bzgl. der Sprintzyklen synchronisiert). Klare Rollenbeschreibungen, methodische Einführungen für das Team sowie die Kommunikation der neuen Prozesse und Erwartungshaltungen nach außen sind hier entscheidende Erfolgsfaktoren.
Ziel der Initialisierungsphase sollte es insgesamt sein, die Grundlage für einen fließenden Prozess zu legen und Spielregeln zu definieren. Ob die Initialisierungsphase auch für das konkrete Projekt seinen Zweck erfüllt hat, wird im nächsten Serienteil erörtert.
Sollte es in Ihrem Hause Fragen zum Umgang und zu den Herausforderungen mit der agilen Transformation geben, stehen wir Ihnen gerne beratend zur Seite. Wenden Sie sich hierzu einfach an Herrn David Feldmann.