Viele Finanzinstitute tun sich schwer, alte hierarchische Strukturen zu Gunsten neuer agiler Setups zu verändern. Alte und neue Strukturen können jedoch koexistieren. Fünf Massnahmen zeigen den Weg zur erfolgreich optimierten Produktentwicklung.
Durch mehr Agilität könnten Banken und Sparkassen ihre Produktentwicklung optimieren und beschleunigen.
Partner des Bank Blogs
Was ist notwendig, um einer Bank ein erfolgreiches agiles Setup zu ermöglichen? Ich meine damit nicht wie ein Kulturwechsel anzustossen und ein komplett neues Mindset zu etablieren ist. Ich meine vielmehr in einer Bank die Voraussetzungen zu schaffen, um erfolgreich und schnell neue Produkte zu entwickeln und einzuführen.
Der Weg erscheint einfach: Man stellt ein Team aus Businessvertretern, Entwicklern und gegebenenfalls weiteren Personen zusammen. Alles super agile Leute die den richtigen Mindset haben und Agilität nicht nur predigen, sondern auch leben (letztere gibt’s nach wie vor wenige im Banking). Und dann geht’s los!
Doch schon sehr bald heisst es „Stopp“! Der Entwickler kann die gewünschten Open-Source-Lösungen nicht installieren (verboten!), Spezifikationen am UI/UX sind durch das Businessmanagement abzunehmen, Marketingvorhaben (z.B Growth Hacking) sind in einem Steering Committee (einmal im Monat) abzunehmen und das Ausrollen einer Beta-Version kann nur erfolgen sofern sämtliche Dokumentationen bewilligt und abgenommen wurden (weit mehr als fünf Personen involviert!). Zu guter Letzt ist sogar das fertige und bereite Produkt nicht ausrollbar, da das Management dies zuvor im Aufsichtsrat noch präsentieren möchte (Tagt einmal alle fünf Wochen!). Viel Zeit und Kraft gehen verloren! Konkret also auch Cash!
Fünf Maßnahmen für ein agiles Setup
Wie können diese Hürden, Behinderungen und Tempobremsen eliminiert oder zumindest reduziert werden? Oder noch besser, Tempo und Drive sogar optimiert werden? Dafür habe ich fünf Punkte identifiziert.
- Einen maximierten Arbeitsplatz einrichten!
- Sämtliche Kompetenzen im Team bündeln!
- Mut loszulassen und machen (lassen)!
- Guidelines, die helfen und nicht verhindern!
- Realistische Erwartungen des Managements!
Alle fünf müssen angegangen werden. Nur so ist das fragile Gebilde eines optimalen agilen Setups in einer Bank unter Berücksichtigung aller Hierarchien, möglich.
1. Maximierter Arbeitsplatz (Power-Dev-Workplace)
Damit meine ich nicht ein möglichst cooles Büro mit Boxsack, Ping-Pong-Tisch und Café-Bar. Ich meine einen Arbeitsplatz, welcher es den Entwicklern ermöglicht, jederzeit, sofort und unabhängig irgendetwas zu probieren, installieren oder zu lizenzieren. Egal, ob es sich um ein Tool handelt, welches installiert werden muss, eine Firewall-Rule die zu umgehen ist oder gar ein Cloud-Service, der genutzt werden will; eine Lösung muss schnellstmöglich zugänglich gemacht werden.
Nichts ist mühsamer für einen Entwickler, als mitten in der Entwicklung eines vermeintlich optimalen Lösungsansatzes über Berechtigungen, Firewall-Rules und andere Verbote zu stolpern, welche nur mit mühsamen Berechtigungsprozessen aus dem Weg geräumt werden können, wenn überhaupt. Nicht selten werden so aus fünf Minuten mehrere Tage und Sitzungen.
Maximize the Workplace!
2. Sämtliche Kompetenzen im Team bündeln
Sämtliche Kompetenzen müssen im Team sein. Sämtliche! Architekturentscheide, Road-Map, Releases, Marketing, sogar welche Früchte in die Schale auf dem Tisch gehören. Das Team soll und muss selbst entscheiden, was das Beste für es und somit für das Produkt ist, wann die Reife eines Produkts gegeben ist oder wie und wann eine Beta-Version nach aussen gehen soll.
Team definiert, Team baut, Team verantwortet! Bedeutet, Team entscheidet!
Dies fördert auch den Zusammenhalt, die Leistungen sowie auch das Commitment zum Produkt und innerhalb des Teams um ein Vielfaches.
3. Mut loszulassen und machen (lassen)
Nicht zuletzt braucht’s eben auch das Management. Sprich, eben nicht!
Will heissen, dass das Management lernen muss, seinen Teil an diesem agilen Setup beizusteuern und entsprechend die Kompetenzen abzugeben und dem Team das Vertrauen zu schenken.
Es gibt keine Garantie, dass dann alles ohne Fehler umgesetzt wird, jedoch die Gewissheit allfällige Fehler möglichst früh zu machen und daraus schnellstmöglich die richtigen Lehren zu ziehen. Das Team braucht den Support des Managements in Form von Vertrauen und Handlungsspielraum. Kein Mikromanagement, keine Kontrollen von oben, keine wöchentlichen Budgetkontrollen! Das Management kann sich jederzeit in Review-Meetings (passive Teilnahme) ein Bild machen. Ansonsten muss das Management das Team ganz einfach machen lassen.
4. Guidelines, die helfen und nicht verhindern
Für das Team müssen selbstverständlich Rahmenbedingungen geschaffen werden. Wichtigste Regel dabei: Die Guidelines sollen dem Team helfen, sich auf die Lösung zu fokussieren!
Sämtliche Freiheiten dem Team zu überlassen, kann kontraproduktiv sein. Das Team kann sich verlieren und mitunter sogar gegenteilige Vorstellungen vom Produkt haben. Der Auftrag an das Team muss daher klar sein, aber nicht limitierend.
Es ist eine Gratwanderung, das Team nicht zu stark einzuschränken und trotzdem gewisse Stossrichtungen vorzugeben, um dessen Kreativität und die Power nicht einzuschränken. Zum Beispiel müssen dem Team die regulatorischen Limitierungen bekannt sein. Auch die Security-Anforderungen muss dem Team klargemacht werden. Vorgaben zu bereits existierenden Technologien und Plattformen der Bank sollten jedoch unterlassen werden. Hier muss die Idee sein, Empfehlungen oder Hinweise auf existierende Umgebungen, Produkte, Plattforen oder Software zu machen. Vorwiegend sollen die Guidelines dem Team helfen sich zu finden und ein allgemeines Verständnis über das Ziel zu schaffen.
Insgesamt sind Guidelines ein sehr fragiles und von der Formulierung her heikles Thema.
5. Realistische Erwartungen des Managements
Dem Management muss klar sein, dass ein agiles Setup nicht unbedingt günstiger ist. Damit lassen sich – zumindest kurzfristig – keine Kosten sparen. Tendenziell ist sogar kurzfristig eine Erhöhung der Kosten die Folge.
Wichtig ist, dem Management klar aufzuzeigen, dass das Setup unter Befolgung der Regeln (diese können in Working-Agreements festgehalten werden) das Produkt viel schneller entwickelt und adaptiert (Markteinfluss, technologischer Einfluss, etc.) werden kann. Somit ist das Produkt auch schneller am Markt (Time to Market).
Berücksichtigt man diese Faktoren bezüglich der Kosten, so wird einem schnell klar, dass diese unter dem Strich meistens sogar höher liegen als zuvor. Es muss daher klar artikuliert werden, was das Management in Bezug auf Setup, Vorhaben und Regeln erwarten darf.
In diesem Sinne… Nicht warten! Machen!