karriere.at Insights: Selbstorganisation – So wenden wir das Spotify-Modell an

„Agil“ bedeutet „wendig“ oder auch „schnell“. Je kürzer Entscheidungswege in Unternehmen sind, umso wendiger oder eben „agiler“ können Entwicklungen vorangetrieben werden. Doch wer ist an welchen Entscheidungen beteiligt? Und wie organisiert man Teams, um maximale Autonomie zu gewährleisten? Zum Beispiel mit der „Spotify-Methode“. Benannt nach dem schwedischen Streamingdienst, ist dieses Management-Modell populär für die Organisation interdisziplinärer Teams. Das Modell wird hier sehr anschaulich erklärt.

Im Grunde funktioniert es so: Teams bestehen aus den Personen, die es zur Erfüllung der Aufgabe braucht – jede nötige Kompetenz ist vorhanden, damit alle Entscheidungen direkt im Team getroffen werden können. Wie das bei karriere.at funktioniert und welche Rolle die Führungskräfte dabei einnehmen, haben mir vier Head-ofs aus der Softwareentwicklung erklärt:

• Paulina Hornbachner ist Head of Product Development. Ihr Team besteht aus sechs Product Ownern, die jeweils hauptverantwortlich für ein Produkt von karriere.at sind.
• Anita Eglauer ist Head of Design und sorgt mit ihrem Team aus sechs Product Designer*innen dafür, dass alle Bereiche von karriere.at in einheitlichem Look&Feel erstrahlen.
• Manuel Timelthaler ist Head of Frontend Development. Sein Team, bestehend aus zehn Softwareentwickler*innen, kümmert sich um flexible und hochwertige Benutzerschnittstellen für die karriere.at-Services.
• Johannes Pichler ist Head of Backend Development. Gemeinsam mit seinem Team aus neun Entwickler*innen ist er verantwortlich für die serverseitige Architektur von karriere.at.

Interdisziplinäre Teams organisieren: Wie wir das Spotify-Modell einsetzen #

Ihr vier sitzt hier, weil ihr einige Teams gemeinsam führt. Wo habt ihr Überschneidungspunkte?

Paulina: Wir sind eine agile Softwareentwicklung und nach dem Spotify-Modell aufgebaut. Das heißt, wir haben agile Entwicklungsteams, die crossfunctional zusammengestellt sind: Mitarbeiter*innen aus UX/UI, Backend und Frontend Development, Product Owner, Tester*innen, teils auch Marketing-Mitarbeiter*innen. Jeder Fachbereich hat dabei seine eigene Führungskraft, deswegen sitzen wir vier heute hier. Wir stehen vor der Herausforderung, mehrere agile Teams gemeinsam zu führen.

Manuel: Genau, als Head-of führst du nicht nur deinen Fachbereich, sondern auch gleichzeitig mehrere Entwicklungsteams.

Gründe für das Spotify-Modell: Kein „Über-die-Mauer-Werf-Problem“ mehr #

Warum arbeitet ihr eigentlich nach der Spotify-Methode? War das eine bewusste Entscheidung?

Manuel: Also grundsätzlich verändert sich unsere Organisation ja ständig und auch, wie wir diese Methode einsetzen. Aber ab einer gewissen Größe, vor etwa 6, 7 Jahren war es nötig, dass wir einen strukturierteren Prozess einführen. Wir haben dann mithilfe externer Coaches geschaut, welche Methoden es gibt und welche wir ausprobieren wollen. Wir haben dann versuchsweise mit zwei SCRUM-Teams gestartet, haben dann abwechselnd SCRUM und KANBAN eingesetzt, manche Dinge dazugenommen, die hilfreich waren, andere verworfen, die uns nicht getaugt haben – und so hat sich seither sehr viel verändert: die Teams, die Menschen, die Methoden … Das ist ein fortlaufender Prozess.

Anita: Das Ziel damals war, langfristig skalierbar zu bleiben. Dieses Spotify-Modell hatte für uns die meisten Vorteile, weil es so veränderbar ist und den Teams maximale Autonomie bietet. Das macht viel mehr Freude bei der Arbeit. Würden wir sie nicht crossfunctional gestalten, sondern auf Fachbereiche aufteilen, würden immer bestimmte Kompetenzen fehlen und es wäre viel schwerer skalierbar.

