die bank 04 // 2019

BERUF & KARRIERE

BERUF & KARRIERE PROJEKTMANAGEMENT MITTELS SCRUM Fünf Mythen verhindern Agilität Fast alle Kreditinstitute setzen mittlerweile agile Vorgehensweisen wie Scrum ein. Doch es scheint, als hätte der Hype um das Thema Agilität seinen Gipfel überschritten. Selbst Ken Schwaber, einer der Scrum-Vordenker, sieht Probleme in der Umsetzung. Er schätzt, dass 75 Prozent dieser Projekte nicht die Erwartungen erfüllen, die in sie gesetzt wurden. Doch an welchen Mythen scheitert das agile Arbeiten, und wie kann die aktuelle Situation verbessert werden? Viele Banken sehen in der agilen Arbeitsweise Scrum das methodische Allheilmittel gegen die Behäbigkeit komplexer Organisationen. Die Verantwortlichen glauben, Scrum versetze ihr Kreditinstitut in die Lage, ähnlich einem IT-Unternehmen schnell auf wechselnde Faktoren und Bedingungen zu reagieren. Nicht selten werden die Mitarbeiter mit beinahe missionarischem Eifer Scrum-zertifiziert. Agilität, also Flinkheit oder Beweglichkeit, ist als Reaktion auf die zunehmende Komplexität in Unternehmen in aller Munde. Kaum eine Bank nimmt nicht für sich in Anspruch, agile Methoden zu nutzen, und Scrum ist die wohl am weitesten verbreitete. Die Institute haben ihre Beschäftigten geschult und versuchen, die Vorgehensweisen umzusetzen. Formal betrachtet, gelingt ihnen das auch. Tatsächlich aber enden agile Projekte oftmals unvollkommen und hinterlassen überarbeitete, frustrierte Mitarbeiter. Es scheint gar, als habe das Thema Agilität den „Gipfel der überzogenen Erwartungen“ bereits überschritten. ÿ 1 In dem vom Analysehaus Gartner entwickelten „Hype-Zyklus“ steuern die ernüchterten Beschäftigten anschließend auf das „Tal der Enttäuschungen“ zu. An diesem Punkt besteht die Gefahr, dass Mitarbeiter und Management der Banken überreagieren und die agilen Methoden verteufeln. Mythos 1: Scrum als agile Blaupause Die Unternehmensleitung hatte der Organisation die Arbeitsweise Scrum als Patentrezept verordnet, ohne sich mit den Werten und Wirkmechanismen der Agilität zu befassen und ohne diese in einer Form umzusetzen, die zum Institut passt. Sie kopierten das Modell, statt es zu verstehen, missachteten die Bedenken ihrer Wissensträger und ordneten sowohl deren fachliche Expertise der Methode unter als auch die realen Probleme. Das Management war und ist davon überzeugt, Scrum könne als agile Blaupause genutzt werden. Scrum-Pionier Ken Schwaber beschreibt dieses Phänomen als Methoden-Fassade (Methodology Facade Pattern). Scrum wird nicht als Werkzeug zur Einführung von Agilität verwendet, sondern als eine eigene Schicht über die bereits existierende und unverändert bleibende Arbeitswelt gelegt. Es werden also Praktiken und Prozesse kopiert, anstatt Werte und Prinzipien zu verinnerlichen. ÿ 2 Und der US-amerikanische Software-Entwickler kennt auch die Konsequenzen daraus: „Ich schätze, dass 75 Prozent der Organisationen, die Scrum nutzen, nicht die erhofften Vorteile erzielen werden." Die Mitarbeiter spüren die Auswirkungen jeden Tag. Viele von ihnen lehnen agile Methoden mittlerweile ab und benutzen den Begriff geradezu als Schimpfwort für wenig zielgerichtetes Vorgehen. Für sie bedeutet Scrum Chaos. Andere Institute wiederum haben Scrum nur in einzelnen Abteilungen eingeführt. So stellt häufig die IT darauf um, ohne die Zusammenarbeit mit den übrigen Bereichen zu klären. Doch Agilität sollte nicht als Stückwerk verstanden werden. Sie setzt im Gegenteil eine ressortübergreifende Kommunikation und Kooperation aller Beteiligten voraus. 62 04 // 2019

