Montag, 19. Juli 2021

Doch wie Spotify werden

 

Bild: Wikimedia Commons / Florian Koppe - CC BY-SA 4.0

Wirft man einen Blick auf die Versuche grosser Organisationen sich agil zu organisieren, wird man mit grosser Wahrscheinlichkeit schon nach kurzer Zeit auf das so genannte "Spotify Model" stossen (das hier näher erklärt wird). 2012 eher zufällig in dieser Firma eintwickelt (und mittlerweile in der Ursprungsform dort gar nicht mehr im Einsatz) scheint es in vielen Konzernen einen Nerv getroffen zu haben. ING, Axa, Commerzbank, Telekom und viele mehr versuchen es bei sich umzusetzen.


Dass sich diese Change-Programme in der Realität schwierig gestalten (Beteiligte berichten unter der Hand von z.T. sehr durchwachsenen Ergebnissen) liegt natürlich zum einen daran, dass derartige Vorhaben immer schwer sind, zum anderen aber auch daran, dass der Ansatz mittlerweile aus verschiedenen Richtungen sehr stark politisiert und dogmatisiert wird, wodurch eine unbefangene Beschäftigung mit ihm immer schwerer wird.


Zum einen sieht diese Dogmatisierung so aus, dass versucht wird das Spotify Model unreflektiert als Blaupause für alle agilen Skalierungsvorhaben einzusetzen (warum das ein Problem ist kann man hier nachlesen), zum anderen hat sich als Gegenreaktion darauf unter vielen Scrum Mastern und Agile Coaches eine so reflexhafte und ebenso unreflektierte Ablehnung verbreitet, dass auf den Begriff ähnlich hysterisch reagiert wird wie in im Film Life of Brian auf das Wort Jehova.


In beiden Fällen bleibt eine wirkliche Beschäftigung mit dem Modell auf der Strecke. Das ist vor allem deshalb schade, weil viele seiner Elemente gute Lösungsansätze für real existierende Probleme bieten, so dass es sehr wohl Sinn machen kann einige oder sogar alle von ihnen bei sich einzuführen - immer unter der Voraussetzung, dass man diese Probleme wirklich hat, und dass regelmässig überprüft wird ob sie sich wirklich so lösen lassen.


Beispielsweise kann das Konstrukt eines Tribes, also einer Gruppe von Teams die aufeinander abgestimmt an einem gemeinsamen Produkt arbeiten, eine grosse Hilfe sein wenn die einzelnen Teams (noch) nicht oder nur zu langsam in der Lage sind dieses Produkt alleine weiterzuentwickeln. Ebenfalls nicht zu unterschätzen ist die Aussenwahrnehmung, in der ein Tribe deutlich sichtbarer und ansprechbarer erscheint als eine Ansammlung von für Teilprodukte zuständigen Einzelteams.


Auch die in den Tribes vorhandenen Chapter (Querschnittsorganisationen für gleichartige Spezialisten) können einen Mehrwert bieten. Zum Einen wegen ihrer Koordinations- und Abstimmungsfunktion, zum Anderen wegen der Beschränkung der "Chapter Lead"-Rolle auf eine Teilzeitstelle, die von einem Mitglied neben der Entwickler-Tätigkeit übernommen wird. Die bei Team- und Gruppenleitern sonst häufige Entfremdung von der Arbeit der Teams kann so gar nicht erst entstehen.


Ebenfalls hilfreich können die Gilden sein, der dritte Skalierungs-Aspekt des Spotify Models. Von Bedeutung ist hierbei, dass sie explizit keine Koordinationsfunktion haben (für die es ja bereits die Chapter gibt) sondern dass sie lediglich gemeinsame Interessen zum Gegenstand haben. Bedingt dadurch entfällt die Notwendigkeit für Führungsrollen, Regeln, Dokumentationspflichten und ähnliche Bürokratie-anfälligen Elemente, so dass der Fokus ganz auf Wissensaustausch und Erkenntnisgewinn liegen kann.


Um es noch einmal klar zu sagen: jeder der das Spotify Model bei sich einführen will sollte vorher überprüfen ob die Probleme für deren Lösung es entwickelt wurde in der eigenen Organisation vorhanden sind (und nicht bereits anders gelöst werden), nur dann macht die Einführung Sinn. Wenn diese Voraussetzung gegeben ist, ist dieser Weg aber eine brauchbare (wenn auch regelmässig zu validierende) Vorgehensweise.


Und sollte diese Entscheidung doch wie Spotify werden zu wollen dazu führen, dass der Scrum Master oder Agile Coach laut Jehova, Jehova! schreit - dann weiss man wenigstens wen man fragen kann ob er Interesse an einem Gespräch über Offenheit und Growth Mindset hat.

Related Articles