Was braucht es, um in einer Bank ein erfolgreiches agiles Setup zu ermöglichen?
Ich meine damit nicht den Weg, wie ein Kulturwechsel anzustossen und ein komplett neues Mindset zu etablieren ist. Vielmehr geht es mir um ein agiles Setup, das in einer Bank möglichst schnell bereitgestellt werden soll, damit neue Produkte entsprechend schnell entwickelt und umgesetzt werden können. Was braucht es dazu? Was steht oftmals im Wege? Und welches sind die wichtigsten Hürden, die abgebaut werden müssen?
Wie es nicht funktionieren kann
Man stellt ein Team aus Businessvertretern, Entwicklern und weiteren Spezialisten zusammen. Ein Team mit durchwegs super agilen Leuten, die das richtige Mindset haben und Agilität nicht nur predigen, sondern auch tatsächlich leben. Davon gibt’s im Banking nach wie vor wenige, aber es gibt sie. Steht dieses Team, kann es losgehen.
Doch schon sehr bald heisst es: Stopp! Der Entwickler kann die gewünschte und notwendige Open Source-Lösungen nicht installieren (verboten). Spezifikationen im Zusammenhang mit UI/UX sind durch das Businessmanagement abzunehmen. Marketingvorhaben (zum Beispiel Growth Hacking) sind innerhalb definierter Strukturen (einmal pro Monat) abzunehmen. Und das Ausrollen einer Beta-Version kann nur erfolgen, nachdem sämtliche Dokumentationen bewilligt und abgenommen wurden (weit mehr als fünf Personen involviert). Zu guter Letzt ist sogar das fertige und marktbereite Produkt nicht ausrollbar, weil das Management dies zuerst noch dem Verwaltungsrat präsentieren möchte (tagt alle fünf Wochen einmal). Viel Zeit und Kraft gehen verloren. Motivation ebenfalls. Und konkret auch Cash.
Der Weg zum agilen Setup in einer Bank
Wie können diese Hürden, Behinderungen und Tempobremsen reduziert und eliminiert werden? Oder noch besser, wie können Tempo und Drive sogar optimiert und erhöht werden? Dazu habe ich fünf Punkte identifiziert. Alle fünf Punkte müssen konkret angegangen und gelöst werden. Nur so ist das fragile Gebilde eines optimalen agilen Setups in einer Bank, unter Berücksichtigung sämtlicher Hierarchiestufen, möglich.
Maximierter Arbeitsplatz (Power-Dev-Workplace)
Damit ist nicht ein möglichst cooles Büro mit Boxsack, Pingpong-Tisch und Café-Bar gemeint. Vielmehr geht es um einen Arbeitsplatz und eine Arbeitsumgebung, welche dem Entwickler jederzeit ermöglicht, sofort und unabhängig Dinge zu probieren, zu installieren und zu lizenzieren. Sei das ein Tool, das installiert werden muss, eine Firewall Rule, die zu umgehen ist oder gar ein Cloud Service, der genutzt werden soll – all das muss schnellstmöglich nutzbar sein und deshalb zugänglich gemacht werden.
Nichts ist für einen motivierten Entwickler mühsamer, als mitten in der Entwicklung eines vielleicht optimalen Lösungsansatzes über Berechtigungen, Firewall Rules und andere Verbote zu stolpern. Hürden, welche nur mit langwierigen Bewilligungsprozessen übersprungen werden können, wenn überhaupt. Nicht selten werden so aus fünf Minuten mehrere Tage. Und zahllose Sitzungen mit langfädigen Erklärungen und unnötigen Diskussionen bremsen nicht nur das Tempo, sie sind Gift für die Motivation von begabten Entwicklern.
Deshalb: Maximize the Workplace.
Sämtliche Kompetenzen gehören ins Team
Ein sehr zentraler Punkt: Sämtliche Kompetenzen müssen im Team angesiedelt sein. Sämtliche! Architekturentscheide, Roadmap, Releases, Marketing – ja, sogar welche Früchte in die Schale gehören. Das Team soll und muss entscheiden können, was das Beste für die Entwicklung, für die Teamarbeit und somit für das Produkt ist. Das Team entscheidet, wann die Reife eines Produkts erreicht ist, wie und wann eine Beta-Version nach aussen gehen soll.
Team definiert, Team baut, Team verantwortet – das bedeutet: Team entscheidet.
Dies fördert und erhöht auch den Zusammenhalt, die Leistungen sowie auch das Commitment zum Produkt und zum Team um ein Vielfaches.
Es braucht Mut loszulassen und andere machen zu lassen
Nicht zuletzt braucht’s auch das Management. Oder eben gerade nicht. Irgendwie schon, aber in einer anderen Form.
Will heissen, dass das Management lernen muss, seinen Teil zu diesem agilen Setup beizusteuern und entsprechend Kompetenzen abzugeben und dem Team das Vertrauen zu schenken. Es gibt keine Garantien, dass alles auf Anhieb ohne Fehler umgesetzt wird. Doch es gibt die Gewissheit, möglichst schnell Lehren daraus zu ziehen, wenn allfällige Fehler in einem Frühstadium des Projekts gemacht werden.
Das Team braucht den Support des Managements in Form von Vertrauen und von umfassend definiertem Handlungsspielraum. Keine hierarchischen Bremsen, keine Kontrollen von oben, keine wöchentlichen Budgetkontrollen. Das Management kann sich jederzeit in Review Meetings (passive Teilnahme) ein aktuelles Bild verschaffen. Das Management muss das Team machen lassen.
Guidelines sollen helfen, nicht verhindern
Für das Team müssen selbstverständlich Rahmenbedingungen geschaffen werden. Wichtigste Regel: "Die Guidelines sollen dem Team helfen, sich auf die Lösung zu fokussieren." Dem Team sämtliche Freiheiten ohne Leitplanken zu überlassen, kann kontraproduktiv sein. Das Team kann sich verlieren und allenfalls sogar gegenteilige Vorstellungen des Produkts entwickeln. Der Auftrag an das Team muss deshalb klar sein, aber nicht limitierend.
Es ist eine Gratwanderung, das Team nicht zu stark einzuschränken und dennoch die gewünschte Stossrichtung vorzugeben, um Kreativität und Power eines Teams in die richtigen Bahnen zu lenken. Zu den Leitplanken gehören sicher die regulatorischen Limitierungen, die dem Team bekannt sein müssen. Oder auch die Anforderungen der Security müssen in den Guidelines klar formuliert werden.
Was aber nicht geht, sind zum Beispiel bereits existierende Technologien und Plattformen der Bank als zwingende Vorgaben ins Briefing zu schreiben. Hier muss es in die Richtung gehen, Empfehlungen oder Hinweise auf existierende Umgebungen, Produkte, Plattformen oder Software zu platzieren – als Information, nicht als Zwang.
Vorwiegend sollen die Guidelines dem Team helfen, sich zu finden und ein allgemeines Verständnis für die Ziele zu schaffen. Wie bereits gesagt, ein sehr fragiles Feld und von der Formulierung her ein heikles und anspruchsvolles Thema.
Erwartungen des Managements
Dem Management muss klar sein, dass ein agiles Setup nicht kostengünstiger sein wird. Damit lassen sich, zumindest kurzfristig, keine Kosten sparen. Im Gegenteil, tendenziell ist in ersten Phasen sogar mit höheren Kosten zu rechnen.
Wichtig ist jedoch dem Management klar aufzuzeigen, dass ein agiles Setup mit den richtigen Leitplanken und unter Einhaltung der Regeln klare Vorteile generiert: Das Produkt kann viel schneller entwickelt und adaptiert werden. Somit ist das Produkt auch deutlich schneller am Markt (Time to Market).
Berücksichtigt man nicht nur die Entwicklungsphase, sondern sämtliche Faktoren, ergibt sich auch in Bezug auf die Kosten ein anderes Bild. Diese liegen unter dem Strich meistens tiefer als zuvor. Weil neue Produkte schneller oder überhaupt erst auf den Markt kommen.
So oder so muss klar Stellung bezogen und für das Management definiert werden, was in Bezug auf agiles Setup, Vorhaben und Regeln, Massnahmen, Freiräume und Ziele erwartet werden darf.
In diesem Sinne: Nicht warten! Machen!