BERUF & KARRIERE 1 | Agilität im Hype Cycle Aufmerksamkeit Gipfel der überzogenen Erwartungen Agilität Plateau der Produktivität Pfad der Erleuchtung Tal der Enttäuschungen Technologischer Auslöser Zeit Quelle: Basierend auf Gartner Inc., 1995. Selbstredend kann eine dafür notwendige Kultur der Zusammenarbeit nicht einfach oktroyiert werden, sondern muss als stetiger, unternehmenskultureller Prozess mit den Teams gemeinsam Schritt für Schritt entwickelt und auf spezifische Gegebenheiten angepasst werden. Mythos 2: Banken müssen zu IT-Unternehmen transformieren Es kommt nicht von ungefähr, dass Kreditinstitute gerade ihre IT-Bereiche auf agiles Arbeiten einschwören. Spätestens mit der verpflichtenden Freigabe von Kundendaten im Rahmen der Zweiten Zahlungsdiensterichtlinie (PSD2) hatte sich in etablierten Bankhäusern die Angst ausgebreitet, RoboAdvisors der FinTechs könnten bald das Geschäft der Retailbanken übernehmen. So wird immer wieder gefordert, dass Banken mit ihren meist veralteten Kernbankensystemen zu IT-Unternehmen transformieren müssten, um den Anschluss an die technologisch überlegen scheinenden Softwareschmieden nicht zu verpassen. Doch die Forderung gehört ins Reich der Mythen, die agiles Arbeiten verhindern. Schließlich kann eine IT-Firma auch nicht im Handumdrehen zur Bank werden. Was den Banken fehlt, ist nicht die Wirkungsweise eines Technologieunternehmens, sondern die Fähigkeit, fachliche Anforderungen des Markts zu antizipieren und die passende, auf ihrer spezifischen Expertise basierende IT-Lösung zügig an den Markt zu bringen. Die Institute sollten also ihr bankfachliches Wissen schneller nutzen können. In der Tat haben sie den IT-Unternehmen viel voraus: Auf der einen Seite stehen ihre Kenntnisse über Produktspezifika, Kapitalmärkte, Reporting- und Regulatorik-Anforderungen, und auf der anderen Seite steht die Nähe zum Kunden. Um diese Mehrwerte zu erbringen und in einem volatilen Marktumfeld bestehen zu können, benötigt eine konkurrenzfähige Bank eine funktionierende, lieferfähige IT. Dies aber setzt für die Institute voraus, wieder den Kundennutzen in den Mittelpunkt zu stellen und etwaige Software-Lösungen mit ihrer bankeneigenen Expertise zu lenken, statt sich einem technologiegetriebenen Diktat zu unterwerfen. Nur das führt zu fachlich durchdachten Produkten, die am Markt bestehen werden. Zu diesem Prozess gehört auch, dass der jeweilige Fachbereich und die IT eine gemeinsame Sprache finden. Doch oft ist das Gegenteil der Fall. Das folgende Beispiel verdeutlicht die Herausforderung: Eine Bank will ein neues Wertpapiersystem entwickeln, aber die IT-Mitarbeiter kennen die fachlichen Grundlagen und Begriffe rund um eine Wertpapier- Order nicht. Statt ihre Fachkollegen nach den Unterschieden zwischen dem Buchungs-, dem Schlusstag und dem Valutadatum zu fragen, werfen sie die Bezeichnungen durcheinander. Um das zu verhindern, wird zu Beginn des Projekts nicht nur ein technisches Set-up, sondern auch ein fachlicher „Sprint 0“ benötigt. In diesem entwickeln die Teilnehmer mit der Produktvision ein fachliches Zielbild und schaffen über entsprechende Fachskizzen und Glossare eine gemeinsame fachliche Basis. Mythos 3: Das Product Backlog steuert den Produktumfang Die Dominanz der IT-Abteilungen in den Instituten zeigt sich auch daran, dass häufig sie diejenigen sind, die die Einführung von Scrum initiieren oder antreiben. Damit einhergehend setzen technische Sichtweisen die Rahmenbedingungen. In der Folge geht die Perspektive des Bankkunden in den User Storys häufig verloren. Scrum sieht vor, dass der Produktverantwortliche (Product Owner) alles, was die Software leisten muss, in das Product Backlog aufnimmt. Ziel ist es, kurzfristig die Funktionalität auf den Markt zu bringen, die den größten Nutzen für den Kunden hat. Das Product Backlog dient dabei lediglich als Werkzeug zur internen Abstimmung. 04 // 2019 63