Kommunikation in agilen Projekten nach Scrum

Published in

DevFuture

26 min readSep 30, 2020

Inhalt

· 1 Einleitung
· 2 Kommunikation und Projektmanagement
∘ 2.1 Kommunikation
∘ 2.2 Projektmanagement
∘ 2.3 Einordnung der Kommunikation in das Projektmanagement
∘ 2.4 Scrum
· 3 Untersuchung der Kommunikation in Scrum
· 4 Diskussion
∘ 4.1 Einﬂuss von Scrum auf die Projektkommunikation
∘ 4.2 Auswirkungen der Kommunikation auf ein Projekt
· 5 Zusammenfassung
· 6 Literatur

1 Einleitung

Die Kommunikation ist ein beherrschendes Thema im Umfeld des Projektmanagements, weil sie durch ihre vielen Facetten erheblichen Einﬂuss auf Projekte nimmt, ohne dass die Ursache oﬀensichtlich ist oder wahrgenommen wird. Sie wird daher auch als „Lebenselixier“ (life blood) eines Projekts und Unternehmens bewertet (Vgl. Drinkwater [2007]; Awati [2010]). Durch ihre Komplexität wird ihr eine besondere Rolle zugeschrieben. Studien belegen, dass Missverständnisse, die durch Kommunikation entstehen, Sand im Getriebe eines Projektablaufs sind. Die Metapher lässt sich fortsetzen, denn dieser Sand kann gravierende Auswirkungen auf den Projektablauf haben oder zum Stillstand des Projekts führen. Die Kommunikation sollte daher schon in der ersten Projektphase eine entsprechende Berücksichtigung ﬁnden und früh im Projekt und seinen Ablauf eingeplant werden.

Untersuchungen, die sich der Kommunikation im Projektmanagement widmen, kommen zu dem Schluss, dass die Kommunikation die wichtigen Faktoren Zeit, Kosten und Umfang eines Projekts sichert. Sie kann demnach als grundlegende Funktion für ein Projekt angesehen werden (Vgl. Zulch [2014]). Konsequenterweise sollten Projektmanager gut kommunizieren können, um das Projekt positiv zu beeinﬂussen. Das gilt aber nicht nur für Projektmanager, es gilt auch für die Projektmitarbeiter und für die Methode bzw. strukturelle Vorgehensweise die zur Durchführung eines Projekts angewandt wird, welche die Kommunikation positiv oder negativ beeinﬂussen kann.

Diese Methoden sind Vorgehensweisen die bei der Bearbeitung des Projekts befolgt werden und können als Blaupause für den Projektablauf verstanden werden. Die Methode nach Scrum oder Kanban, die in Softwareprojekten vermehrt angewendet wird, stellt einen agilen Ansatz zur Projektdurchführung dar. Mit diesem Ansatz soll neben anderen Faktoren unter anderem auf Änderungen des Projekts ﬂexibel reagiert und eine Nähe zum Kunden hergestellt werden. Das ermöglicht unter anderem eine Projektdurchführung die dem Kunden den Projektstatus, die anstehenden Aufgaben und die bereits umgesetzten Anforderungen zu jedem Zeitpunkt transparent vermittelt.

Durch verschiedene Elemente bei der Ausübung von Scrum, z. B. bei täglichen Meetings, wird der Kommunikation ein hoher Stellenwert eingeräumt. Es stellt sich daher die Frage, wie die Komponente der Kommunikation in Scrum ein Projekt beeinﬂusst und welche positiven oder negativen Auswirkungen auf den Projektablauf zu erwarten sind, wenn Scrum angewendet wird. Das Ziel dieser Arbeit ist die Untersuchung der Auswirkung von Scrum auf die Kommunikation im Projektablauf.

2 Kommunikation und Projektmanagement

Die separierte Betrachtung der Kommunikation sowie des Projektmanagement ermöglicht einen Überblick über die Rolle der Kommunikation im Projektmanagement und anschließende Einordnung. Mit diesen Erkenntnissen lässt sich das agile Vorgehen nach Scrum in das Projektmanagement einordnen.

2.1 Kommunikation

Der Begriﬀ „Kommunikation“ beschreibt eine Wechselwirkung zwischen Systemen durch den Austausch von Signalen und Informationen. Das schließt allgemein betrachtet demnach auch die Übertragung von Informationen durch elektronische Netzwerke ein (Vgl. Watzlawick u. a. [2003]). Die zwischenmenschliche Kommunikation, die in Projekten und Arbeitsbeziehungen gelebt wird, kann zwar auf ein Senderund Empfänger Prinzip mit Störungen zurückgeführt werden, allerdings ist dieser Teilbereich der Kommunikation nicht trivial zu erfassen, wenn jeder mögliche Aspekt einbezogen wird. Beispielsweise kann man die zwischenmenschliche Kommunikation aus einem interkulturellen Blickwinkel betrachten und deutliche Unterschiede zwischen den Kulturen identiﬁzieren (Vgl. Hall [1959]; Geert H.. Hofstede [1980]).

Zur Beschreibung der zwischenmenschlichen Kommunikation und seines Umfangs wird mit Axiomen und verschiedenen Modellen gearbeitet, die in diesem Bereich erforscht wurden. Mit der bekannten Aussage „Man kann nicht nicht kommunizieren“ (Vgl. Watzlawick u. a. [2003]), deﬁnieren Watzlawick u. a. eines von Fünf Axiome, die es bei der zwischenmenschlichen Kommunikation zu berücksichtigen gilt. Dieses erste Axiom beschreibt die Tatsache, dass selbst wenn verbal keine Worte ausgetauscht werden, dennoch kommuniziert wird. Eine zwischenmenschliche Interaktion, unerheblich welcher Art, führt nach dieser Regel immer zu einer Kommunikation.

Das nächste Axiom deﬁniert einen Inhaltsund Beziehungsaspekt in jeder Kommunikation. Der Inhaltsaspekt transportiert die Information selbst, der Beziehungsaspekt hingegen wird als Metakommunikation deﬁniert und beinhaltet die Art wie die Information beim Empfänger ankommen soll und wie die Beziehung eingeschätzt wird. Das dritte Axiom gibt an, dass die „Interpunktion der Kommunikationsabläufe“ der Kommunikationspartner entscheidend für „die Natur einer Beziehung“ ist. Unter der Interpunktion versteht Watzlawick u. a. die Unterbrechung der Kommunikation sowie die Interpretation der vergangenen Kommunikation. Mit anderen Worten schreiben Kommunikationspartner der

