Effektive Kommunikation in Scrum und der agilen Softwareentwicklung

Eine effektive Kommunikation bedeutet stets zu gestalten. Scrum Teams gestalten stets [6, S. 25], um so effektiv ein Produkt und die Incremente eines Produktes [6, S. 146] in kurzen, iterativen, ein‑ bis vierwöchigen Arbeitszyklen [6, S. 12, 22], sogenannten Sprints [6, S. 60–61] [38, S. 8] zu gestalten (siehe Abb. 1).

Gestalten bedeutet nach Patrice Ras zu verhandeln, zu überzeugen, die Dinge in die Hand zu nehmen und Vorschläge zu machen [33, S. 45]. In einem Scrum Team [6, S. 47–49] sind die drei Rollen Scrum Master:in [38, S. 7], Product Owner:in [38, S. 6] und Developer:innen [38, S. 6] stets gestalterisch mit den Stakeholder:innen am Werk.

Innerhalb eines Scrum Teams sollte eine nach Anne van Stappen [43, S. 23–24] und Stephen R. Covey [13, S. 100] proaktive und nach Patrice Ras gestalterische Einstellung (gesunde und klare Vorschläge machen, überzeugen, Dinge in die Hand nehmen, verhandeln, [33, S. 45] und ehrlich seine Meinung, Wünsche und Gefühle frei äußern, ohne den anderen anzugreifen [33, S. 39–40]) eingenommen werden, welche in ein‑ bis vierwöchigen Sprints [6, S. 60–61] effektiv zu mehr Sprint-Ergebnissen [6, S. 63] führt (siehe Abb. 1), da Energie durch geistige Neigungen wie Vergleichen, Konkurrieren, Klagen und Kritisieren, kurz Reaktivität, nach Anne van Stappen [43, S. 23–24] und Stephen R. Covey [13, S. 100] gespart wird. Proaktivität bedeutet nach Anne van Stappen [43, S. 23–24] und Stephen R. Covey [13, S. 100], sich selbst wahrzunehmen, sich klar bewusst zu werden, was in einem vorgeht, was man selbst als Scrum Master:in [38, S. 7], Product Owner:in [38, S. 6], Developer:in [38, S. 6] sowie Stakeholder:in [38] will oder wonach man selbst strebt (bspw. soziale Anerkennung, Sicherheit und Geborgenheit, Vertrauen, Selbstachtung, Unabhängigkeit und Verantwortung nach Werner Correll [12, S. 47–66]), den Mut zu haben es auszudrücken und Verständnis für den anderen, Scrum Master:in, Product Owner:in, Developer:in sowie Stakeholder:in zu haben [43, S. 24].

Patrice Ras [33, S. 39–40] unterscheidet nach Dominique Chalvin bspw. [8] in drei bzw. vier Kommunikationsarten (siehe Tab. 2): Aggression/Domination, Manipulation, Flucht und Selbstbehauptung. Die Kommunikationsform der Selbstbehauptung ist effektiver in einem Scrum Team mit Stakeholder:innen, da dadurch langfristige und nach Patrice Ras gesunde Beziehungen entstehen können [33, S. 40, 45], welche weniger Konflikte während der Sprints aufweisen und Ressourcen schonen. Im Rahmen zunehmender Frustrationen und gesundheitlicher Herausforderungen erscheint die Kommunikation der Selbstbehauptung dem Autor auch als gesundheitsförderlich [15]. Es gibt nach Patrice Ras vier verschiedene Beziehungstypen [33, S. 45–46] zwischen Sender-Empfänger (siehe Abb. 2) welche in Scrum und der agilen Softwareentwicklung miteinander kommunizieren. Wie in Abb. 2 zu sehen, ist das Dominieren eine ineffektive überstarke Kommunikation und basiert auf Gewalt nach Patrice Ras [33, S. 45–46] welche spürbar beim Gegenüber im Scrum Team und Stakeholder:innen ankommt und eher den Wunsch nach zukünftiger Vergeltung hervorruft (nach Patrice Ras und Dominique Chalvin [33, S. 39–40, 8]) und Verletzungen (ob physisch oder psychisch [15]) verursacht, statt Wert in einen agilen Softwareprojekt zu schaffen. Das Manipulieren, eine schwache Kommunikation nach Patrice Ras [33, S. 45–46] entspricht einer indirekten nach Patrice Ras [33S. 45–46] und unbemerkten Beeinflussung nach Patrice Ras und Dominique Chalvin [33, S. 39–40, 8] und führt sofern die Manipulation entdeckt wird zum Vertrauensverlust innerhalb des Scrum Teams und zwischen Stakeholder:innen (nach Patrice Ras und Dominique Chalvin [33, S. 39–40, 8]). Das Fliehen ermöglicht keine Kommunikation und Schaffung von Wert in Scrum und der agilen Softwareentwicklung. Nur das Gestalten entspricht eine direkten Kommunikation und schafft langfristig und auf Dauer Wert um das Sprint-Ziel während des Sprints zu erreichen.

