Doch wie Spotify werden (II)

Bild: Flickr / Rasmus Anderson - CC BY-NC 2.0

Reden wir noch einmal über das berühmt-berüchtigte Spotify Model, jenen Erfahrungsbericht, der ohne dass es von seinem Verfasser jemals geplant war zu einer Blaupause für zahllose agile Transitions- und Skalierungsvorhaben geworden ist. Dass diese Verwendung nicht im Sinne des Erfinders ist und besser unterlassen werden sollte ist ein immer wieder vorgebrachtes Mantra vieler überzeugter Agilisten. Ein bekannter Name sieht das allerdings anders - der Erfinder selbst, Henrik Kniberg.

Wird Kniberg zu "seinem" Framework befragt (z.B. hier) äussert er sich in der Regel undogmatisch und realistisch. Er sagt, dass in seiner Wahrnehmung die überwiegende Mehrzahl der Umsetzungen weder zu Verbesserungen noch zu Verschlechterungen führt, dass es eine kleine Menge gibt bei der es zu signifikanten Verbesserungen kommt, aber fast keine Beispiele dafür, dass Verschlechterungen die Folge sind. Und diese Beobachtung ist bemerkenswert genug für einige Überlegungen.

Dass die Mehrzahl der Umsetzungen alles beim Alten lässt liegt an einem schlichten Grund: das Spotify Model wird von Beratungen vor allem an Konzerne verkauft, und die sind in der Regel als Matrix-Organisation aufgestellt. Auch das Spotify Model ist eine solche Matrix-Organisation, so dass seine Einführung oft nur eine Umbenennung ist - aus Abteilungen werden Chapter, aus Projekten Squads oder Tribes. So wird zwar nichts besser, aber eben auch nichts schlechter.

Zu Verbesserungen kommt es dort wo die über den blossen Organisationsaufbau hinausgehenden Vorteile des Spotify Models erkannt und umgesetzt werden (mehr dazu hier). Die Ähnlichkeit zur klassischen Matrix-Organisation kann dabei sogar ein Vorteil sein, da der Umbruch weniger hart erscheint und die Sorgen und Widerstände dementsprechend geringer ausfallen. Die Veränderungen erfolgen in solchen Fällen eher evolutionär, was sie aber nicht weniger wirksam macht.

Wirklich interessant ist aber, dass es kaum Fälle gibt in denen eine Umstellung auf das Spotify Model zu einer Verschlechterung des Gesamtzustandes führt (was ich aufgrund der Erfahrungen die ich in über 10 Jahren bei vielen Kunden und auf zahllosen Meetups gemacht habe nur bestätigen kann). Gerade vor dem Hintergrund, dass erschütternd viele Veränderungsvorhaben nur Verschlimmbesserungen hervorbringen, sollte das nicht geringgeschätzt werden.

Näher betrachtet ist ein Grund dafür, dass es nicht nötig ist die alte, funktionierende Struktur zu zerstören um die neue Zielstruktur errichten zu können. Die Ähnlichkeit zur alten Matrix-Organisation ermöglicht schrittweises Ausrollen, eine beliebig lange Koexistenz von alter und neuer Welt und im Extremfall sogar ein relativ schmerzloses rückgängig Machen. Ein riskanter "methodischer Big Bang Release" wird dadurch unnötig, ein dezentrales und asynchrones Change Management wird einfacher.

Ein zweiter Grund ist die einzigartige Benennung der Organisationseinheiten, die verhindert, dass aus anderen Kontexten bereits mit Bedeutungen belegte Begriffe umgedeutet werden müssen. Weder bedeuten alte Namen wie Abteilung oder Projekt plötzlich etwas anderes, noch müssen "agile Fachbegriffe" für Konzern-Erfordernisse verbogen und verfremdet werden, wie es z.B. mit der Scrum-Terminologie in SAFe passiert. Mehrdeutigkeit und Missverständnisse werden so unwahrscheinlicher.

Zusammengenommen tragen diese Faktoren zu Knibergs Beobachtungen bei, dass das Spotify Model meistens wenig verändert, immerhin manchmal die Zustände verbessert und sie dafür nur sehr selten verschlechtert. Zwar bedeutet das, dass man mit ihm keinen "Grossen Sprung nach vorne" durchführen kann, das Risiko, dass es zu Widerständen kommt und die Wahrscheinlichkeit von versehentlichen Verschlimmbesserungen sind dafür aber gering.