Einleitung

Nach Ringhand et al. [22, S. 81] liegt der Fokus von ScrumFootnote 1 [6, 38] auf Kommunikation (nach dem Autor verbal oder nonverbal [6, S. 16, 28, 32]) sowie insbesondere für Johann Botha auf agiler Vorgehensweise [6, S. 12] und der Verwendung von Scrum-Artefakten, wie dem Product Backlog, Sprint Backlog und Increment [6, S. 64, 38, S. 11–14]. Scrum ist eine Softwareprojekt- und Entwicklungsmethode, welche zwischen den Developer:innen nach Barry Boehm et al. [5, S. 46], Richard W. Selby [39, S. 537], Barry Boehm [4] und Cockborn et al.[9] ein hohes Maß an Kommunikation erfordert – und nach dem Autor ein hohes Maß an Kommunikationskompetenz, welche gelehrt und gelernt werden muss [14] und die Gesundheit in der Informatik erhalten und nicht schädigen sollte [15] (bspw. durch Aggressionen oder Manipulationen [33, S. 39–40, 8] in Beziehungen).

Verbale und nonverbale Kommunikation in Scrum Teams und der agilen Softwareentwicklung ist eine stetig zu verbessernde [47], bedeutsame [19], einflussreiche [40], ressourcenintensive [41] und komplexe Angelegenheit [30, S. 55] ob face-to-face oder online. In Scrum müssen die Beteiligten bei der Erstellung des Increments sich stets selbst behaupten, indem der:die Scrum Master:in, Product Owner:in, Developer:innen oder Stakeholder:innen nach Patrice Ras [33, S. 39–40] und Dominique Chalvin [8] ihre Meinung und Wünsche (wie eine Anforderung oder User Story [6, S. 95–96]) ehrlich und frei zum Increment bspw. in einem Sprint Review [6, S. 127–128] oder zum Sprint-Verlauf in der Sprint Retrospective [6, S. 63–64, 127–128] äußern, ohne sich gegenseitig anzugreifen.

Kommunikation kann unterschiedliche Formen annehmen, wie nach Patrice Ras [33, S. 39] und Dominique Chalvin [8] in Form von Aggression/Domination, Manipulation, Flucht oder Selbstbehauptung. Selbstbehauptung will nach Anne van Stappen geübt sein [43, S. 59]. Die Scrum-Werte Commitment, Fokus, Offenheit, Respekt und insbesondere Mut [38, S. 4] erfordern es, eine Kommunikationsart der Gestalter (oder Selbstbehaupter nach Patrice Ras [33, S. 39, 45]) zu leben, sodass Scrum Teams [38] und Stakeholder:innen [38] effektiver miteinander in ihren Beziehungen bei der Erstellung eines Increments [6, S. 64, 146] kommunizieren.

Ein Gestalter oder Selbstbehaupter muss nach Patrice Ras die Fähigkeiten haben, zu verhandeln, zu überzeugen, die Dinge in die Hand zu nehmen und Vorschläge zu machen [33, S. 45]. Gestaltung ist nach Patrice Ras eine Kommunikationsart von verantwortlichen ebenbürtigen Erwachsenen [33, S. 45], welche nach dem Autor auf Augenhöhe stattfinden muss. Dies gilt sowohl für die Rolle des:der Scrum Masters:in [38, S. 7], des:der Product Owners:in [38, S. 6] als auch für die Developer:innen [38, S. 6], das Scrum Team sowie die Stakeholder:innen [38].

Agile Softwareentwicklung [23] mit all ihren Projektmanagementmethoden wie Scrum [6, 38], ABC oder alt: DSDM [6, S. 214–215] oder Extreme Programming (XP) [6, S. 210–213, 3] ermöglicht es, effektiv Innovationen in kurzen Zyklen mit häufigem Kundenfeedback zu entwickeln. Eine erfolgreiche Gestaltung von agiler Softwareentwicklung erfordert eine hohes Maß und Verständnis für deren benötigte Ressourcen sowie nach Barry Boehm et al. [10, S. 292–293] Risiken. Ressourcen wie Geld, Energie, Zeit, Beziehungen und Freude des:der Scrum Masters:in, Product Owners:in, Developers:innen und Stakeholders:innen können mit effektiver Kommunikation geschont und daraus resultierende Konflikte, welche unnötig zusätzliche Ressourcen kosten, vermieden werden [33, S. 28].