Kommunikation jeweils eine unterschiedliche Bedeutung durch die Unterbrechung und Interpretation vergangener Kommunikation zu. Es entsteht eine UrsacheWirk-Beziehung der Kommunikationspartner. Das vierte Axiom teilt die Kommunikation in die Bereiche Digital und Analog ein. Die digitale Kommunikation umfasst die Zeichen, Zeichensätze, Alphabete, Logik und das gesprochene Wort. Unter der analogen Kommunikation hingegen werden z. B. Bilder, Mimik sowie Gestik eingeordnet und diese Mittel eignen sich um die Beziehung zu kommunizieren. Das letzte Axiom gliedert die Kommunikation in symmetrische und komplementäre Abläufe ein und bezieht sich damit auf Gleichheit oder Unterschiedlichkeit der Kommunikationspartner. Die Gleichheit von zwei Kommunikationspartnern, z. B. in gleicher Position innerhalb eines Unternehmens betrachtet, wirkt sich auf das Verhalten sowie die Interaktion aus und führt zu einer symmetrischen Kommunikation. Das Verhalten und die Kommunikation ist in diesem Fall spiegelbildlich. Die Unterschiedlichkeit hingegen führt zu einem komplementären Verhalten und einer komplementären Kommunikation, in denen sich die Kommunikationspartner ergänzen z. B. bei ungleichen Positionen wie Mitarbeiter und Vorgesetzter (Vgl. Watzlawick u. a. [2003]).

Aufbauend auf den Überlegungen von Watzlawick und dem Senderund Empfänger Prinzip ist das „Kommunikationsquadrat“ oder „Vier-Ohren-Modell“ durch Schulz von Thun u. a. entstanden. Das Kommunikationsquadrat beschreibt das die Nachricht aus mehr als nur der Information besteht. Es deﬁniert hierzu vier relevante Seiten einer Nachricht: Sachinhalt, Selbstoﬀenbarung, Beziehung und Appell. Diese Seiten sind in jeder Nachricht enthalten. Sachinhalt heißt der Teil der Nachricht, der die eigentliche Information, über die der Sender den Empfänger informieren will, enthält. Die Selbstoﬀenbarung enthält Informationen über den Sender und etwas das der Sender preisgibt, obwohl er es nicht immer beabsichtigt. Die Beziehung enthält die Information wie der Sender die Beziehung einschätzt und was er vom Kommunikationspartner hält. Schließlich beinhaltet der Appell eine Auﬀorderung an den Empfänger. Diese Seiten haben nicht immer das gleiche Gewicht, obwohl alle Seiten bedient werden, kann der Sender dem Sachinhalt eine höhere Bedeutung geben als der Beziehung (Vgl. Schulz von Thun u. a. [2014]).

Diese Sachverhalte treﬀen nicht nur auf den Sender der Nachricht zu. Der Empfänger seinerseits kann mit dem Vier-Ohren-Modell beschrieben werden. Analog zum Kommunikationsquadrat enthält das Vier-Ohren-Modell je ein Ohr für den Appell, die Selbstoﬀenbarung, die Beziehung und den Sachinhalt. Der Sender, der die Nachricht mit seinen vier Seiten oder „Schnäbeln“ sendet, triﬀt auf das entsprechende Ohr des Empfängers. Ein Empfänger verwendet die vier Ohren eventuell unterschiedlich stark, sodass z. B. stärker die Beziehungs oder der Sachinhalt einer Nachricht wahrgenommen wird, während der Appell kaum Beachtung ﬁndet. Wenn nun der Sender dem Appell ein größeres Gewicht verliehen hat, kommt es zum Missverständnis. Mit anderen Worten sind sowohl Sender als auch Empfänger Verantwortlich für die reibungslose Kommunikation: der Sender für die gesendete und der Empfänger für die empfangene Nachricht. Fehldeutungen in der Kommunikation, können über die Übermittlung eines Feedbacks durch den Empfänger vermieden werden (Vgl. Schulz von Thun u. a. [2014]).

2.2 Projektmanagement

Die Routinearbeit in einem Unternehmen lässt sich von einer neuen Tätigkeit, die sich von der Routinearbeit unterscheidet, mit dem Begriﬀ „Projekt“ abgrenzen. Ein Projekt hat einen deﬁnierten Anfangs und Endzeitpunkt, enthält eine Zielvorgabe und ist ein einmaliger Prozess mit einer zeitlichen, ﬁnanziellen oder personellen Begrenzung (Vgl. Möller u. Dörrenberg [2003]).

Der Begriﬀ Management wird als eine Position innerhalb eines Unternehmens oder als die Funktion der Unternehmenssteuerung aufgefasst. Die Position im Unternehmen bezieht sich auf die hierarchische Anordnung im Unternehmen selbst, welche unterschiedliche leitende Aufgaben in Form von einer Personalverantwortung, dem Treﬀen von Entscheidungen und der Überwachung wahrnimmt. Das Management als Funktion ist unabhängig von der Unternehmenshierarchie darauf ausgerichtet Sachfunktionen wie Einkauf, Herstellung, Verkauf auf die Unternehmensziele auszurichten. Diese Ausrichtung ist unabhängig von den Abteilungen und gilt für das gesamte Unternehmen (Vgl. Steinmann u. Schreyögg [2000]; Möller u. Dörrenberg [2003]).

Die Managementaufgaben lassen sich dabei in Zielsetzung, Planung, Entscheidung, Realisierung und Kontrolle unterteilen. Aufgaben der Zielsetzung bilden den Beginn des Prozesses, bei dem die Ziele aus Unternehmens-, Abteilungs oder Projektzielen abgeleitet werden. Die Planung befasst sich mit der Dimensionierung der Ressourcen, Zeiten und des Budgets sowohl kurzfristig als auch langfristig. Die Aufgabe der Entscheidung besteht darin gezielt eine Option auf der Basis verschiedener Handlungsoptionen auszuwählen. Die Realisierung stellt durch Anleitung und Führung, durch die Sicherung der Ressourcen sowie des Budgets und der Einhaltung von ﬁxen Terminierungen die Wertschöpfung für das Unternehmen sicher. Diese Aufgaben verlaufen kreisförmig und die letzte Aufgabe, die Kontrolle, misst und vergleicht das Ergebnis der Realisierung mit der Planung. Abweichungen, die bei diesem Vergleich typisch sind, werden in der Planungsoder Zielfunktion erneut überdacht. Der Mittelpunkt in diesem kreisförmigen Verlauf ist die Kommunikation die typischerweise über mehrere Unternehmensbereiche, Abteilungen und Mitarbeiter erfolgen muss (Vgl. Steinmann u. Schreyögg [2000]; Dworatschek u. u. a. [1972]).

Das Projektmanagement enthält die Deﬁnitionen und Zielsetzungen die sowohl für ein Projekt als auch für das Management verwendet werden, jedoch mit einem anderen Geltungsbereich. Die Deﬁnition der Aufgaben im Projektmanagement bezieht sich daher auf das Projektziel, die Projektplanung, die Entscheidung alternativer Projektplanungen, die Projektsteuerung, die Projektkontrolle und die zentrale Projektkommunikation im kreisförmigen Verlauf. Typischerweise wird das Projekt in mehrere Phasen und Meilensteine strukturiert z. B. in die Auftragsklärung, den Projektstart, die Projektplanung, die Projektdurchführung und den Projektabschluss. Relevant ist auch, dass jedes Projektmanagement Vorhaben einen Aufwand bedeutet und im Resultat Zeit und Geld kostet. Ein abwägen des Projektumfangs ist daher wirtschaftlich notwendig. (Vgl. Gessler [2016]).

