So nutzen Banken das Spotify-Modell für ihre agile Transformation

Agilität für ein erfolgreiches Banking der Zukunft (1/2)

Abonnieren Sie den kostenlosen Bank Blog Newsletter

Zunehmende Konkurrenz durch FinTechs und veränderte Kundenwünsche stellen traditionelle Banken vor große Herausforderungen. Als Konsequenz strukturieren Banken und Sparkassen ihre Organisation rigoros um und setzen immer häufiger auf das agil aufgebaute Spotify-Modell.

Umstellung auf agiles Banking

Banken und Sparkassen auf der Suche nach mehr Agilität.

Partner des Bank Blogs

Seit ihrer Gründung im Jahre 2006 verkörpert die schwedische Musik-Streaming-Plattform Spotify den Inbegriff des frischen, agilen Unternehmens. Das Credo: In einem sich permanent ändernden Marktumfeld muss sich auch die Organisation ständig anpassen. Das Prinzip dahinter: Die Mission, den Kunden bestmöglich zu beliefern, ist wichtiger als Regeln und Dogmen.

Der Hype um das Spotify-Modell ist ungebrochen: Arbeiteten zunächst überwiegend Startups damit, nutzte es ab 2015 die Großbank ING mit dem ambitionierten Ziel „Wir wollen die erste agile Bank werden“. Andere traditionelle Banken wie etwa die Commerzbank zogen nach. Die Gründe für den Erfolg sind vielfältig: So lehnt sich das Spotify-Modell stark an klassische Organigramme an, bietet einen vertrauten Rahmen und dient damit als ideale Vorlage für eine agile Transformation.

Der ursprüngliche Aufbau des Spotify-Modells

Für die in 2012 von den Spotify Agile Coaches Kniberg und Ivarsson initiierte Aufbauorganisation waren zwei Ereignisse ausschlaggebend:

  • Das starke Wachstum des Unternehmens auf der einen Seite und
  • die Übermacht von Google und Apple auf der anderen.

Die Aufbauorganisation nach dem Modell von 2012 bezeichnet Spotify als eine „neu designte Matrixorganisation“, die im Gegensatz zu klassischen Strukturen den Fokus auf den kundenzentrierten Wertstrom und weniger auf die Organisation in Funktionen legt.

Spotify-Aufbauorganisation nach dem Modell von 2012

Das Spotify-Modell besteht aus Squads mit einem Product Owner, Chapters und Tribes. Guilds bilden eine Klammer für den bereichsübergreifenden Austausch.

Den Kern bilden die Squads: Teams mit jeweils etwa acht Mitgliedern. Sie arbeiten interdisziplinär, selbstorganisiert und selbstgesteuert und sind mit Scrum-Teams vergleichbar. Im Mittelpunkt steht die Schwarmintelligenz sowie die Ideenfindung und -umsetzung aller Teammitglieder. Der Product Owner fungiert im Squad als inhaltliche Führungskraft – er gibt das Ziel und die Rahmenbedingungen vor.

Aus mehreren Squads bilden sich wiederum Tribes, die gemeinsam beispielsweise an einem Produkt arbeiten. Diesem Tribe steht ein Tribe Lead vor, der die Gesamt-Vision und -richtung der produktzentrierten Einheit verantwortet. Chapter sind Mitglieder eines Tribes aus einer Fachrichtung (z.B. User Experience Designer). Der Chapter Lead sorgt für den Wissensaustausch und damit die stetige Weiterbildung der Gruppenmitglieder. Guilds sind freiwillige Zusammenschlüsse über Tribes hinweg, die einen bereichsübergreifenden Austausch zu Themen wie beispielsweise Testautomatisierung ermöglichen.

Die Aufbauorganisation Bank oder Sparkasse, die das Spotify-Modell anwendet, bildet beispielhaft folgende Grafik ab. In dieser ist gut zu erkennen, dass es sich in der Regel um einen produktzentrierten Schnitt handelt, der durch relevante Support-Einheiten unterstützt wird:

Beispiel der Aufbauorganisation einer Bank

Das Spotify-Modell ist am Beispiel einer Bank produktzentriert ausgerichtet.

Notwendigkeit des Wandels: Leadership-Trios und Alliances

Um das personelle Wachstum von Spotify zu stemmen, gehörte ab 2015 die Einführung von Leadership-Trios auf Tribe-Ebene und die Einführung sogenannter Alliances, ein Zusammenschluss von mindestens zwei nahestehenden Tribes, zu den großen Veränderungen im Modell. Zusätzlich teilten sich ab dato die Alliances und Tribes je nach Art ihrer Kunden (intern oder extern) in Business und Support Missions. Die Business Mission Alliances bilden in der Regel Kundensegmente (z.B. Retail) ab, um deren optimale Bedienung durch mehrere Produkte sicherzustellen.

Spotify-Aufbauorganisation nach dem Modell nach 2015

Ab 2015 kamen Alliances und Leadership-Trios beim Spotify-Modell hinzu.

Herausforderungen bei der Anwendung des Modells

Bei der Implementierung des Spotify-Modells in Unternehmen und insbesondere Banken und Sparkassen zeigen sich immer wieder ähnliche Schwierigkeiten. Zwei häufig auftretende Hürden werden im Folgenden mit Lösungsvorschlägen beschrieben:

  1. Der organisatorische Schnitt von Tribes und
  2. die Rolle des Product Owners.

1. Der organisatorische Schnitt von Tribes