Ein Konflikt kann entstehen, weil die Kommunikation zwischen den:der Scrum Master:in [38, S. 7], Product Owner:in [38, S. 6], Developer:innen [38, S. 6] und Stakeholder:innen [38] nach Patrice Ras nicht gesund, klar [33, S. 45] und nach Anne van Stappen und Steven R. Covey nicht proaktiv [43, S. 23–24, 13, S. 100] ist und Bedürfnisse und Wünsche [33, S. 39, 51], User Stories [6, S. 81–82] oder Anforderungen [6, S. 95–96] nicht effektiv kommuniziert werden, welche Ressourcen wie Zeit, Geld, Beziehungen oder Freude kosten. Sofern Bedürfnisse und Wünsche nicht frühzeitig kommuniziert werden, kann Frustration entstehen, welche die Leistungsfähigkeit (geistige Kapazität) der Scrum Teammitglieder nach Werner Correll mindern [12, S. 36 ] und das Erreichen des Sprint-Ziels [38, S. 12] gefährden.

Patrice Ras [32] unterscheidet nach Albert Mehrabian [25,26,27] Kommunikation in verschiedene Kommunikationsformen wie verbale (Worte), paraverbale (Stimme), ausschließlich nonverbale (Körper) und nonverbale (Stimme und Körper) Kommunikation [32, S. 6]. Diese Kommunikationsformen haben einen unterschiedlichen tatsächlichen Anteil (siehe Tab. 1) in der Kommunikation und werden unterschiedlich bewusst wahrgenommen nach Patrice Ras [32, S. 6] und Albert Mehrabian [25,26,27]. Zu erwähnen ist, dass nonverbale Kommunikation [28, 32], nach Johann Botha [6, S. 16] 80 % der Kommunikation in einem Scrum Team einnimmt. In einem Scrum Team und mit Stakeholder:innen müssen die verbale und die nonverbale Kommunikationsform bei der Kommunikation beachtet werden, um effektiv zu kommunizieren, Konflikte zu vermeiden und Ressourcen zu schonen.

Tab. 1 Tatsächlicher Anteil und bewusst wahrgenommene Kommunikation nach Kommunikationsform in Prozent (%) nach Patrice Ras [32, S. 6] nach Albert Mehrabian [25,26,27], welche zwischen Scrum Master:in, Product Owner:in, Developer:innen sowie Stakeholder:innen stattfindet
Full size table

Dieser Artikel soll es ermöglichen, den Konflikten aufgrund ineffektiver Kommunikation bei der Einführung oder Durchführung von Scrum in der agilen Softwareentwicklung positiv zu begegnen und die Konfliktursache(n) zu verstehen, sodass Konflikte gelöst und effektive Scrum Teams mit Stakeholder:innen etabliert werden können. Wir unterscheiden im Artikel in effektive verbale und nonverbale Kommunikation bei einem Scrum Team und Stakeholder:innen in der agilen Softwareentwicklung.

Effektive verbale Kommunikation in Scrum und der agilen Softwareentwicklung

Effektiv kommunizieren in Scrum in 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).

Abb. 1
figure 1

Proaktive (Selbstwahrnehmung, klare Bewusstheit, Mut und Verständnis nach Anne van Stappen [43, S. 23–24] und Stephen R. Covey [13, S. 100]) und gestalterische (nach Patrice Ras [33, S. 45]) Kommunikation (gesunde und klare Vorschläge machen, überzeugen, Dinge in die Hand nehmen, verhandeln, [33, S. 45] und ehrlich seine/ihre Meinung, Wünsche und Gefühle frei äußern, ohne den anderen anzugreifen [33, S. 39–40]) Einstellung des Scrum-Teams mit Scrum Master:in [38, S. 7], Product Owner:in [38, S. 6], Developer:innen [38, S. 6] sowie Stakeholder:innen [38] zur Erstellung eines Increments [38, S. 13] (vereinfacht dargestellt; es können mehr als ein Increment in Scrum pro Sprint angefertigt werden) innerhalb von ein‑ bis vierwöchigen nachhaltigen [6, S. 16] Sprints die mit den Scrum-Säulen: Transparenz, Überprüfung und Anpassung [38, S. 3–4] sowie mit den Scrum-Werten: Commitment, Fokus, Offenheit, Respekt und Mut [38, S. 4–5] im Einklang ist