Deﬁnitionen und Zielsetzungen eines Projekts gehen klassischerweise davon aus, dass bereits zu Anfang bzw. vor Projektstart eines Projekts der vollständige Umfang und die Anforderungen eines Projekts deﬁniert werden können. Aus dem Umfang und den Inhalten ergibt sich ein Zeitplan sowie die möglichen Kosten des Projekts. Aus diesen Überlegungen leitet man das Dreieck des Projektmanagements ab, welches die Faktoren Inhalte, Termine und Kosten eines Projekts deﬁniert. Die Termine und Kosten sind vom Inhalt abgeleitete Größen. Mit anderen Worten ergibt sich aus dem Umfang des Projekts der Zeitplan und dessen Kosten. Aus diesen Faktoren entsteht ein Projektplan. Änderungen der Anforderungen im klassischen Projektmanagement wirken als Störfaktoren auf den Projektplan ein und gefährden das Projekt (Vgl. Litke [2007]).

Das agile Projektmanagement wird dem modernen Zeitalter mit immer komplexeren Umgebungen sowie wechselnden und instabilen Anforderungen gerecht, indem es diesen Störfaktor der Anforderungsänderungen des klassischen Projektmanagements aktiv aufgreift und Änderungen nicht als Ausnahme sondern als Regel ansieht. Das heißt, die Natur des agilen Projektmanagement besteht aus dem souveränen Umgang mit ständig wechselnden Anforderungen im Projektverlauf und versucht den Störfaktor der auf das klassische Projektmanagement einwirkt durch die Drehung des Projektmanagement-Dreiecks zu eliminieren. Im agilen Projektmanagement sind die Termine oder Kosten typischerweise deﬁniert, während der Inhalt eine abgeleitete Größe darstellt. Daraus folgt, dass nicht das gesamte Projekt vollständig geplant wird, sondern die Planungen sich lediglich auf kleine Anforderungsbereiche beziehen. Eine Anforderung wird daher zunächst in kleinere Arbeitspakete aufgeteilt und typischerweise iterativ bearbeitet bis die Anforderung, aus der die Arbeitspakete abgeleitet wurden, bearbeitet ist. Sowohl das klassische als auch das agile Projektmanagement lassen sich kombinieren zum hybriden Projektmanagement. Dies ist dann sinnvoll, wenn stabile Anforderungen durch das klassische Projektmanagement bearbeitet werden sollen (Vgl. Timinger [2017]; Preußig [2018]).

2.3 Einordnung der Kommunikation in das Projektmanagement

Die Reduktion auf ein Sender und Empfänger Prinzip und die Modelle der Kommunikation werden in der aktuellen Projektmanagement Literatur, die sich mit dem Thema der Kommunikation befasst, als nicht ausreichend kritisiert und durch ein ein theoretischsystemisch-konstruktivistisches Kommunikationsmodell ersetzt. In diesem werden insgesamt 34 Funktionen der Projektkommunikation heraus gearbeitet, die auf mehreren Ebenen wirken (Vgl. Freitag [2016]).

Dies verdeutlicht die Komplexität und vielen Facetten der Kommunikation, welche daher auch im Projektmanagement vollständig zum Tragen kommen und darüber hinaus an Komplexität zunimmt. Die Kommunikation ist aber nicht an einem fest deﬁnierten Punkt auszumachen z. B. bei der Zieldeﬁnition oder der Ressourcen-Planung, viel mehr kommt die Kommunikation in jeder Projektphase und während dem gesamten Verlauf des Projekts zum Einsatz und wird daher als die Grundlage des Projektmanagements deﬁniert (Vgl. Zulch [2014]). Das heißt von der Anforderungsklärung mit dem Kunden über die Projektbearbeitung mit den Mitarbeitern bis zum Projektabschluss und der Übergabe begleitet die Kommunikation das Projekt. Die Konsequenz daraus ist, dass die Kommunikation an jeder Abzweigung vom Projektmanagement unterschiedlich eingesetzt werden kann und sich dieser individuelle Einsatz auf das Projekt auswirkt. Die folgende Graﬁk soll diesen Sachverhalt verdeutlichen.

Übersicht der Rolle der Kommunikation im Projektmanagement

Aus dieser Tatsache folgt, dass auch die Projektmanagement Methoden oder Herangehensweisen unter dem Einﬂuss der Kommunikation stehen und implizit auf den Projektverlauf und seinen Erfolg wirken.

2.4 Scrum

Einen agilen Ansatz für das Projektmanagement stellen Scrum oder Kanban dar. Die Anfänge von Scrum entstammen einem Bericht im Harvard Technology Review mit einem Vorschlag für eine neue Vorgehensweise zur Durchführung von Projekten. Dieser Vorschlag beinhaltet eine Analogie zur Sportart Rugby, bei der sich das Team die Bälle innerhalb der Mannschaft selbst zuwirft und das Spiel als eine Einheit bestreitet. Die Analogie spielt auf eine Projektstruktur mit einem eigenverantwortlichen Team an. Kritisiert wird mit diesem Vorschlag auch der sequentielle Ansatz der Projektdurchführung, bei der zunächst die Planungsphase vollständig abgeschlossen sein muss, bevor mit der Umsetzungsphase begonnen werden kann (Vgl. Takeuchi u. Nonaka [1986]). Dieser Ansatz wurde durch Jeﬀ Sutherland und Ken Schwaber weiter verfolgt und im Ergebnis entstanden formale Regeln für den Einsatz von Scrum (Vgl. Sutherland [2020]).

Der Kern von Scrum wird durch diese Regeln beschrieben, die im laufe der Zeit weiterentwickelt wurden. Dieser Kern besteht aus vier Ereignissen, drei Rollen und drei Artefakten. Der praktische Einsatz von Scrum folgt diesen Regeln, wobei die Umsetzung individuell deﬁnierbar ist. Dies ermöglicht einen ﬂexiblen Einsatz von Scrum und steigert den praktischen Nutzen. Im Kern von Scrum sind die Rollen Product Owner, Scrum Master und das Entwicklungsteam deﬁniert. Der Product Owner ist eine Person die sich sich mit dem Produkt und seinen Inhalten befasst. Er deﬁniert, priorisiert und beschreibt das Produkt sowie seine Eigenschaften und verantwortet damit den ökonomischen Erfolg des Produkts. Die Rolle des Scrum Masters bezeichnet eine Person, welche für die Einführung, die Akzeptanz sowie das allgemeine Regelwerk von Scrum im Unternehmen und des Projekts verantwortlich ist. Diese Rolle ist weiterhin verantwortlich für die Beseitigung von Störungen und Hindernissen während der Bearbeitung. Das schließt unter anderem Störungen in der Kommunikation, Störungen der Zusammenarbeit und Störungen zwischen den Rollen ein. Schließlich hat das Entwicklungsteam, welches aus mindestens drei bis maximal neun Personen besteht, die Aufgabe die Produktfunktionalitäten in der priorisierten Reihenfolge zu produzieren. Das Entwicklungsteam arbeitet dabei vollständig autark und erhält keine Vorschriften wie die Aufgaben zu bearbeiten sind. Das Entwicklungsteam ist typischerweise fachübergreifend aufgestellt und besteht, z. B. bei einem Softwareprojekt, nicht nur aus Softwareentwicklern, sondern auch aus Testern. Darüber hinaus wird die Anforderung vom Entwicklungsteam bewertet, der Umfang geschätzt und kleinere Arbeitspakete, sogenannte Tasks, zur Bearbeitung innerhalb eines kurzen Zeitintervalls erstellt.