Dominatoren (oder Aggressoren) zwingen einem Dinge auf, sie provozieren, sie kritisieren, sie beleidigen und sie setzen Menschen im Scrum Team und Stakeholder:innen herab (nach Patrice Ras [33, S. 39, 45]). Dominatoren sind nach Patrice Ras überstark und kommunizieren auf der Basis eines ungleichen Kräfteverhältnisses [33, S. 45] im Scrum Team und Stakeholder:innen. Dominatoren bedienen sich nach Patrice Ras einer Neandertalerkommunikation und Kommunikation der Barbaren [33, S. 45] im Scrum Team und Stakeholder:innen. Für ein gesundes, nachhaltiges Scrum Team [38, S. 5] mit Stakeholder:innen sind Dominatoren nicht geeignet, ob als Scrum Master:in [38, S. 7], Product Owner:in [38, S. 6], Developer:innen [38, S. 6] oder Stakeholder:innen [38], weil durch ihre Domination und Aggression nach Patrice Ras [33, S. 39] ein stetiger Wunsch nach Vergeltung im Scrum Team und den Stakeholder:innen vorherrscht, was Energie, Zeit, Freude und weitere Ressourcen kostet und den Sprint-Erfolg gefährdet.

Manipulatoren nach Patrice Ras [33, S. 39, 45] täuschen, beeinflussen indirekt und unbemerkt, lügen, lassen Informationen weg, verbergen, was sie wollen, wecken Schuldgefühle (als sogenannte Schuldeinflüsterer nach Thalmann [42, S. 12]; machen andere für ihr Denken, Tun, Sagen und Fühlen verantwortlich nach Thalmann [42, S. 12, 38]) und erpressen nach Patrice Ras Menschen [33, S. 39, 45] im Scrum Team und Stakeholder:innen. Manipulatoren sind schwach nach Patrice Ras [33, S. 45] im Scrum Team und Stakeholder:innen. Manipulatoren sind nach Petitcollin krankhaft frustriert und unzufrieden [30, S. 60] im Scrum Team und Stakeholder:innen. Diese:r Scrum Master:in, Product Owner:in und Developer:innen oder Stakeholder:innen verdrehen nach Petitcollin [30, S. 60] die Tatsachen und tendieren zu verbaler, psychischer, körperlicher und oft auch sexueller Gewalt.

Manipulatoren spielen nach Petitcollin Psychospiele im Dramadreieck (siehe Abb. 3) der drei Rollen Täter/Verfolger, Retter und Opfer wie ein Profi [30, S. 60] im Scrum Team und Stakeholder:innen. Die einzige Möglichkeit für den Umgang mit solchen Menschen in Scrum Teams und bei Stakeholder:innen ist nach Petitcollin zu fliehen [30, S. 61] oder nach dem Autor, sie aus einem Scrum-Team zu entfernen.

Flucht bei einem Konflikt oder einer Konfrontation ermöglicht nach Patrice Ras [33, S. 39–40, 45] keine Kommunikation im Scrum Team und mit Stakeholder:innen mehr. Bei der Angst vor einer Konfrontation oder einem Konflikt, der Schwierigkeit, nein zu sagen [43] oder Schuldgefühlen [42] sollte nach Anne van Stappen [43, S. 59] und Patrice Ras[33, S. 39–40, 45] Gestaltung oder gesunde Selbstbehauptung im Scrum Team und Stakeholder:innen geübt werden und sich bei Schuldgefühlen bewusst gemacht werden, dass nach Thalmann [42, S. 40] jeder für sein Denken, Fühlen, Sagen und Handeln zu 100 % im Scrum Team und Stakeholder:innen selbst verantwortlich und nach Thalmann [42, S. 40] für Beziehungen in Scrum in der agilen Softwareentwicklung mitverantwortlich ist.