Full size image

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.

Tab. 2 Mögliche Kommunikationsarten [33, S. 39–40, 33, 8] mit Beziehungstypen [33, S. 45–46] und Ich-Kommunikation [33, S. 46–47,37, 46] nach Patrice Ras (Kommunikationsarten, Beziehungstypen, Ich-Kommunikation) [33, S. 39–40, 45–46, 46–47], Dominique Chalvin (Kommunikationarten) [8] und Jacques Salmomé und Methode ESPERE (Ich-Kommunikation) [37, 46] in einem Scrum Team mit Scrum Master:in [38, S. 7], Product Owner:in [38, S. 6], Developer:innen [38, S. 6] sowie Stakeholder:innen [38] mit den Aktivitäten in der Kommunikation
Full size table
Abb. 2
figure 2

Beziehungstypen nach Patrice Ras [33, S. 45] (Quelle der Abbildung; rot-schwarze Hervorhebung von Sender und Empfänger wurde entfernt) für die effektive Kommunikation in Scrum-Teams mit Scrum Master:in [38, S. 7], Product Owner:in [38, S. 6], Developer:innen [38, S. 6] und Stakeholder:innen [38]. Legende nach dem Autor von Quelle abgeleitet: gestrichelter Pfeil: schwache bis keine Kommunikation (Manipulieren oder Fliehen), durchgezogener Pfeil: starke Kommunikation (Gestalten) bis überstarke Kommunikation (Dominieren)

Full size image

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.

Abb. 3
figure 3

Dramadreieck der Unreife (nach Petitcollin [30, S. 11] und Stephen Karpman [21]) mit Rollen des Verfolgers/Täters, Retters und des Opfers nach Petitcollin [30, S. 6] (Angelehnt an Quelle der Abbildung, Abkürzungen zu den Rollen wurden entfernt), in welchem ein:eine Scrum Master:in, Product Owner:in, Developer:innen und Stakeholder:innen beim Einstieg seine Lieblingsrolle hat und während des Psychospiels nach Petitcollin [30, S. 43] die Rolle wechselt