Dieses Zeitintervall wird Sprint genannt und es besteht aus mindestens einer bis zu maximal vier Wochen. Das Ergebnis der Bearbeitung des Sprints wird als Inkrement bezeichnet. Die Tasks werden für einen Sprint geplant und ergeben ein Sprintziel des Teams. Ein Sprint wird nicht verlängert. Ein vorzeitiger Abbruch ist möglich, wenn sich die Anforderungen gravierend verändert haben. Die neuen Anforderungen werden dann erneut vom Entwicklungsteam bewertet, geschätzt und mit einem neuen Sprint bearbeitet. Die geplanten Tasks eines Sprints bilden auch den Sprint Scope, der während einem laufenden Sprint nicht verändert werden sollte. Der Ablauf von Scrum ist in Abbildung 2 dargestellt (Vgl. Sutherland [2020]; Preußig [2018]).

Artefakte in Scrum werden durch das Product Backlog, das Sprint Backlog und das Product Increment deﬁniert. Das Product Backlog stellt die priorisierte Sammlung der Produktanforderungen dar. Der Product Owner verantwortet das Product Backlog, welches bei Projektstart nicht die gesamten Anforderungen enthält und bewusst nicht vollständig ist. Im Product Backlog werden ﬂexibel weitere Anforderungen aufgenommen, die bei der Bearbeitung des Projekts entstehen. Aus dem Product Backlog werden nach der vorgegebenen Priorisierung die Tasks für einen Sprint übernommen, welche damit das Sprint Backlog bilden. Dieses dient bei der Bearbeitung in einem Sprint dazu den aktuellen Zustand der Tasks und dessen Fertigstellungsgrad transparent für alle Beteiligten darzustellen. Schließlich entsteht ein Product Increment sowohl aus der Summe der vergangenen als auch dem abgeschlossenen Sprint. Zusätzliche Anforderungen von Scrum fordern diese Transparenz und Deﬁnitionen die klarstellen wann ein Task im Sprint begonnen werden kann oder als abgeschlossen gilt. Hierzu wird die Deﬁnition of Ready sowie die Deﬁnition of Done verwendet, die zu Beginn des Projekts festgelegt und im Verlauf des Projekts weiterentwickelt wird. Die Deﬁnition of Ready ermöglicht eine Festlegung wann ein Task in einen Sprint aufgenommen und bearbeitet werden kann z. B. durch Abhängigkeiten. Die Deﬁnition of Done regelt die Bedingungen oder Qualitätsmerkmale, wann ein Task als abgeschlossen gilt. Bedingungen können unter anderem erfolgreiche Tests oder notwendige Dokumentationen im Quellcode sein. Qualitätsmerkmale wiederum sichern die besprochene Qualität der Anforderung und Produkteigenschaft.

Ereignisse sind Arbeitsbezogene Scrum Meetings die einem deﬁnierten Zeitfenster unterliegen, welches vom Team nicht überschritten werden sollte. Im Daily-Scrum werden täglich innerhalb von 15 Minuten von jeder Person im Entwicklungsteam die erledigten sowie anstehenden Tasks dargestellt und auf eventuelle Probleme hingewiesen. Das Daily dient primär zur Informationsweitergabe und nicht zur Problemlösung. Bei Problemen kann weitere Hilfe aus dem Team angefordert werden. Product Owner und Scrum-Master partizipieren im Daily, wenn diese ebenfalls Tasks aus dem Sprint bearbeiten. Das Ereignis des Sprint-Planning ist auf ein Zeitfenster von 120 Minuten je Woche festgelegt und in diesem wird festgestellt welche und wie diese Tasks im nächsten Sprint bearbeitet werden. Die Summe der Tasks im Sprint Backlog wird nach einer Überarbeitung des Scrum Guide nicht mehr als Versprechen (commitment), sondern als Prognose (forecast ) des Entwicklungsteams bezeichnet, weil die Qualität des Produkts Vorrang vor einem commitment haben sollte (Vgl. Scrum.org [2011]). Die Tasks werden aus dem Product Backlog entnommen, welche im Backlog Reﬁnement sowohl vom Entwicklungsteam als auch vom Product Owner genauer beschrieben werden. Diese Aufgabe ist ein kontinuierlicher Prozess und dient zur Backlog-Pﬂege und -Weiterentwicklung. Das Sprint Review ist ein Ereignis von 60 Minuten in dem die Inhalte des Sprints nach dessen Abschluss vom Entwicklungsteam den Stakeholdern und Kunden vorgestellt werden. Diese bewerten das fertiggestellte Inkrement und geben notwendiges Feedback an das Entwicklungsteam über die abgeschlossenen Aufgaben. Das schließt Missverständnisse der Anforderung sowie neue Erkenntnisse oder Anforderungen ein. Im Ereignis der Sprint-Retrospektive reﬂektiert das gesamte Team den abgeschlossenen Sprint und die Arbeitsweise im Zeitfenster von 45 Minuten je Sprintwoche, um mögliche Potenziale und Verbesserungen in der Arbeitsweise zu erreichen. Die Retrospektive soll oﬀen und ehrlich ablaufen, um das Verbesserungspotenzial zu steigern und Probleme zu identiﬁzieren, welche die Arbeit behindern und damit die Eﬃzienz senken (Vgl. Sutherland [2020]; Preußig [2018]).

3 Untersuchung der Kommunikation in Scrum

Die Ereignisse in Scrum lassen einen informellen Kommunikationsﬂuss während der Bearbeitung eines Projekts entstehen, den das gesamte Scrum-Team einschließt. Zusätzlich bildet sich eine kontinuierliche Kommunikation mit den Kunden und Stakeholdern. Das gilt aber nicht nur für die Ereignisse, auch die Artefakte haben Einﬂuss auf die Kommunikation im Projekt.

Scrum führt durch das Daily zum täglichen Informationsaustausch aller Beteiligten. Die Zeit im Daily ist auf 15 Minuten begrenzt, es soll aber jeder Teilnehmer kommunizieren. Diese tägliche Kommunikation resultiert in einer Transparenz und mit dieser ergibt sich die Möglichkeit von Rückfragen und Feedback der anderen Teammitglieder. Diese Kommunikationsmaßnahme steigert nicht nur den Informationsﬂuss, sondern ermöglicht es dem Scrum-Team zeitnah bei etwaigen Problemen Handlungsmaßnahmen einzuleiten. Eine Handlungsmaßnahme kann z. B. die Unterstützung anderer Teammitglieder oder eine Rücksprache mit dem Kunden sein, um die Anforderung zu besprechen. Die Zeitbegrenzung von 15 Minuten soll die Themen auf das wesentliche reduzieren. Hierzu erläutert jedes Teammitglied welche Themen gestern bearbeitet wurden, welche für heute geplant sind und ob es Hindernisse (impediments) im Bezug auf das Sprintziel gibt. Themen die nicht im Daily besprochen werden können, weil sie die Zeitbegrenzung überschreiten, können in einem Anschlusstermin ggfs. im kleineren Kreis erörtert werden, um eine Problemlösung zu ermöglichen.

