Seit Googles Aristoteles-Studie wissen wir, dass der wichtigste Faktor zur erfolgreichen Teamarbeit in der psychologischen Sicherheit unter den Teammitgliedern liegt. Psychologische Sicherheit beschreibt das Gefühl, das man in Teamsituationen benötigt, die potenziell peinlich oder unangenehm sein könnten (vgl. Edmondson 1999). Fühlt man sich in solchen Situationen als Teammitglied sicher und ohne Angst, sozial abgestraft zu werden, dann äußert man eher seine wirkliche Meinung, seine Ideen und Wahrnehmungen zur konkreten Arbeitsaufgabe. Man tut also das, was sich Führungskräfte und ManagerInnen von agil arbeiteten Teams wünschen: Man arbeitet selbstorganisiert und gleichzeitig in Abstimmung mit seinen TeamkollegInnen.

Was in der Theorie und diversen Methodenratgebern so einfach klingt, ist in der Praxis der Teamentwicklung oft mühsam: Oberflächliche Retrospektiven, herausgezögerte Entscheidungen, unausgesprochene Gegenmeinungen – allesamt verpackt und gerahmt in neu aufgesetzte Meetingformate, Check-In-Runden oder Kanban-Boards – also alter Wein in neuen Schläuchen.

Psychologische Sicherheit lässt sich nicht "methodisieren", sie muss im zwischenmenschlichen Austausch entwickelt werden. Dazu sollten Teams regelmäßig gemeinsam tauchen gehen: unter die Wasseroberfläche, zu den 90% des "agilen Eisbergs", die unter der Oberfläche liegen! In diesem Beitrag zeige ich Ihnen anhand eines Beispiels aus meiner Beratungspraxis den Einfluss verborgener Teamdynamiken und gebe Ihnen die Ausrüstung an die Hand, mit der Sie Team-Tauchgänge mit Gewinn abhalten können: Sie erfahren, wie Sie den Aufbau von psychologischer Sicherheit im agilen Team fördern – sowohl als Teammitglied als auch als Führungskraft oder Scrum Master. Abschließend lernen Sie die Methode Team-Radar kennen, mit der das Team mittelfristig seine Zusammenarbeit stark verbessern kann.

3 Szenen eines gescheiterten Scrum-Teams

In der Anfrage zu einer Teamentwicklung fand ich folgende Ausgangslage vor: Ein Team mit sieben Entwicklern, einem Scrum Master und einem Product Owner entwickelt die Software für Sprechanlagen in Hochhäusern. Der Druck vom Markt steigt, da die Kunden sowohl schnellere Lieferzyklen als auch immer anspruchsvollere Features verlangen. Der Product Owner versucht, deren Wünsche zu erfüllen und gerät dadurch gegenüber dem Entwicklerteam zunehmend in Erklärungsnot. Der Scrum Master versucht ohne Erfolg zu vermitteln. Dies auch deshalb, weil unter den Entwicklern selbst angespannte Stimmung bezüglich der Aufgabenverteilung herrscht.

Mit einem neuen Entwicklungsprojekt spitzt sich die Lage rasch zu:

1. Bei einem gemeinsamen Design Thinking Workshop zu Projektbeginn geraten der Product Owner und zwei ältere Entwickler aneinander: Bei der Frage, auf welche zwei Features man sich fokussieren will, gehen die Vorstellungen diametral auseinander. Beide Parteien argumentieren aus ihrer Perspektive und kämpfen für ihre Ideen. Auf sachliche Argumente folgen schnell Vorwürfe auf persönlicher Ebene. Der Scrum Master kann den Streit nicht schlichten und die Entscheidung wird vertagt.
2. Einer der beiden älteren Entwicklern ist schon sehr lange in dem Unternehmen, hat also über die Jahre viel Erfahrung in der Entwicklung und dem Bau der Produkte gesammelt. Da die Dokumentation der Software in der Vergangenheit weniger sorgfältig betrieben wurde, stellt das Wissen dieses "alten Hasens" eine zentrale Ressource für die Weiterentwicklung der Softwarekomponenten dar. Entsprechend gefragt ist sein Rat. In den Teammeetings fällt jedoch auf, dass vor allem andere erfahrene Kollegen seine Meinung erbitten. Den jüngeren Teammitgliedern fällt es offenbar schwer, dem alten Hasen ihre Fragen zu stellen und ihn für die Zusammenarbeit zu gewinnen. Auch deshalb geht die Entwicklung nur schleppend voran.
3. In der Folge kippt langsam die Stimmung im Team: Um den alten Hasen entwickelt sich ein Kreis von drei Personen, dessen Mitglieder bei den täglichen Meetings zwei andere Teammitglieder wiederholt unterbrechen und sich über deren Entwicklungsfortschritt lustig machen: Es fehle an Qualität und diese beiden Entwickler arbeiteten zu langsam und überdies schlampig. Der Scrum Master geht bei den wiederholten Vorwürfen nicht dazwischen und greift die Unzufriedenheit der beiden Parteien mit der Zusammenarbeit nicht auf. Schlussendlich wechseln beide Entwickler das Team. Jedoch stockt die Entwicklung dadurch noch mehr und auch die zwei neuen Teammitglieder, die die ausgeschiedenen ersetzten, haben in der Folge einen schweren Stand bei der Gruppe um den alten Hasen.

Was ist hier passiert?

Abtauchen unter die Wasseroberfläche … Beziehungen