Full size image

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:inFootnote 2 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:

  • Es sollte bei Aussagen des:der Scrum Master:in, Product Owner:in oder Developer:innen sowie Stakeholder:innen das Personalpronom Ich verwendet werden nach Patrice Ras [33, S. 47] und Thomas Gorden [20], um mit den anderen von sich, nicht für (generalisiertes Personalpronom: Man) oder über (Personalpronom: Du) den/die anderen zu sprechen nach Jacques Salmomé [37, 46].

  • Es sollte aktiv dem Gegenüber, Scrum Master:in, Product Owner:in oder Developer:innen sowie Stakeholder:innen zugehört werden (nach Carl Roger [29, 34]), sodass verstanden werden kann, was das Gegenüber denkt, fühlt und will und nach Patrice Ras [33, S. 59].

  • Es sollte die gegenseite Befriedigung der Bedürfnisse (und Wünsche auch in der Form von User Stories [6, S. 81–82] oder Anforderungen [6, S. 95–96]) des:der Scrum Master:in, Product Owner:in oder Developer:innen sowie Stakeholder:innen angestrebt werden, sodass Zufriedenheit geschaffen und Frustration vermieden wird nach Patrice Ras [33, S. 16–19].

  • Die zwölf Kommunikationssperren sollten nach Patrice Ras [33, S. 48] und Thomas Gorden [20] vom Scrum Master:in, Product Owner:in oder Developer:innen sowie Stakeholder:innen vermieden werden: Analysieren, Befehlen, Beraten, Beruhigen, Drohen, Moralisieren, Predigen, Ironie, Kritisieren, Schmeicheln, (Ver‑)Urteilen und Verhören; stattdessen sollte proaktiv kommunziert werden (siehe Abb. 1)

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]:

  • Regeln des Verhandelns:

    • Emotionale Probleme sollten vorrangig im Scrum Team und Stakeholder:innnen behandelt werden (siehe auch Kapitel zu nonverbaler Kommunikation).

    • Gefühle sollten nicht zu unüberlegten Entscheidungen bspw. bei der Priorisierung des Product Backlogs [6, S. 76 ] in Scrum verleiten.

    • Verhandelt wird ausschließlich über die Wünsche, User Stories [6, S. 81–82] oder Anforderungen [6, S. 95–96].

    • Die bestmögliche Lösung bspw. User Story [6, S. 81–82] oder Anforderungen [6, S. 95–96] sollte im Scrum Team und Stakeholder:innen gesucht und gefunden werden.

    • Aus dem anfänglichen Verhandlungsrahmen zu den Ressourcen wie Dauer der Projektzeit oder Geld kann gegebenenfalls in Scrum herausgetreten und dieser angepasst werden bspw. beim nächsten Sprint Review [6, S. 63].

  • Bedingungen für erfolgreiches Verhandeln:

    • Die obigen Regeln des Verhandelns sollten im Scrum Team und Stakeholder:innen beachtet werden.

    • Der Konflikttyp sollte im Scrum Team und Stakeholder:innen identifiziert werden, wie Wertekonflikte, soziale Konflikte, Interessenkonflikte, Ego-Konflikte, zwischenmenschliche Konflikte, Rivalitäten und gemischte Konflikte nach Patrice Ras [33, S. 7] sowie typische Konflikte bei der Einführung von Scrum in der agilen Softwareentwicklung nach Johann Botha [6, S. 189–192] (Art des Widerstands: aktiv (0), passiv (1) vs. Grund des Widerstands: Ist-Zustand akzeptabel (2) oder Ist-Zustand inakzeptabel (3); Unverbesserliche (02), Saboteure (03), Mitläufer (12), Skeptiker (31)).

    • Zugeständnisse sollten im Scrum Team und Stakeholder:innen sortiert aufgeführt und benannt werden.

    • Die Kommunikation muss gut, d. h. gesund und klar im Scrum Team und Stakeholder:innen sein, die eines Gestalters nach Patrice Ras [33, S, 39, 45].

    • Es sollte eine geeignete Methodik oder Mittel beim Verhandeln im Scrum Team und Stakeholder:innen herangezogen werden, wie Fragen nach und Erhalten weiterer Informationen, Neuformulierungen, Vorschläge, Zugeständnisse, Argumentieren, Einwände und Entscheidungen.

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].

Konfliktursachen in der Kommunikation in Scrum und der agilen Softwareentwicklung

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.

Abb. 4
figure 4

Konfliktursachen bei der Einführung und Durchführung von Scrum nach Patrice Ras ([33, S. 63]; Grafik ist angelehnt an Definition [33, S. 63]): Wunsch Recht zu behalten, kindliche Allmacht und Ego eines Scrum Teams mit Scrum Masters:in [38, S. 7], Product Owner:in [38, S. 6], Developer:innen [38, S. 6] sowie Stakeholder:innen [38]

Full size image

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 TrainingFootnote 3) 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]:

  • Sich zu sorgen:

    • Wie gut sorgt sich ein Scrum Master:in, Product Owner:in, Developer:innen oder Stakeholder:innen um seine physische und psychische Gesundheit?

    • Wie gut sorgt sich ein Scrum Master:in, Product Owner:in, Developer:innen oder Stakeholder:innen um seine finanzielle Unabhängigkeit?

    • Wie gut sorgt sich ein Scrum Master:in, Product Owner:in, Developer:innen oder Stakeholder:innen um sein persönliches Wachstum und seine Entfaltung?

  • Und in Beziehungen zu anderen im Scrum Team und Stakeholder:innen, in denen jeder individuell zu 100 % für sein Denken, Handeln, Fühlen und Sagen verantwortlich und für die Qualität der Beziehungen mitverantwortlich ist nach Yves-Alexandre Thalmann [42, S. 40], welche folgendermaßen nach Petitcollin [30, S. 16–17] gepflegt werden können:

    • Mit wem will ein Scrum Master:in, Product Owner:in, Developer:in oder Stakeholder:in Umgang haben? Hier sollten Synergien aus Fachexperten entstehen [6, S. 47].

    • Welchen Art des Austausches will ein:eine Scrum Master:in, Product Owner:in, Developer:in oder Stakeholder:in gerne haben? Es sollte nach Patrice Ras und Don Miguel Ruiz [33, S. 58–59, 36] die Sprache tadellos sein, d. h., die Worte sollten nie gegen jemanden gerichtet sein in Form von Beleidigungen, Kritik, Klatsch, Lügen, Provokation, Spott usw. im Scrum Team mit Stakeholder:innen. Es sollten Gedanken, Gefühle, Taten, Handlungen, das Sagen und Worte nicht persönlich im Scrum Team und Stakeholder:innen genommen werden nach Patrice Ras [33, S. 58–59]. Es sollten keine voreiligen Schlüsse gezogen werden (das ineffektiv in der Kommunikation ist), was der andere will, denkt oder fühlt im Scrum Team und Stakeholder:innen (zum Beispiel, indem man es errät oder versucht, Gedanken zu lesen nach Petitcollin [30, S. 40–41]), sondern es sollte danach gefragt/geäußert, es geklärt/erklärt oder überprüft werden, um Missverständnisse zu vermeiden nach Patrice Ras [33, S. 58–59] im Scrum Team und mit Stakeholder:innen ist.

    • Was ermöglicht einem:einer Scrum Master:in, Product Owner:in, Developer:in oder Stakeholder:in, sich zu entfalten und von Liebe umgeben zu sein?

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.