Untersuchungen zeigen, dass das Daily als die wichtigste kommunikative Komponente in Scrum gilt, welche alle Projektteilnehmer verbindet und zusammenhält (Vgl. Pikkarainen u. a. [2008]; B. Ramesh u. a. [2010]). Dem Daily werden wegen der Zeitbegrenzung nicht nur positive Aspekte zugeschrieben, da es nicht primär der Problemlösung dient und weitere Meetings, dies gilt insbesondere für Softwareentwicklungsprojekte, zur Problemlösung erforderlich macht (Vgl. Paasivaara u. a. [2009]). Die Vermeidung von Missverständnissen ist ein hohes Gut in der Kommunikation, um dies im Daily anzustreben sollten alle Projektteilnehmer am Daily teilnehmen, dies triﬀt insbesondere auf global verteilte Projekte zu (Vgl. Wijnands u. van Dijk [2007]).

Herausfordernd für die Scrum-Teams kann die informelle Ebene der Kommunikation sein, die durch Scrum gefördert und im agilen Manifest zur Softwareentwicklung, dem Scrum entspricht, gefordert wird. Die informelle Art zieht Kommunikation von Angesicht zu Angesicht den formellen Dokumentationen, formellen E-Mails oder detaillierten Plänen vor. Insbesondere global verteilte, interkulturelle oder in Scrum unerfahrene Teams haben Schwierigkeiten mit der informellen Kommunikation, sodass das Daily fünf Minuten dauert, wenig angesprochen und die Team-Kommunikation somit behindert wird (Vgl. Pikkarainen u. a. [2008]; Hummel u. a. [2013]; Scrum Alliance).

Im Product Backlog Reﬁnement werden kontinuierlich neue Erkenntnisse, Anforderungen und Beschreibungen zu den bestehenden Tasks im Product Backlog eingearbeitet. Ein probates Mittel in der Praxis für die fachliche Beschreibung der Anforderung und Tasks sind User Stories. Eine User Story dokumentiert die Anforderung aus Kundensicht. Dieser Prozess des Reﬁnements stellt ein kommunikatives Meeting dar, in dem die Anforderung im Team besprochen und die notwendige Zeit geschätzt werden kann. Es eröﬀnet dem Entwicklungsteam die Möglichkeit Rückfragen mit dem Product Owner zu besprechen und Unklarheiten zu beseitigen, bevor der Task in einem Sprint eingeplant wird. In der Praxis nehmen auch Stakeholder und Kunden am Reﬁnement teil, wenn diese fachliche Informationen zur Produkteigenschaft liefern können (Vgl. Foegen u. a. [2017]). Weiterhin können hier Hindernisse oder Widersprüche in der Anforderung erkannt und vermieden werden, die im Entwicklungsprozess auftreten würden. Im Reﬁnement lassen sich zudem Überarbeitungen an bereits vorhandenen Anforderungen einarbeiten, die nach neuen Erkenntnissen z. B. durch Feedback im Sprint Review, aufgenommen werden.

Das Product Backlog Reﬁnement ist kein deﬁniertes Ereignis im Scrum Kern. Dies zeigt, dass auch die Artefakte von Scrum, in diesem Fall das Product Backlog, den kommunikativen Prozess unterstützen und im gesamten Scrum-Team fördern (Vgl. Garcia u. a. [2019]). Das Sprint Backlog ist keine Ausnahme, weil es im Daily typischerweise dazu verwendet wird visuell den aktuellen Status des Sprint an alle Projektbeteiligten zu kommunizieren (Vgl. Hummel u. a. [2013]). Diese visuelle Präsentation steigert den Kommunikationsﬂuss im Daily durch Rückfragen der Projektteilnehmer. Implizit wirken die Artefakte daher auf die Kommunikationsfrequenz und den Projektverlauf.

Den Beginn eines Sprints markiert das Ereignis des Sprint Planning. Es dient einerseits zum Informationsaustausch zwischen dem Entwicklungsteam und dem Product Owner darüber welche Themen bearbeitet werden sollen und prägt das fachliche Verständnis für diese Themen. Hierzu wird das priorisierte Product Backlog herangezogen, welches die Tasks enthält. Andererseits legt das Entwicklungsteam selbstständig die Summe der Aufgaben fest, die potenziell bearbeitet werden können und gibt damit eine Prognose ab. Diese Aufgaben sollten das Sprintziel erfüllen. Im Sprint Planning kann die Deﬁnition of Ready überprüft werden, um zu prüfen ob der Task bereit für die Umsetzung ist. Weiterhin können unklare Anforderungen kommunikativ präzisiert und das Verständnis für alle Beteiligten gefestigt werden. Das Sprint Planning kann weiterhin als Informationsverteilung für die Kunden und Stakeholder eingesetzt werden, welche Themen als nächstes bearbeitet werden und wie das Verständnis des Entwicklungsteam für die fachlichen Anforderungen ist (Vgl. Pikkarainen u. a. [2008]).

Sprint Reviews werden zusammen mit den Kunden und Stakeholdern durchgeführt. Das Inkrement dient zur Präsentation des erreichten Ergebnisses. In diesem Fall unterstützt das Scrum Artefakt demnach den Kommunikationsprozess im Sprint Review. Der Kunde sieht die Ergebnisse des Sprints und kann anhand des Inkrements Rückfragen stellen und Feedback geben. Im Sprint Review kommt die informelle Kommunikation zum Tragen und Kunden sowie Stakeholder können dem Entwicklungsteam direkt Fragen stellen und die Anforderung vergleichen (Vgl. Pikkarainen u. a. [2008]). Die Präsentation des Inkrement zeigt darüber hinaus das Verständnis der fachlichen Anforderung aus der Sicht des Entwicklungsteams und gibt dem Kunden oder Product Owner erneut die Möglichkeit die Anforderung zu präzisieren, wenn dies notwendig sein sollte.

In der Retrospektive soll der vergangene Sprint oﬀen und ehrlich mit dem gesamten ScrumTeam reﬂektiert werden, um Probleme zu vermeiden, die einen negativen Eﬀekt auf das Projekt haben. Dieses Ereignis unterstützt die informelle Kommunikation und trägt zur künftigen Beseitigung von Hindernissen und Störungen der Kommunikation bei, wenn eine Umgebung geschaﬀen wird, in der die oﬀene Kommunikation möglich ist. Der Scrum Master kann dabei unterstützen und anleiten, um die Eﬀektivität und Produktivität zu steigern (Vgl. Hummel u. a. [2013]). Für die Umsetzung der Retrospektive ergeben sich daher mehrere Ansätze von schematischen Fragestellungen, Retrospektiven-Phasen bis hin zu einem Retrospektive-Spiel (Vgl. Marshburn u. Sieck [2019]).

Die Maximalgröße der Scrum-Teams kann in größeren Projekten zu Problemen führen, daher werden mehrere Scrum-Teams gebildet, die unterschiedliche Aufgaben und Bereiche wahrnehmen. Der Kommunikationsﬂuss wird in der Praxis durch ein Scrum of Scrum gewährleistet, bei dem jedes Team einen Vertreter benennt der an einem Teamübergreifenden Meeting teilnimmt und die Informationen weitergibt. Dieses Scrum of Scrum ﬁndet nicht täglich, sondern zwei bis drei mal in einer Woche statt (Vgl. Qurashi u. Qureshi [2014]).

