Agile Skalierung per Framework: wie Banken die richtige Mischung für ihr IT-Großprojekt finden

Auf den IT-Baustellen deutscher Banken soll so agil wie möglich gecodet, getestet und deployed werden. Sogenannte Skalierungs-Frameworks unterstützen die Projektbüros bei der Übertragung agiler Ansätze auf Großprojekte. Doch nicht jedes Framework passt wie angegossen. Ein methodisches Vorgehen hilft bei der Auswahl der passenden Ansätze und der Kombination einzelner Bausteine.  

von Christian Steinweg von Sopra Steria

Es ist viel los in der deut­schen Ban­ken­bran­che. Die Com­merz­bank hat an­ge­kün­digt, auf mo­der­ne Cloud-Tech­no­lo­gi­en von Mi­cro­soft zu set­zen. Die Deut­sche Bank wird im Rah­men ih­res Mo­der­ni­sie­rungs­pro­jek­tes eben­falls Cloud-Ser­vices nut­zen, al­ler­dings die von Goog­le. Und die Spar­kas­sen ste­hen den pri­va­ten Ge­schäfts­ban­ken in nichts nach. Die Fi­nanz In­for­ma­tik ver­mel­de­te be­reits im Ju­li 2020 ei­ne Zu­sam­men­ar­beit mit dem In­ter­net­kon­zern aus den USA.

Für die Umsetzung dieser IT-Großprojekte entscheiden sich die Institute mittlerweile flächendeckend für agile Ansätze. Was die Häuser allerdings bei der Planung immer wieder feststellen:

Agile Ansätze sind in ihrer Grundidee mit den bekannten Scrum-Rollen nicht für derart voluminöse Vorhaben mit mehreren hundert Projektbeteiligten ausgelegt.”

Skalierbare Frameworks wie SAFe, LeSS, Nexus, OKR oder das Spotify Tribe Model helfen zwar dabei, agile Arbeitsbedingungen auch in Konzernstrukturen zu schaffen. Doch viele Ansätze lassen sich nicht eins zu eins auf jedes Vorhaben übertragen.

Hier einige typische Hürden, auf die Projektplaner im Umgang mit Skalierungs-Frameworks immer wieder stoßen:

• Die Skalierungsansätze in ihrer Reinform verfügen über eine starre Nomenklatur der vordefinierten Rollen, Events und Artefakte. Dieses Korsett passt häufig nicht für das konkrete Vorhaben.
• SAFe skaliert beispielsweise vertikal (hierarchisch) über mehrere Ebenen und LeSS skaliert tendenziell eher horizontal auf einer Ebene. Je nachdem, welche Abteilungen und welche externen Partner beteiligt sind, stoßen die Frameworks in ihrer Reinform an ihre Grenzen.
• Skalierungsansätze wie SAFe oder LeSS verfügen zudem über ein hohes Maß an „Basisdemokratie“. Wenn Banken eines dieser Frameworks in ihrer Reinform nutzen, besteht die Tendenz einer „ausufernden Meetingkultur“. In der aktuellen Projektpraxis der Banken ist das nicht erwünscht, denn es erschwert klar abgegrenzte Berichts- und Eskalationswege und Verantwortlichkeiten.
• Dazu kommt: In traditionellen Banken ist eine fortgeschrittene agile Kultur in der Regel noch nicht zu erkennen. Eine agile DNA findet man eher in Neobanken wie N26 oder Solarisbank mit viel häufigeren Release-Zyklen. Ergo: Der durchgängige Einsatz eines agilen Skalierungs-Frameworks in seiner Reinform passt noch nicht zur Projektkultur einer Sparkasse oder Landesbank.
• Und: Viele Banken wollen oder können auf bestimme Rollen des klassischen Projektmanagements nicht verzichten – insbesondere nicht auf Projektleiter und Teilprojektleiter.

Nun könnte man theoretisch auf die Idee kommen, IT-Großprojekte einfach in kleine Scrum-Teams zu stückeln, um sie komplett agil zu managen. Doch das hat zwei entscheidende Nachteile:

1. Inhaltliche Steuerung: Abhängigkeiten von den anderen „n“ agilen Teams lassen sich nur schwer erkennen und managen. Es fehlt die übergeordnete Steuerung und Validierung des Gesamtergebnisses.
2. Synchronisation und Vernetzung: Jedes Team arbeitet losgelöst für sich. Ergebnisse und Ressourcen werden nicht untereinander abgestimmt. Der Gleichlauf zwischen den agilen Teams ist erschwert, weil die Schnittstellen- und Synchronisationsfunktionen fehlen. 

Eignungstest für Skalierungs-Framework durchführen

Es gilt somit, für jedes Projekt zu prüfen, ob es sich mit einem agilen Skalierungs-Framework, ei­nem rei­nen Was­ser­fallan­satz oder mit ei­ner Mi­schung (Hy­brid­an­satz) um­set­zen lässt. Es hat sich be­währt, im Vor­we­ge ei­ne Art Au­dit durch­zu­füh­ren. Hier­für soll­ten die Pro­jekt­ver­ant­wort­li­chen in Ban­ken in­ter­ne Prüf­kri­te­ri­en be­stim­men, die für Pro­jek­te wie den Um­zug in die Cloud, die Ein­füh­rung ei­nes neu­en Kern­bank­sys­tems oder die Um­set­zung ei­ner Ze­ro-Help­desk-Stra­te­gie wich­tig sind.