Effektive nonverbale Kommunikation in Scrum und der agilen Softwareentwicklung

Es kann nach Patrice Ras [32, S. 6] und Albert Mehrabian [25,26,27] zwischen drei grundlegenden Kommunikationsformen unterschieden werden: verbal (Worte), paraverbal (Stimme), ausschließlich nonverbal (Körper) und eine Kombination Nonverbal (Stimme und Körper) [32, 6], welche ein Scrum Team mit Stakeholder:innen hat.

Nach Patrice Ras und Albert Mehrabian [25,26,27] gibt es 23 nonverbale Ausdrucksformen [32, S. 11] in einem Scrum Team mit Stakeholder:innen. Sie betreffen die visuell (Gesicht, Mimik, Gesten und Bewegungen, Körperhaltungen, Posen und Krankheiten) und die nicht-visuell wahrnehmbare, die anderen Sinne betreffende Körpersprache (Stimme (Timbre, Höhe, Rhythmus etc.), Tastsinn (Händedruck, Streicheln, Massage etc.), Gerüche (natürliche oder künstliche) oder Geschmack (Küssen etc.)) nach Patrice Ras [32, S. 12] in einen Scrum Team mit Stakeholder:innen.

Sie betreffen andere Ausdrucksformen laut Patrice Ras [32, S. 12] wie äußere Attribute (Look (Kleidung, Schuhe, Frisur, Make-up), Gegenstände, die wir mit uns führen (Accessoires, Utensilien), feste Objekte (Möbel), Transportmittel (Fahrzeuge), Tiere, die wir besitzen), das Handeln (Handlungen, Rollen, die wir spielen, Zeitpunkt/-dauer unseres Tuns, Pünktlichkeit), das Raumverhalten (Distanz, die wir zwischen uns im Scrum Team, Scrum Master:in, Product Owner:in und Developer:innen und anderen einhalten (Proxemik laut Patrice Ras [32, S. 47–48] und Hemmings et al. [18, S. 220–221]), Platz, den wir uns in einem Raum suchen, Orte, die wir regelmäßig besuchen) und übergreifende Ausdrucksformen (rund um den Körper) wie Träume ([18, S. 14–15, 119, 17]), Schrift (Grafologie) und Farben laut Patrice Ras [32, S. 12].

