Ein Kölner IT-Dienstleister veränderte nicht die Zahl seiner Meetings, sondern die Art, wie Teams zwischen fachlichem Widerspruch, ungeklärter Entscheidung und echtem Beziehungskonflikt unterschieden.
Das Projekt begann mit einer Beobachtung, die in agilen Organisationen leicht übersehen wird: Ein Team kann kommunikativ sehr aktiv sein und trotzdem zentrale Konflikte nicht klären. Beim Kölner IT-Dienstleister gab es Dailys, Refinements, Sprint Plannings, Reviews, Retrospektiven, Projekt-Chats und spontane Videocalls. Trotzdem kehrten bestimmte Spannungen immer wieder zurück.
Der Dienstleister entwickelte Individualsoftware, Kundenportale und datenbasierte Plattformlösungen. In den Projektteams arbeiteten Softwareentwicklung, UX/UI, Product Ownership, Qualitätssicherung und Projektmanagement zusammen. Die fachlichen Unterschiede waren gewollt. Problematisch wurde nicht der Widerspruch selbst, sondern die Frage, wann aus ihm ein ungelöstes Muster wurde.
Ein Product Owner wollte kurzfristig Scope verändern. Development hielt dagegen. UX bestand auf einem zusätzlichen Arbeitsschritt. Die Projektleitung sah den Release-Termin. Jeder Standpunkt hatte eine nachvollziehbare Logik. Trotzdem wurde aus „Welche Lösung ist tragfähig?“ zunehmend „Warum versteht die andere Seite unsere Arbeit nicht?“
Das zentrale Problem war nicht zu wenig Kommunikation. Es fehlte eine gemeinsame Logik dafür, wann ein Team diskutiert, wann eine Rolle entscheidet und wann ein Konflikt einen eigenen Klärungsraum braucht.
Der Fall gehört zum Themenbereich Konflikte im Job professionell lösen. Passende Vertiefungen sind die Kurse zum Konfliktmanagement, die Rubrik Schwierige Gespräche & Feedback, die FAQ zu Konflikten im Job und die Case-Study-Übersicht.
Unser maßgeschneidertes Inhouse-Seminar für Sie!
Wählen Sie bei Ihrer Anfrage zwischen einem a) Inhouse-Präsenz-Seminar an Ihrem Standort, b) einem Inhouse-Online-Workshop mit Ihrem Team oder c) einem Inhouse-Präsenz-Kurs direkt an der Akademie – gern auch in Kombination mit Teambuilding-Aktionen.
Ein Ticket kippt in einen Konflikt…
Im Mittelpunkt des Trainings stand keine theoretische Konfliktmatrix, sondern der Verlauf eines typischen Arbeitstages. Am Montagvormittag diskutierte das Team ein Feature für ein Kundenportal. UX wollte den vorgesehenen Ablauf ändern. Development sah dafür im laufenden Sprint keinen realistischen Spielraum. Product Ownership argumentierte mit einer Rückmeldung des Kunden.
Nach wenigen Minuten verschob sich das Gespräch. Aus „Welche Variante ist möglich?“ wurde „Das wurde doch schon wieder zu spät eingebracht.“ Darauf folgte: „Wir sagen nicht zu spät Bescheid, ihr wollt nur nichts mehr anfassen.“ Das Ticket selbst war weiterhin lösbar. Schwieriger war die zweite Ebene: Beide Fachseiten begannen, aus einem konkreten Vorgang ein Muster über die jeweils andere Gruppe abzuleiten.
Im Training wurden deshalb drei Ebenen getrennt: die fachliche Sachfrage, das dafür geltende Entscheidungsrecht und die Beziehungsebene zwischen den beteiligten Rollen.
Diese Trennung veränderte den weiteren Projektverlauf. Fachlicher Widerspruch musste nicht beseitigt werden. Er musste lediglich dort bleiben, wo er hingehörte. Erst wenn Rollen, Kriterien oder frühere Erfahrungen das Gespräch überlagerten, entstand ein zusätzlicher Klärungsbedarf.
Warum „Wir müssen besser kommunizieren“ keine Maßnahme war
In einer Retrospektive tauchte ein vertrauter Satz auf: „UX und Development müssen früher miteinander sprechen.“ Alle stimmten zu. Genau darin lag das Problem. Niemand musste widersprechen – und niemand musste etwas Konkretes entscheiden.
Das Team rekonstruierte deshalb mehrere frühere Maßnahmen. „Früher einbinden“, „besser abstimmen“, „klarer kommunizieren“ und „mehr Transparenz“ waren wiederholt vereinbart worden. Trotzdem kehrten dieselben Themen zurück.
Eine Retrospektiven-Maßnahme war im Projekt erst dann belastbar, wenn sie ein beobachtbares Verhalten, eine zuständige Rolle und einen Zeitpunkt für die Überprüfung enthielt.
Aus „UX früher einbinden“ wurde beispielsweise: Bei Tickets mit veränderter Nutzerführung erfolgt die UX-Prüfung vor Aufnahme in die Sprint-Planung. Product Ownership kennzeichnet entsprechende Tickets. Development beginnt die technische Umsetzung erst nach diesem Schritt. Aus einer guten Absicht wurde damit eine überprüfbare Arbeitsregel.
Das Team legt ein Entscheidungsprotokoll an
Die wichtigste Neuerung des Trainings war keine zusätzliche Besprechung. Das Team begann stattdessen mit einem kleinen Entscheidungsprotokoll für wiederkehrende Konfliktpunkte.
Es bestand aus vier Fragen:
- Differenz: Worüber besteht tatsächlich Uneinigkeit?
- Wirkung: Was passiert, wenn die Frage offenbleibt?
- Entscheidung: Wer entscheidet anhand welcher Kriterien?
- Wiedervorlage: Wann prüfen wir, ob die Vereinbarung funktioniert?
Diese vier Fragen bildeten die BARO-SPRINT-KLÄRUNG. Sie war keine neue agile Methode neben Scrum oder Kanban und sollte bestehende Projektmethoden nicht ersetzen. Sie diente ausschließlich dazu, Konfliktpunkte aus Meetings in eine nachvollziehbare Entscheidung zu überführen.
BARO-SPRINT-KLÄRUNG bedeutet: Eine Differenz darf den Sprint nur dann ungelöst verlassen, wenn bewusst festgelegt wurde, wer sie wann weiterbearbeitet.
Damit wurde ein bis dahin häufiges Muster unterbrochen. Ein Thema konnte nicht mehr allein deshalb als „geklärt“ gelten, weil es in einer Retrospektive besprochen worden war.
Ein Entscheidungslog aus dem Training
Eine Trainingseinheit arbeitete mit fünf konkreten Konfliktpunkten. Das Ergebnis wurde in Form eines Entscheidungslogs dokumentiert.
| Konfliktpunkt | Was tatsächlich strittig war | Entscheidungsregel | Überprüfung |
|---|---|---|---|
| zusätzliches Feature im laufenden Sprint | Kundenwert gegen verfügbare Kapazität | Product Ownership priorisiert; Development benennt Aufwand und technisches Risiko; eine vorhandene Aufgabe muss bei Mehrumfang sichtbar zurückgestuft werden | im Sprint Review |
| UX-Änderung kurz vor Umsetzung | Nutzungsqualität gegen bereits geplanten Entwicklungsaufwand | UX benennt notwendiges Nutzungskriterium; Development Aufwand; Product Ownership entscheidet über Scope | beim nächsten vergleichbaren Ticket |
| technische Schuld | kurzfristiger Release gegen spätere Wartbarkeit | Development dokumentiert technische Konsequenz und Aufwand der späteren Bereinigung; Product Ownership entscheidet bewusst über Priorität | im nächsten Planning |
| informelle Büroentscheidung | Geschwindigkeit gegen Nachvollziehbarkeit im hybriden Team | Gespräche dürfen informell erfolgen; verbindlich wird eine Projektentscheidung erst nach gemeinsamer Dokumentation | laufend im Projektboard |
| wiederholte persönliche Spannung | nicht mehr nur fachliche Differenz | separates Klärungsgespräch statt erneuter Behandlung als allgemeines Retro-Thema | vereinbarter Follow-up-Termin |
Das Entscheidungslog trennte erstmals systematisch fachliche Beratung von Entscheidungsverantwortung: Fachrollen mussten ihre Kriterien liefern, aber nicht jede Fachrolle erhielt dadurch automatisch das letzte Wort.
Gerade für interdisziplinäre Teams war das relevant. UX konnte ein Nutzungskriterium definieren, ohne allein über den Sprint-Scope zu entscheiden. Development konnte ein technisches Risiko benennen, ohne damit automatisch jede Produktentscheidung zu blockieren. Product Ownership konnte priorisieren, musste die Konsequenzen dieser Priorisierung jedoch sichtbar machen.
Drei Konflikte – drei verschiedene Verfahren
Im nächsten Trainingsschritt wurde bewusst auf eine allgemeine Konflikttypologie verzichtet. Stattdessen erhielt das Team drei reale Situationen und musste jeweils entscheiden, welches Verfahren angemessen war.
Fall A: Fachlicher Widerspruch
Zwei Entwickler bevorzugten unterschiedliche technische Lösungswege. Beide Varianten waren grundsätzlich realisierbar.
Hier brauchte das Team keine Konfliktmoderation. Es brauchte technische Entscheidungskriterien und die dafür zuständige Rolle.
Der Streit blieb fachlich. Das war kein Problem, sondern Teil professioneller Entwicklung.
Fall B: Dieselbe Vereinbarung scheitert zum dritten Mal
UX sollte bei bestimmten Tickets früher eingebunden werden. Trotzdem kam es wiederholt erst kurz vor der Umsetzung zur Abstimmung.
Hier war nicht mehr die ursprüngliche UX-Frage der Konflikt. Der Konflikt lag darin, dass eine gemeinsam beschlossene Arbeitsregel nicht umgesetzt wurde.
Das Team prüfte deshalb nicht zum vierten Mal, ob frühe UX-Beteiligung sinnvoll sei. Es untersuchte, warum die vereinbarte Kennzeichnung im Backlog nicht funktionierte.
Fall C: Zwei Personen sprechen kaum noch direkt miteinander
Nach mehreren angespannten Situationen liefen Abstimmungen zunehmend über Product Owner oder Scrum Master. Fachlich konnte das Team noch arbeiten, doch direkte Kommunikation wurde vermieden.
Hier war die Grenze des agilen Prozessformats erreicht. Ein persönlicher Beziehungskonflikt wurde nicht als weiteres Backlog- oder Retro-Thema behandelt.
Für diesen Fall wurde ein eigener Gesprächsrahmen vereinbart. Bei weiterer Verhärtung wären Führung beziehungsweise eine geeignete interne oder externe Moderation einzubeziehen gewesen.
Was Kay Schönewerk im Training bewusst nicht als „agiles Problem“ behandelte
Kay Schönewerk ordnete die Konflikte im Training nicht nach Methodenbegriffen wie Scrum oder Kanban, sondern nach der praktischen Frage, ob Menschen gerade über Inhalt, Zuständigkeit, Verbindlichkeit oder Beziehung streiten.
Dieser Ansatz ist Teil der Konfliktarbeit der Bildungsakademie am Rosental: Die Methode des Kunden bleibt bestehen. Konfliktmanagement wird nicht als konkurrierendes System darübergelegt. Stattdessen werden bestehende Arbeitsformate darauf geprüft, ob sie für die jeweilige Konfliktart tatsächlich geeignet sind.
Gerade bei agiler Arbeit ist diese Unterscheidung wichtig. Eine Retrospektive ist ein starkes Format zur Reflexion der Zusammenarbeit. Sie ist aber nicht automatisch ein geeigneter Raum für jeden persönlichen Konflikt. Ein Daily schafft Transparenz über Arbeit, ist aber kein Entscheidungsforum für komplexe Rollenfragen. Ein Product Owner priorisiert Produktarbeit, ist dadurch aber nicht automatisch Konfliktmoderator des gesamten Teams.
Schönewerks fachliche Einordnung im Projekt lautete deshalb: Konfliktkompetenz beginnt dort, wo ein Team nicht nur über den Konflikt spricht, sondern erkennt, welches Verfahren der Konflikt überhaupt braucht.
Was im Team ab sofort nicht mehr passieren sollte
Am Ende der Trainingswoche definierte die Gruppe vier Anti-Muster. Sie waren einfacher zu erinnern als ein umfangreiches Regelwerk.
- Keine unsichtbare Scope-Erweiterung: Neue Priorität bedeutet sichtbar, dass eine andere Aufgabe zurückgestuft, verschoben oder neu bewertet wird.
- Keine Dauer-Retrospektive: Taucht dasselbe Konfliktthema wiederholt auf, wird es aus der allgemeinen Retro herausgenommen und separat geklärt.
- Keine Entscheidung ohne Entscheidungsrecht: Wer fachlich berät, muss nicht automatisch entscheiden; wer entscheidet, muss die relevanten Fachkriterien berücksichtigen.
- Keine verbindliche Flurentscheidung: In hybriden Teams ist eine Entscheidung erst dann verbindlich, wenn sie für alle relevanten Beteiligten nachvollziehbar dokumentiert wurde.
Damit erhielt das Team vier konkrete Stop-Regeln für Situationen, in denen Konflikte zuvor regelmäßig unsichtbar weitergetragen wurden.
Transfer: Nicht weniger Konflikt, sondern weniger ungeklärte Wiederholung
In der Transferphase wurde nicht gezählt, wie viele Konflikte es gab. Diese Kennzahl wäre im agilen Kontext wenig aussagekräftig gewesen. Fachlicher Widerspruch sollte ausdrücklich bestehen bleiben.
Beobachtet wurde stattdessen, ob bereits besprochene Konfliktpunkte erneut ohne erkennbare neue Ursache auftauchten, ob Entscheidungen dokumentiert waren und ob Teammitglieder wussten, wer bei einer strittigen Frage entscheiden durfte.
| Beobachtungsfeld | Zu Beginn | In der Transferphase |
|---|---|---|
| Retrospektiven | mehrere allgemein formulierte Kommunikationsmaßnahmen | konkretere Maßnahmen mit Rolle und Wiedervorlage |
| Entscheidungen | teilweise implizit aus Diskussionen entstanden | bei strittigen Themen sichtbarer dokumentiert |
| fachliche Konflikte | häufig mit Rollen- oder Beziehungsebene vermischt | stärker anhand von Kriterien bearbeitet |
| wiederkehrende Themen | erneut in allgemeine Teamdiskussion eingebracht | gezielt auf Umsetzungs- oder Beziehungsproblem geprüft |
| hybride Zusammenarbeit | informelle Informationsvorsprünge möglich | Verbindlichkeit an gemeinsame Dokumentation gekoppelt |
Der wesentliche Transfer bestand darin, nicht „Konfliktfreiheit“ zu messen, sondern die Zahl ungeklärter Wiederholungsschleifen im Arbeitsprozess zu reduzieren.
Wo der Ansatz ausdrücklich endet
BARO-SPRINT-KLÄRUNG kann einen Entscheidungsprozess strukturieren; sie kann weder personelle Unterbesetzung noch unrealistische Projektplanung oder einen verhärteten persönlichen Konflikt beheben.
Diese Grenze wurde im Projekt ausdrücklich benannt. Wenn ein Team dauerhaft mehr Arbeit übernehmen soll, als Kapazität vorhanden ist, produziert nicht die Kommunikation den Konflikt. Wenn Rollen offiziell beschrieben, Entscheidungsrechte praktisch aber widersprüchlich gelebt werden, reicht auch eine besser moderierte Retrospektive nicht aus.
Ebenso gehören persönliche Herabsetzungen, anhaltende Ausgrenzung oder andere gravierende Beziehungskonflikte nicht dauerhaft in agile Standardformate. Sie benötigen je nach Situation Führung, HR, Konfliktmoderation oder andere zuständige Verfahren. Konfliktkompetenz soll Organisationsprobleme sichtbar machen – nicht sie sprachlich kaschieren.
Arbeitswissenschaftliche Einordnung
Agile Arbeit verbindet höhere Eigenverantwortung und Beteiligung mit besonderen Anforderungen an Abstimmung und Rollenklärung. Die Bundesanstalt für Arbeitsschutz und Arbeitsmedizin untersucht diese Zusammenhänge unter anderem im Forschungsprojekt „Empowerment – Risiken und Nebenwirkungen agiler Arbeit“.
Für interdisziplinäre Zusammenarbeit ist außerdem relevant, dass unterschiedliche Fachperspektiven gleichzeitig verarbeitet werden müssen. Ein BAuA-Beitrag zur interdisziplinären Zusammenarbeit beschreibt unter anderem den hohen Informationsfluss in agiler Teamarbeit.
Die DGUV weist im Kontext sozialer Beziehungen am Arbeitsplatz darauf hin, dass ungelöste Konflikte Belastungen erzeugen können. Auch § 5 des Arbeitsschutzgesetzes nennt psychische Belastungen bei der Arbeit im Kontext der Gefährdungsbeurteilung.
Für agile Teams folgt daraus kein spezielles Konfliktmodell, wohl aber eine wichtige Organisationsfrage: Selbstorganisation funktioniert nur, wenn Rollen, Entscheidungswege und soziale Zusammenarbeit tatsächlich gestaltbar sind.
Wo dieser Case im BARO-Konfliktcluster einzuordnen ist
Der Kölner Fall unterscheidet sich vom Münchner Software-Case. Dort steht präventive Konfliktkompetenz unter anhaltender IT-Belastung im Mittelpunkt. In Köln geht es enger um interdisziplinäre Entscheidungs- und Rollenkonflikte innerhalb agiler Projekte.
Auch der Case eines Energieversorgers bei Leipzig behandelt eine andere Konfliktarchitektur: Dort stehen Veränderung und Strukturwandel im Zentrum, nicht iterative Produktarbeit und gleichzeitige Fachrollen.
Der Kölner Case erweitert den Cluster damit um eine spezifische Frage: Wie bleibt fachlicher Widerspruch in selbstorganisierter Projektarbeit produktiv, ohne sich in Rollenunklarheit oder persönliche Lagerbildung zu verwandeln?
Transferstimme aus dem Projekt
„Wir hatten nicht zu wenige Meetings. Wir haben nur zu oft geglaubt, ein besprochenes Thema sei damit schon entschieden. Heute unterscheiden wir genauer: Was ist eine fachliche Differenz, wer hat das Entscheidungsrecht und wann müssen wir einen Konflikt aus dem normalen Sprint-Prozess herausnehmen?“
Senior Product Owner, IT-Dienstleister für Individualsoftware und digitale Plattformen in Köln
Die Transferstimme ist fachlich relevant, weil der Product Owner im Projekt genau an der Schnittstelle zwischen Kundenanforderung, Priorisierung, Development, UX und Projektsteuerung arbeitete. Seine Rolle war damit unmittelbar von den beschriebenen Entscheidungs- und Schnittstellenkonflikten betroffen.
Zusammenfassung
Der Kölner IT-Dienstleister stabilisierte seine agilen Teams nicht durch zusätzliche Kommunikation, sondern durch eine klarere Trennung von fachlicher Differenz, Entscheidungsrecht, Umsetzung und Beziehungskonflikt.
Die BARO-SPRINT-KLÄRUNG gab wiederkehrenden Konfliktpunkten einen einfachen Übergang aus dem Gespräch in eine nachvollziehbare Entscheidung: Differenz, Wirkung, Entscheidung und Wiedervorlage. Ergänzt wurde sie durch konkrete Stop-Regeln für unsichtbare Scope-Erweiterungen, wiederkehrende Retro-Themen, informelle Entscheidungen und ungeklärte Zuständigkeiten.
Eine passende Inhouse-Schulung im Bereich Konfliktmanagement kann diese Logik auf die tatsächlichen Projektrollen, Arbeitsformen und Konfliktmuster eines Unternehmens übertragen.
FAQ: Zusätzliche Fragen aus der Praxis agiler Projektteams
Ist häufiges Widersprechen in einem agilen Team bereits ein Konfliktproblem?
Nein. Regelmäßiger fachlicher Widerspruch kann gerade in interdisziplinären Teams ein Qualitätsmerkmal sein. Problematisch wird er erst, wenn Sachargumente nicht mehr anhand nachvollziehbarer Kriterien bewertet werden, Entscheidungen dauerhaft offenbleiben oder aus dem Verhalten einer Person allgemeine negative Zuschreibungen über ihre Rolle oder Fachgruppe entstehen.
Ein Team mit wenig Widerspruch ist deshalb nicht automatisch konfliktkompetenter als ein Team mit vielen fachlichen Debatten.
Welche Konflikte sollten nicht in einer Retrospektive bearbeitet werden?
Eine Retrospektive eignet sich gut für gemeinsame Arbeitsmuster. Ein verhärteter Konflikt zwischen einzelnen Personen kann dort jedoch zusätzlichen sozialen Druck erzeugen, insbesondere wenn andere Teammitglieder faktisch zu Zuschauern oder unfreiwilligen Schiedsrichtern werden. Persönliche Vorwürfe, Vertrauensverlust oder wiederholte direkte Herabsetzungen benötigen häufig einen kleineren und klar moderierten Rahmen.
Die entscheidende Frage ist nicht, ob ein Konflikt „agil“ ist, sondern ob alle Personen im jeweiligen Format tatsächlich für seine Bearbeitung benötigt werden.
Wer entscheidet bei einem Konflikt zwischen UX und Development?
Das lässt sich nicht pauschal einer Rolle zuweisen. UX besitzt die Fachkompetenz für Nutzungskriterien, Development für technische Machbarkeit und Risiken. Eine Produkt- oder Scope-Entscheidung kann wiederum beim Product Owner liegen. Deshalb sollten zuerst die Kriterien der einzelnen Fachrollen sichtbar gemacht und danach das konkrete Entscheidungsrecht bestimmt werden.
Fachkompetenz und finales Entscheidungsrecht sind in interdisziplinären Projekten häufig bewusst auf unterschiedliche Rollen verteilt.
Woran erkennt ein Team einen Wiederholungskonflikt?
Ein starkes Signal ist, wenn dieselbe Forderung in mehreren Retrospektiven auftaucht, obwohl bereits eine Maßnahme beschlossen wurde. Dann sollte nicht erneut über die ursprüngliche Forderung diskutiert werden. Stattdessen muss geprüft werden, ob die Vereinbarung zu unkonkret war, niemand zuständig war, ein strukturelles Hindernis besteht oder Beteiligte die Regel nicht akzeptieren.
Die Wiederholung eines Konflikts liefert deshalb zusätzliche Information: Nicht nur das Ausgangsproblem, sondern auch die bisherige Lösung funktioniert nicht.
Wie verhindert man Nachteile für Remote-Teammitglieder?
Nicht jedes spontane Bürogespräch muss dokumentiert werden. Relevant sind Entscheidungen, die Scope, technische Architektur, Priorität, Rollen oder verbindliche Arbeitsweisen verändern. Werden solche Entscheidungen außerhalb gemeinsamer Formate vorbereitet, sollten sie anschließend für alle betroffenen Teammitglieder nachvollziehbar festgehalten werden.
Das Problem hybrider Teams ist nicht informelle Kommunikation an sich, sondern informelle Verbindlichkeit.
Ist ein Scrum Master automatisch neutraler Konfliktmoderator?
Nein. Ein Scrum Master kann Prozesse strukturieren und Hindernisse in der Zusammenarbeit sichtbar machen. Ob er einen persönlichen Konflikt neutral moderieren kann, hängt jedoch von seiner eigenen Beteiligung, Akzeptanz bei den Konfliktparteien und der konkreten Situation ab. Bei einer verhärteten Auseinandersetzung kann eine andere interne oder externe Person geeigneter sein.
Die Scrum-Rolle allein erzeugt noch keine Neutralität in einem persönlichen Konflikt.
Wie konkret muss eine konfliktbezogene Maßnahme sein?
Sie sollte mindestens beantworten, welches Verhalten oder welcher Ablauf verändert wird, wer dafür verantwortlich ist und wann überprüft wird, ob die Änderung funktioniert. „Früher abstimmen“ erfüllt keines dieser Kriterien. „UX-relevante Tickets werden vor Sprint Planning gekennzeichnet und dort gemeinsam geprüft“ ist überprüfbar.
Je abstrakter die Maßnahme formuliert ist, desto schwieriger lässt sich später feststellen, ob sie tatsächlich umgesetzt wurde.
Wann wird aus einem fachlichen Konflikt ein Beziehungskonflikt?
Ein Hinweis ist der Wechsel von Aussagen über eine konkrete Lösung zu Aussagen über Personen oder Gruppen: aus „Diese Architektur erzeugt Risiko X“ wird beispielsweise „Development blockiert immer alles“. Weitere Signale können Gesprächsvermeidung, Kommunikation über Dritte oder die pauschale Interpretation fachlicher Entscheidungen als Sieg und Niederlage sein.
Der Wechsel von konkreter Kritik zu stabilen negativen Zuschreibungen ist ein wichtiges Warnsignal für die Beziehungsebene.
Kann Konfliktkompetenz schlechte Sprintplanung ausgleichen?
Nein. Ist ein Sprint dauerhaft überplant oder werden Scope-Änderungen regelmäßig ohne Kapazitätsentscheidung aufgenommen, bleibt ein struktureller Zielkonflikt bestehen. Gute Gesprächsführung kann die Folgen sichtbar machen, aber keine zusätzliche Entwicklungszeit erzeugen.
Konfliktkompetenz darf nicht dazu dienen, Überlastung kommunikativ erträglicher zu machen.
Welche Kennzahl eignet sich besser als „Anzahl der Konflikte“?
Für agile Teams kann beispielsweise beobachtet werden, wie oft dieselben Konfliktpunkte trotz vereinbarter Maßnahme erneut auftauchen, wie viele strittige Entscheidungen ohne klaren Owner bleiben oder wie häufig verbindliche Entscheidungen nachträglich erneut ausgehandelt werden. Solche Beobachtungen sagen mehr über Konfliktfähigkeit aus als eine möglichst niedrige Zahl offener Meinungsverschiedenheiten.
Ein konfliktkompetentes Team kann viele Meinungsverschiedenheiten haben – entscheidend ist, ob sie entscheidbar und lernfähig bleiben.
English Summary
This case study describes how a Cologne-based IT service provider integrated conflict competence into interdisciplinary agile project work without adding another meeting framework.
The teams worked across software development, UX/UI, product ownership, quality assurance and project management. Their main challenge was not insufficient communication but recurring ambiguity about professional disagreement, decision rights and implementation of previous agreements.
The BARO-SPRINT-KLÄRUNG uses four checkpoints: difference, impact, decision and follow-up. Its purpose is to prevent unresolved project decisions from silently becoming recurring interpersonal conflicts.
The project also distinguished normal professional disagreement from recurring implementation conflicts and relationship escalation. Existing agile formats remained in place; the conflict method was integrated into them.
Unser maßgeschneidertes Inhouse-Seminar für Sie!
Wählen Sie bei Ihrer Anfrage zwischen einem a) Inhouse-Präsenz-Seminar an Ihrem Standort, b) einem Inhouse-Online-Workshop mit Ihrem Team oder c) einem Inhouse-Präsenz-Kurs direkt an der Akademie – gern auch in Kombination mit Teambuilding-Aktionen.
Ähnliche Artikel:
- Case Study: IT-Teams im Dauerstress – wie ein Software-Unternehmen in München präventive Konfliktkompetenz aufbaute
- Case Study: Bauleitung im Streit – wie ein Bauunternehmen in Köln Projektleiter für Konflikte mit Subunternehmern stärkte
- Case Study: Geschäftsführung übernimmt Verantwortung – wie ein Mittelständler in Chemnitz Konfliktkompetenz auf Führungsebene verankerte
- Case Study: So schulte ein Industriekonzern aus Kiel seinen Betriebsrat zum Thema Konflikte
- Case Study: Wie ein Lebensmittelproduzent in Magdeburg Vorarbeiter für schwierige Alltagssituationen schulte
- Case Study: Wie eine Frankfurter Konzerntochter Außendienstler zu Kundenkonflikten schulte