Im Spotify-Modell verschmelzen technische und fachliche Kompetenzen. In letzter Instanz bedeutet das ein Zusammenlegen von IT und Fachbereich in eine Einheit – eine Konsequenz, die viele Unternehmen abschreckt.

Dementsprechend übernimmt in den jeweiligen Organisationseinheiten nur noch eine Führungskraft, der Tribe Lead. Seine Aufgabe ist es, die unterschiedlichsten Fachexperten auf das gemeinsame Ziel hin anzuleiten.

Ein weiteres Thema ist die Größe der Tribes. In der Praxis stellt schon eine Größe mit 100 Personen pro Tribe Unternehmen vor große Herausforderungen. Denn: Bei einem Tribe dieser Größenordnung erreicht die Führungsspanne von Tribe Leads schnell über 20 Personen, da sowohl Chapter Leads als auch Product Owner an den Tribe Lead berichten.

Das inzwischen erweiterte Spotify-Modell bietet folgende Lösung: die Einführung von Technologie-Leads auf Tribe-Leadership-Ebene. Diese unterstützen den Tribe Lead, der die Produktverantwortung innehat, und führen in der Regel die IT-nahen Chapter Leads. Doch auch in diesem Fall gilt: Kleine Tribes mit weniger als 100 Mitarbeitern sind mehr als sinnvoll.

2. Die Rolle des Product Owners

Die Ausgestaltung der Rolle des Product Owners steht immer wieder im Fokus: Da zwischen Product Owner und Tribe Lead keine weitere Ebene vorgesehen ist, müssen Product Owner bei Tribes mit mehr als fünf bis sechs Squads sehr strategisch arbeiten. Denn die Strategie eines jeden einzelnen Produktes oder Services kann hier durch den Tribe Lead nicht mehr selbst geleistet werden, sodass diese nun durch die operative Ebene erarbeitet werden muss. Im Wesentlichen entspricht das einem „reifen“ agilen Setup, indem der Product Owner sehr viel Autonomie genießt und auf strategischer Ebene arbeitet, während das Team sich selbst um die User Stories kümmert. Die Voraussetzung dafür sind eigenverantwortliche Teams mit viel Business-Know-how und das stellt in der Regel in der Praxis eine große Herausforderung für viele Banken dar. In großen Setups kann auch die Installation eines zusätzlichen Chief Product Owners (CPO) sinnvoll sein, um die Arbeit an der Ausrichtung und die Kommunikation mit den Stakeholdern zu bündeln. CPOs übernehmen in der Regel die strategische Arbeit für Produkte, die aus mindestens drei Squads bestehen.

Auch gestaltet sich die Entwicklung eines Mitarbeiters von der Rolle des Product Owners hin zur potentiellen Rolle des Tribe Leads häufig schwierig: Während ein Product Owner in der Regel ein kleines Team bis zu neun Personen führt, führt ein Tribe Lead mindestens 50 Menschen und berichtet in vielen Unternehmen direkt an die Geschäftsführung oder den Vorstand. Ohne starkes Investment in die persönliche Weiterentwicklung des Mitarbeiters ist dieser Sprung kaum zu meistern.

Fazit : Spotify-Modell unterstützt Neuaufstellung der Organisation

Das Spotify-Modell unterstützt Banken und Sparkassen bei der Neuaufstellung ihrer Organisation. Richtig angewandt fördert es eine offene Kommunikationsstruktur und eine enge Zusammenarbeit aller Beteiligten und kurbelt damit den Wandel an. Doch die Neugestaltung der Aufbauorganisation ist immer ein großer Einschnitt – ein strukturierter, agiler Prozess kann bei der Transformation unterstützen.

Im zweiten Teil wird es um die Umsetzung des Modells und die besondere Rolle der Chapter (Leads) im agilen Spotify-Modell gehen.

Über den Autor

Christoph Schmiedinger

Christoph Schmiedinger ist Executive Management Consultant bei borisgloger consulting mit Schwerpunkten in den Bereichen Enterprise Agility, agile Transformationen und skalierte Projekte in Banking und Finance. Zuvor war er als Product Owner bei einem Hersteller von sicherheitskritischen Kommunikationslösungen in Wien tätig und kann auf über acht Jahre Erfahrung in der agilen Entwicklung von Produkten und Systemen zurückblicken.

Vielen Dank fürs Teilen und Weiterempfehlen


Mit dem kostenlosen Bank Blog Newsletter immer informiert bleiben:

Anzeige

Get Abstract: Zusammenfassungen interessanter Businessbücher

Ein Kommentar

  1. Avatar
    Michael Baldauf am

    Die schönen und richtigen Gedanken der Agilität treffen auf BWG/KWG/EBA-Guidelines…. da war doch noch was.

    Auch ING und Commerzbank sind „Nur“ für ihre Change-Themen agil aufgestellt. Filialen und Kernabteilungen im Run bleiben im Wesentlichen unberührt. Warum: Weil wir im Geschäft eine gesetzlich vorgeschriebene Trennung von Markt und Marktfolge haben
    Das hindert uns nicht an der Zusammenarbeit bei Neuentwicklungen oder Verbesserungen, wohl aber im Tagesgeschäft.

    Spannende Antworten darauf gibt es in der KURS-IT der IMH am 24./25. März in Wien. Sowohl Marktteilnehmer als auch Aufsichtsbehörden werden ihre Sicht auf Agilität und BWG darlegen.

Bank Blog Newsletter abonnieren

Bank Blog Newsletter abonnieren