Die Artefakte, Rollen und Ereignisse fördern die Kommunikation im Projekt. Sie können die Kommunikation aber auch behindern, wenn die falschen Medien zur Kommunikation eingesetzt werden oder ein Wechsel des klassischen Projektmanagement zu Scrum durchgeführt wird (Vgl. Vidgen u. Wang [2009]).

4 Diskussion

Die Auswirkungen von Scrum auf das Projekt werden durch den Anteil der Projektkommunikation, die durch Scrum entsteht, am Beispiel einer Arbeitsbzw. Sprintwoche untersucht. Dieser Anteil der Kommunikation nimmt einen reservierten Raum in der Projektzeit ein, der nicht für die Bearbeitung der Aufgaben zur Verfügung steht. In der folgenden Analyse werden unter anderem die Maximalangaben des Scrum Regelwerks und Studien genutzt, welche die Abweichungen des Scrum Regelwerks in der Praxis dokumentieren.

4.1 Einﬂuss von Scrum auf die Projektkommunikation

Die Kommunikation im Projekt wird in hohem Maße durch Scrum und das Regelwerk beeinﬂusst. Das Daily wird als kommunikationsfördernd, Bindeglied des Teams und wichtig für den täglichen Informationsaustausch sowie als Erhöhung der Transparenz im Projekt angesehen. Gemessen an der Maximalangabe von 15 Minuten reserviert das Daily zur Projektkommunikation insgesamt 75 Minuten in einer Fünftagewoche. Das Sprint-Planning reserviert 120 Minuten, das Review 60 Minuten und die Retrospektive 45 Minuten. Summiert man diese Anteile ergeben sich insgesamt fünf Stunden für die Kommunikation je Woche, wenn die Maximalangaben ausgeschöpft werden.

In dieser Überlegung ist das Product Backlog Reﬁnement, eine Überziehung der Soll-Werte und zusätzliche Kommunikation, die z. B. zur Problemlösung nach dem Daily stattﬁndet, nicht inbegriﬀen. Ausgehend von einer 40 Stunden Woche ergibt sich ein Anteil von 12,5% der Projektzeit, der mindestens für die Kommunikation reserviert ist, wenn Scrum Anwendung ﬁndet. Das Product Backlog Reﬁnement ist nicht vorgeschrieben, sollte in seiner Anwendung jedoch 10% der verfügbaren Kapazität des Entwicklungsteams nicht überschreiten (Vgl. Deemer u. a. [2012]). In Scrum-Teams, die ein Product Backlog Reﬁnement durchführen, beläuft sich der Anteil der für die Kommunikation reserviert ist demnach auf 22,5%.

Studien zeigen, dass Scrum in der praktischen Ausführung variiert und z. B. das Daily die Grenze von 15 Minuten überschreitet, wenn das Scrum-Team die Regelgröße erreicht. Das gilt auch für das Planning und die Retrospektive (Vgl. Diebold u. a.). Berücksichtigt man lediglich die Angabe von 30 Minuten steigt der Anteil der Kommunikation auf mindestens 15% (ohne Reﬁnement) oder 25% (mit Reﬁnement). Diese Quantiﬁzierung zeigt den Anteil der allgemeinen Projektkommunikationssituation, die durch die Anwendung des Scrum Regelwerk im Projekt entsteht.

Die Kommunikation in Scrum basiert dabei auf der informellen Ebene und hebt diese hervor. Auf dieser Ebene kann es zu Konﬂikten in den Rollen kommen, wenn ein Scrum Master oder Product Owner zuvor als klassischer Projektmanager tätig war und sich nicht auf die Übertragung der Verantwortung an das Entwicklungsteam und informelle Kommunikation einlassen kann (Vgl. Vidgen u. Wang [2009]).

Weiterhin kann die Informelle Kommunikation zu einem Problem führen, wenn die Kommunikation intern wie extern überstrapaziert wird (Vgl. Vidgen u. Wang [2009]). Eine Nichteinhaltung der Soll-Werte in den Scrum Ereignissen führt daher schnell zu signiﬁkanten Steigerungen der Kommunikationsaufwände, die von der eﬀektiven Projektzeit zur Bearbeitung der Aufgaben abgezogen werden müssen und im Ergebnis zum Hindernis für das Projekt werden können.

Auf der anderen Seite stellt eine unzureichende informelle Kommunikation eine Herausforderung oder sogar ein Hindernis von agilen Projekten dar (Vgl. Adolph u. a. [2012]). Mit anderen Worten ist das Scrum Team herausgefordert die Kommunikationsintensität im Auge zu behalten, um den richtigen Grad der informellen Kommunikation anzuwenden.

Die informelle und direkte Kommunikation erfordert auch, dass jede Person im ScrumTeam bzw. Entwicklungsteam über die notwendigen Kommunikationsfähigkeiten verfügt. Im Sprint Review wird vom Entwicklungsteam die Präsentation des Inkrements und der fertiggestellten Aufgaben gefordert. Dies kann bei introvertierten Personen oder unzureichender Kommunikation zu Schwierigkeiten während der Präsentation und Darstellung der Ergebnisse führen. Zusätzlich könnten sich Personen mit schwach ausgeprägten Kommunikationsfähigkeiten im Daily zurückhalten oder gehemmt sein, Probleme oﬀen anzusprechen. Indirekt kann sich die informelle Kommunikation daher auf den Projekterfolg auswirken. Das gleiche gilt für die Retrospektive, die Probleme und Hindernisse für künftige Sprints ausräumen soll oder das Product Backlog Reﬁnement, in welchem die fachlichen Anforderungen detailliert werden.

Diese Ausführungen machen deutlich, dass Scrum den Kommunikationsﬂuss des Projekts durch das Regelwerk deutlich steigert. Ausschlaggebend für den kommunikativen Einﬂuss von Scrum auf das Projekt sind sowohl die Artefakte als auch die Ereignisse des Regelwerks die sowohl die interne als auch externe Kommunikation fördern. Betrachtet man die Kommunikation als „Lebenselexier“ (Vgl. Drinkwater [2007]; Awati [2010]) für ein Projekt, dann beeinﬂusst Scrum das Projekt im positiven Sinne und wirkt sich auf den Projekterfolg durch die kommunikationsfördernden Maßnahmen aus, wenn der Anteil der Kommunikation die Soll-Werte nicht überschreitet und die Projekteﬃzienz nicht gehemmt wird.

4.2 Auswirkungen der Kommunikation auf ein Projekt

Die Auswirkungen auf ein Projekt ergeben sich durch den Anteil der Kommunikation, den Scrum verursacht. Ausgehend von einem Anteil von 1/4 der für die Kommunikation reserviert ist, verbleiben 75% der Zeit zur Bearbeitung der geplanten Projektaufgaben (Tasks). Themen, die nicht im Daily, dem Reﬁnement, dem Planning oder der Retrospektive geklärt werden können, benötigen zusätzlich Zeit und senken den restlichen Anteil von 75% der eﬀektiven Projektzeit.

