Datengetriebene Teamentwicklung: Wie OTTO Tech-Teams zum Erfolg führt

Ein sehr bekanntes und seit vielen Jahren weit verbreitetes Modell ist das Teamuhr-Modell von Tuckman (Tuckman, B. W. (1965). Developmental sequence in small groups. Psychological Bulletin, 63 (6), 384–399.), welches Teamentwicklung als eine Abfolge verschiedener Phasen beschreibt. Laut diesem Modell folgt nach einer initialen Formierungsphase in Teams die Sturmphase, in der Konflikte und Spannungen auftreten, bevor in der Normierungsphase gemeinsame Werte und Normen entwickelt werden. Erst danach kommt diesem Modell zufolge die Phase, in der ein Team tatsächlich Leistung erbringt (Performing). Die Einordnung eines Teams in die „Teamuhr“ erfolgt dabei losgelöst von quantitativen Messungen, ausschließlich auf Basis von Beobachtungen. Phasenmodelle wie das von Tuckman bieten eine qualitative Orientierung, lassen jedoch die konkrete Wirksamkeit von Teams im Arbeitskontext weitgehend offen. Entsprechend haben sich in den letzten Jahren Ansätze etabliert, die stärker auf Messbarkeit, Produktivität und Arbeitsbedingungen von Teams ausgerichtet sind.

