Diese Case Study zeigt, wie ein Software-Unternehmen in München in einer Inhouse Schulung präventive Konfliktkompetenz aufbaute, bevor Sprintdruck, Priorisierungsstreit und Dauerstress die IT-Teams dauerhaft belasteten.
IT-Teams geraten selten durch einen einzelnen Streit in Konflikt. Häufig entsteht Spannung schleichend: Tickets werden kurzfristig umpriorisiert, Bugs drängen in laufende Sprints, Product Owner erwarten schnelle Reaktion, Entwicklungsteams fordern realistische Zusagen, Support meldet Kundendruck, Führung möchte Planbarkeit und einzelne Entwicklerinnen und Entwickler erleben permanenten Kontextwechsel. Wenn diese Dynamik nicht früh geklärt wird, entsteht Dauerstress.
Diese Case Study beschreibt eine Inhouse-Schulung der Bildungsakademie am Rosental mit einem Software-Unternehmen in München. Ziel war nicht, ein bereits eskaliertes Teamproblem nachträglich zu reparieren. Ziel war präventive Konfliktkompetenz: IT-Teams sollten Reibungen früher erkennen, Priorisierungskonflikte sauberer besprechen, Rollen klarer unterscheiden, Spannungen in Reviews und Retrospektiven konstruktiver nutzen und schwierige Gespräche führen, bevor sie in Rückzug, Sarkasmus oder offene Eskalation kippen.
Der Projektbericht gehört zum Themenbereich Konflikte im Job lösen. Für Software-Unternehmen, IT-Abteilungen, Produktteams, Scrum Master, Product Owner, Tech Leads und Führungskräfte sind besonders die Kursrubrik Konfliktmanagement, die Kursrubrik Schwierige Gespräche & Feedback, die FAQ zu Konflikten im Job, das Magazin Konflikte im Job lösen und die Case Studies zu Konfliktmanagement passende Vertiefungen.
Unser maßgeschneidertes Inhouse-Seminar für Sie!
Wählen Sie bei Ihrer Anfrage auch gern 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 – das Inhouse-Training gern auch in Kombination mit Teambuilding-Aktionen.
Ausgangslage: Viel Tempo, viele Abhängigkeiten, wenig Konfliktklarheit
Das Software-Unternehmen in München entwickelte eine B2B-Plattform für mittelständische Kunden. Die Organisation arbeitete mit agilen Methoden, mehreren Produktlinien, verteilten Teams und einem hohen Anteil hybrider Zusammenarbeit. Fachlich war das Unternehmen stark aufgestellt. Gleichzeitig stieg die Belastung in den IT-Teams deutlich.
-
Der Dauerstress zeigte sich nicht nur in hoher Ticketzahl. Er zeigte sich in kurzen Antworten in Slack, gereizten Sprintplannings, unausgesprochenem Ärger über kurzfristige Prioritätswechsel, sinkender Bereitschaft zur gegenseitigen Unterstützung und einer wachsenden Trennung zwischen Produkt, Entwicklung, QA und Support. Niemand wollte eskalieren. Aber viele spürten: Die Art der Zusammenarbeit wurde anstrengender.
-
Besonders herausfordernd war, dass Konflikte in IT-Teams häufig sachlich wirken. Es geht um Architekturentscheidungen, technische Schulden, Release-Termine, Bugs, Kundenanforderungen, Security-Fixes, Refactoring oder Priorisierung. Hinter diesen Sachfragen liegen jedoch oft Beziehungsthemen: Wer wird gehört? Wessen Risiko zählt? Wer trägt die Last kurzfristiger Zusagen? Wer entscheidet, was wirklich dringend ist?
Konfliktbild: Dauerstress wurde als Sachproblem getarnt
Der zentrale Konflikt lag nicht in fehlender Fachkompetenz, sondern in wiederkehrenden Spannungen zwischen Priorisierung, Verantwortung, Kommunikation und Erwartungsdruck.
-
Im Vorgespräch mit Kay Schönewerk wurde schnell deutlich: Das Software-Unternehmen brauchte keine allgemeine Teambuilding-Maßnahme. Die Teams waren leistungsfähig, aber die Konfliktmuster wurden zu spät sichtbar. Reibungen wurden entweder technisch begründet, ironisch kommentiert oder in Retrospektiven zu vorsichtig angesprochen.
-
Typische Aussagen lauteten: „Das ist wieder ein Product-Thema“, „Development blockiert“, „Support versteht nicht, was im Sprint passiert“, „QA bekommt alles zu spät“, „Tech Debt interessiert nur uns“, „Prioritäten ändern sich täglich“ oder „Wir diskutieren immer wieder dieselben Punkte.“ Solche Sätze wirkten wie sachliche Einschätzungen, waren aber häufig bereits Konfliktsignale.
-
Der Trainingsansatz setzte deshalb präventiv an. Die Teams sollten lernen, Konflikte nicht erst bei Eskalation ernst zu nehmen, sondern bereits bei wiederkehrender Reibung, Rollenunklarheit, stiller Verärgerung und belastender Kommunikationsverdichtung.
Cluster-Einordnung: Präventives Konfliktmanagement für digitale Teams
Der Fall gehört fachlich in den Konfliktmanagement-Cluster der Bildungsakademie am Rosental. Im Mittelpunkt stand nicht akute Deeskalation nach einem offenen Streit, sondern präventive Konfliktkompetenz: Wie erkennt ein IT-Team früh, dass aus normaler fachlicher Reibung ein belastendes Konfliktmuster wird?
Damit unterscheidet sich diese Case Study von Konflikten im Maschinenbau oder in der Pflege. Dort entstanden Spannungen stark an Übergaben und Schichtgrenzen. Im Münchner Software-Unternehmen lagen die Konfliktzonen in Priorisierung, Sprintlogik, hybrider Kommunikation, Rollenklärung und Abhängigkeiten zwischen Produkt, Entwicklung, QA und Support.
Der Artikel ist deshalb im Bereich Case Studies Konflikte im Job lösen verankert und verweist auf den Themenhub Konflikte im Job lösen sowie auf die Kursrubriken Konfliktmanagement und Schwierige Gespräche & Feedback.
Stress- und Reibungsanalyse: Wo IT-Konflikte früh sichtbar wurden
Die Analyse zeigte sechs Frühindikatoren für IT-Konflikte: Prioritätswechsel, unklare Rollen, technische Schulden, Review-Spannungen, Supportdruck und hybride Missverständnisse.
Im ersten Projektschritt sammelten die Teilnehmenden keine Schuldzuweisungen, sondern typische Reibungsereignisse. Entscheidend war die Frage: Wo entsteht regelmäßig Spannung, obwohl alle fachlich gute Arbeit leisten wollen?
| Reibungspunkt | Typische Situation | Konfliktrisiko | Trainingsansatz |
|---|---|---|---|
| Priorisierung | Tickets werden während des Sprints neu bewertet | Entwicklung erlebt Zusagen als instabil | Prioritätsklärung mit Entscheidungslogik |
| Rollen | Product, Tech Lead, QA und Support erwarten Unterschiedliches | Verantwortung wird hin- und hergeschoben | Rollenklärung im Konfliktfall |
| Technische Schulden | Refactoring wird immer wieder verschoben | Fachlicher Ärger wird zu Beziehungsspannung | Risikosprache statt Frustsprache |
| Code Review | Rückmeldungen wirken persönlich oder abwertend | Lernen wird durch Verteidigung ersetzt | Feedbackregeln für Reviews |
| Supportdruck | Kundenprobleme drängen ungeplant ins Team | Support und Entwicklung werfen sich fehlendes Verständnis vor | Klärungsweg für Dringlichkeit und Wirkung |
| Hybridarbeit | Slack-Nachrichten ersetzen schwierige Gespräche | Ton und Kontext gehen verloren | Kanalregeln für Konfliktthemen |
Die Analyse machte sichtbar: Viele Spannungen waren vorhersehbar. Sie mussten nicht erst eskalieren, bevor sie bearbeitet werden konnten.
Trainingsdesign: Zwei Teams, drei Module, ein Transfer-Sprint
Das Inhouse-Training wurde als mehrstufiges Format aufgebaut. Beteiligt waren 18 Personen aus Entwicklung, QA, Product, Support, Scrum Master-Rollen, Tech Lead und Führung. Das Format bestand aus zwei halbtägigen Workshops, einem moderierten Konfliktlabor und einem vierwöchigen Transfer-Sprint.
Die erste Einheit behandelte Konfliktfrüherkennung. Die zweite Einheit trainierte schwierige Gespräche in agilen Arbeitsformaten. Das Konfliktlabor bearbeitete typische Szenen: Sprint Planning unter Druck, Code Review mit verletzender Wirkung, Support-Eskalation kurz vor Release, Product-vs-Development-Diskussion über Priorität und Retro, in der niemand das eigentliche Problem anspricht.
Der Transfer-Sprint stellte sicher, dass die Methode nicht als Workshopwissen liegen blieb. Die Teams probierten neue Regeln in Planning, Review, Retro, Slack und Eskalationsgesprächen aus. Nach vier Wochen wurden Wirkung und Grenzen ausgewertet.
BARO-IT-KONFLIKTRADAR: Früh erkennen, bevor Reibung eskaliert
Mit dem BARO-IT-KONFLIKTRADAR lernten die Teams, wiederkehrende Reibung anhand von vier Signalen zu erkennen: Wiederholung, Rollenunklarheit, verdeckter Ärger und Entscheidungsdruck.
Die zentrale Methode des Trainings war der BARO-IT-KONFLIKTRADAR. Er wurde für digitale Teams entwickelt, die Konflikte nicht immer offen austragen, sondern häufig über Tickets, Slack, Reviews, Retrospektiven oder Priorisierungsrunden ausdrücken.
| Signal | Leitfrage | Beispiel im IT-Team |
|---|---|---|
| Wiederholung | Kommt dieselbe Reibung mehrfach zurück? | Prioritätswechsel wird in jeder Retro angesprochen |
| Rollenunklarheit | Ist unklar, wer entscheidet oder verantwortet? | Product erwartet Umsetzung, Tech Lead sieht Architektur-Risiko |
| Verdeckter Ärger | Wird Ärger indirekt, ironisch oder still ausgedrückt? | Slack-Kommentare werden kürzer und schärfer |
| Entscheidungsdruck | Muss schnell entschieden werden, obwohl Risiken unklar sind? | Bugfix verdrängt Sprintziel kurz vor Release |
Der BARO-IT-KONFLIKTRADAR half, Konflikte früher zu benennen, ohne sie aufzublasen. Nicht jede Reibung ist ein Konflikt. Aber wiederkehrende Reibung mit Rollenunklarheit und Entscheidungsdruck braucht Klärung, bevor sie Vertrauen beschädigt.
Priorisierungsgespräche: Aus Druck wurde Entscheidungslogik
Ein Schwerpunkt lag auf Priorisierungsgesprächen. In Softwareteams ist Priorisierung selten nur eine Reihenfolge von Tickets. Sie ist eine Konfliktzone zwischen Kundendruck, technischer Stabilität, Produktstrategie, Teamkapazität und Lieferzusage.
Die Teams übten, Priorisierung nicht als Machtfrage zu behandeln, sondern als Entscheidung mit Kriterien. Statt „Das muss sofort rein“ oder „Das geht nicht“ wurden vier Fragen eingeführt: Was ist der Kundennutzen? Welches Risiko entsteht bei Verschiebung? Welche Arbeit wird verdrängt? Wer entscheidet nach welchen Kriterien?
Diese Fragen machten Diskussionen nicht konfliktfrei, aber transparenter. Product Owner konnten Dringlichkeit klarer begründen. Entwicklung konnte Risiken sichtbarer machen. Führung konnte entscheiden, ohne verdeckte Belastung zu erzeugen.
Code Review und Feedback: Fachliche Härte ohne persönliche Schärfe
Ein zweiter Schwerpunkt war Feedback in Code Reviews. Reviews sind fachlich notwendig, können aber schnell persönlich wirken. Besonders unter Zeitdruck werden Kommentare knapp, direkt oder ironisch. Das kann Lernprozesse blockieren und Beziehungsspannung erzeugen.
Im Training wurden Review-Kommentare in drei Kategorien sortiert: fachliche Anforderung, Verständlichkeitsfrage und Risikohinweis. Aus „Das ist viel zu kompliziert“ wurde zum Beispiel: „Ich sehe hier ein Wartbarkeitsrisiko, weil die Logik an drei Stellen verteilt ist. Können wir die Verantwortung bündeln?“
Die Teams entwickelten eine Review-Regel: hart in der Sache, präzise im Risiko, respektvoll im Ton. Dadurch blieb Qualitätssicherung möglich, ohne dass Rückmeldungen als persönliche Abwertung wirken mussten.
Hybrid-Kommunikation: Wann Slack nicht mehr reicht
Viele Reibungen im Unternehmen wurden digital sichtbar. Slack war schnell, niedrigschwellig und effizient. Gleichzeitig wurden schwierige Themen zu oft schriftlich verhandelt: Priorität, Verantwortung, Enttäuschung, Fehlverhalten, Überlastung oder wiederholte Störung.
Im Training entwickelte das Team einfache Kanalregeln. Sachliche Statusfragen bleiben in Slack. Kurze Rückfragen bleiben im Ticket. Wiederholte Reibung, persönliche Irritation, Prioritätskonflikt oder Tonfallproblem wechseln in ein Gespräch. Nach dem Gespräch wird nur das Ergebnis kurz dokumentiert.
Diese Regel reduzierte Missverständnisse. Sie machte deutlich: Nicht jedes Problem braucht ein Meeting. Aber nicht jedes Konfliktthema gehört in einen Chatverlauf.
Rollenklärung: Product, Tech Lead, QA und Support nicht gegeneinanderstellen
In mehreren Übungen zeigte sich, dass Rollenbilder Teil des Konfliktmusters waren. Product wurde als treibend erlebt, Entwicklung als bremsend, QA als kritisch und Support als drängend. Diese Rollenbilder vereinfachten die Wirklichkeit und verschärften Konflikte.
Kay Schönewerk arbeitete mit den Teams an einer Rollenklärung für Konfliktmomente. Product bringt Kundennutzen und Priorität ein. Entwicklung bringt technische Machbarkeit und Architekturfolgen ein. QA bringt Qualitätsrisiken und Testbarkeit ein. Support bringt aktuelle Kundenwirkung ein. Führung entscheidet, wenn Zielkonflikte nicht im Team aufgelöst werden können.
Dadurch wurde aus einem Gegeneinander ein strukturierter Abgleich. Unterschiedliche Perspektiven wurden nicht als Störung behandelt, sondern als notwendige Information für bessere Entscheidungen.
Transferstimme: Warum Konflikte früher sichtbar wurden
Die folgende Stimme aus der internen Transferauswertung ist bewusst nicht als Review formuliert. Sie dokumentiert den wichtigsten Lernpunkt des Software-Unternehmens.
„Vor dem Training haben wir viele Konflikte als normale Sprint-Reibung abgetan. Danach konnten wir besser unterscheiden: Ist das nur eine fachliche Diskussion, oder sehen wir ein Muster aus Rollenunklarheit, Ärger und Entscheidungsdruck? Das hat uns geholfen, früher zu klären, statt in der Retro wieder denselben Frust zu sammeln.“
Team Lead Engineering, Software-Unternehmen in München
Die Aussage zeigt den Kern des Projekts. Das Ziel war nicht, Konflikte zu vermeiden. Das Ziel war, sie früher, präziser und weniger persönlich zu bearbeiten.
Ergebnisse nach sechs Wochen: Mehr Klärung, weniger stille Verärgerung
Sechs Wochen nach dem Training nutzte das Software-Unternehmen den BARO-IT-KONFLIKTRADAR, klarere Priorisierungsfragen, Review-Regeln und Kanalwechsel für konflikthafte Themen.
Die Teams berichteten nicht von einem stressfreien Arbeitsalltag. Release-Druck, Kundenthemen und technische Abhängigkeiten blieben bestehen. Verändert hatte sich jedoch der Umgang mit Reibung. Konflikte wurden früher benannt und weniger als persönliches Problem einzelner Rollen verstanden.
| Bereich | Vor dem Training | Nach sechs Wochen | Nutzen |
|---|---|---|---|
| Priorisierung | häufige Diskussion über Dringlichkeit | vier Entscheidungsfragen eingeführt | mehr Transparenz bei Zielkonflikten |
| Retrospektiven | wiederkehrender Frust ohne Klärung | Konfliktmuster gezielter benannt | mehr Wirksamkeit im Teamlernen |
| Code Reviews | Feedback teils als persönlich erlebt | Risikohinweise klarer formuliert | weniger Verteidigung |
| Slack-Kommunikation | Konfliktthemen schriftlich verlängert | Kanalwechsel-Regel eingeführt | weniger Missverständnisse |
| Rollen | Product, Development, QA und Support teils gegeneinander | Perspektiven als Entscheidungsbeiträge geklärt | weniger Rollenbilder |
| Führung | Eskalation oft spät oder informell | Entscheidungsdruck früher sichtbar | klarere Führungsentscheidungen |
Der wichtigste Fortschritt lag in der Prävention. Konflikte mussten nicht erst laut, verletzend oder lähmend werden. Die Teams hatten eine gemeinsame Sprache, um Reibung früher zu sortieren.
Grenzen: Was präventive Konfliktkompetenz nicht lösen kann
Präventive Konfliktkompetenz kann IT-Teams entlasten, ersetzt aber keine realistische Roadmap, keine ausreichende Personalplanung und keine klaren Produktentscheidungen.
Im Training wurde offen benannt, dass Kommunikation keine strukturellen Engpässe wegmoderieren darf. Wenn dauerhaft zu viele parallele Projekte laufen, wenn technische Schulden ignoriert werden, wenn Supportdruck ständig Sprintziele verdrängt oder wenn Führung Prioritäten offen lässt, entstehen Konflikte zwangsläufig.
Deshalb sammelten die Teams nicht nur Gesprächsregeln, sondern auch strukturelle Klärungspunkte: Wer darf Prioritäten ändern? Welche Kriterien gelten bei Bugfixes kurz vor Release? Wann wird technische Schuld sichtbar gemacht? Welche Konflikte gehören ins Team, welche in Führung, welche in Produktstrategie?
Diese Grenze machte das Training glaubwürdig. Konfliktkompetenz bedeutet nicht, unter unrealistischen Bedingungen gelassener zu wirken. Sie bedeutet, Reibung früher sichtbar zu machen und sauber zwischen Kommunikation, Entscheidung und Strukturproblem zu unterscheiden.
Fachliche Leitplanken: Digitaler Stress, psychische Belastung und Teamnormen
Das Training wurde fachlich durch arbeitsbezogene und softwarebezogene Quellen gestützt. Die BAuA beschreibt digitalen Stress als Faktor, der mit Erschöpfung, Gereiztheit und psychischen Beeinträchtigungen zusammenhängen kann. Für IT-Teams ist das relevant, weil digitale Arbeit, ständige Unterbrechung, Tool-Kommunikation und hohe Reaktionsgeschwindigkeit den Arbeitsalltag prägen.
Die DGUV weist darauf hin, dass psychische Belastungen im Rahmen der Gefährdungsbeurteilung betrachtet werden müssen. Ergänzend betont INQA, dass Konflikte im Team dazugehören und konstruktiv bearbeitet werden sollten.
Für den IT-Kontext wurden außerdem der Bitkom-Studienbericht zum IT-Arbeitsmarkt und Forschung zu psychologischer Sicherheit und Normklarheit in Software-Engineering-Teams berücksichtigt. Gerade Normklarheit war im Projekt wichtig: Teams brauchen nicht nur psychologische Sicherheit, sondern auch klare Regeln, wie Prioritäten, Reviews, Konflikte und Kanalwechsel gehandhabt werden.
Interne Orientierung im Konfliktmanagement-Cluster der Bildungsakademie
Diese Case Study ergänzt den Themenhub Konflikte im Job lösen, weil sie präventives Konfliktmanagement in digitalen Teams zeigt. Der Fall unterscheidet sich von Schichtkonflikten im Maschinenbau oder Pflegekonflikten im Klinikalltag, weil Reibung hier vor allem über Priorisierung, Ticketlogik, Rollen, Reviews und hybride Kommunikation sichtbar wurde.
Als fachliche Vertiefung eignen sich die Kursrubrik Konfliktmanagement, die Kursrubrik Schwierige Gespräche & Feedback, die FAQ zu Konflikten im Job und das Magazin Konflikte im Job lösen.
Als direkte Vergleichsberichte eignen sich die Case Study Konfliktmanagement im Maschinenbau und die Case Study Pflegekonflikte im Klinikalltag. Während dort Übergaben und Schichtlogik im Mittelpunkt standen, zeigt der Münchner IT-Fall, wie Konflikte in digitalen Arbeitsformen früh erkannt werden können.
Durchführende Person im Projekt
Kay Schönewerk als fachlicher Leiter für präventive Konfliktkompetenz in IT-Teams
Das Inhouse-Training wurde fachlich von Kay Schönewerk verantwortet und im Projektkontext als präventives Konfliktmanagement-Format für digitale Teams entwickelt.
Für dieses Projekt war entscheidend, dass Konfliktkompetenz nicht erst bei Eskalation ansetzt, sondern bereits bei wiederkehrender Reibung, Rollenunklarheit und Entscheidungsdruck.
Der Trainingsansatz berücksichtigte die besonderen Anforderungen von Software-Unternehmen: Sprintdruck, Priorisierungen, hybride Kommunikation, Rollen zwischen Product und Development, Review-Kultur, Supportdruck und Führung bei Zielkonflikten.
Zu den Schwerpunkten gehörten Konfliktfrüherkennung, schwierige Gespräche, Feedback, Rollenklärung, Führung in Konflikten, Teamnormen und Transfermethoden für Arbeitsumgebungen mit hoher digitaler Verdichtung.
FAQ zur Case Study: Präventive Konfliktkompetenz in IT-Teams
Warum brauchte das Software-Unternehmen in München präventive Konfliktkompetenz?
Das Software-Unternehmen brauchte präventive Konfliktkompetenz, weil Dauerstress, Prioritätswechsel und Rollenunklarheit wiederkehrende Reibung in den IT-Teams erzeugten.
Es gab keinen einzelnen Großkonflikt, sondern viele kleine Spannungen, die sich im Arbeitsalltag verdichteten.
Besonders belastend waren kurzfristige Sprintänderungen, Review-Spannungen, Supportdruck und hybride Missverständnisse. Das Training half, diese Signale früher zu erkennen.
Was ist der BARO-IT-KONFLIKTRADAR?
Der BARO-IT-KONFLIKTRADAR ist eine Methode zur Früherkennung von Konflikten in digitalen Teams anhand von Wiederholung, Rollenunklarheit, verdecktem Ärger und Entscheidungsdruck.
Die Methode hilft IT-Teams, Reibung früher zu sortieren, bevor sie in Rückzug, Sarkasmus oder Eskalation kippt.
Sie wurde im Projekt genutzt, um wiederkehrende Konflikte in Sprintplanung, Reviews, Retrospektiven, Slack-Kommunikation und Priorisierungsgesprächen sichtbar zu machen.
Welche Konfliktfelder wurden im IT-Team identifiziert?
Identifiziert wurden Prioritätswechsel, unklare Rollen, technische Schulden, Code-Review-Spannungen, Supportdruck und Missverständnisse in hybrider Kommunikation.
Diese Konfliktfelder wirkten zunächst sachlich, hatten aber deutliche Beziehungseffekte.
Wenn dieselben Themen immer wieder auftauchen, entsteht nicht nur fachliche Reibung, sondern auch Vertrauensverlust zwischen Rollen und Teams.
Welche Personen nahmen am Training teil?
Am Training nahmen 18 Personen aus Entwicklung, QA, Product, Support, Scrum Master-Rollen, Tech Lead und Führung teil.
Diese Mischung war wichtig, weil IT-Konflikte häufig an Schnittstellen entstehen.
Nur wenn Product, Development, QA und Support gemeinsam arbeiten, lassen sich Priorisierungskonflikte und Rollenbilder präventiv bearbeiten.
Wie half das Training bei Priorisierungskonflikten?
Das Training half, Priorisierungskonflikte mit vier Fragen zu klären: Kundennutzen, Risiko bei Verschiebung, verdrängte Arbeit und Entscheidungsverantwortung.
Priorisierung wurde dadurch weniger als Machtfrage und stärker als transparente Entscheidung behandelt.
Product konnte Dringlichkeit klarer begründen, Entwicklung konnte technische Risiken sichtbarer machen und Führung konnte gezielter entscheiden.
Wie wurden Code Reviews konfliktärmer gestaltet?
Code Reviews wurden konfliktärmer, indem Feedback als fachliche Anforderung, Verständlichkeitsfrage oder Risikohinweis formuliert wurde.
Die Regel lautete: hart in der Sache, präzise im Risiko, respektvoll im Ton.
Dadurch blieb Qualitätssicherung möglich, ohne dass Rückmeldungen als persönliche Abwertung verstanden wurden.
Welche Rolle spielte hybride Kommunikation?
Hybride Kommunikation spielte eine große Rolle, weil viele Konflikte über Slack, Tickets und kurze digitale Rückmeldungen sichtbar wurden.
Das Training führte Kanalregeln ein: Sachfragen bleiben schriftlich, konflikthafte Themen wechseln ins Gespräch.
So wurden Missverständnisse reduziert, ohne die Effizienz digitaler Kommunikation aufzugeben.
Was war das wichtigste Ergebnis des Trainings?
Das wichtigste Ergebnis war eine gemeinsame Sprache für frühe Konfliktsignale und klare Regeln für Priorisierung, Reviews, Kanalwechsel und Rollenklärung.
Die Teams warteten nicht mehr, bis sich Konflikte in der Retrospektive stauten.
Sie konnten früher unterscheiden, ob es um ein Sachthema, Rollenunklarheit, Entscheidungsdruck oder ein Beziehungsmuster ging.
Wie schnell wurden erste Ergebnisse sichtbar?
Erste Ergebnisse wurden innerhalb von sechs Wochen sichtbar, weil die Teams neue Fragen, Review-Regeln und Kanalwechsel direkt im Arbeitsalltag testeten.
Der Dauerstress verschwand nicht, aber Reibung wurde schneller besprechbar.
Besonders hilfreich waren der BARO-IT-KONFLIKTRADAR und die Priorisierungsfragen im Sprintalltag.
Welche Grenzen hatte das Training?
Das Training konnte Konfliktkompetenz stärken, aber keine unrealistische Roadmap, keinen Personalmangel und keine unklaren Produktentscheidungen allein lösen.
Diese Grenze wurde offen benannt, damit Kommunikationsarbeit nicht strukturelle Engpässe verdeckt.
Konfliktkompetenz half, Probleme früher sichtbar zu machen. Entscheidungen über Kapazität, Roadmap und Prioritäten blieben Führungsaufgabe.
Für welche Unternehmen eignet sich dieser Ansatz?
Der Ansatz eignet sich für Software-Unternehmen und IT-Abteilungen, die unter Sprintdruck, Priorisierungsstreit, hybrider Kommunikation und Rollenunklarheit leiden.
Besonders sinnvoll ist er, wenn Teams leistungsfähig sind, aber wiederkehrende Reibung zunehmend Energie bindet.
Der sichere Einstieg beginnt mit Konfliktfrüherkennung, Rollenklärung, Priorisierungslogik, Review-Regeln und Kanalwechseln.
Warum gehört der Fall in den Konfliktmanagement-Cluster?
Der Fall gehört in den Konfliktmanagement-Cluster, weil präventive Konfliktkompetenz, Rollenklärung und wiederkehrende Arbeitskonflikte im Mittelpunkt standen.
Es ging nicht um akute Deeskalation, sondern um frühe Bearbeitung von Reibung in digitalen Teams.
Die Case Study zeigt, wie Konflikte im Job bereits vor der offenen Eskalation erkannt und bearbeitet werden können.
Warum dieser Projektbericht exemplarisch für die Arbeit der Bildungsakademie ist
Diese Case Study ist exemplarisch für die Arbeit der Bildungsakademie am Rosental, weil sie Konfliktmanagement nicht erst bei eskalierten Auseinandersetzungen ansetzt. Der Münchner Fall zeigt, wie Teams präventiv handlungsfähig werden, wenn Reibung noch als Sprintdruck, Review-Spannung oder Prioritätsdiskussion erscheint.
Die Bildungsakademie verbindet in solchen Projekten Konfliktfrüherkennung, schwierige Gespräche, Rollenklärung, Feedback, Führungskommunikation und Transfer in bestehende Arbeitsformate. Gerade in IT-Teams ist diese Verbindung entscheidend, weil Konflikte nicht immer laut auftreten, sondern oft in Tickets, Chatverläufen, Reviews und Retrospektiven sichtbar werden.
Zusammenfassung: Das Software-Unternehmen machte Konflikte früher besprechbar
Die Case Study zeigt, wie ein Software-Unternehmen in München präventive Konfliktkompetenz aufbaute, bevor Dauerstress und Priorisierungsstreit die IT-Teams dauerhaft belasteten.
Der Erfolg entstand durch klare Arbeitsinstrumente: Reibungsanalyse, BARO-IT-KONFLIKTRADAR, Priorisierungsfragen, Review-Regeln, Kanalwechsel für konflikthafte Themen und Rollenklärung zwischen Product, Development, QA, Support und Führung.
Für andere Software-Unternehmen und IT-Abteilungen ist der Ansatz wertvoll, weil er Konfliktmanagement direkt in agile Arbeitsformate übersetzt. Eine praxisnahe Inhouse-Schulung zu Konfliktmanagement kann helfen, Reibung früher zu erkennen, schwierige Themen klarer zu besprechen und digitale Teams arbeitsfähig zu halten.
English Summary
How a Munich software company built preventive conflict competence in IT teams
This case study describes how a Munich software company used an in-house conflict management training to build preventive conflict competence in IT teams.
The project focused on sprint pressure, prioritization conflicts, unclear roles, code review tensions, support pressure, hybrid communication and early conflict signals.
The company did not wait for a major escalation. It introduced the BARO-IT-KONFLIKTRADAR, a method for detecting recurring friction through repetition, role ambiguity, hidden frustration and decision pressure. Six weeks later, teams used clearer prioritization questions, review rules, channel-switching routines and role clarification to address conflicts earlier and more constructively.
Unser maßgeschneidertes Inhouse-Seminar für Sie!
Wählen Sie bei Ihrer Anfrage auch gern 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 – das Inhouse-Training gern auch in Kombination mit Teambuilding-Aktionen.
Ähnliche Artikel:
- Case Study: Pflegekonflikte im Klinikalltag – wie ein Klinikverbund nahe Dresden Stationsteams für Reibung, Druck und Übergaben stärkte
- Case Study: Konfliktmanagement im Maschinenbau – wie ein Zulieferer in Stuttgart Spannungen zwischen Schichtteams löste
- Case Study: Konflikte am Empfang – wie eine Hotelkette in Hamburg Front-Office-Teams auf schwierige Gästesituationen vorbereitete
- Case Study: Spannungen zwischen Disposition & Fahrern – wie eine Bremer Spedition sich nach Kurs neu strukturierte