Johannes: Wir haben aber auch den Vorteil, dass wir sehr langlebige Produkte entwickeln, bei denen diese Organisationsweise Sinn macht. Unsere Teams arbeiten lange, oft dauerhaft, an einem Produkt. Sonst wäre es vermutlich sinnvoller, die Teams kurzfristig für ein abgeschlossenes Projekt zusammenzustellen und dann wieder aufzulösen. Es ist allerdings schwierig für den Teamspirit, wenn du ständig wechselnde Kolleg*innen hast.

Manuel: Genau, das wäre das klassische „Über-die-Mauer-Werf-Problem“: „Wir sind fertig, jetzt macht ihr weiter!“ – Und wenn etwas nicht passt, fängt alles von vorne an und eine Abteilung hat völlig umsonst gearbeitet.

Die Spotify-Methode in der Praxis: Maximale Autonomie #

Die Spotify-Methode liest sich eher kompliziert, finde ich. Ist sie das auch in der Praxis?

Manuel: „Die“ Spotify-Methode gibt es nicht, sie entwickelt sich ja ständig weiter. Spotify wendet die auch schon nicht mehr genauso an, wie es in dem Artikel beschrieben ist. In klassischen Begriffen formuliert, handelt es sich dabei um eine Matrix-Organisation, die jede Firma etwas anders umsetzt. Bei uns wird es eben so gemacht, wie Paulina beschrieben hat. Wir haben unser Unternehmen auch nicht streng in „Squads“, „Tribes“ und „Guilds“ eingeteilt, wie es im Modell vorgesehen wäre.

Johannes: Was vielleicht zum Thema „Führen“ noch wichtig ist: Wir führen die Mitarbeiter*innen in diesen Teams. Was die Teams machen, das liegt in der Verantwortung der Product Owner, da sind wir nicht maßgeblich beteiligt.

Ein Beispiel?

Paulina: Die Arbeit an sich, also woran das jeweilige Team arbeitet, ist Aufgabe des Product Owners. Er oder sie nimmt alle Anforderungen entgegen, die an das Produkt und das dazugehörige Team gestellt werden, priorisiert und bereitet diese so auf, dass das Team damit arbeiten kann. Ob das Designs sind, die erstellt werden, Coding-Umsetzungen oder die finale Abnahme vom Tester. Also diese Art der Führung übernimmt der Product Owner, auch was Teambuilding-Maßnahmen oder Arbeits-Abläufe betrifft.

Hier können wir allerdings gut unterstützen, wenn wir zum Beispiel sehen, dass die Skill-Verteilung nicht passt. Dann besprechen wir gemeinsam mit dem gesamten Team Verbesserungsmöglichkeiten. Was noch in unserer Verantwortung liegt, das ist natürlich die Weiterentwicklung der einzelnen Teammitglieder: Welche Schulungen können sie absolvieren, welche Positionsweiterentwicklungen sind möglich …

Projektablauf: Arbeiten ohne Head-ofs #

Wie funktioniert so ein Projektablauf?

Paulina: Ich möchte das gern anhand unseres Big Room Plannings erklären. Einmal im Quartal treffen sich alle, die an der Planung der Softwareentwicklung beteiligt sind, und besprechen anhand von unseren OKRs, woran die Softwareentwicklung im nächsten Quartal arbeitet. Dazu werden dann in den einzelnen Teams Arbeitspakete geschnürt und deren Steuerung liegt, wie schon erklärt, bei den Product Ownern und dem Product Management. Diese Art von Selbstorganisation funktioniert bei uns in der Softwareentwicklung sehr gut.

Meine Rolle dabei ist, Probleme zu beseitigen. Das können ganz banale Dinge sein wie „mein Mac ist kaputt“ oder komplexere wie „Wir haben bei dem Projekt etwas übersehen oder sind auf etwas draufgekommen, was uns zurückwirft“. Diese Steine versuche ich dann gemeinsam mit ihnen aus dem Weg zu räumen. Zum genauen Product- und Projektmanagement sind wir als Head-ofs aber die falschen Ansprechpersonen. Im agilen Leadership arbeiten wir eher an den Rahmenbedingungen, die die Teams brauchen, um gut arbeiten zu können. Nicht an den konkreten Projekten selbst.

Mehr zur Rolle der Führungskräfte in agilen Teams gibts im nächsten Teil der karriere.at Insights!

Bildnachweis: shutterstock/Andrii Yalanskyi, Studio Romantic; Portraitfotos: karriere.at