Nonverbale Sprache der Handlungen nach Patrice Ras [32, S. 43–44] bei einem Scrum Team: Scrum Master:in, Product Owner:in, Developer:innen und Stakeholder:innen. Es sollte sich in Scrum an gesellschaftliche Vorgaben, insbesondere den Scrum Guide [38] gehalten werden und auch jeder Erfolg in Scrum laut Patrice Ras [32, S. 43–44] gefeiert werden. Anlässe wie Scrum Events [6, S. 56] sollten besucht werden, sodass Scrum gelebt und durchgeführt werden kann. Es sollte die Schule des Arbeitslebens jeden Tag besucht werden, welche jeden Tag neue Lektionen in Scrum und Arbeitsleben nach Patrice Ras [31, S. 47–50] bereithält. Fehlleistungen in Scrum und der agilen Softwareentwicklung sollten als unbewusste Wünsche (Aktivitäten, Objekte, Personen oder Beziehungen nach Patrice Ras [33, S. 49]) wahrgenommen werden nach Patrice Ras [32, S. 44], welche berücksichtigt werden, identifiziert werden, eine Lösung mit dem Ziel zur Befriedigung der Wünsche vorgeschlagen wird, es zugelassen wird das die Wünsche geäußert werden, anerkannt und akzeptiert werden nach Patrice Ras [33, S. 35]. Sodann soll zum Bedürfnis wieder zurückgekehrt werden nach Patrice Ras [33, S. 35] im Scrum Team und Stakeholder:innen. Es sollte auf den Stil nach Patrice Ras [32, S. 44] und nicht nur auf das Was bei der Durchführung in Scrum geachtet werden. Beziehungen [6, S. 65] sollten in Scrum eingegangen und nicht vermieden werden nach Patrice Ras [32, S. 44].

Nonverbale Sprache der Mimik nach Patrice Ras [32, S. 15–16] bei einem Scrum Team: Scrum Master:in, Product Owner:in, Developer:innen und Stakeholder:innen. Es gibt nach Patrice Ras [32, S. 16] und Carter et al. [7, S. 136–137] sechs Basisemotionen: Ekel, Freude, Überraschung, Traurigkeit, Angst und Zorn sowie weitere Gefühle wie Groll, Schuldgefühle, Reue, Stress, Langeweile und Zweifel usw. nach Patrice Ras [32, S. 16] im Scrum Team und Stakeholder:innen. Des Weiteren identifiziert Nico Frijda nach Collin et al. [11, S. 324–325] neben Basisemotionen wie Wut, Freude, Scham, Traurigkeit und Angst auch andere wie Eifersucht und Schuld, welche für ihn nicht dieselbe biologische Dringlichkeit haben im Scrum Team und Stakeholder:innen. Um die Emotionen und Gefühle des anderen zu erkennen, soll man dem:der anderen Scrum Master:in, Product Owner:in, Developer:in und Stakeholder:in laut dem Autor beim Gespräch ins Gesicht und auf den Körper sehen, um die nonverbale Kommunikation zu erkennen und so effektiv in einem Scrum Team und mit Stakeholder:innen zu kommunizieren, was auch in Scrum eine osmotische und enge Kommunikation ermöglicht [6, S. 208].

Nonverbale Sprache der Macht laut Patrice Ras [32, S. 59–60] bei einem Scrum Team: Scrum Master:in, Product Owner:in, Developer:innen und Stakeholder:innen. Zorn als Ausdruck von Macht zu nutzen, trägt laut Patrice Ras [32, S. 60] nicht dazu bei, dass effektiv kommuniziert wird, da das Risiko von Aggression und Gewalt steigt (Zorn kann sich zu Aggression und dann Gewalt wandeln nach Patrice Ras [33, S. 16–18]) und dies weitere Frustrationen auslösen könnte im Scrum Team und Stakeholder:innen. Eine User Story bspw. als Ausdruck von Macht nach Patrice Ras [32, S. 60] unleserlich auf einen Klebezettel zu schreiben, bewirkt, dass die Scrum-Teammitglieder die Informationen im Scrum Team nicht teilen können und nicht effektiv miteinander gearbeitet werden kann. Bei Scrum Events verspätet zu erscheinen, als Ausdruck von Macht nach Patrice Ras [32, S. 60], gefährdet den Sprinterfolg.

Nonverbale Sprache der Zeit laut Patrice Ras [32, S. 45–46] bei einem Scrum Team: Scrum Master:in, Product Owner:in, Developer:innen und Stakeholder:innen. Zu spät zu Scrum Events zu kommen und erwartet oder herbeigesehnt zu werden, weil der Wunsch nach Macht vorhanden ist laut Patrice Ras [32, S. 46], stellt ein Risiko für einen erfolgreichen Sprint dar [6, S. 60–61]. Nur integer zu sein und seine zeitlichen Verpflichtungen laut Patrice Ras [32, S. 46] in Scrum einzuhalten, wie die Länge eines Scrum Events [6, S. 60–64], führt zu einem erfolgreichen Sprint.

