Wenn das Team vergiftet wird: Der ehrliche Umgang mit toxischen Kollegen
Es gibt ein schmutziges Geheimnis in vielen agilen Organisationen: Die größte Bedrohung für psychologische Sicherheit sitzt nicht im Management — sie sitzt im Team selbst. Während Agile Coaches und Scrum Master akribisch daran arbeiten, hierarchische Strukturen aufzubrechen und Selbstorganisation zu fördern, untergräbt ein einziger toxischer Akteur monatelange Aufbauarbeit in wenigen Wochen. Und die kollektive Reaktion? Meistens: Wegschauen, Rationalisieren, Hoffen.
Die unbequeme Wahrheit lautet: Toxisches Verhalten im Team ist kein HR-Problem, das sich von selbst löst. Es ist eine Führungsaufgabe — auch und gerade in agilen Kontexten, wo Servant Leadership fälschlicherweise mit Konfliktscheu gleichgesetzt wird. Wer als Agile Leader, Scrum Master oder Coach schweigt, ist Teil des Problems.
Dieser Artikel ist kein Ratgeber für Anfänger. Er richtet sich an erfahrene Praktiker, die wissen, wie sich ein Daily Standup anfühlt, wenn jemand die Energie aus dem Raum saugt, und die endlich einen klaren Handlungsrahmen wollen — ohne die übliche "Hab Empathie"-Rhetorik.
Was toxisches Verhalten wirklich bedeutet — jenseits der Buzzwords
Toxizität ist kein Persönlichkeitsmerkmal, es ist ein Verhaltensmuster. Diese Unterscheidung ist fundamental, weil sie den Handlungsspielraum definiert. Menschen sind nicht toxisch — Verhaltensweisen sind es. Und Verhalten kann adressiert, dokumentiert und im besten Fall verändert werden.
Konkret: Toxische Muster in agilen Teams lassen sich in drei Cluster unterteilen. Erstens destruktive Dominanz: Das Hijacking von Retrospektiven, systematisches Niedermachen von Ideen anderer, das Monopolisieren von Airtime in Planning Sessions. Zweitens passive Sabotage: Commitments öffentlich eingehen, aber still untergraben — Impediments nicht kommunizieren, Informationen zurückhalten, "Vergessen" von Vereinbarungen. Drittens soziale Vergiftung: Korridorgespräche, die Vertrauen zersetzen, selektives Lob das Spaltung schafft, oder das subtile Ausschlussverhalten, das Newcomer systematisch marginalisiert.
Was diese Muster eint: Sie zielen — bewusst oder unbewusst — auf die Reduktion psychologischer Sicherheit. Amy Edmondson von der Harvard Business School hat in ihrer Forschung konsistent gezeigt, dass teams mit hoher psychologischer Sicherheit bessere Outcomes liefern. Der Umkehrschluss ist genauso valide: Ein einziges toxisches Verhaltensmuster kann das Fundament dieser Sicherheit erodieren.
Besonders tückisch ist die sogenannte High-Performer-Falle: Der toxische Akteur liefert individuell herausragende Ergebnisse. Velocity ist hoch, technische Qualität stimmt, der Sprint-Review läuft glatt. Aber das Team funktioniert trotzdem nicht — und die Zusammenhänge bleiben oft lange unsichtbar. Will Felps, Terence Mitchell und Eliza Byington haben in einer viel zitierten Studie ("How, When, and Why Bad Apples Spoil the Barrel", 2006) gezeigt, dass ein einziges toxisches Mitglied die Teamperformance um bis zu 40 Prozent reduzieren kann — selbst wenn die Person individuell hohe Beiträge liefert. Der Nettoeffekt ist negativ.
Der erste Erkenntnisgewinn: Wer toxisches Verhalten nur über individuelle KPIs bewertet, misst am falschen Ort. Die Schäden entstehen systemisch.
Die Systemdynamik verstehen: Warum Teams toxische Muster tolerieren
Bevor Führungskräfte handeln, müssen sie verstehen, warum toxische Muster überhaupt so lange überleben. Die Antwort liegt in der Systemdynamik — nicht in der Feigheit Einzelner.
Agile Teams sind soziale Systeme mit eigenen Homöostasen. Sie tendieren zur Stabilität, auch wenn diese Stabilität dysfunktional ist. Das Phänomen hat einen Namen: Kollusive Vermeidung. Das Team arrangiert sich kollektiv mit dem toxischen Akteur, entwickelt Umgehungsstrategien, passt Kommunikationswege an — und normalisiert damit das Abnormale. Nach einigen Sprints ist das toxische Verhalten schlicht "wie es hier läuft."
Drei Dynamiken treiben diese Kollusion:
1. Diffusion of Responsibility: In selbstorganisierten Teams ist niemand explizit verantwortlich für Teamdynamiken. Der Scrum Master facilitiert, ist aber kein Manager. Der Product Owner fokussiert auf Wert. Führungskräfte halten Abstand. Alle wissen, dass etwas nicht stimmt — aber wer soll es ansprechen?
2. Fear of Retaliation: In Systemen, in denen der toxische Akteur informellen Status hat — durch Seniorität, technisches Know-how oder politische Vernetzung — ist das Risiko des Ansprechens real. Wer sich traut, riskiert, zum Ziel zu werden. Diese Angst ist nicht irrational, sie ist systemisch begründet.
3. Gaslighting als Schutzreflex: Toxische Akteure sind oft meisterhaft darin, ihre Verhaltensweisen als Reaktion zu framen. "Ich sage nur meine Meinung." "Das war doch nicht so gemeint." "Du bist zu sensibel." Das Team beginnt, an der eigenen Wahrnehmung zu zweifeln — ein klassisches Zeichen, dass Gaslighting funktioniert.
Ein Praxisbeispiel aus einem Coaching-Kontext: Ein Scrum Team in einem mittelständischen Softwareunternehmen kämpfte seit zwei Quartalen mit sinkender Teamzufriedenheit — trotz stabiler Velocity. In einer Team-Health-Check-Analyse nach dem Spotify-Modell fielen fast alle kollaborativen Dimensionen ins Rote, während technische Kompetenz hoch blieb. Die Ursache war ein Senior Developer, der neue Teammitglieder in Code Reviews systematisch demütigte — nie direkt, immer mit dem Anschein von fachlicher Strenge. Der Scrum Master hatte es bemerkt, aber nicht benannt, weil er "nicht als parteiisch gelten wollte." Drei Entwickler hatten intern um Teamwechsel gebeten — ohne den Grund zu nennen.
Der Erkenntnisgewinn: Toxische Muster überleben, weil das System sie schützt — oft aus rationalen Einzelentscheidungen heraus, die kollektiv irrationale Ergebnisse produzieren.
Konfrontation als Führungsaufgabe: Das Gespräch, das niemand führen will
Servant Leadership bedeutet nicht, jedem zu dienen — auch nicht dem toxischen Akteur auf Kosten des Teams. Diese Verwechslung ist eine der häufigsten und schädlichsten Fehlinterpretationen des Konzepts. Robert Greenleaf, der Begründer des Servant-Leadership-Gedankens, hat Service explizit als Dienst am Gesamtsystem beschrieben. Das Team ist das System. Und manchmal dient man dem System, indem man unbequeme Wahrheiten ausspricht.
Das direkte Gespräch ist der unvermeidliche Schritt — aber es gibt einen Unterschied zwischen Konfrontation und Konfrontationsbereitschaft. Die meisten Führungskräfte, Scrum Master und Coaches schieben das Gespräch auf, weil sie es als Konfrontation framen. Es ist keines. Es ist ein Klärungsgespräch — und das erfordert einen klaren strukturellen Rahmen.
Das SBI-Modell (Situation, Behavior, Impact) ist in diesem Kontext besonders wirksam, weil es Beobachtungen von Interpretationen trennt:
- Situation: "In der letzten Retrospektive, als Jonas seinen Vorschlag präsentiert hat..."
- Behavior: "...hast du mehrfach unterbrochen und den Vorschlag als 'naiv' bezeichnet, bevor er ausgesprochen war."
- Impact: "Das hat Jonas sichtlich verunsichert und dazu geführt, dass in der zweiten Hälfte niemand mehr Ideen eingebracht hat."
Kein Angriff auf die Person. Keine Deutung der Intention. Nur: Was war zu beobachten, und was war die Wirkung?
Entscheidend ist die Haltung vor dem Gespräch: Wer in das Gespräch geht mit der Prämisse "Ich muss diesen Menschen ändern", wird scheitern. Wer eingeht mit "Ich kommuniziere eine Beobachtung und deren Systemwirkung und lade zur gemeinsamen Reflexion ein", schafft zumindest eine Chance für Veränderung.
Konkrete Vorbereitung für das Gespräch:
- Dokumentiere spezifische Vorfälle mit Datum, Situation und Beobachtung — nicht "er ist immer so", sondern drei konkrete Momente.
- Kläre die eigene Rolle: Führst du das Gespräch als Scrum Master, als Teamkollege, als Vorgesetzte? Diese Rolle bestimmt Mandat und Ton.
- Definiere ein klares Ziel: Welches konkrete Verhaltens-Delta ist das Minimum, um gemeinsam weiterzuarbeiten?
- Plane einen Folgetermin ein: Einmalige Gespräche verpuffen. Accountability entsteht durch Kontinuität.
Was nicht funktioniert: Das Gespräch als letzten Ausweg nutzen, wenn das Team bereits zerbrochen ist. Oder die HR-Abteilung als erste Eskalationsstufe einzuschalten, ohne ein direktes Gespräch versucht zu haben. Beides signalisiert dem Team, dass die Führung das Problem nicht eigenverantwortlich trägt.
Wenn das Gespräch nicht reicht: Eskalation als strategische Entscheidung
Manchmal verändert sich nach dem Gespräch nichts. Das Verhalten geht weiter — vielleicht subtiler, vielleicht offener. Jetzt wird aus einem Coaching-Problem ein Organisationsproblem. Und das erfordert eine andere Art von Handeln.
Eskalation in agilen Organisationen ist strukturell unterentwickelt. Flache Hierarchien und Selbstorganisation werden oft so interpretiert, dass niemand zuständig ist — gerade für das Unangenehme. Das ist eine gefährliche Leerstelle. Wer Eskalation vermeidet, macht das Team zum Kollateralschaden einer ideologischen Haltung.
Ein klarer Eskalationsrahmen für Scrum Master und Agile Coaches:
Stufe 1 — Direkte Adressierung: Das Klärungsgespräch (s.o.), dokumentiert, mit Folgetermin.
Stufe 2 — Team-Einbeziehung: Wenn ein Muster auch im Team bekannt ist, braucht es eine strukturierte Retrospektive, in der das Thema explizit bearbeitet wird — nicht als Anklage, sondern als Systemfrage: "Was hindert uns als Team daran, sicher miteinander zu kommunizieren?" Working Agreements können hier als konkrete Vereinbarungen re-aktiviert oder neu erstellt werden.
Stufe 3 — Eskalation zur Führungsebene: Wenn direkte Adressierung und Team-Intervention keine Veränderung bringen, ist es Führungsaufgabe auf Leitungsebene. Scrum Master und Coaches müssen in der Lage sein, dies klar zu empfehlen — mit Dokumentation und konkreten Auswirkungsbelegen, nicht mit Befindlichkeitsberichten.
Stufe 4 — Strukturelle Konsequenzen: Im Extremfall bedeutet Servant Leadership auch, die Empfehlung zu geben, dass eine Person aus dem Team herausgelöst wird. Das ist keine Niederlage — es ist Schutz des Systems.
Ein wichtiger Hinweis zur Dokumentation: Jede Eskalationsstufe sollte schriftlich festgehalten werden — nicht als Mittel der Bestrafung, sondern als Transparenzwerkzeug. Was wurde beobachtet? Was wurde besprochen? Was wurde vereinbart? Was hat sich verändert oder nicht? Ohne diese Dokumentation verliert jede Eskalation ihre Grundlage.
Ein Fallbeispiel aus der Praxis: In einem Scale-Agile-Kontext eines Telekommunikationsunternehmens blockierte ein erfahrener Agile Coach — paradoxerweise — seit Monaten die Entwicklung des Teams durch belehrendes Verhalten und offene Abwertung anderer Coaches. Die Programmebene sah zunächst weg, weil der Coach "langjährig und erfahren" war. Erst als zwei Coaches offiziell dokumentierten, dass Teammitglieder Retrospektiven boykottierten, wurde gehandelt. Das Feedback-Gespräch auf Leitungsebene führte zu einer Rollenanpassung — mit positivem Ausgang. Der entscheidende Hebel war die Dokumentation über Zeit.
Psychologische Sicherheit aktiv schützen: Präventive Systemarchitektur
Wer toxische Muster nur reaktiv adressiert, kämpft immer auf verlorenem Terrain. Die eigentliche Meisterklasse liegt in der präventiven Systemarchitektur — also: Strukturen, Rituale und Normen zu schaffen, die toxische Muster schwerer entstehen lassen und früher sichtbar machen.
Das beginnt mit Working Agreements als lebenden Dokumenten. Die meisten Teams haben Working Agreements, die einmal erstellt und nie wieder angefasst wurden. Wirkungsvolle Agreements sind keine Platitüden ("Wir respektieren uns") — sie sind operationalisierte Verhaltenserwartungen: "Wir lassen ausreden. Wenn jemand unterbrochen wird, benennt die moderierende Person dies direkt." Solche Konkretisierungen schaffen Referenzpunkte, auf die sich alle — auch und gerade — in schwierigen Momenten beziehen können.
Psychologische Sicherheit messbar machen: Amy Edmondson hat einen validierten Fragebogen entwickelt, der sich ohne großen Aufwand als Puls-Check in Retrospektiven integrieren lässt. Sieben Items, fünfzehn Minuten — und plötzlich wird sichtbar, was im Raum längst gespürt aber nie benannt wird. Teams, die regelmäßig ihre psychologische Sicherheit messen, entwickeln eine Sprache für Unbehagen. Diese Sprache ist der erste Schutzwall.
Rituale der gegenseitigen Sichtbarkeit: Formale Anerkennungsmechanismen — ob in Form von Kudos-Karten in der Retro, Shoutouts im Weekly oder strukturierten Feedbackrunden — stärken die sozialen Bindungen im Team und machen es schwerer, informelle Machthierarchien zu etablieren. Wer regelmäßig gesehen und anerkannt wird, verliert weniger leicht seine Stimme.
Onboarding als Schutzmoment: Neue Teammitglieder sind die vulnerabelste Gruppe — sie können toxische Muster noch nicht einordnen, haben keine Vertrauensbasis und tendieren dazu, Auffälligkeiten als "normal hier" zu interpretieren. Ein strukturiertes Onboarding, das explizit die Teamkultur und die Working Agreements thematisiert, gibt Newcomern einen sicheren Rahmen und sendet gleichzeitig ein klares Signal: Diese Werte werden aktiv verteidigt.
Die Rolle des Scrum Masters als Kulturarchitekt: In der Praxis ist die Scrum-Master-Rolle oft entweder überfrachtiert (alles Organisatorische landet dort) oder unterinvestiert (nur Zeremonienfacilitation). Die eigentlich transformative Funktion — aktive Gestaltung der Teamkultur — bleibt liegen. Scrum Master, die regelmäßig 1:1-Gespräche mit Teammitgliedern führen, die Dynamiken in Meetings aktiv beobachten und benennen, und die Working Agreements als Instrument des Schutzes und nicht als Formalität behandeln, sind der wirksamste Präventionsmechanismus, den ein agiles Team haben kann.
Was bleibt: Leadership bedeutet nicht Harmonie, sondern Klarheit
Toxische Muster in agilen Teams sind kein Versagen der Agilität — sie sind eine Einladung zur Reife. Reife in der Führung bedeutet: die Bereitschaft, unbequeme Realitäten zu benennen, auch wenn die agile Ideologie Konsens und Harmonie als Leitwerte propagiert.
Es gibt eine Passage aus Patrick Lencionis "The Five Dysfunctions of a Team", die in diesem Kontext präziser ist als alle Coaching-Frameworks zusammen: "If you could get all the people in an organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time." Das Gegenteil davon ist nicht Konflikte — das Gegenteil davon ist eine Person, die aktiv gegen den Strom rudert, und alle anderen, die so tun, als wäre es Wellengang.
Die Kernbotschaft dieses Artikels lautet: Toxisches Verhalten in Teams ist nicht ein Problem für HR, nicht ein Problem für die nächste Retrospektive, und nicht ein Problem, das sich "mit der Zeit gibt." Es ist eine systemische Störung, die sofortiges, strukturiertes und dokumentiertes Handeln erfordert — auf der Ebene des direkten Gesprächs, der Teamnormen, der Eskalation und der präventiven Systemgestaltung.
Agile Leader, die das verstehen, schützen nicht nur das Team. Sie schützen das Fundament, auf dem Agilität überhaupt erst möglich wird: Vertrauen. Und Vertrauen entsteht nicht durch Schweigen — es entsteht dadurch, dass Menschen sehen, dass klares, mutiges Handeln möglich ist.
Wer toxic behavior toleriert, kommuniziert implizit: Ihr seid auf euch allein gestellt. Wer es benennt und handelt, kommuniziert: Dieses Team hat eine Grenze — und ich stehe dafür ein.
Das ist Servant Leadership in seiner ursprünglichsten Form.