Gestalter (oder Selbstbehaupter) hingegen äußern dagegen nach Patrice Ras ehrlich ihre Gefühle, Wünsche [33, 39], User Stories [6, S. 81–82] oder Anforderungen [6, S. 95–96] und Meinungen, ohne den anderen anzugreifen, was für uns die effektivste Kommunikation in einem Scrum Team und mit Stakeholder:innen darstellt.

Gestalter kommunizieren nach Patrice Ras gesund und klar [33, 45] im Scrum Team und zwischen Stakeholder:innen. Gestalter handeln und wählen ihre Worte nach Patrice Ras [33, S. 39] als verantwortliche (wie es auch in Scrum gewollt ist: [6, S. 44, 46, 38, S. 7]), ebenbürtige Erwachsene, Scrum Teammitglieder und Stakeholder:innen. Sie machen nach Patrice Ras [33, S. 45] Vorschläge, nehmen die Dinge in die Hand, verhandeln und überzeugen im Scrum Team und Stakeholder:innen. Die Kommunikation bei Gestaltern (oder Selbstbehauptern) ist nach Patrice Ras [33, S. 40] gesund und klar und somit effektiv, um gesunde und langfristige Beziehungen in einem Scrum Team und Stakeholder:innen zu ermöglichen und dadurch nicht aufgrund ungesunder und unklarer Kommunikation Teammitglieder auszutauschen oder ersetzen zu müssen.

Erfolg oder Versagen bei der Gestaltung und Selbstbehauptung in Scrum und der agilen Softwareentwicklung hängt nicht vom Können, sondern nach Anne van Stappen von Übung und Anstrengung ab [43, S. 59], wie auch nach Hemmings et al. [18, S. 172–173] das Lernen oder nach dem Autor das Erlernen von neuen Fähigkeiten [14]. Wenn eine Meinung gesund und klar frei geäußert werden kann, dann kann verschiedenartig kommuniziert und gesprochen werden im Scrum Team und zwischen Stakeholder:innen.

Sprache bzw. Kommunikation kann nach Szudek et al. [2, S. 236–237] differenziert werden in eine Behauptung (Aussage zu einer Tatsache oder Überzeugung, meist ohne Nachweis für die Bestätigung der Wahrheit), Frage (mündliche oder schriftliche Äußerung, um Informationen zu erhalten), Befehl (jemanden bewegen, etwas zu tun), Vorhersage (eine Vorhersage/Aussage, was womöglich in Zukunft zu einer bestimmten Zeit passiert), Erklärung (Begründung für etwas Vergangenes und des Warums) und schließlich in ein Argument (Reihe von Sätzen/Prämissen Gründen mit Schlussfolgerung) im Scrum Team und Stakeholder:innen. Insbesondere wenn argumentiert, überzeugt wird, muss zwischen deduktiver und induktiver Argumentation nach Szudek et al. [2, S. 242–243, S. 244–245] unterschieden werden, um an Glaubwürdigkeit als Scrum Master:in [38, S. 7], Product Owner:in [38, S. 6], Developer:in [38, S. 6] sowie Stakeholder:in [38] zu gewinnen, weil Unterscheidungsmerkmale und Charakteristika verstanden werden.