Nonverbale Sprache der Distanzzonen laut Patrice Ras [32, S. 47–48] bei einem Scrum Team: Scrum Master:in, Product Owner:in, Developer:innen und Stakeholder:innen. In Scrum wird osmotische und enge Kommunikation in einem Raum bevorzugt laut Johann Botha [6, S. 208]. Eine optimale Distanz für die Kommunikation zwischen Scrum Master:in, Product Owner:in wie auch für die Developer:innen oder Stakeholder:innen liegt in der sozialen Zone, welche einen Abstand zwischen den Individuen von 1,20 m und 2,50 m hat und in der sich formale Diskussionsgruppen aufhalten laut Patrice Ras [32, S. 48]. Die öffentliche Zone von unendlich bis 2,50 m ist laut Patrice Ras [32, S. 48] als anonyme Zone ungeeignet für eine osmotische und enge Kommunikation [6, S. 208]. Die persönliche Zone laut Patrice Ras [32, S. 48] von 50 cm bis 1,20 m ist eher für emotional verbundene Gruppen geeignet und die intime und körperliche Zone von 0 cm bis 50 cm ist ungeeignet für eine effektive Kommunikation in einem Scrum Team. Hemmings et al. [18, S. 220–221] definieren 45 cm als intimen Raum, 1,20 m als persönlichen Raum, 3,6 m als sozialen Raum und 7,6 m als öffentlichen Raum in einem Scrum-Team und mit Stakeholder:innen.

Zorn kann sich nach Patrice Ras durch eine geballte Faust zeigen [32, S. 18, 20] sowie in der Sprache konventioneller [32, S. 17–18] und natürlicher Handgesten [32, S. 19–20] bei einem Scrum Team: Scrum Master:in, Product Owner:in, Developer:innen und Stakeholder:innen. Eine Zustimmung kann mit einem Daumen nach oben nach Patrice Ras [32, S. 18] in einem Scrum Team mit Stakeholder:innen signalisiert werden. Auf eine Drohung oder einen Hinweis weist laut Patrice Ras [32, S. 20] ein Finger hin, der auf etwas oder jemanden im Scrum Team mit Stakeholder:innen zeigt wie bspw. auf einen Product-Backlog-Eintrag [6, S. 78–79], auf einen Eintrag am Information Radiator [6, S. 149–150] oder den Fortschritt am Burn-Down‑/Burn-Up-Chart [6, S. 147–148].

Des Weiteren unterscheiden Joe Navarro und Marvin Karlins [28, S. 18–20] bei der nonverbalen Kommunikation bei einem Scrum Team: Scrum Master:in, Product Owner:in, Developer:innen und Stakeholder:innen bei der nonverbalen Informationsvermittlung in Berührungen, Haltung, Gestik, Körperbewegungen, Körperinszenierungen (Frisur, Kleidung, Schmuck, Tätowierungen usw.), Mimik sowie Tonfall, Klangfarbe und Lautstärke der Stimme, welche auf die Gedanken, Gefühle und Absichten des:der Scrum Master:in, Product Owner:in, Developer:innen oder Stakeholder:innen schließen lassen.

Zusammenfassung

Effektive verbale und nonverbale Kommunikation in Scrum und der agilen Softwareentwicklung kann zu erfolgreicheren Sprints führen. Die Ursache von Konflikten in Scrum und der agilen Softwareentwicklung ist die kindliche Allmacht, der Wunsch, Recht zu behalten, oder das Ego. Die Konflikte in der verbalen und nonverbalen Kommunikation sind der Grund, warum Ressourcen wie Zeit, Energie oder Freude in Scrum Events und während Sprints verschwendet und nicht eingehalten werden. Psychospiele im Dramadreieck der Unreife sollten vermieden werden. Wünsche sollten klar und gewaltfrei geäußert und wenn möglich von Scrum Master:in, Product Owner:in, Developer:innen und Stakeholder:innen befriedigt werden. Das Verständnis von nonverbaler Kommunikation, welche 80 % in Scrum ausmacht, hilft, effektiver in Scrum und agiler Softwareentwicklung zu kommunizieren. Kommunikation ist eine komplexe Angelegenheit. Eine effektive und gesunde Kommunikation in der agilen Softwareentwicklung ermöglicht trotz der stetigen Veränderungen in einen Scrum Team mit Stakeholder:innen, erfolgreich und gesund mit Scrum und agiler Softwareentwicklung in der Arbeit zu leben.