Die Aufwendungen von 25% stellen aus Sicht des Scrum Regelwerks keine verlorene Zeit dar, sondern werden als notwendig erachtet, um Probleme aufzudecken, Anforderungen festzustellen, ﬂexibel Änderungen zu ermöglichen, Prioritäten zu vergeben und den Kommunikations und Informationsﬂuss aufrecht zu erhalten. Das kontinuierliche Feedback durch die Kunden und Stakeholder im Sprint Review führt dazu, dass sich das Projekt in die notwendige und vom Kunden gewünschte Richtung entwickelt. Kundenanforderungen, die nicht im Sinne des Kunden umgesetzt wurden, können sofort besprochen und zeitnah korrigiert werden. Zusätzlich eröﬀnet sich die Möglichkeit von neuen Gedanken durch die Präsentation des Ergebnisses, aus dem neue fachliche Anforderungen entstehen, die zuvor nicht bedacht wurden.

Negative Auswirkungen auf das Projekt sind durch den falschen Einsatz von Scrum, den falschen Umgang mit der informellen Kommunikation oder einer übermäßigen Kommunikation zu erwarten. Das muss von interkulturellen oder global verteilten Teams, von Personen mit mangelnden Kommunikationsfähigkeiten oder im Fall einer überstrapazierenden Kommunikation berücksichtigt werden.

Der Einsatz der informellen Kommunikation wirkt sich dann positiv auf das Projekt aus, wenn das Scrum-Team mit der informellen Kommunikation und dem schmalen Grad umzugehen weiß. Das Feedback des Kunden, z. B. im Sprint-Planning, kann vom Entwicklungsteam hinterfragt und das Verständnis der Anforderung überprüft werden. Die oﬀene Kommunikationsplattform in der Retrospektive ermöglicht es Hindernisse oder Kommunikationsstörungen, die auf folgende Sprints negativen Einﬂuss hat, zu beseitigen.

Weiterhin führt die Transparenz im Daily dazu, dass Probleme, die den Sprint gefährden könnten, für das Team sichtbar werden. Diese Transparenz bewirkt, dass Probleme die Aufgabenerfüllung des Sprints nicht gefährden. Diesen Informationsaustausch stützt Scrum im gesamten Produktentwicklungsprozess. Positive Auswirkungen ergeben sich daher dann, wenn das Team die selbstständige Kultur versteht. Wichtig dafür ist das Verständnis das Spiel, entsprechend der Rugby Analogie, gemeinsam zu bestreiten.

5 Zusammenfassung

Die Kommunikation kann als Grundlage für ein Projekt angesehen werden und lässt sich mit ihrer Komplexität im gesamten Projektmanagement einordnen. Das agile Projektmanagement mit Scrum führt gegenüber dem traditionellen Projektmanagement zu einer Übertragung der Verantwortung an das Entwicklungsteam. Diese Vorgehensweise nutzt einen iterativen Produktentwicklungsprozess und ermöglicht die transparente und priorisierte Bearbeitung fachlicher Anforderungen. Zwar geben die Scrum Regeln eine Orientierungshilfe, jedoch wird die praktische und technische Umsetzung dieser Regeln für jedes Projekt individuell deﬁniert.

Die Arbeit hat gezeigt, dass Scrum einen signiﬁkanten Einﬂuss auf die Kommunikation im Projekt hat und sich kommunikationsfördernd auswirkt. Dieser Einﬂuss reserviert einen Raum für den Mindestanteil der Kommunikation im Projekt und nutzt die informelle Kommunikation für den direkten Austausch sowie den transparenten Informationsﬂuss intern wie auch extern. Kommunikationsfördernd können bei der Anwendung von Scrum die Ereignisse als auch die Artefakte sein, die das Regelwerk im Kern vorsieht. Die Transparenz, die z. B. durch das Daily im Scrum-Team entsteht, fördert diesen Kommunikationsﬂuss zusätzlich und trägt zur Lösung von auftretenden Problemen bei.

Die informelle Kommunikation und Präsentation des Inkrements nach einem Intervall sichert den Umfang des Projekts sowie die fachlichen Anforderungen. Der Kunde erhält die Möglichkeit das Feedback direkt an das Entwicklungsteam zu übermitteln und das Entwicklungsteam kann das Verständnis für die fachlichen Anforderungen sichern und das Feedback im nächsten Intervall einﬂießen lassen. Das Sprint Review bewirkt damit, dass sich das Projekt in die vom Kunden gewünschte Richtung entwickelt.

Scrum ist nicht automatisch ein Garant für einen erfolgreichen Projektablauf. Der oﬃzielle Scrum-Guide fasst Scrum als „lightweight, simple to understand [but] diﬃcult to master“ (Vgl. Schwaber u. Sutherland [2011]) zusammen. Die Berücksichtigung des Anteils der Kommunikation und Beachtung der Soll-Werte führt dazu, dass die Kommunikation nicht überstrapaziert wird. Das Team ist herausgefordert die Kommunikationsintensität im Auge zu behalten und schwach ausgeprägte Kommunikationsfähigkeiten zu fördern.

Zusammenfassend lassen sich mit dem bedachten Umgang von Scrum die relevanten Faktoren Umfang, Kosten und Zeit eines Projekts optimieren. Scrum bewirkt mit seinem Einﬂuss auf die Kommunikation einen positiven Impuls auf das Projekt, wenn sich das Team als Einheit versteht, die Verantwortung wahrgenommen und die Kultur vom ScrumTeam verstanden wird.

6 Literatur

Adolph u. a. 2012
Adolph, Steve ; Kruchten, Philippe ; Hall, Wendy: Reconciling perspectives: A grounded theory of how people manage the process of software development. In: Journal of Systems and Software 85 (2012), Nr. 6, S. 1269–1286

Awati 2010
Awati, Kailash: Obstacles to project communication. In: http://www. projectsmart.co.uk/obstacles-to-projectcommunication.html (2010)

B. Ramesh u. a. 2010
B. Ramesh ; L. Cao ; R. Baskerville: Agile requirements engineering practices and challenges: an empirical study. In: Information Systems Journal 20 (2010)

Deemer u. a. 2012
Deemer, Pete ; Benefield, Gabrielle ; Larman, Craig ; Vodde, Bas: A lightweight guide to the theory and practice of scrum. In: Ver 2 (2012), S. 2012

Diebold u. a.
Diebold, Philipp ; Ostberg, Jan-Peter ; Wagner, Stefan ; Zendler, Ulrich: What do practitioners vary in using scrum?

Drinkwater 2007
Drinkwater, Ann: Communication: The Life Blood of a Project. In: Retrieved from (2007)

Dworatschek u. u. a. 1972
Dworatschek, S. ; u. a.: Management — für alle Führungskräfte in Wirtschaft und Verwaltung. In: Bd. l, II, Begleitbücher zur gleichnamigen Fortbildungs-Femsehserie, Stuttgart (1972)

Foegen u. a. 2017
Foegen, Jörn M. ; Battenfeld, Jörg ; Croome, David ; Dorn, Manuel ; Gans ser, Caroline: Der ultimative Scrum Guide 2.0. Vierte korrigierte Auﬂage. Darmstadt : wibas, 2017. — ISBN 9783981583755

