Squad, Tribe, Guild und Chapter. Was sich nach den Inhalten eines Online-Rollenspiels wie World of Warcraft anhört, ist im Business-Kontext die Grundlage für ein agiles Arbeitsmodell. Seit jeher ist die Softwarebranche ein guter Nährboden für neue Ansätze in der Arbeitsorganisation, oft Vorreiter für andere Berufsgruppen und hat bereits viele wegweisende Vorgehensmodelle hervorgebracht. Auch bei knowis werden immer wieder vielversprechende Ideen auf Herz und Nieren getestet und finden im Erfolgsfall ihren Weg in den Arbeitsalltag. Lesen Sie von unseren ersten Erfahrungen mit der agilen Teamorganisation nach dem Spotify-Modell.
'Agile' ist seit vielen Jahren der Inbegriff für zeitgemäße Softwareentwicklung und schlanke, flexible Prozesse. Egal ob Scrum, Kanban oder eine der diversen Abwandlungen – vom klassischen Wasserfall oder dem V-Modell sind mittlerweile fast alle Entwicklerteams abgerückt. Anders sieht es jedoch bei der übergeordneten Teamorganisation aus. Hier sind häufig noch klassische Hierarchien und starre Strukturen an der Tagesordnung und die Agilität endet an der Bürotür des jeweiligen Teams.
Bereits 2012 überlegte man deshalb beim schwedischen Musikstreaming-Unternehmen Spotify, wie durch kleine, funktionsübergreifende und sich selbstorganisierende Teams die Entwicklungseinheiten dynamischer agieren und Skills zielgerichteter eingesetzt werden können. Es entstand eine neuartige Einteilung der Mitarbeiter*innen in Squads, Tribes, Chapters und Guilds. Dieses Modell ist heute auch unter dem Namen Spotify-Modell bekannt und gilt als eines der fortschrittlichsten agilen Arbeitsmodelle in der Branche. Insbesondere seine Skalierbarkeit ist ein großer Vorteil für wachsende Unternehmen.
Agiles Arbeiten nach dem Spotify-Prinzip
Squads
Die Basis des Spotify-Modells bilden die Squads. Sie sind die kleinste Einheit und orientieren sich am Aufbau klassischer Scrum-Teams. Die Teams sollten so zusammengesetzt sein, dass sie durch ihre Mitglieder alle notwendigen Skills in sich vereinen, um Software zu designen, zu entwickeln, zu testen und schließlich zu releasen und in Produktion zu bringen. Jedes Squad hat seinen eigenen Aufgabenbereich und verfolgt darin eine langfristige Mission. Bei Spotify beschäftigt sich zum Beispiel ein Squad nur mit der Bereitstellung von Zahlungsdiensten, ein anderes mit der Skalierung der Backend-Systeme. Die jeweilige Mission ist aber Teil der übergreifenden Strategie und den Zielen des Unternehmens untergeordnet.
Die Teams organisieren sich grundsätzlich selbst; das Spotify-Modell sieht aber einen Product Owner pro Squad vor, der die Aufgaben des Teams priorisiert. Zusätzlich gibt es einen Agile Coach der, anders als der klassische Scrum-Master, bei der Sprintplanung und den Retrospektiven unterstützt und dabei helfen soll, mögliche Hindernisse in den Arbeitsprozessen zu erkennen und diese so kontinuierlich zu verbessern.
Tribes
Mehrere dieser kleinen multidisziplinären Gruppen bilden wiederum einen Tribe, der Entwickler-Gruppen aus ähnlichen Bereichen miteinander vereint – also zum Beispiel alle Squads, die am selben Produkt arbeiten. Jeder Tribe hat einen Tribe Lead, dessen Aufgabe es ist für die bestmögliche Arbeitsumgebung der Squads zu sorgen. Spotify empfiehlt, dass die Squads innerhalb eines Tribes bestenfalls in räumlicher Nähe zueinander arbeiten sollten – das führt zu einer Verbesserung der Zusammenarbeit unter den Squads. Auch regelmäßige Treffen, bei denen zum Beispiel Live-Demos der Software gezeigt oder neue Tools vorgestellt werden und man sich gegenseitig berichtet, woran gerade gearbeitet wird, fördern den Tribe-Zusammenhalt.
Chapters und Guilds
Im Großen wie im Kleinen sind die Mitarbeiter*innen durch Chapters und Guilds miteinander verbunden: Chapters bringen die Mitglieder verschiedener Squads zusammen. Guilds verbinden die einzelnen Tribes wie Querstreben.
In Chapters kommen Personen mit ähnlichen Fähigkeiten und Kompetenzbereichen zusammen, die innerhalb desselben Tribes organisiert sind. Das hat den Vorteil, dass Wissen zwischen den Squads leichter transferiert werden kann, ohne den Squads ihre Autonomie zu nehmen. Wenn zum Beispiel ein*e Tester*in aus Squad A ein Problem gelöst hat, sollten das auch die Tester*innen aus Squad B und C erfahren, damit das Problem nicht zeitaufwendig von jedem Team einzeln gelöst werden muss. Jedes Chapter trifft sich daher regelmäßig, um aktuelle Herausforderungen in seinem spezifischen Bereich, wie beispielsweise dem Testing, zu besprechen.
Eine Guild kann sich über die Tribes hinaus auf das gesamte Unternehmen erstrecken – das erleichtert Mitarbeiter*innen mit denselben fachlichen Interessen und ähnlichen Aufgabenstellungen den Austausch. So können sich beispielsweise Guilds für Softwarearchitekt*innen oder Tester*innen bilden. Grundsätzlich kann aber jeder, der sich für das Thema interessiert, dieser Community beitreten. Guilds setzen squad- und tribeübergreifend Standards für die Erledigung der Aufgaben, von denen das gesamte Unternehmen profitiert.
Agile Best-Practices bei knowis
knowis entwickelt Lösungsplattformen im Banking und arbeitet dazu seit vielen Jahren agil nach Scrum oder Kanban. Seit einiger Zeit hat knowis auch Ansätze der agilen Organisationsform in den Prozess der Softwareentwicklung integriert und eine Tribe-Organisation etabliert.
Für die Erstellung neuer Softwarefeatures sind alle am Prozess beteiligten Mitarbeiter*innen auf die gegenseitige Zusammenarbeit angewiesen, denn hier sind unterschiedlichste Fähigkeiten und Skills gefragt. Bei knowis wurden daher mehrere Squads geschaffen, die einen jeweils abgeschlossenen Aufgabenbereich haben. Innerhalb dieser Squads sind cross-funktional alle Skills vorhanden, um autonom Softwarefeatures entwickeln zu können und Problemstellungen eigenverantwortlich zu lösen. Jedes Squad führt regelmäßig seine eigene Sprintplanung durch. Die jeweiligen Squad-Leads tauschen sich aber untereinander aus, denn diese Squads arbeiten alle am selben Produkt und bilden daher einen gemeinsamen Tribe.
Über die einzelnen Squads hinweg finden sich Entwickler*innen, Produktmanager*innen und Tester*innen zu Chapters zusammen. Gleiche Skills werden hier gefördert und nach Bedarf in die Squads entsendet. So profitieren die Mitarbeiter*innen vom gegenseitigen Feedback über die Teamgrenzen hinweg und eine offene Kommunikationskultur für neue Ideen und Wissensaustausch wird etabliert.
Betonte Spotify 2012 noch die Wichtigkeit der räumlichen Nähe der Teams, konnte diese Neuorganisation bei knowis unabhängig von remote work und Homeoffice problemlos umgesetzt werden. Entscheidend ist, dass jede*r Mitarbeiter*in in die Sprintplanung und andere wichtige Meetings einbezogen wird und gemeinsam reflektiert wird. Der Aufbau tribe-übergreifender Guilds ist jetzt der nächste Entwicklungsschritt in der agilen Teamorganisation bei knowis. Wie sich diese Methode bisher im Alltag bewährt hat, berichtet Softwareentwicklerin Saja Darwish aus erster Hand im Interview.
Fazit
Die Benefits agiler Softwareentwicklung sind mittlerweile hinlänglich bekannt: Sie liefert schnell greifbare Ergebnisse, die Planung kann flexibel an aktuelle Gegebenheiten und Erkenntnisse angepasst werden und auf dem Informationstransfer im Team liegt ein gesonderter Fokus. Besonders in schnell wachsenden Unternehmen besteht der Bedarf, von dieser Dynamik auch teamübergreifend zu profitieren und die im Unternehmen vorhandenen Skills bedarfsorientiert und zielgerichtet einzusetzen. Das bringt die klassischen, gewachsenen Organisationsstrukturen aber häufig an ihre Grenzen, was gerade im Development-Bereich zu einem Nadelöhr werden kann.
Die agile Teamorganisation nach dem Spotify-Modell transferiert die teaminterne Agilität auf ganze Abteilungen oder Unternehmensbereiche und ermöglicht es den Teammitgliedern zudem, sich ihren Stärken und Interessen entsprechend weiterzuentwickeln. Darüber hinaus wird durch Chapters und Guilds über die einzelnen Squads hinweg Wissen übertragen, was sich positiv auf die Softwarequalität auswirkt. Die ersten Erfahrungen mit der agilen Tribeorganisation bei knowis, bei der verschiedene Squads eigenverantwortlich, unabhängig und selbstorganisiert Features eines Produkts entwickeln, sind durchaus vielversprechend und werden in den nächsten Monaten weiter vertieft werden. Trotz aller Einschränkungen die Corona-Lockdown, Homeoffice und Hygienekonzepte innerhalb des Unternehmens mit sich gebracht haben, ist eine positive Entwicklung in der teamübergreifenden Softwareentwicklung, dem gemeinsamen strategischen Verständnis und im Austausch von Erfahrungswissen sichtbar geworden.
Quellen:
Videos: Spotify Engineering Culture - Part 1. (Henrik Kniberg / YouTube)
Grafik: Spotify-Modell – Henrik Kniberg & Anders Ivarsson via https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf; Agile Teamorganisation bei knowis – knowis AG.
Teaser: mbbirdy – 877042462 – iStock.