Die ein­zel­nen agi­len und klas­si­schen An­sät­ze müs­sen zu­nächst ein­mal zum Pro­jekt-Scope pas­sen. Grö­ße, Ab­hän­gig­kei­ten und Kom­mu­ni­ka­ti­ons­we­ge soll­ten trenn­scharf ab­bild­bar sein. Spe­zi­ell die gro­ßen Stra­te­gie­pro­jek­te, wie sie Ban­ken der­zeit vor­ha­ben, er­for­dern zu­dem ei­nen Blick auf das Ge­samt­pro­jekt so­wie kla­re Ver­ant­wort­lich­kei­ten und Berichtswege.

Darüber hin­aus soll­ten Pro­gramm- und Pro­jekt­ma­na­ger ab­klä­ren, in wel­chem Pro­jekt­um­feld sie sich be­we­gen. Gibt es ei­ne Vor­lie­be in den Teams für ei­ne be­stimm­te Me­tho­de, soll­te dies in die Be­wer­tung ein­flie­ßen. Wenn SAFe oder ein an­de­rer An­satz be­reits eta­bliert sind und es gu­te Er­fah­run­gen gibt, ist das ein Plus­punkt für die­ses Framework.

Der Zuschnitt der Projektmanagementmethode hängt zudem von der Unternehmens- und Projektkultur in der Bank ab. Das Skalierungs-Framework, ob in Reinform oder als Hybrid, muss mit internen Verfahren und Richtlinien zur Projektabwicklung vereinbar sein, beispielsweise mit Test- und Abnahmeprozessen. Pluspunkte haben zudem Methoden, wenn sie mit den intern genutzten Planungstools und Testwerkzeugen abgebildet werden können. Und: Die Mitarbeiterinnen und Mitarbeiter sollten eine Affinität für die Methode besitzen.

Letztendlich geht es somit auch darum, eine passende Methode für das Projektteam zu finden. Mit Projektteam sind alle Beteiligten gemeint. Die Methode muss zur Zahl der Teilnehmer passen, unter Umständen muss die Methode auf mehrere hundert Personen skalierbar sein.”

Eine häufige Anforderung ist, dass ein Framework Vernetzung und Synchronisation der Einheiten untereinander ohne Reibungsverluste unterstützt. Zudem sollte der Schulungsaufwand daraufhin untersucht werden, inwieweit Know-how zur Methode im Unternehmen vorhanden oder leicht aufzubauen ist.

Ein bisschen SAFe, ein wenig Nexus, ein Hauch von Spotify mit einer Prise Wasserfall

Mit dem „Audit“ besitzen Banken eine solide Basis, um ein Projekt vernünftig aufzugleisen. Aus den Einschätzungen zu den einzelnen Frameworks, ob rein agil, hybrid oder rein klassisch, können sich Projektmanager die Framework-Elemente heraussuchen, die am besten zur individuellen Situation passen.

In einem konkreten Digitalprojekt bei einer großen Bank ergab das Audit beispielsweise, klassische Elemente in das Skalierungs-Framework SAFe einzubetten. Heraus kam ein Ansatz, in dem es sowohl agile Rollen wie den Chief Product Owner (CPO), Chief Scrum Master/Release Train Engineer (RTE) und Enterprise Architect gab, als auch klassische Rollen wie den Testmanager sowie Qualitätsmanager und die Projektleitung.

Zwei Gründe gaben in diesem Fall den Ausschlag für den gewählten Projektzuschnitt:

1. SAFe skaliert vertikal (hierarchisch) mit einer Umsetzungsebene mit „n“ Scrum-Teams und einer übergeordneten Steuerungsebene. Dieses Modell passte am besten zu den konkreten Projektanforderungen.
2. SAFe bietet auf der Steuerungsebene eine Mittelfristplanung (Planung von Inkrementen), die sich sehr gut in die klassische Gesamtplanung und die kurzfristige Scrum-Team-Planung (Sprints) einbetten lässt.

Es hat sich in einigen Großprojekten bewährt, dass der inhaltliche Projektteil agil bearbeitet wird und in eine klassische Projektsteuerung von Zeit, Budget, Ressourcen und Risiken eingebettet ist. Die klassische Dreiteilung in Entscheidungsebene, Steuerungsebene und Umsetzungsebene bleibt somit erhalten.”

Die folgenden Punkte sind ein typisches Grundgerüst:

• Zeit, Budget, Ressourcen und Risiken steuern die alten Bekannten wie der Sponsor, Auftraggeber, Lenkungsausschuss, die Projektleitung und das Projektmanagement-Office.
• Die inhaltliche Bearbeitung übernehmen dann agile Teams, beispielsweise in Form von Sprints. Dazu zählen unter anderem Feature-Teams mit allen bekannten Scrum-Rollen wie Product Owner, Scrum Master etc.
• Die inhaltliche Verantwortung teilen sich die Umsetzungsebene (ein Product Owner verantwortet ein Teilprodukt) und die übergeordnete Steuerungsebene (Chief Product Owner verantwortet das Gesamtprodukt).
• Vertikal eingezogene Schnittstellen sorgen für eine regelmäßige inhaltliche und methodische Synchronisation zwischen der Umsetzungsebene und der Steuerungsebene.
• Die flankierende operative Projektsteuerung obliegt den klassischen Rollen, also dem Projektleiter oder je nach Komplexität dem Teilprojektleiter.

Jedes Projekt ist anders, deshalb wird es sich nicht verhindern lassen, dass Banken diese Bewertung bei Folgeprojekten wiederholen. Das methodische Vorgehen unterstützt allerdings als Template.”

Bestimmte Schritte verkürzen sich, und Banken kommen so schneller zu einem fundierten Ergebnis. Zudem sinken die Risiken eines Projektmisserfolgs, wenn die Methode zu den Menschen passt.Christian Steinweg, Sopra Steria