Ein deduktives Argument ist nach Szudek et al. [2, S. 240–241] eine Behauptung auf Basis von Gründen, Prämissen im Scrum Team und Stakeholder:innen. Ein Argument kann nach Szudek et al. [2, S. 240–241] nach gut/schlecht und solide evaluiert werden, indem geprüft wird, ob eine Behauptung/Schlussfolgerung auf der Basis von Prämissen/Gründen folgt (gutes Argument) und ob die Prämissen wahr sind, das Argument solide im Scrum Team und Stakeholder:innen ist (Beispiele: Im Sprint wird die Timebox [2, S. 62] des Scrum Events nicht eingehalten, die User-Stories sind nicht komplett bearbeitet, das Sprint-Ziel [6, S. 64–65] ist nicht erreicht). Sofern nach Szudek et al. [2, S. 244] die Prämissen eines guten deduktiven Arguments wahr sind, so ist die Schlussfolgerung auch wahr im Scrum Team und Stakeholder:innen. Bei induktiven Argumenten muss nach Szudek et al. [2, S. 244–245] die Schlussfolgerung – obwohl die Prämissen wahr sind – nicht konsequenterweise wahr sein, sie kann vielmehr stark (Konklusion/Schlussfolgerung glaubhaft), moderat (Konklusion/Schlussfolgerung möglich) oder schwach (Konklusion/Schlussfolgerung unwahrscheinlich), d. h. wahrscheinlich wahr oder nicht wahr, sein im Scrum Team und Stakeholder:innen. Induktive Argumente basieren nach Szudek et al. [2, S. 244] auf Behauptungen statt auf Gründen im Scrum Team und Stakeholder:innen.

Induktive Argumente sind nach Szudek et al. [2, S. 244–245]: induktive Generalisierung (aus der Vergangenheit folgt die Zukunft), kausale Generalisierung (ein Ding/Ereignis verursacht das andere), Autoritätsargument (durch eine Autorität soll das Argument überzeugender sein; Beispiel: Ein:e zertifizierte:r Scrum Master:in² führt Scrum ein. Die Einführung [6, S. 45] von Scrum wird ein Erfolg.), Analogieargument (eine Behauptung basiert auf Ähnlichkeiten) und abduktives Argument im Scrum Team und Stakeholder:innen. Um ein induktives Argument zu evaluieren, benötigt ein Scrum Master:in, Product Owner:in oder Developer:in und Stakeholder:in nach Szudek et al. [2, S. 244–245] Hintergrundinformationen. Ein deduktives Argument kann mit A‑priori-Wissen, Verständnis der Wörter nach Szudek et al. [2, S. 244–245] im Scrum Team und Stakeholder:innen evaluiert werden.

Jeder Einzelne in einem Scrum Team und jeder Stakeholder:in ist stets verantwortlich [6, S. 46] für seine Worte, Taten, Gefühle und Denken sowie mitverantwortlich für eine gesunde Beziehung untereinander nach Yves-Alexandre Thalmann [42, S. 40], in der nach Patrice Ras [33, 46–47] und Jacques Salomé (Methode: ESPERE von Jacques Salomé [37, 46]) mit den anderen von sich gesprochen wird (Ich-Kommunikation). Als Gestalter (oder Selbstbehaupter) sollte bei Aussagen im Daily Scrum Meeting [6, S. 124–125] das Wort Ich benutzt werden, um von seinen Sprintergebnissen (Projektergebnissen) [6, S. 60–61] mit den anderen zu sprechen [33, S. 47]. Es sollte vermieden werden, wie Dominatoren (oder Aggressoren) es gerne tun, das Du zu verwenden, um nicht über die Sprintergebnisse des anderen zu sprechen [33, S. 47]. Manipulatoren dagegen verwenden gerne das Wort Man, um für die anderen und deren Sprintergebnisse zu sprechen [33, S. 47].

Gestalten bedeutet zu kommunizieren nach Patrice Ras [33, S. 39]. In der Kommunikation während der Gestaltung im Scrum Team und Stakeholder:innen, in der eine Win-Win-Lösung angestrebt wird, sollte nach Thomas Gorden [20] laut Patrice Ras [33, S. 48] folgendermaßen vorgegangen werden:

Gestalten bedeutet nach Patrice Ras auch zu verhandeln [33, S. 45]. Nach William L. Ury et al. und dem Harvard-Konzept [16] nach Patrice Ras [33, S. 58] kann sachbezogenes Verhandeln bspw. bei der Erhebung der Anforderungen in Scrum [6, S. 95–96], User Stories [6, S. 81–82], beim Sprint Review [6, S. 63] (neue Anforderungen verhandeln) oder bei der Sprint Retrospective [6, S. 63–64] (neue Prozesse, Tools verhandeln) in folgende Kategorien und Vorgehensweisen unterschieden werden [33, S. 58]:

Die Analyse der Kommunikation und Aussagen nach Schulz von Thun [44] kann helfen, Feedback während der Sprint Retrospective [6, S. 63–64] auf die enthaltene Sachinformation, Selbstkundgabe, Beziehungshinweise und Appelle zu analysieren und diese zu verstehen, um somit effektiver die Kommunikation und Beziehungen im Scrum Team mit Stakeholder:innen in der agilen Softwareentwicklung zu gestalten.

Zudem kann die Methode DESC nach Patrice Ras [33, S. 51–52] vom Scrum Master und anderen in Scrum verwendet werden, um bei Konflikten in Scrum [6, S. 55–56] klar um etwas zu bitten, indem die Fakten dargestellt und beschrieben, die dadurch hervorgerufenen Empfindungen und Gefühle erklärt, eine oder mehrere Lösungen vorgeschlagen und somit spezifiziert werden sowie Chancen und Konsequenzen, welche positiv für die anderen im Scrum-Team und Stakeholder:innen sind, aufgezeigt und verkauft werden nach Patrice Ras [33, S. 51–52].

Die Konfiktursachen bei einem Scrum Team mit Scrum Master:in [38, S. 7], Product Owner:in [38, S. 6], Developer:innen [38, S. 6] und Stakeholder:innen [38] sind nach Patrice Ras der Wunsch, Recht zu behalten, die kindliche Allmacht und das Ego [33, S. 63], wie in Abb. 4 gezeigt.

In Scrum ist der freie Meinungsaustausch erwünscht, womit Konflikte und Streitigkeiten unausweichlich sind [33, S. 28]. Der Wunsch, Recht zu behalten, ist eine wahre Ursache eines Konflikts nach Patrice Ras [33, S. 63]. Nun sollte der:die Scrum Master:in, Product Owner:in, Developer:in bzw. Stakeholder:in bei einer Meinungsverschiedenheit nach Patrice Ras [33, S. 63] darauf bedacht sein, Ergebnisse zu erzielen statt Recht zu behalten. Der Wunsch, Recht zu behalten, kann Arbeit, Beziehung, Geld, Energie, Freude, Freundschaft, Liebe und Zeit kosten und stellt somit ein Risiko für den Erfolg eines Scrum Teams in der agilen Softwareentwicklung dar, da als Folge unnötig Ressourcen verloren gehen könnten nach Patrice Ras[33, S. 28] und so das Sprint-Ziel [38, S. 60] gefährden.

Eine weitere Konfliktursache kann die kindliche Allmacht nach Patrice Ras [33, S. 63] sein, welche unnötig Ressourcen wie Energie, Zeit oder Freude im Scrum Team und Stakeholder:innen verschwendet. Die kindliche Allmacht ist eine Emanation des Ichs nach Patrice Ras [33, S. 25] im Scrum Team und Stakeholder:innen. Diese Emanation des Ichs ist zusammengesetzt aus Grundannahmen und Erwartungen, die der/die Scrum Master:in, Product Owner:in, Developer:innen oder Stakeholder:innen haben nach Patrice Ras [33, S. 25]. Die Grundannahmen und Erwartungen können von Kultur zu Kultur nach Patrice Ras variieren [33, S. 25] im Scrum Team und Stakeholder:innen. Entsprechend muss das Scrum Team mit Stakeholder:innen ausreichend in Scrum geschult sein, um gleiche Grundannahmen und Erwartungen zu haben [33, S. 25]. Die Grundannahmen und Erwartungen jedes Einzelnen im Scrum müssen zudem stets klar und gesund nach Patrice Ras [33, S. 45] als Gestalter kommuniziert werden, sodass Konflikte vermieden und effektiv in Scrum und der agilen Softwareentwicklung gestaltet werden kann.

Eine weitere Konfliktursache ist das Ego nach Patrice Ras [33, S. 63] im Scrum Team und Stakeholder:innen. Worte und Taten in Scrum persönlich zu nehmen nach Patrice Ras [31, S. 22–23], und nicht die Worte und Taten des anderen als Ausdruck seiner Bedürfnisse zu sehen, fördert die Frustration in Scrum und der agilen Softwareentwicklung und führt zu Verschwendung von Ressourcen wie Energie, Zeit oder Freude. Das Bedürfnis, wichtig zu sein, ist ein Ausdruck der Egozentrik nach Patrice Ras [31, S. 22–23] im Scrum Team und Stakeholder:innen. Jedes Scrum Teammitglied ist gleich wichtig (es gibt keine Hierarchien nach Johann Botha [6, S. 47]). Bedürfnisse können sich unterscheiden und gegenüberstehen sowie nach Patrice Ras vorherrschen [33, S. 50, 51] im Scrum Team und Stakeholder:innen: körperliche Bedürfnisse vs. geistige und spirituelle Bedürfnisse, Bedürfnisse nach Sicherheit vs. Bedürfnisse nach Freiheit, Bedürfnisse nach Zugehörigkeit vs. Bedürfnisse nach Selbstverwirklichung, Bedürfnisse nach Anregung vs. Bedürfnisse nach Ordnung, Bedürfnisse nach Kommunikation vs. Bedürfnisse nach Alleinsein (zu sich selbst finden) und Bedürfnisse nach Anerkennung vs. Bedürfnisse nach Kontrolle [33, S. 50, 51].

Schlussfolgernd sollte sich der/die Scrum Master:in, Product Owner:in, Developer:innen oder Stakeholder:innen nach Patrice Ras nicht als Zentrum des Universums [31, S. 22], sondern als Teil des Scrum Teams oder des Projektes [6, S. 12–14]) sehen. Des Weiteren sollte sich darauf geeinigt werden, dass die Logik des Ablaufs von Scrum, der Scrum Events und der Pflege der Artefakte von Scrum nach dem Scrum Guide [38] effektiv kommuniziert und verstanden wurde (bspw. durch ein externes Training³) und nicht die subjektive (egozentrische) Logik (Definitionen, Grundannahmen, Postulate, Überzeugungen, Werte etc.) nach Patrice Ras [31, S. 35] des einen oder anderen im Scrum Team und Stakeholder:innen als Referenz zum Ablauf der agilen Softwareentwicklung mit Scrum befolgt wird.

Des Weiteren ist der Beginn eines Psychospiels, im Dramadreieck der Unreife nach Petitcollin [30, S. 11] und Stephen Karpman [21] (siehe Abb. 3 und [30, S. 6]) als Retter auch auf das Ego zurückzuführen nach Petitcollin [30, S. 31–32], das sich ernähren will im Scrum Team und Stakeholder:innen. Der/Die Scrum Master:in, Product Owner:in, Developer:in oder Stakeholder:in tritt in ein Dramadreieck in der Rolle eines Retters ein. Ein Retter versucht, andere zu bemuttern, er fühlt sich gefestigter, klüger als andere, er empfindet Mitleid für das Gegenüber, er flieht vor seinen eigenen Problemem und kümmert sich aktiv um die der anderen und Weiteres nach Petitcollin [30, S. 32] im Scrum Team und Stakeholder:innen. Der Retter will Aufmerksamkeit nach Petitcollin [30, S.33] im Scrum Team und Stakeholder:innen. Um nicht in diese Rolle zu verfallen, sollte in einem Scrum-Team die gesunde Hilfsbeziehung gelebt werden, indem eine Bitte um Hilfe klar geäußert sein muss, das Hilfsangebot inhaltlich und zeitlich begrenzt ist, eine Gegenleistung zugelassen wird, nur die Hälfte des Weges mitgegangen und der Hilfsempfänger unabhängig gemacht wird nach Petitcollin [30, S. 34–36] im Scrum Team und Stakeholder:innen.

Es sollte im Scrum Team und bei Stakeholder:innen darauf geachtet werden, ob ein Scrum Teammitglied oder Stakeholder:in dramatische, emotionale oder launische Denk-, Verhaltens- und soziale Umgangsmuster nach Hemmings et al. [18, S. 102, 104–105] oder nach Carter et al. [7, S. 245] dramatische oder überemotionale Verhaltens- und Denkweisen aufzeigt, was eine histrionische Persönlichkeitsstörung (PS) darstellen kann nach Hemmings et al. [18, S. 104–105]. Scrum Master:innen, Product Owner:innen, Developer:innen oder Stakeholder:innen mit einer histrionischen Persönlichkeitsstörung sind egozentrisch und wollen Aufmerksamkeit nach Hemmings et al. [18, S. 105]. Sie kleiden oder verhalten sich im Scrum Team und Stakeholder:innen unangemessen und ihr Erscheinungsbild zieht Aufmerksamkeit nach Hemmings et al. auf sich [18, S. 105]. Scrum Master:innen, Product Owner:innen, Developer:innen oder Stakeholder:innen, die histrionisch sind, sind leicht zu beeinflussen und halten ihre Beziehungen inniger, als sie es nach Hemmings et al. sind [18, S. 105]. Sie stellen nach Hemmings et al. ihre Emotionen zur Schau, sind überaus pathetisch und suchen ständig nach Bestätigung und Anerkennung nach Hemmings et al. [18, S. 105] im Scrum Team und Stakeholder:innen. Dieses Verhalten und Denken kostet unnötig Zeit, Aufmerksamkeit und weitere Ressourcen in Scrum und der agilen Softwareentwicklung.

Des Weiteren sei hier erwähnt, dass ein Täter/Verfolger in Form eines Scrum Masters:in, Product Owners:in, Developers:in oder Stakeholders:in im Dramadreieck der Unreife nach Petitcollin [30, S. 11] (siehe Abb. 3) unnötig Ressourcen nimmt, indem er kritisiert (reaktive Handlung (hierzu gehört Klagen, Kritisieren, Vergleichen und Konkurrieren nach van Stappen [43, S. 23] und Stephen R. Covey [13, S. 100]) statt proaktive Handlung (siehe Abb. 1), über andere urteilt, gereizt auf andere reagiert, ihnen droht oder seine Emotionen dazu benutzt, es anderen schwer zu machen, in Wut gerät oder andere Dinge nach Petitcollin [30, S. 28] tut. Ein Täter/Verfolger sollte hierbei die Ursache seiner Frustration finden, seine unbefriedigten Bedürfnisse definieren und versuchen, diese auf eine gesunde Weise zu befriedigen, sowie sich um seine Verletzungen kümmern nach Petitcollin [30, S. 28] im Scrum Team und Stakeholder:innen. Hinter einer Kritik kann ein Verbot stecken nach Petitcollin [30, S. 29] im Scrum Team und Stakeholder:innen. Nur was im Scrum Guide [38] oder weiterer Literatur [6, 10] verboten wird, kann in Scrum verboten werden.

Als Letztes sollte hier erwähnt werden, dass das Opfer in Form eines/einer Scrum Masters:in, Product Owners:in, Developers:in oder Stakeholders:in im Dramadreieck (siehe Abb. 3 und [30, S. 6]) aufgrund seines Beklagens laut Petitcollin [30, S. 22] (reaktive Handlung (hierzu gehört Klagen, Kritisieren, Vergleichen und Konkurrieren nach van Stappen [43, S. 23] und Stephen R. Covey [13, S. 100]) statt proaktive Handlung (siehe Abb. 1) Ressourcen wie Energie und Zeit schädigt. Das Opfer fühlt sich hierbei machtlos, beschuldigt andere, behauptet, es könne dies oder jenes einfach nicht verstehen oder sich nicht anders verhalten nach Petitcollin [30, S. 22] im Scrum Team und Stakeholder:innen. Ein Opfer sollte sich seiner Passivität nach Petitcollin bewusst sein [30, S. 23] und stets erwachsen, ruhig, bestimmt bleiben und das Gegenüber ebenfalls als erwachsenes, verantwortliches (für das Denken, Fühlen, Sagen und Handeln sowie mitverantwortlich für Beziehungen nach Thalmann [42, S. 40]) Scrum Teammitglied oder Stakeholder:in wahrnehmen nach Petitcollin [30, S. 48]. Des Weiteren sollten sein Klagen und seine Beschwerden gewaltfrei durch klare Bitten nach Patrice Ras [33, S. 51] ersetzt werden nach Petitcollin [30, S. 23] und gegebenfalls die GFK-Methode (Gewaltfreie Kommunikation nach Marshall B. Rosenberg [35]) nach Patrice Ras [33, S. 53] angewandt werden, in der Beziehungen auf Wohlwollen und Empathie im Scrum Team und Stakeholder:innen aufgebaut werden: Situation beobachten und beschreiben möglichst ohne Bewertung (bspw. die Timebox vom Scrum Event: Daily Scrum [6, S. 124–125] wurde nicht eingehalten); zusammenhängendes Gefühl äußern (bspw. ich als Scrum Master:in vertraue euch Developer:innen nicht mehr und werde in meiner Autorität nicht respektiert); eigenes Bedürfnis klären und äußern (bspw. ich in meiner Rolle mit Aufgaben in Scrum im Scrum Team will respektiert werden) und offene Bitte äußern, welche dem Bedürfnis entspricht (bspw. ich möchte gerne, dass die Timebox des Daily Scrums ab sofort beachtet wird).

Es sollte für (100 %) selbstverantwortliches Handeln, Tun, Sagen, Denken und Fühlen nach Thalmann [42, S. 40] jedes Scrum Teammitglied für ein nachhaltiges, gesundes Scrum Team mit Stakeholder:innen folgende Prinzipien und Fragen beachten nach Petitcollin [30, S. 16–17]:

Konflikte sind erst gegeben, wenn Aggressivität und Gewalt nach Patrice Ras [33, S. 17–18] gegeben sind, was in einem Scrum Team mit Stakeholder:innen ineffektiv ist. Der Nutzen eines Konflikts sind nach Patrice Ras [33, S. 10]: Aggressivität und Stress abreagieren, Ausreden haben, Anerkennung, Gefühl der Wichtigkeit, der Selbstachtung, Gefühl, im Besitz der Wahrheit zu sein, Macht, Selbstbild aufwerten, Recht und das letzte Wort haben im Scrum Team und Stakeholder:innen.

Es sollte sich vorrangig um die Bedürfnisse und Wünsche gekümmert werden und sich gesund selbst behauptet werden (nach Patrice Ras Vorschläge machen, Dinge in die Hand nehmen, verhandeln, überzeugen [33, S. 45]), statt einen Konflikt in Scrum und der agilen Softwareentwicklung zu haben. Der Nutzen eines Konflikts ist auf das Ego im Scrum Team und Stakeholder:innen beschränkt nach Patrice Ras [33, S. 10]. Der Nutzen muss an ethischen Maßstäben und Werten [24, S. 224–227] bei einem Scrum Team gemessen werden.

Um Konfliktsituationen zu vermeiden oder nach Patrice Ras zu deeskalieren [33, S. 33–36] sollte in den Beziehungen in einem Scrum Team mit Stakeholder:innen bei sich anbahnender Frustration nach Patrice Ras [33, S. 17–18] schon früh versucht werden, die Bedürfnisse und Wünsche des anderen nach Patrice Ras [33, S. 35–36] zu berücksichtigen, anzuerkennen und zu akzeptieren, sonst kann sich der Konflikt nach Patrice Ras zu Aggression und Gewalt [33, S. 33] wandeln, aufgrund der Aktion des einen und der Reaktion des anderen im Scrum Team mit Stakeholder:innen sowie der Innerungen (inneren Reaktionen) von beiden nach dem Teufelskreismodell von Schulz von Thun [45] oder nach dem Eskalationsprozess von Patrice Ras [33, S. 14–15].

Alfred Adler [1] hat nach Werner Correll [12, S. 42] gesagt, dass das Streben nach Macht, Geltung und Anerkennung den:der Scrum Master:in, Product Owner:in, Developer:innen oder Stakeholder:innen im Sinne seiner Grundmotivation antreiben kann. Je minderwertiger sich ein:eine Scrum Master:in, Product Owner:in, Developer:innen oder Stakeholder:innen fühlt und je größer seine erfahrenen Frustrationen waren, desto größer ist das Streben nach Macht und Geltung, was das jeweils Schickliche insbesondere für den Projekterfolg übersteigen könnte laut Werner Correll [12, S. 42]. Ein Machtstreben ist laut Werner Correll als kompensatorisch zu sehen [12, S. 42]. Das übersteigerte Machtstreben kann nach Werner Corell [12, S. 42] dazu führen, dass mehr Konflikte in einem Scrum Team und bei Stakeholder:innen entstehen, was durch ein hohes Maß an erfahrener Frustration in einer sehr komplexen Domäne wie Software Engineering [39] wahrscheinlich ist.