Einen eher technischen Blickwinkel und Ansatzpunkt für die Entwicklung von Teams bietet das DORA-Framework (https://cloud.google.com/resources/content/2025-dora-ai-capabilities-model-report). Der spezifisch auf Softwareentwicklungsteams ausgerichtete Ansatz basiert auf einem Modell, das mithilfe von vier technischen Metriken organisationale Performance vorhersagt. Die standardisierte Erhebung dieser Kennzahlen bietet eine Reihe von Vorteilen, lässt jedoch die Folgen anhaltenden Stresses im Team sowie den Einfluss von Zusammenarbeitspraktiken vollständig außen vor. Dieser Umstand hat zu einer Reihe von Weiterentwicklungen geführt.

Eine der daraus entstandenen Weiterentwicklungen ist das sogenannte SPACE-Framework (Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of Developer Productivity. Communications of the ACM, 64(6), 46–53.) zur Messung der Team-Produktivität. Basierend auf den Erkenntnissen des DORA-Frameworks bezieht SPACE neben Metriken zur Effizienz und Performance auch das Wohlbefinden und die Zufriedenheit, die Kommunikation und Zusammenarbeit sowie die Quantität der Arbeitsergebnisse mit ein, um schlussendlich auf die Produktivität von Teams zu schauen. Dieses Framework berücksichtigt also verschiedene Dimensionen der Team-Produktivität, nicht nur quantitativ messbare. Insbesondere die Betonung der Bedeutung der Mitarbeitenden-Zufriedenheit und deren Wohlbefinden war ein Novum und wird in der Arbeit weiterer darauffolgender Frameworks noch intensiviert.

Ein Beispiel hierfür ist das DevEx-Framework (Noda, A., Storey, M.-A., Forsgren, N., & Greiler, M. (2023). DevEx: What actually drives productivity? Communications of the ACM, 66(11), 44–49.). DevEx steht dabei für “Developer Experience”. Dieser Ansatz stellt konkret die Arbeitserfahrungen der Softwareentwickler*innen in den Vordergrund und verfolgt die These, dass alles, was die Arbeit der Softwareentwickler*innen angenehmer bzw. deren Umgebung passender macht, die Produktivität insgesamt erhöht. Erfasst werden drei Komponenten: Flow State, Feedback-Loops und Cognitive Load. Outputs oder Outcomes werden im Rahmen des DevEx-Frameworks nicht erfasst. Die gesamte Erfassung der “Developer Experience” erfolgt dabei über qualitative Umfragen. Im Gegensatz zu DORA und SPACE setzt das DevEx-Framework auf die Erfassung der Qualität der Rahmenbedingungen der Softwareentwickler*innen. Statt die Performance im Sinne des Outputs oder Outcomes direkt zu messen, setzt das Framework somit den Fokus vollständig auf Faktoren, die diese Performance bedingen.

Die Erkenntnisse aus DORA, SPACE und DevEx wurden nun im sogenannten Core-4-Framework von DX zusammengeführt und weiterentwickelt. Core 4 ist eine Mischung aus den vorangegangenen Ansätzen und erhebt vier Kern-Konstrukte: Geschwindigkeit (Speed), Wirksamkeit (Effectiveness), Qualität (Quality) und Einfluss/Auswirkung (Impact).

Diese Erkenntnisse und etablierten Frameworks haben wir uns bei OTTO zu Nutze gemacht und diese, in Kombination mit einer ausgedehnten Literaturrecherche zum aktuellen Stand von Teamentwicklung und Team Wirksamkeit, in die Entwicklung unseres eigenen Teamentwicklungsmodells eingebracht. Dieses Modell dient uns nun als Grundlage für die regelmäßige Messung der Wirksamkeit von über 100 Teams und ist die Basis für Entscheidungen innerhalb der Teams und für organisationsweite Prozesse zur Verteilung der Teamentwickler*innen. Diese beiden Aspekte, unser Teamentwicklungsmodell und den Prozess zur Erfassung der Team Wirksamkeit und die daraus abgeleiteten Teamentwicklungsmaßnahmen, möchten wir euch im Folgenden näher beschreiben.

Die Entwicklung eines Teams folgt in der Regel weder genau einem linearen Entwicklungsverlauf noch können wir in unseren international zusammengesetzten IT-Teams sicherstellen, dass diese lange genug in unveränderter Konstellation zusammenarbeiten, um alle Phasen bis hin zum „Performing“, im Sinne der Tuckman Teamuhr zu durchlaufen. Daher ist es für uns von hoher Bedeutung, in jeder Phase der Teamentwicklung systematisch und gezielt den aktuellen Entwicklungsstand unserer Teams zu erheben, um auf Basis dieser Erkenntnisse gezielt mit Teams an ihren Stärken und Potenzialen ansetzen zu können. Wir haben uns daher gegen ein Phasenmodell entschieden und richten unseren Blick, ähnlich dem SPACE und Core 4 Framework, auf Resultate und Auswirkungen der Teamarbeit, welche wir als die Wirksamkeit beschreiben. Wie auch in diesen Modellen fokussieren wir uns dabei auf das Wohlbefinden der Mitarbeitenden und deren Performance, im Sinne der Arbeitsergebnisse. Zusätzlich umfasst unsere Wirksamkeitsdefinition auch noch die Lebensfähigkeit des Teams, da in der heutigen komplexen Arbeitswelt die Anpassungsfähigkeit von Teams einen wesentlichen Erfolgsfaktor für langfristigen wirtschaftlichen Erfolg darstellt.

Wir sind zudem der Ansicht, dass sich die Ergebnisse und Mitarbeitenden-Zufriedenheit in unserem Arbeitskontext nicht ausschließlich auf Basis technischer Metriken vorhersagen lassen, so wie es das DORA-Framework vorsieht, sondern verfolgen bei OTTO, ähnlich dem DX Core 4 Produktivitäts-Framework, einen gemischten Erhebungsansatz.

Unser Teamentwicklungsmodell, welches in Abbildung 1 dargestellt ist, basiert ebenso wie zahlreiche andere Modelle der Teameffektivität auf dem sogenannten Input-Mediator-Output (IMO)-Framework.

Das Modell umfasst drei Säulen: die Rahmenbedingungen des Teams als Input-Variablen, Faktoren der Leistungsfähigkeit als Mediatoren und die Wirksamkeit als Output. Eine solche Darstellung des Wirkungsgefüges basiert auf der Annahme eines durch verschiedene Prozesse (z. B. Teamwork und Taskwork) vermittelten Einflusses der durch die Organisation determinierten Rahmenbedingungen auf die Wirksamkeit eines Teams. Da es sich bei den Mediatoren nicht ausschließlich um Prozesse (vgl. I-P-O-Modell), sondern auch um Zustände in den Teams (z. B. Vertrauen oder Psychologische Sicherheit) handelt, ist das zugrundeliegende Modell als IMO-Modell zu bezeichnen. Diese Struktur liegt zahlreichen wissenschaftlich untersuchten Modellen zur Wirksamkeit beziehungsweise Effektivität von Teams zugrunde (Ilgen, D. R., Hollenbeck, J. R., Johnson, M., & Jundt, D. (2005). Teams in organizations: From input-process-output models to IMOI models. Annual Review of Psychology, 56, 517–543.; Mathieu, J., Maynard, M. T., Rapp, T., & Gilson, L. (2008). Team effectiveness 1997–2007: A review of recent advancements and a glimpse into the future. Journal of Management, 34(3), 410–476.), deren Inhalte und Erkenntnisse in unser Teamentwicklungsmodell eingeflossen sind.

Nach der Darstellung des wissenschaftlichen Ansatzes hinter unserem Teamentwicklungsmodell möchten wir im Folgenden darauf eingehen, wie wir mit Hilfe unseres Teamentwicklungs-Tools Check’n’Swarm die Daten zur Wirksamkeit unserer Teams erheben.

Mit Check’n’Swarm erheben wir die Effektivität der Teams anhand quantitativer Fragebögen, die überwiegend subjektive Einschätzungen beinhalten. Um die Wirksamkeit nicht ausschließlich über die rein subjektive Einschätzung der Teammitglieder zu betrachten, erfolgt die Einschätzung der Wirksamkeit eines Teams aus mehreren Perspektiven. Zusätzlich zu den Einschätzungen des Teams selbst, gibt es die Möglichkeit einer externen Einschätzung durch Stakeholder und User. Des Weiteren erfolgt eine Einschätzung zu dem Team von einer Person in der Rolle des*r Teamentwickler*in und auch die direkte Führungskraft des Teams erhält die Möglichkeit, dem Team ein Feedback zur Wirksamkeit zu geben. Wenngleich es sich bei Befragungen generell um subjektive Messverfahren handelt, sind wir durch unseren multiperspektivischen Ansatz und die standardisierte Erhebung in der Lage, die Objektivität der Daten zu erhöhen. Zusätzlich dazu, ist, gemäß State of the Art eine Kombination Umfragen-basierter Messmethoden mit Daten aus automatisierten Monitoring-Systemen in Planung (vgl. DORA), um einen ganzheitlichen Überblick hinsichtlich der Wirksamkeit eines Teams zu erhalten.

Das Durchführen der Befragung aus den verschiedenen Perspektiven allein stellt jedoch noch keinen Mehrwert dar, weder für das Team selbst noch für die Organisation. Um mithilfe der erhobenen Daten einen Impact generieren zu können, ist es essenziell, auch mit den erhobenen Daten zu arbeiten. Dies geschieht zunächst innerhalb der Teams, einmal im Quartal im Rahmen eines Workshops, orientiert am Format einer Retrospektive, der in der Regel von einer*m Teamentwickler*in des jeweiligen Bereichs durchgeführt wird. Mit dem Ziel, relevante Handlungsfelder für das Team zu identifizieren, werden in diesem Workshop die Ergebnisse der jeweiligen Perspektiven besprochen. Bei Bedarf können unterstützend sogenannte „Vertiefungsmodule“ genutzt werden, mit denen die Teams in einzelne identifizierte Handlungs- und Lernfelder tiefer einsteigen können. Dabei können für das Team relevante Aspekte der Teamarbeit näher untersucht und besprochen werden, bevor es sich für dedizierte Maßnahmen zur Teamentwicklung entscheidet.

Dieser Prozess ist auf folgender Abbildung 2 mithilfe einer OODA-Loop einmal dargestellt: