In der vierten Folge des CIO Debatten Podcasts diskutieren Olaf Terhorst und Nils Gralfs von den mgm consulting partners, ob die IT-Organisation in Squads und Tribes tatsächlich hilft, schneller Wert zu schaffen – oder ob sie klare Verantwortlichkeiten und Governance gefährlich untergräbt. Wir fassen die wichtigsten Argumente aus dem Pro- und Contra-Teil des Gesprächs zusammen.
Das Squad-Modell – was steckt dahinter?
Squads und Tribes, oft inspiriert vom „Spotify-Modell“, organisieren sich crossfunktional. Sie vereinen verschiedene Disziplinen wie Entwicklung, Betrieb, Fachbereich und Testing in einem Team – mit dem Ziel, Kundennutzen in hoher Geschwindigkeit zu liefern. Die zentrale Idee: Silos aufbrechen, Time-to-Market verkürzen und die Eigenverantwortung der Teams steigern.
Doch wie alltagstauglich ist dieses Modell wirklich? Wo liegen die Chancen – und wo die Stolpersteine?
In der Debatte: Olaf Terhorst, Partner mgm consulting partners und Nils Gralfs, Senior Manager mgm consulting partners
Moderation: Karsten Kneese, Marketing Manager, mgm
Länge: 42 Minuten
Podcast hören und mitdiskutieren
Pro: Mehr Geschwindigkeit, Autonomie und Kundennähe
- Time-to-Market verbessern:
Durch die enge Zusammenarbeit der Disziplinen innerhalb eines Squads entfallen klassische Übergaben zwischen Entwicklung und Betrieb. Entscheidungen können schneller getroffen und Features zügig ausgeliefert werden – ideal für dynamische Produktentwicklungen. - Fokus auf Kundennutzen:
Statt auf technische Silos konzentrieren sich Squads auf den Wert für den Nutzer. Jedes Squad bearbeitet ein konkretes Produkt oder ein Kundenproblem – das führt zu klarerem Fokus und oft auch zu höherer Motivation im Team. - Experimentieren im Kleinen möglich:
Ein großer Vorteil: Die Transformation kann iterativ erfolgen. Statt die gesamte Organisation auf einen Schlag umzukrempeln, lassen sich Pilotbereiche oder Leuchtturmprojekte starten. So kann ein Unternehmen lernen, was funktioniert – und was nicht. - Moderne Architektur trifft moderne Organisation:
Das Prinzip der Microservices – kleine, autonome Funktionseinheiten – passt hervorragend zum Squad-Modell. Wer seine IT-Architektur modernisieren will, findet in crossfunktionalen Teams das passende organisatorische Gegenstück. - Neue Talente gewinnen:
Junge Fachkräfte, die moderne Arbeitsweisen gewohnt sind, fühlen sich in agilen, autonomen Teams häufig wohler. Das Squad-Modell kann helfen, ein attraktiver Arbeitgeber zu bleiben.
Contra: Komplexität, Governance-Probleme und kulturelle Hürden
- Neue Silos entstehen – nur anders:
Statt funktionaler Trennung droht eine neue Fragmentierung: Jeder Squad optimiert sein Teilproblem – doch wie bleibt das „große Ganze“ im Blick? Ohne übergreifende Koordination entsteht schnell Chaos statt Kundenzentrierung. - Governance und Qualitätssicherung unter Druck:
Viele Releases, schnelle Deployments: Das erfordert hohe Disziplin und automatisierte Prozesse. Fehlt diese technologische Reife, leidet die Qualität – und der Betrieb wird anfällig für Fehler. - Nicht für jeden geeignet:
Gerade im deutschen Mittelstand fehlt oft die Personaldecke für Rollen wie Product Owner, Scrum Master oder DevOps Engineers. Die Einführung solcher Modelle kann Ressourcen überfordern und Widerstände hervorrufen – vor allem, wenn etablierte Strukturen betroffen sind. - Ein hoher Veränderungsaufwand:
Ein echtes Squad-Modell erfordert mehr als nur neue Teamnamen. Es betrifft Rollen, Prozesse, Technologien – und vor allem: das Mindset. Viele Transformationsprojekte scheitern daran, dass dieser Wandel unterschätzt wird. - Regulierte Branchen tun sich schwer:
In Banken, Versicherungen oder dem Gesundheitswesen gelten oft strenge Prozess- und Compliance-Vorgaben (z. B. ITIL). Ein freier Umgang mit Strukturen ist hier kaum möglich, was agile Skalierung erschwert.
Fazit: Kein One-Size-Fits-All – aber viel Potenzial
Das Fazit der beiden Berater ist differenziert: Squads und Tribes sind kein Allheilmittel, aber eine sinnvolle Antwort auf moderne Anforderungen, wenn sie richtig eingesetzt werden. Organisationen sollten sich nicht vom Spotify-Vorbild blenden lassen, sondern eigene Wege entwickeln. Dabei gilt: Crossfunktionale Zusammenarbeit ist weniger ein fertiges Ziel als ein lernorientierter Prozess.
Drei zentrale Empfehlungen aus der Diskussion:
- Technologie, Organisation und Prozesse gemeinsam denken: Nur wenn Architektur, Skillsets und Governance zusammenpassen, kann das Modell funktionieren.
- Mit Pilotprojekten starten: Lernen im Kleinen statt scheitern im Großen.
- Top-Management einbinden: Ein echtes agiles Organisationsmodell braucht Rückhalt von oben – und Mut zur Veränderung.