Freitag 2016
Freitag, Matthias: Kommunikation im Projektmanagement, Dissertation, 2016. ht tp://dx.doi.org/10.1007/978–3–658–13388–7 . — DOI 10.1007/978–3–658–13388– 7

Garcia u. a. 2019
Garcia, Andrei ; da Silva, Tiago S. ; Silveira, Milene S.: Artifact-Facilitated Communication in Agile User-Centered Design. In: Kruchten, Philippe (Hrsg.) ; Fraser, Steven (Hrsg.) ; Coallier, François (Hrsg.): Agile Processes in Software Engineering and Extreme Programming. Cham : Springer International Publishing, 2019. — ISBN 978–3–030–19034–7, S. 102–118

Geert H.. Hofstede 1980
Geert H.. Hofstede: Culture’s Consequences: International diﬀerences in work related values. Sage publications, 1980

Gessler 2016
Gessler, Michael (Hrsg.): Kompetenzbasiertes Projektmanagement (PM 3): Hand buch für die Projektarbeit, Qualiﬁzierung und Zertiﬁzierung auf Basis der IPMA Com petence Baseline Version 3.0. 8. überarbeitete Auﬂage. Nürnberg : GPM Deutsche Gesellschaft für Projektmanagement e.V, 2016. — ISBN 9783924841409

Hall 1959
Hall, Edward T.: The Silent Language.-Garden City, NY. 1959

Hummel u. a. 2013
Hummel, Markus ; Rosenkranz, Christoph ; Holten, Roland: The Role of Com munication in Agile Systems Development: An Analysis of the State-of-the-Art. In: Business & Information Systems Engineering 5 (2013). http://dx.doi.org/10.10 07/s12599–013–0282–4. — DOI 10.1007/s12599–013–0282–4

Litke 2007
Litke, Hans-Dieter: Projektmanagement: Methoden, Techniken, Verhaltensweisen, evolutionäres Projektmanagement. 5., erw. Auﬂ. München : Hanser, 2007. http: //dx.doi.org/10.3139/9783446413870 . http://dx.doi.org/10.3139/978344641 3870. — ISBN 3446413871

Marshburn u. Sieck 2019
Marshburn, David ; Sieck, J. P.: Dont Break the Build: Developing a Scrum Retrospective Game. In: Proceedings of the 52nd Hawaii International Conference on System Sciences, 2019

Möller u. Dörrenberg 2003
Möller, Thor ; Dörrenberg, Florian: Projektmanagement. München u. a. : Ol denbourg, 2003 (WiSorium Wirtschaftsund Sozialwissenschaftliches Repetitorium). http://dx.doi.org/10.1524/9783486700602 . http://dx.doi.org/10.1524/978 3486700602. — ISBN 9783486700602

Paasivaara u. a. 2009
Paasivaara, Maria ; Durasiewicz, Sandra ; Lassenius, Casper: Using scrum in distributed agile development: A multiple case study. In: 2009 Fourth IEEE Interna tional Conference on Global Software Engineering, 2009, S. 195–204

Pikkarainen u. a. 2008
Pikkarainen, M. ; Haikara, J. ; Salo, O. ; Abrahamsson, P. ; Still, J.: The impact of agile practices on communication in software development. In: Empirical Software Engineering 13 (2008), Nr. 3, S. 303–337. http://dx.doi.org/10.1007/s 10664–008–9065–9. — DOI 10.1007/s10664–008–9065–9 . — ISSN 1382–3256

Preußig 2018
Preußig, Jörg: TaschenGuide. Bd. 270: Agiles Projektmanagement: Scrum, User Stories, Task Boards & Co. 2. Auﬂage 2018. Freiburg : Haufe, 2018 https://www.ha ufe.de/. — ISBN 364812188X

Qurashi u. Qureshi 2014
Qurashi, Saja A. ; Qureshi, M. Rizwan J.: Scrum of scrums solution for large size teams using scrum methodology. In: Life Science Journal-ACTA Zhengzhou Univer sity Overseas Edition, online May 2014 (2014), Nr. 8. https://arxiv.org/pdf/14 08.6142

Schulz von Thun u. a. 2014
Schulz von Thun, Friedemann ; Ruppel, Johannes ; Stratmann, Roswitha: Mit einander reden. 2014

Schwaber u. Sutherland 2011
Schwaber, Ken ; Sutherland, Jeﬀ: The scrum guide. In: Scrum Alliance 21 (2011), S. 19

Scrum Alliance
Scrum Alliance: Scrum Alliance Code of Ethics for the Scrum Community. https: //www.scrumalliance.org/code-of-ethics, Abruf: 02.09.2020

Scrum.org 2011
Scrum.org: Commitment vs. Forecast: A Subtle But Important Change to Scrum | Scrum.org. https://www.scrum.org/resources/commitment-vs-forecast . Version: 2011, Abruf: 05.09.2020

Steinmann u. Schreyögg 2000
Steinmann, Horst ; Schreyögg, Georg: Management: Grundlagen der Unternehmensführung ; Konzepte Funktionen Fallstudien. 4., überarb. und erw. Auﬂ., Nachdr. Wiesbaden : Gabler, 2000 (Gabler-Lehrbuch). — ISBN 3409433120

Sutherland 2020
Sutherland, J. J.: Das Scrum Praxisbuch. 2020. — ISBN 9783593512365

Takeuchi u. Nonaka 1986
Takeuchi, Hirotaka ; Nonaka, Ikujiro: The New New Product Development Game. In: Harvarad Business Review (1986). https://hbr.org/1986/01/the-new-new-pr oduct-development-game

Timinger 2017
Timinger, Holger: Modernes Projektmanagement: Mit traditionellem, agilem und hybridem Vorgehen zum Erfolg. 1. Auﬂage. Weinheim : Wiley, 2017 http://www.wi ley-vch.de/publish/dt/books/ISBN978–3–527–53048–9/. — ISBN 3527530487

Vidgen u. Wang 2009
Vidgen, Richard ; Wang, Xiaofeng: Coevolving systems and the organization of agile software development. In: Information Systems Research 20 (2009), Nr. 3, S. 355–376

Watzlawick u. a. 2003
Watzlawick, Paul ; Bavelas, Janet B. ; Jackson, Don D.: Menschliche Kom munikation: Formen, Störungen, Paradoxien. Nachdr. der 10., unveränd. Auﬂ. 2000. Bern : Huber, 2003. — ISBN 3456834578

Wijnands u. van Dijk 2007
Wijnands, Ruud ; van Dijk, Ingmar: Multi-tasking Agile Projects: The Pressure Tank. In: Concas, Giulio (Hrsg.) ; Damiani, Ernesto (Hrsg.) ; Scotto, Marco (Hrsg.) ; Succi, Giancarlo (Hrsg.): Agile Processes in Software Engineering and Ex treme Programming. Berlin, Heidelberg : Springer Berlin Heidelberg, 2007. — ISBN 978–3–540–73101–6, S. 231–234

Zulch 2014
Zulch, B. G.: Communication: The Foundation of Project Management. In: Procedia Technology 16 (2014), S. 1000–1009. http://dx.doi.org/10.1016/j.protcy.2014 .10.054. — DOI 10.1016/j.protcy.2014.10.054 . — ISSN 22120173