Die Bedeutung von Kommunikation bei der agilenSystementwicklung
Aktueller Stand der Forschung
Agile Systementwicklung (SE) fordert eine Verlagerung des traditionellen,dokumentationsgetriebenen Kommunikationsparadigmas hin zu mehr informaler,mündlicher Kommunikation. Der momentane Wissensstand zur Umsetzung dieses sichverändernden Kommunikationsparadigmas von agilen SE-Projekten ist fragmentiert, daeine integrative Linse über verschiedene Studien fehlt. Der Beitrag bietet eine integrierteSichtweise auf die Rolle der Kommunikation bei agiler SE an, indem ein strukturierter,systematischer Literaturüberblick gegeben wird. Obwohl Kommunikation alsSchlüsselfaktor identifiziert wird stellen wir fest, dass nur wenige Studien explizit denKommunikationsprozess betrachten und somit das Wissen über Kommunikation und agileSE beschränkt ist. Als Ergebnis werden mehrere Forschungslücken und -richtungen fürzukünftige Forschung aufgezeigt.
DOI 10.1007/s11576-013-0376-0
Die Autoren
Markus Hummel, MSc (�)Dr. Christoph RosenkranzProf. Dr. Roland HoltenChair of Information SystemsEngineeringInstitute of Business InformaticsGoethe-Universität FrankfurtGrüneburgplatz 160323 Frankfurt am [email protected]:http://www.ise.wiwi.uni-frankfurt.de/
Eingegangen: 2012-09-25Angenommen: 2013-05-04Angenommen nachzwei Überarbeitungen durchProf. Dr. Peter Buxmann.Online publiziert: 2013-08-15
This article is also available in Englishvia http://www.springerlink.com andhttp://www.bise-journal.org: Hum-mel M, Rosenkranz C, Holten R (2013)The Role of Communication in AgileSystems Development. An Analysis ofthe State of the Art. Bus Inf Syst Eng.doi: 10.1007/s12599-013-0282-4.
Zusätzliche Information ist in derOnline-Version dieses Beitrags(doi: 10.1007/s11576-013-0376-0)enthalten.
Agile Systementwicklungsmethoden wieExtreme Programming (XP) (Beck 1999)oder Scrum (Schwaber und Beedle 2002)sind in der heutigen Softwareindustriesehr populär. Agilität bezeichnet die fort-währende Bereitschaft einer Systement-wicklungsmethode, schnell bzw. von sichaus Veränderungen zu bewirken, proak-tiv oder reaktiv Veränderungen einzube-ziehen und von Veränderungen zu ler-nen, während sie zum wahrgenommenenKundennutzen beiträgt (Conboy 2009,S. 340). Diese Methoden ergänzen itera-tive und prototypische Vorgehensweisender Systementwicklung (SE) und sie wur-den vorgeschlagen, um schnell auf sichverändernde Anforderungen reagieren zukönnen, indem kleine Releasezyklen undeine fortwährende Integration des Kun-den betont werden (Erickson et al. 2005).Agile SE-Methoden fußen auf Erfahrun-
gen der SE-Praxis aus der Vergangen-heit: Sie ersetzen strikte Kontrolle durchFlexibilität und Autonomie; der gesamteSE-Entwicklungsprozess wird nicht mehrim Vorhinein zeitlich geplant; und Fort-schritte werden in kleinen iterativen Pha-sen gemacht, da laufende Veränderungenund konstantes Feedback betont werden(Cao et al. 2009; Vidgen und Wang 2009).
Obwohl bereits einige Konzepte undRahmenwerke für die Forschung vorge-schlagen wurden und eine Vielzahl anStudien vorliegen, hinkt die Forschungder Praxis hinsichtlich des Verständnis-ses von agiler SE immer noch hinterher(Conboy 2009; Dingsøyr et al. 2012; Dy-bå und Dingsøyr 2008; Erickson et al.2005). Es existiert Nachholbedarf bei derLösung von Forschungsproblemen (Ra-jlich 2006, S. 70). Eines der dringlichs-ten Probleme ist die fehlende theore-tische Verankerung („theoretical glue“)der agilen SE (Conboy 2009, S. 330).Die Prinzipien und Praktiken agiler SEbasieren hauptsächlich auf Erfahrungenaus der Praxis und der Literatur überagile SE fehlt die theoretische Fundie-rung (Lee und Xia 2010). Dies resul-tiert in der Forderungen, mehr theo-riegetriebene Forschung über agile SEdurchzuführen (Dingsøyr et al. 2012).
Einer der zentralen Aspekte agilerSE-Methoden, der sie von traditionel-len plangetriebenen SE-Methoden unter-
scheidet, ist die zentrale Rolle der Kom-munikation, sowohl innerhalb der Ent-wicklungsteams als auch mit den Kunden(Melnik und Maurer 2004; Pikkarainenet al. 2008; Sarker et al. 2009). Das „Agi-le Manifesto“ (Beck et al. 2001), das ge-meinsame Werte und Prinzipien der agi-len SE formuliert, hebt diese fundamen-tale Rolle der informalen Kommunika-tion bei agiler SE hervor: Geschäftskun-den und Entwickler sollen durchgehendund täglich zusammenarbeiten und Pro-jektinformationen sollen durch informa-le Kommunikation (z. B. mündlich) ver-teilt werden, anstatt durch Dokumenta-tionen, Pläne und Modelle. Konsequen-terweise wird agile SE als eine kooperati-ve Aktivität aus Innovation und Kommu-nikation beschrieben (Cockburn 2002,S. 28) und die Wichtigkeit von mensch-lichen und sozialen Faktoren unterstri-chen (Dybå und Dingsøyr 2009). Einigeagile Vorgehensweise fußen fast vollstän-dig auf mündlicher Kommunikation mitdem Kunden (Ramesh et al. 2010, S. 451).
Obwohl Kommunikation wiederholtals einer der fundamentalen Aspekte vonagiler SE genannt wird (Melnik undMaurer 2004; Pikkarainen et al. 2008;Sarker et al. 2009) und gezeigt wur-de, dass Kommunikation bei der agi-len Entwicklung von höchster Bedeu-tung ist (Korkala et al. 2006, S. 76), ha-ben bisher nur sehr wenige Studien ver-sucht, das Zusammenspiel von agiler SEund Kommunikation aufzudecken (Ma-ruping et al. 2009a; Pikkarainen et al.2008). Aus diesem Grund entwickelt die-ser Beitrag eine integrierte Betrachtungüber bisherige Forschungsstudien zu agi-ler SE und Kommunikation. Es wird einsystematischer Literaturüberblick gege-ben und die folgende Forschungsfrageadressiert: „Was ist die Rolle der Kommu-nikation bei SE-Projekten, die agile Prak-tiken einsetzen?“ Die Ziele des Literatur-überblicks sind (1) über vorhandene Er-gebnisse zu berichten, (2) Lücken im mo-mentanen Wissenstand über die Rolle derKommunikation bei agiler SE zu identifi-zieren und zu strukturieren, und (3) eineLeitlinie für die zukünftige Forschung zuerarbeiten.
Der Beitrag ist wie folgt strukturiert.Im nächsten Abschnitt wird die Metho-dik des Literaturüberblicks präsentiert.Dies beinhaltet die Darstellung der Quel-lenselektion und der theoretischen Ba-sis für die Einschränkung der Suche und
Auswertung der Ergebnisse. Danach wer-den die Ergebnisse der Literaturrecher-che präsentiert und im Detail analysiert,wie bestehende Studien Kommunikati-on im Kontext agiler SE adressiert ha-ben. Anschließend werden die Erkennt-nisse zusammengefasst und Auswirkun-gen auf die zukünftige Forschung aufge-zeigt, indem Forschungslücken hervorge-hoben werden.
2 Methodik
Es wird eine strukturierte, systematischeLiteraturrecherche durchgeführt, um dieFrage zu beantworten, in welchem Aus-maß Kommunikation im Bereich agi-ler SE bisher untersucht worden ist.Den Leitlinien von Webster und Watson(2002) folgend wird der Fokus explizitauf die führenden Journals und Konfe-renzen der für agile SE relevanten Diszi-plinen gelegt. Die hieraus resultierendenErgebnisse werden durch eine vollständi-ge Datenbankrecherche ergänzt (vgl. Ab-schn. 2.1). Eine auf mehreren Katego-rien basierende Konzeptmatrix definiertdie Struktur für die Präsentation der Er-gebnisse und fasst die wesentlichen Er-kenntnisse und Einblicke zusammen. Dertheoretische Rahmen zur Herleitung die-ser Kategorien basiert auf dem UnifiedModel of Systems Development Success(Siau et al. 2010) (vgl. Abschn. 2.2).
2.1 Datenerhebung und Suchprozess
Die Literatursuche erfolgte in zwei Pha-sen (vgl. Online-Anhang A für eine de-tailliertere Beschreibung des Suchprozes-ses). In der ersten Phase wurden alle rele-vanten Beiträge in den wichtigsten Jour-nals und Konferenzen zum Thema agileSE aus dem Bereich „Software Enginee-ring“ ausgewählt (nach Dingsøyr et al.2012). Da agile SE auch für den Bereich,“Information Systems” (IS) relevant ist,wurde diese Liste um die Zeitschriftenaus dem „Senior Scholar’s Basket of Jour-nals“1 und die Beiträge der ICIS als wich-tigster IS-Konferenz ergänzt. Jeder Bei-trag wurde manuell auf Erkenntnisse imZusammenhang mit Kommunikation ge-prüft. Zusätzlich wurde die automatischeSuchfunktion genutzt, um jeden Beitragnach dem Wort „communication“ zudurchsuchen.
In der zweiten Phase des Suchprozesseswurden die initialen Ergebnisse um die
Ergebnisse einer Datenbankrecherche in-nerhalb von acht Datenbanken erweitert,in denen nach dem Wort „communi-cation“ in Titel, Zusammenfassung undSchlüsselwörtern gesucht wurde. Inner-halb beider Suchphasen wurden die Ti-tel und Zusammenfassungen der Beiträ-ge eingehend untersucht und es wurdenStudien ausgeschlossen, die nicht agileSE zum Thema haben (bspw. fokussier-ten viele Beiträge auf „organisatorischeAgilität“ oder „Supply-Chain-Agilität“).
Das Ergebnis dieses Suchprozesses wa-ren insgesamt 333 Studien, die relevan-te Erkenntnisse zu agiler SE in Bezugauf Kommunikation enthielten. Detailsder 333 Studien bzgl. der Untersuchungs-kategorien und allgemeine Daten wie z.B. Schlagwörter wurden in eine separateDatei kopiert, die im Anschluss als Basisfür die Strukturierung der Daten diente.
2.2 Theoretisches Rahmenwerk undKategorien
Das Unified Model of Systems De-velopment (SD) Success (Siau et al.2010) wurde zur Herleitung der Kate-gorien für die Strukturierung und Ana-lyse der identifizierten Studien verwen-det. Das Modell stellt vorangegangeneSE-Forschungsergebnisse integriert darund identifiziert wichtige Faktoren, dieden SE-Prozess beeinflussen. Es bie-tet einen passenden Untersuchungsrah-men zur Strukturierung, da es einezusammenfassende Darstellung des SE-Prozesses und seiner Input- und Output-faktoren enthält (vgl. Abb. 1).
Kategorie 1 (K1) betrifft die Input-dimension des Rahmenwerks. Agile SEwird hauptsächlich für kleine, loka-le Teams als geeignet angesehen, dieunkritische Software entwickeln (Åger-falk et al. 2009). Um diese Annahmezu überprüfen, wurden Teamverteilung(Kategorie C1a), Teamgröße (Katego-rie K1b) und Projektdomäne (Katego-rie K1c) als separate Kategorien in dasRahmenmodell aufgenommen, da ange-nommen wird, dass diese Inputvariablendie Kommunikationsmechanismen vonSE-Teams beeinflussen (Ågerfalk et al.2009):� Teamverteilung bezeichnet das Aus-
maß, in dem Teammitglieder physischgetrennt voneinander (verteilt) odernahe beieinander (lokal) positioniertsind (Ågerfalk et al. 2009).
Abb. 1 AusgewählteKategorien destheoretischenUntersuchungsrahmensbasierend auf dem UnifiedModel of SD Success(angepasst von Siau et al.2010)
Tab. 1 Analytische Kategorien (Konzeptmatrix)
Kategorie Kurzbeschreibung
Kategorie 1(K1a, K1b, K1c)
Einfluss der Teamverteilung auf die Kommunikationsmechanismenvon agilen SE-Teams.
Einfluss der Teamgröße auf die Kommunikationsmechanismen vonagilen SE-Teams.
Einfluss der Projektdomäne auf die Kommunikationsmechanismenvon agilen SE-Teams.
Kategorie 2(K2a, K2b)
Einfluss von agilen Methoden und Praktiken auf dieKommunikationsmechanismen von agilen SE-Teams.
Kategorie 3 (K3) Einfluss der Kommunikationsmechanismen von agilen SE-Teams aufden SE-Erfolg.
� Teamgröße ist definiert als die Anzahlder Teammitglieder (Ågerfalk et al.2009; Maruping et al. 2009a).
� Die Projektdomäne befasst sich mitden Projektmerkmalen, bspw. ob eineSoftware oder ein Anwendungssystemfür einen einzelnen (inhouse) Kundenentwickelt wird oder ob es sich um einekommerzielle Standardlösung handelt,ob es eine Neuentwicklung ist oder ei-ne Weiterentwicklung eines bestehen-den Systems, oder ob das entwickel-te System unkritisch oder missionskri-tisch ist (Ågerfalk et al. 2009).
Der SE-Prozess wird auch von der ein-gesetzten SE-Methode beeinflusst. Imvorliegenden Fall untersuchen wir alsMethode die Ansätze der agilen SE, wel-che wiederum aus spezifischen agilenPraktiken bestehen. In diesem Zusam-menhang wird insbesondere untersucht,wie die in der Praxis am häufigsten einge-setzten agilen Methoden (Dingsøyr et al.2012), nämlich Extreme Programming(XP) (Kategorie K2a) und Scrum (Ka-tegorie K2b), die Kommunikationsme-chanismen von SE-Teams beeinflussen.Beide Methoden enthalten verschiedeneTechniken und Praktiken; zum Beispielbeinhaltet XP technische Praktiken wie
„Pair Programming“, „Continuous Inte-gration“ und „Refactoring“ (Beck 1999),wohingegen Scrum den Fokus auf Prak-tiken des Projektmanagements wie bspw.„Daily Stand-Ups“, „Sprint Planning“und „Review Meetings“ legt (Schwaberund Beedle 2002).
Das Ergebnis der Prozessdimension istSE-Erfolg, der aus Faktoren wie Projek-terfolg, Systemnutzung und Kundenzu-friedenheit besteht (Siau et al. 2010).Es wird untersucht, wie die Kommuni-kationsmechanismen agiler SE den SE-Erfolg beeinflussen (Kategorie K3). Dieverwendeten Kategorien werden in Tab. 1zusammengefasst.
3 Analyse und Ergebnisse
3.1 Einfluss der Inputfaktoren aufKommunikationsmechanismen
3.1.1 Teamverteilung (Kategorie 1a)
155 Studien adressieren das ThemaTeamverteilung und Kommunikation. Eswird festgestellt, dass lokale Teams auf-grund der physischen Nähe effizienterkommunizieren. Zum Beispiel ist eine
Kollaboration mittels Whiteboards, Sta-tusboards und andere informaler Kom-munikationsmedien möglich wenn Bü-ros an einem Ort liegen (z. B. Fruhlingund de Vreede 2006; Mishra et al. 2012).Ein wichtiger Faktor für lokale Teamsist das Layout des Arbeitsraumes (Meloet al. 2011). Bspw. wird berichtet, dasshalbhohe Glasbarrieren und halbe Ar-beitskabinen die Häufigkeit und Qualitätder Kommunikation im Vergleich zu ab-geschotteten Arbeitskabinen verbessern(Mishra et al. 2012). Jedoch zeigen eini-ge Studien, dass offene Arbeitsräume dieKommunikation auch behindern kön-nen, da es schwierig ist, sich zu fokussie-ren und zu konzentrieren, was auf einenhohen Geräuschpegel zurückzuführen ist(Layman et al. 2004; Pikkarainen et al.2008). Im Gegensatz dazu stellen andereStudien fest, dass Konversationen in lo-kalen Arbeitsräumen nicht zwingend alsstörend empfunden werden (Whitworthund Biddle 2007).
In extrem verteilten Kontexten lau-fen die Erfahrungen mit agiler Entwick-lung auf einen kritischen Punkt hinaus– Kommunikation (Poole 2004, S. 67).Die kritische Rolle der Kommunikati-on wird auch von vielen anderen Studi-en bestätigt (z. B. Ramesh et al. 2012;Sarker et al. 2009; Sarker und Sarker2009). Jedoch zeigen andere Erkenntnis-se, dass nicht Kommunikation, sonderneine gut-definierte Kundenschnittstelleder Haupterfolgsfaktor für ein verteiltesProjekt ist (Korkala und Abrahamsson2007).
Herausforderungen in Verbindung mitKommunikation in verteilten Kontex-ten haben ihren Ursprung in verschie-denen Zeitzonen, Sprachen und Kultu-ren (Dorairaj et al. 2012b; Ramesh et al.2012; Sarker und Sarker 2009). Entspre-chend ist die Menge an verbaler Kommu-nikation in verteilten Projekten im Ver-
WIRTSCHAFTSINFORMATIK 5|2013 349
WI – STATE OF THE ART
gleich zu lokalen Teams niedriger (Ni-inimäki 2011), was sich in Kommuni-kationspannen, Missverständnissen undVerwirrung der Teammitglieder äußernkann (Hossain et al. 2009b).
Mehrere Studien schlagen vor, dass agi-le Methoden helfen, dieses Grundpro-blem der Kommunikation in verteilenProjekten zu lösen, indem die Teammit-glieder zum kommunizieren gezwungenwerden und somit die zeitliche, geogra-phische und sozio-kulturelle Distanz re-duziert wird (Holmström et al. 2006;Paasivaara et al. 2008). Probleme beider Kommunikation in verteilten Projek-ten können auch durch die Verteilungder Arbeit innerhalb der gleichen Zeit-zone abgeschwächt werden oder indemArbeitszeiten synchronisiert werden, wasArbeit außerhalb normaler Bürozeitennach sich ziehen kann (Hossain et al.2009a; Paasivaara et al. 2008; Sindhgat-ta et al. 2011). Das Vorhandensein ver-trauter Beziehungen als auch ein gemein-sames Verständnis werden ebenfalls alsäußerst wichtig angesehen (Holmströmet al. 2006; Lavazza et al. 2010). Bspw.wird berichtet, dass Vertrauen durch ge-genseitige Besuche (sogenannte „SeedingVisits“) an anderen Standorten zu Pro-jektbeginn aufgebaut und durch „Main-taining Visits“ in späteren Projektpha-sen aufrechterhalten werden kann (Bo-den et al. 2007; Paasivaara et al. 2008).Auch wird empfohlen, dass ein wich-tiges Mitglied des einen Teams phy-sisch beim anderen Team positioniertwird, um die Kommunikation zu verbes-sern und technische, geographische undsprachliche Hindernisse zu überbrücken(z. B. Braithwaite und Joyce 2005; Dorai-raj et al. 2012b; Layman et al. 2006).
Weitere Studien zeigen, dass sich ver-teilte agile Teams insbesondere auf Kom-munikationstools verlassen, um übermehrere Zeitzonen hinweg zusammen-zuarbeiten (Bocock und Martin 2011;Dorairaj et al. 2012b). Dies führt zu derEmpfehlungen, dass mehrere Kommu-nikationsmethoden, inklusive einer Viel-falt an verschiedenen Medien, zur Verfü-gung gestellt werden sollten, um den Aus-fall von Kommunikationstools zu über-brücken und unterschiedlichen Vorliebenzu entsprechen (Paasivaara et al. 2008,2009).
Es wurde gezeigt, dass asynchrone Me-dien wie E-Mail (Korkala et al. 2009), Wi-kis, Ticketingsysteme und eine gemein-same Codebasis helfen, den Bedarf ansynchroner Kommunikation zu verrin-gern (Braithwaite und Joyce 2005; Hos-sain et al. 2009a; Reeves und Zhu 2004).
In Bezug auf synchrone Kommunika-tionsmedien werden Telefon- und Vi-deokonferenzen (auch kombiniert mitDesktop-Sharing) als effektiver im Ver-gleich zu asynchronen Medien angese-hen, um eine konstante Kommunikati-on zu ermöglichen (z. B. Dorairaj et al.2012b; Layman et al. 2006; Young undTerashima 2008). Videokonferenzen soll-ten bevorzugt werden, wenn mündli-che Kommunikation nicht möglich ist,da es der natürlichen Kommunikati-on am meisten ähnelt (Bless 2010). In-stant Messaging ist ein weiteres Medi-um, das häufig eingesetzt wird, da es alsguter Kompromiss zwischen synchronerund asynchroner Kommunikation ein-geschätzt wird (Estler et al. 2012). Zu-sammenfassend lässt sich festhalten, dassdie Wahl des „richtigen“ Kommunikati-onsmediums für die „richtige“ Aufgabewichtig ist. Zum Beispiel bieten sich syn-chrone Medien für das Lösen von An-fragen an, während asynchrone Medienwie E-Mail geeignet sind, um die An-frage mitzuteilen (Fernando et al. 2011).Blindes Vertrauen auf informale Kom-munikation in verteilten Kontexten kannzu Problemen und Kommunikationspan-nen führen (Ramesh et al. 2012).
Da synchrone, mündliche und durchTools mediierte Konversationen in einemverteilten Kontext aufgrund der zeitli-chen Trennung nicht möglich ist (z. B.Braithwaite und Joyce 2005), wird emp-fohlen, die Menge an notwendigen Inter-aktionen so gering wie möglich zu halten.Um dies zu erreichen, sollten asynchroneund auch lokale Meetings durchgeführtwerden (Hossain et al. 2009b). Die An-zahl der notwendigen Interaktionen kannauch dadurch reduziert werden, dass dasProjekt in Teilprojekte aufgespalten wird,die unabhängig voneinander implemen-tiert werden können (Szoke 2011). Au-ßerdem kann der Grad der Formali-tät in der Kommunikation erhöht wer-den, bspw. durch Berücksichtigung vondetaillierten Dokumentationsunterlagenwie Architekturdesigns und -plänen (Ra-mesh et al. 2012; Szoke 2011). Nichts-destotrotz wurde festgestellt, dass selbstin verteilten Teams solch formale Do-kumentation auf das absolut notwendi-ge Maß beschränkt werden kann (Sharpet al. 2012).
3.1.2 Teamgröße (Kategorie 1b)
33 Studien geben Einblicke in die Auswir-kungen der Teamgröße auf die Kommu-nikation. Da große Teams dazu neigen,
eher verteilt zu sein, und kleine Teamseher lokal angesiedelt sind, sind die Er-kenntnisse in der Kategorie „Teamgrö-ße“ auch zu einem gewissen Grad auf dasvorhergehende Kapitel zur „Teamvertei-lung“ übertragbar. Insbesondere wird inder Literatur angeführt, dass Kommuni-kation für kleine, agile SE-Teams einfa-cher ist, da die Kollaboration mehr undmehr an Komplexität gewinnt, wenn dieTeamgröße steigt (z. B. Melo et al. 2011).Es wird u. a. berichtet, dass der großeVorteil von kleinen Teams darin liege,dass informale mündliche Kommunika-tion auf natürliche Art und Weise gesche-he und dies zum Aufbau von implizi-tem Wissen führe (Kajko-Mattsson 2008;Nevo und Chengalur-Smith 2011).
Parallel zu den Ergebnissen für ver-teilte Umgebungen wird auch vorge-schlagen, dass agile SE-Teams in größe-ren Entwicklungsvorhaben die passendenKommunikationsmechanismen auswäh-len sollten, da ansonsten die Kommuni-kation behindert werde könne (Pikkarai-nen et al. 2008). Es wird u. a. geschildert,dass die Adaption agiler SE-Praktikendie Kommunikation auch in großen Ent-wicklungsprojekten verbessert hat (Peter-sen und Wohlin 2009, 2010). InformaleKommunikation kann in großen Projek-ten jedoch problematisch sein, wenn vie-le Akteure involviert sind und viele In-formationen ausgetauscht werden müs-sen (z. B. Cao et al. 2009; Fitzgerald et al.2006; Pikkarainen et al. 2008). Synchro-ne und asynchrone Kommunikationsme-dien, Tools und Kommunikationskanä-le werden in größeren Projekten als not-wendig angesehen, um die Vielzahl an so-zialen Beziehungen zwischen den Team-mitgliedern zu unterstützen (z. B. Sar-ker et al. 2009) und den laufenden Zu-gang zu Projektinformationen zu ermög-lichen (Mishra et al. 2012). Einige Stu-dien erwähnen, dass formale Dokumen-tation für die Koordination vieler Team-mitglieder notwendig ist; beschriebeneMedien für die Koordination von großenTeams beinhalten Wikis und Gruppen-E-Mails (Elshamy und Elssamadisy 2007;Hansson et al. 2006).
3.1.3 Projektdomäne (Kategorie 1c)
Im Hinblick auf den Einfluss der Projekt-domäne auf die Kommunikation von agi-len SE-Teams gibt es bisher kaum Un-tersuchungen (vier Studien insgesamt).Ramesh et al. (2010) untersuchen agi-le Anforderungsentwicklung im Hinblick
350 WIRTSCHAFTSINFORMATIK 5|2013
WI – STATE OF THE ART
Tab. 2 Erkenntnisse zu XP-Praktiken
XP-Praktiken # Studien Einfluss auf die Kommunikationsmechanismen von SE-Teams
Coding Standards 6 Fördert die Kommunikation, da u. a. allen Entwickler dieselben Regeln für dieEntwicklung von Code gegeben werden (Hazzan und Dubinsky 2003; Maruping et al.2009b).
Collective Code Ownership 1 Begünstigt die Kommunikation indirekt, indem u. a. Verlässlichkeit in Bezug aufrechtzeitige Kommunikation zwischen den Entwicklern bei der Verteilung von Codeangenommen werden muss (Xiaohu et al. 2004).
Continuous Integration 3 Erlaubt u. a. schnelles Feedback hinsichtlich der Codequalität (Xiaohu et al. 2004).
On-Site Customer 14 Fördert u. a. die Kommunikation zwischen Team und Kunden (z. B. Dorairaj et al.2012a; Svensson und Höst 2005); zieht auch einen wesentlichen positiven Einfluss aufdie Qualität der Kommunikation nach sich (Wojciechowski et al. 2010).
Pair Programming 47 Fördert u. a. Kommunikationsfähigkeiten und erleichtert die Interaktionen zwischenden Entwicklern (Karlström und Runeson 2006; Melo et al. 2011; Vidgen und Wang2009).
Planning Game 15 Fördert u. a. die Kommunikation zwischen den Teammitgliedern und mit dem Kunden,indem sie in regelmäßigen Treffen zur Kommunikation gezwungen werden (z. B. Caoet al. 2009; Dorairaj et al. 2012a).
Refactoring 3 U.a. wichtig für die Kommunikation zwischen den Entwicklern (Hazzan und Dubinsky2003), da das Ergebnis dieser Praktiken „Einfachheit“ ist, welche für eine effizienteKommunikation benötigt wird (Conboy et al. 2007).
Simple Design 3
Small Releases 4 Erlaubt u. a. häufigere Kommunikation in Meetings (Pikkarainen et al. 2008) und bietetschnelles Feedback zwischen Kunden und Entwicklern (Xiaohu et al. 2004).
Sustainable Pace – Keine Studie behandelte diese Praktik in Bezug auf ihre Auswirkung aufKommunikation.
System Metaphor 8 Dient u. a. als Kommunikationsplattform, die das gemeinsame Verständnis und dieQualität der Kommunikation verbessert (Beck 1999; Dall’Agnol et al. 2003). Es wird eingemeinsames Vokabular zwischen Entwicklern und Kunden aufgebaut (Sharp undRobinson 2004). Mehrere Metaphern auf Basis unterschiedlicher Sichtweisen auf dasSystem und unterschiedlicher Anspruchsgruppen verbessern ebenfalls dieKommunikation (Keeling und Velichansky 2011).
Unit Testing (inkl.Automated AcceptanceTests)
9 U. a. sind automatisierte Akzeptanztests ein effektives Kommunikationsmedium fürKunden und Entwickler, um Geschäftsanforderungen, Bereichswissen und den Statusder Implementierung auszutauschen (Melnik et al. 2006; Park und Maurer 2009); demwidersprechende Ergebnisse werden jedoch von Haugset und Hanssen (2008)präsentiert, die feststellen, dass die Kommunikation mit den Kunden nicht verbessertwird, da ihnen das Verständnis über das System fehlt, so dass das Spezifizieren von Testsschwierig ist.
auf eine missionskritische Bankingsoft-ware. Sie stellen dabei fest, dass Kom-munikation eine wichtige Rolle im SE-Prozess gespielt hat. Auch wenn for-male Dokumentation ebenfalls einge-setzt wurde, konnten die sich änderndenKundenanforderungen nur durch häu-fige mündliche Kommunikation erfasstwerden. Für sicherheitskritische Appli-kationen sei mündliche Kommunikationmit dem Kunden die wichtigste Anforde-rungsquelle (Cao und Ramesh 2008). InBezug auf Wartungsprojekte legen ersteErkenntnisse nahe, dass die ausschließ-liche Nutzung von oraler Kommunika-tion später während der Wartung Pro-bleme verursachen kann, wenn imple-mentierte Änderungen am System nichtdokumentiert wurden (Kajko-Mattsson2008). Nawrocki et al. (2002) beobach-ten, dass orale Kommunikation anfällig
für das Vergessen relevanter Details ist;dies gilt insbesondere für die Entwick-lung komplexer Systeme, da es zu späte-ren Zeitpunkten Probleme bei der Nach-vollziehbarkeit, warum bestimmte Alter-nativen ausgewählt wurden, geben kann.Um dieses Problem zu vermeiden, soll-ten Entscheidungen dokumentiert wer-den.
3.2 Einfluss von Agilen Methoden undPraktiken aufKommunikationsmechanismen
3.2.1 Erkenntnisse zu ExtremeProgramming (Kategorie 2a)
95 Studien beinhalten Erkenntnisse zumEinfluss von Extreme Programming (XP)auf die Kommunikation. „XP is all aboutmaximizing communication“ (Murru
et al. 2003, S. 39). Es wird u. a. fest-gestellt, dass der vorteilhafteste Aspektvon XP die gestiegene Kommunikati-on innerhalb des Teams ist (Fruhlingund de Vreede 2006; Layman et al. 2004;Ramesh et al. 2010). XP-Entwickler ver-bringen ein Viertel ihrer Zeit mit Kom-munikation (Coman und Succi 2009).Außerdem haben einige Studien gezeigt,dass die agilen Praktiken von XP so-wohl die formale als auch die informaleKommunikation verbessern (z. B. Pik-karainen et al. 2008). Kommunikationauf jeder Ebene und in jeder Phase einesXP-Projektes scheint das Rückgrat allerXP-Praktiken zu sein (Juric 2000, S. 102).Jedoch kommen andere Arbeiten im Ge-gensatz dazu zu dem Schluss, dass dieEinführung von XP keinen Einfluss aufdie Art und die Häufigkeit der Kommu-nikation des Teams mit der umgebenden
WIRTSCHAFTSINFORMATIK 5|2013 351
WI – STATE OF THE ART
Organisation und mit den Kundenre-präsentanten hat (Svensson und Höst2005).
Die häufigste untersuchte XP-Praktikin Bezug auf Kommunikation ist PairProgramming. Insgesamt liefern 47 Stu-dien Ergebnisse zu Pair Programmingund Kommunikation. Obwohl der Zweckder Paarbildung die Entwicklung vonCode ist, basiert der Prozess grundlegendsowohl auf verbaler als auch nonverbalerKommunikation (Sharp und Robinson2006, S. 6). Pair Programming ist durchkonstante Ad-hoc-Kommunikation zwi-schen Entwicklern charakterisiert (Sharpund Robinson 2004; Sharp et al. 2006),was gemäß der Studien die Kommuni-kationsfähigkeiten und die Interaktionzwischen den Entwicklern fördert (Karl-ström und Runeson 2006; Melo et al.2011; Vidgen und Wang 2009). Es wur-de beobachtet, dass die meisten Konver-sationen zwischen Partnern auf einemsehr niedrigen Abstraktionslevel stattfin-den und häufige Nachfragen beinhalten(Stapel et al. 2010). Während der ge-meinsamen Programmierung verbringenEntwickler insgesamt ein Drittel ihrerZeit ohne Computerinteraktion (Plon-ka et al. 2011). Zarb (2012) beobachtetfolgende Themen der Kommunikationwährend des Pair Programming: „Übervorhergehende Aufgaben sprechen“, „Re-gelmäßige Besprechung des erwartetenZiels“, „Erklärungen“, „stille Momente“,„Diskussion“, „Konversationen ohne Be-zug“, „Witze“, „Rollenwechsel“, „High 5(Jubel)“ und „Ablenkung“. Zusammen-fassend hat jede Untersuchung von PairProgramming gezeigt, dass es ein kom-munikationsintensiver Prozess ist (Begelund Nagappan 2008, S. 125).
Im Vergleich zu Pair Programmingwurden andere XP-Praktiken deutlichseltener untersucht (vgl. Tab. 2).
3.2.2 Erkenntnisse zu Scrum (Kategorie2b)
Obwohl die Anzahl der Studien zu-nimmt, gibt es immer noch auffallendwenige Studien zu Scrum, die die Kom-munikation adressieren (insgesamt 64).Bisherige Studien heben hervor, dassScrum die Team Mitglieder daran erin-nert, über das Projekt zu reden, und siedazu zwingt, eng zusammenzuarbeiten;dies führe zu einer gestiegenen Kommu-nikationshäufigkeit und zu einer besse-ren Qualität der Kommunikation (z. B.Paasivaara et al. 2008, 2009).
Tab. 3 Erkenntnisse zu Scrum-Praktiken
Scrum-Praktik # Studien Einfluss auf die Kommunikationsmechanis-men der SE-Teams
Daily Scrums 42 � Es wird u. a. berichtet, dass sie die wich-tigsten Mechanismen für die Kommunika-tion in Scrum sind (Pikkarainen et al. 2008)und dass Kommunikation das „Bindemit-tel“ ist, das alle Projektmitglieder währendden Daily Scrums zusammenhält (Rameshet al. 2010).
� Neben positiven Effekten auf die Häu-figkeit der Kommunikation innerhalb desgesamten Teams wird die Eins-zu-eins-Kommunikation auch nach den Meetingsgefördert (Paasivaara et al. 2009).
� Alle Teammitglieder sollten am Meetingteilnehmen, um spätere Kommunikations-störungen zu vermeiden (Wijnands undDijk 2007).
Sprint Planning 13 � Werden u. a. genutzt, um Informationenüber Features und Anforderungen mit Re-präsentanten des Kunden zu koordinieren(Pikkarainen et al. 2008).
� Fördern u. a. auch die informale Kommuni-kation unter den Entwicklern (Pikkarainenet al. 2008).
Sprint Review/Retrospective 13
Scrum-of-Scrums 9 � Stärken u. a. die Kommunikation zwischenmehreren Teams (Paasivaara und Lassenius2010).
� Können u. a. Kommunikationszusammen-brüche und Missverständnisse erzeugen, dadarauf vertraut wird, dass eine einzelne Per-son jeweils ihr Team repräsentiert (Hossainet al. 2009c).
Tabelle 3 fasst die Ergebnisse in Be-zug auf die einzelnen Scrum-Praktikenzusammen.
3.3 Einfluss derKommunikationsmechanismen auf denSE-Erfolg (Kategorie 3)
Es wurden 100 Beiträge identifiziert, diedie Beziehung zwischen Kommunikationund Erfolg agiler SE diskutieren. Kom-munikation wird dabei wiederholt als ei-ner der wichtigsten Erfolgsfaktoren vonagilen SE-Projekten genannt (z. B. Aaen2008; Asnawi et al. 2011; Hoda et al. 2011;Koskela und Abrahamsson 2004; Mishraund Mishra 2009; Nevo und Chengalur-Smith 2011; Overhage et al. 2011; Sharpet al. 2009). Im Speziellen wird u. a.herausgestellt, dass höhere Kommunika-tionshäufigkeit und höhere Produktivi-tät im Projekt in einem Zusammenhangstehen (Braithwaite und Joyce 2005). Be-obachtete positive Effekte der verbesser-ten Kommunikation auf den SE-Erfolgin einem agilen Umfeld beinhalten u. a.
eine höhere Softwarequalität (Hanakawa2010), eine reduzierte Anzahl an falschenFeatures (Back et al. 2004) und eine nied-rigere Anzahl an Fehlern (Li et al. 2010),sowie kürzere Zeit- und Aufwandsanfor-derungen (Molokken-Ostvold und Furu-lund 2007). Erste Ergebnisse aus Fallstu-dien weisen darauf hin, dass die posi-tive Wirkung der verbesserten Kommu-nikation auf die Teamleistung u. a. vonweiteren Faktoren wie Vertrauen (Paasi-vaara et al. 2008), einem gemeinsamenVerständnis (Holmström et al. 2006) undgemeinsamer Team-Identität (Piri undNiinimäki 2011) beeinflusst wird.
Teammitglieder in SE-Projekten, dieXP verwenden, sollen die Arbeit besserverstehen und Aufgaben schneller lösenkönnen im Vergleich zu Teams, die tradi-tionelle Entwicklungsmethoden anwen-den (z. B. Karlström und Runeson 2006;Layman et al. 2004). Entwickler pro-fitieren von intensiverer Kommunikati-on, weil dadurch weniger Missverständ-nisse entstehen, eine größere Arbeitsef-fizienz vorherrscht und besseres Lernen
352 WIRTSCHAFTSINFORMATIK 5|2013
WI – STATE OF THE ART
Tab. 4 Haupterkenntnisse der Literatur über agile SE in Bezug auf die Rolle der Kommunikation
Kategorien # Studien Haupterkenntnisse der Literatur über den Einfluss der Kommunikation
Kategorie 1a:Teamverteilung→ Kommunikation
155 � Kommunikation ist einfacher für lokale Teams.� Verteilte Teams sind vielen Herausforderungen in Bezug auf Kommunikation ausgesetzt (z. B.
unterschiedliche Zeitzonen).� Agile SE hilft dabei, diese Herausforderungen zu überwinden, indem es Teams zur Kommunika-
tion zwingt.� Verschiedene Kommunikationsmethoden sind in einer verteilten Umgebung notwendig (asyn-
chrone und synchrone Medien, ermöglicht durch Tools).
Kategorie 1b:Teamgröße →Kommunikation
33 � Informale Kommunikation ist hauptsächlich für kleine Teams geeignet.� Größere Teams müssen mehr formale Kommunikation einsetzen (z. B. für die Koordination und
um Wissen zu dokumentieren).
Kategorie 1c:Projektdomäne →Kommunikation
4 � Bei der Entwicklung von missionskritischen Systemen sollten Anforderungen auch mündlichkommuniziert werden, um Fehlkommunikation und Missverständnisse zu vermeiden.
� Für spätere Wartungsprojekte ist mehr formale Dokumentation notwendig, um Wissen zuerhalten.
Kategorie 2a:XP → Kommunikation
95 � XP-Praktiken fördern informale Kommunikation, insbesondere die Pair Programming-Praktik.
Kategorie 2b:Scrum → Kommunikation
64 � Scrum-Praktiken fördern informale Kommunikation, insbesondere die Daily-Scrum-Praktik.
Kategorie 3:Kommunikation →SE-Erfolg
100 � Positiver Einfluss: Es wird berichtet, dass informale Kommunikation einer der Haupterfolgsfak-toren von agiler SE ist, insbesondere in einer verteilten Umgebung.
� Negativer Einfluss: Informale Kommunikation wird als herausfordernd und überwältigendbeschrieben insbesondere im Fall von vielen Anspruchsgruppen oder um Wissen zu erhalten.
� Identifizierte Mediatoren für Kommunikation und SE-Erfolg beinhalten: Gemeinsames Ver-ständnis, Vertrauen und Teamidentität.
� Beobachtete Hauptvorteile beinhalten: Höhere Produktivität, höhere Softwarequalität, wenigerZeitaufwand und weniger Budget.
ermöglicht wird (Melnik und Maurer2004; Vidgen und Wang 2009). Nebender Kommunikation unter den Entwick-lern wird die intensive Kommunikati-on mit dem Kunden als Schlüsselele-ment agiler SE-Methoden bezeichnet (z.B. Baskerville et al. 2002). Über agile SE-Methoden wird u. a. berichtet, dass sie esden Kunden erlauben, präzisere und rea-listischere Anforderungen zu kommuni-zieren (Mann und Maurer 2005; Rameshet al. 2010).
Informale, mündliche Kommunikati-on als Hauptwerkzeug für das Verteilenvon Wissen hat sich als am effektivs-ten herausgestellt und es wird nahegelegt,dieses Medium so oft wie möglich anzu-wenden, da es dadurch weniger Filterun-gen und Verzerrungen gibt (Korkala et al.2006; Mishra et al. 2012). Es wird berich-tet, dass die Entwickler selbst die direkte,mündliche Kommunikation stark bevor-zugen, da hierdurch unmittelbares Feed-back möglich wird und Missverständ-nisse einfach vermieden werden können(LaToza et al. 2006). Insbesondere wur-de beobachtet, dass weniger Fehler ge-macht werden und weniger Arbeit erneutdurchgeführt werden muss, wenn wich-tige Informationen durchgängig durch
informale Kommunikation verteilt wird(Petersen und Wohlin 2009).
Besonders in verteilten Umgebungenist die effiziente Kommunikation einSchlüsselfaktor, um eine hohe Produk-tivität sicherzustellen und vollkommenvon Outsourcing-Vorteilen zu profitieren(z. B. Estler et al. 2012). So wurde u..a. einsignifikanter Zusammenhang zwischenverteilter, agiler SE und Kommunikati-onskonvergenz gemessen, die wiederumdie virtuelle Team-Leistung positiv be-einflusst hat (Nevo und Chengalur-Smith2011).
Trotz dieser positiven Berichte undder vielfach geäußerten zentralen Rollevon Kommunikation finden andere Stu-dien, dass Kommunikation nicht signifi-kant oder sogar negativ mit dem Erfolgvon agilen SE-Projekten zusammenhängt(Abbas et al. 2010; Misra et al. 2009).Kommunikation ist problematisch, wennTeammitglieder in verschiedenen Projek-ten involviert sind und die Pläne sich oftverändern, oder auch wenn klare Verant-wortlichkeiten fehlen (Pikkarainen et al.2012). Diese Herausforderungen kom-men zum Beispiel auf, wenn die Feature-Liste nicht priorisiert ist oder sich oft än-dert, und wenn nicht genügend Zeit für
die Planungstreffen vorgesehen ist (Pik-karainen et al. 2008). Es wird außer-dem geschildert, dass der Wechsel vontraditionellen zu agilen Methoden Her-ausforderungen in der Kommunikationnach sich zieht, wenn z. B. Akteure einschriftliches, formales Dokument erwar-ten, aber das Team auf mündliche Kon-versationen vorbereitet ist (Pikkarainenet al. 2008, 2012). In Konsequenz kön-nen so unpassende Kommunikations-medien die Kommunikation des Teamsmit externen Akteuren behindern, undzu viel Kommunikation zwischen Team-mitglieder oder mit den Kunden kannauch zu einem Hindernis werden (Vid-gen und Wang 2009). Unzureichende in-formale Kommunikation in Bezug aufdie Menge und die Vielfalt sind eben-falls Gründe für viele Schwierigkeiten inProjekten; aber zur gleichen Zeit ist zuviel informale Kommunikation für vie-le Menschen auch schwierig und ablen-kend (Adolph et al. 2012). Die Betonungvon mündlichen Konversationen kannauch zu einem Problem für Teammit-glieder mit unzureichenden Kommuni-kationsfähigkeiten werden (Conboy et al.2011).
WIRTSCHAFTSINFORMATIK 5|2013 353
WI – STATE OF THE ART
Tab. 5 Allgemeine Charakteristiken der Forschung über agile SE und Kommunika-tion
aProzentzahlen ergeben nicht notwendigerweise zusammengezählt 100 %, da Studien mehrereMale in der gleichen Kategorie vorkommen können; zum Beispiel kann eine Studie sowohl einenqualitative als auch einen quantitative Forschungsansatz verfolgen
3.4 Zusammenfassung der Ergebnisse
Tabelle 4 fasst die Haupterkenntnisse desLiteraturüberblicks zusammen.
Tabelle 5 stellt eine allgemeine Klassi-fikation der relevanten Studien zu Kom-munikation bei agiler SE im Hinblickauf die eingesetzten Forschungsdesignsund Methoden dar (Kategorien abgelei-tet von Urbach et al. 2009). Die bishereingesetzten Forschungsmethoden zei-gen ein Übergewicht qualitativer Fallstu-dien, die insbesondere auf Interviews ba-sieren. Andere, mehr quantitative Vorge-hensweisen wie z. B. fragebogenbasier-te Umfragen oder Experimente wurdenbisher nicht im selben Ausmaß durch-geführt. Das gleiche gilt für gestaltungs-orientierte Ansätze, die ebenfalls unterre-präsentiert sind. Zum Beispiel beschrei-ben und erklären die meisten Beiträgedie Anwendung agiler SE in der Praxis,
und nur wenige Arbeiten entwerfen oderevaluieren eine agile SE-Methode.
Im Anschluss wurden systematischeKarten („Systematic Maps“) nach demLeitfaden von Peterson et al. (2008) er-stellt, um das Ausmaß darzustellen, in-dem die Forschung die Suchkategori-en untersucht hat und um Forschungs-lücken abzuleiten. Abbildung 2 präsen-tiert die systematische Karte in Bezugauf die Untersuchung von Kommuni-kation und XP-Praktiken, inklusive dereingesetzten Forschungsmethoden. Es istfestzustellen, dass sich die Forschungbisher hauptsächlich auf Pair Program-ming konzentriert hat, während Studi-en zu anderen XP-Praktiken im Hinblickauf Kommunikation in viel geringeremMaße vorliegen.
Hinsichtlich der Scrum-Praktiken istdie bisherige Forschung im Wesentlichenqualitativ geprägt und untersucht haupt-
sächlich die Daily-Scrum-Praktik (vgl.Abb. 3). Einblicke zu anderen Scrum-Praktiken in Bezug auf Kommunikati-on sind weniger häufig in der Literaturvorhanden.
In Bezug auf die Suchkategorien SE-Erfolg, Projektdomäne, Teamgröße undTeamverteilung lässt sich ebenfalls fest-stellen, dass bereits viele explorative, qua-litative Studien sowohl zum Einfluss derTeamverteilung und der Teamgröße alsauch zum Effekt der Kommunikation aufden SE-Erfolg existieren (vgl. Abb. 4). Je-doch fehlen u. a. Studien zu anderen In-putfaktoren wie z. B. der Projektdomäne.
4 Diskussion
„Communication and collaboration areat the heart of agile software develop-ment“ (Karhatsu et al. 2010, S. 298).Trotz solch prägnanter Aussagen, undobwohl Kommunikation wiederholt alseiner der wichtigsten Aspekte agiler SE-Projekten genannt wird, zeigt der vorlie-gende Literaturüberblick, dass der mo-mentane Kenntnisstand bezüglich derRolle von Kommunikation in der agi-len SE und ihres Einflusses auf den SE-Erfolg nur begrenzt ist. Bisherige Ergeb-nisse sind bruchstückhaft, unvollständigund gegensätzlich. Obwohl Kommuni-kation häufig als einer der wichtigstenAspekte von agilen SE-Projekten iden-tifiziert wird, berichten andere Studienüber keine oder sogar negative Effektevon Kommunikation auf die Teamleis-tung und den SE-Erfolg. Kommunikati-on ist also keine „Wunderwaffe“ für ei-ne erfolgreiche SE, da zu viel Kommuni-kation auch zu einem Hindernis werdenkann und Kommunikationshemmnissein verteilten oder erweiterten Umgebun-gen mit vielen Anspruchsgruppen undEntwicklungsteams auftreten können. Eswurde keine Studie identifiziert, die über-zeugend und rigoros zeigen konnte, dassagile Praktiken zu mehr oder zu bessererKommunikation bei SE-Teams führt unddass dies den SE-Erfolg tatsächlich positivbeeinflusst.
Hinsichtlich der Inputfaktoren, die aufdie Kommunikationsmechanismen desagilen SE-Prozess wirken, berichtet dieLiteratur ausführlich über Herausforde-rungen von verteilten Teams und überStrategien, wie diese Herausforderungenzu überwinden sind. Die systematischeKarte zeigt, dass bspw. empirische An-haltspunkte zur Teamgröße vorhanden
354 WIRTSCHAFTSINFORMATIK 5|2013
WI – STATE OF THE ART
Abb. 2 Systematische Karte – Forschung zu XP-Praktiken und Kommunikation
Abb. 3 Systematische Karte – Forschung zu Scrum-Praktiken und Kommunikation
WIRTSCHAFTSINFORMATIK 5|2013 355
WI – STATE OF THE ART
Abb. 4 Systematische Karte – Forschung zu andere Kategorien und Kommunikation
Tab. 6 Forschungslücken
Kategorie Forschungslücke
Input Welche Bedingungen beeinflussen erfolgreiche Kommunikation und welche Faktoren auf dem umfeldbedingten,organisatorischen, und individuellen Level bewirken erfolgreiche Kommunikation bei agiler SE?
Was ist der Einfluss der Projektdomäne und des SE-Kontexts (Faktoren auf umfeldbedingter, organisatorischer undindividueller Ebene) auf die Nutzung und den Effekt der Kommunikationsmechanismen innerhalb von agilenSE-Teams?
Prozess Was ist der Einfluss der Scrum-Praktiken auf Informalität, Häufigkeit und Qualität der Kommunikation im Vergleichzu traditionellen, nicht-agilen SE-Teams? (Führt die Nutzung von Scrum-Praktiken zu mehr informaler und zubesserer Kommunikation?)
Was ist der Einfluss der XP-Praktiken auf Informalität, Häufigkeit und Qualität der Kommunikation im Vergleich zutraditionellen, nicht-agilen SE-Teams? (Führt die Nutzung von XP-Praktiken zu mehr informaler und zu bessererKommunikation?)
Output Was sind die Auswirkungen des sich veränderten Kommunikationsparadigmas von agiler SE auf dasEntwicklungsergebnis?
Sind agile SE-Teams erfolgreicher als traditionelle, nicht-agile SE-Teams aufgrund von besserer Kommunikation?(Führt häufigere und intensivere Kommunikation zu besseren Resultaten?)
sind, dass aber insbesondere Erkenntnis-se über die Auswirkungen der Projekt-domäne auf die Kommunikation fehlen.Zukünftige Studien sollten zudem unter-suchen, ob es noch andere kritische In-putfaktoren gibt, die die Kommunika-tionsmechanismen von agilen SE-Teamsbeeinflussen. Es ist zudem festzuhalten,dass die meisten Ergebnisse in den Input-bezogenen Kategorien auf qualitativenund explorativen Studien basieren, wo-hingegen prüfende und erklärende Un-tersuchungen bisher fehlen.
Es ist ebenfalls festzustellen, dass sichdie Literatur auf ein sehr breites Ver-ständnis des Konzepts „Kommunika-tion“ bezieht. Die bisherigen Studienlegen zwar nahe, dass Kommunikati-on durch das Befolgen von agilen SE-Methoden verbessert werden kann; aberes gibt kaum Untersuchungen, die die
„Black Box“ des Kommunikationsprozes-ses selbst öffnen oder sich direkt auf diesozialen Interaktionen und das Verhaltender Teams als Teil der Forschung fokus-sieren. So ist zum Beispiel völlig unklar,ob es wirklich eine höhere oder niedrige-re Intensität, Häufigkeit oder Qualität derKommunikation von agilen SE-Teams imVergleich zu traditionellen, planorien-tierten SE-Teams gibt. Auch fehlen auf-grund des explorativen Charakters dermeisten Studien harte, empirische Nach-weise der Konsequenzen des sich angeb-lich ändernden Kommunikationspara-digmas agiler SE mit Bezug auf den Ent-wicklungserfolges. Sind agile SE-Teamsnur in bestimmten Kontexten besser (dieeng mit Kommunikation verknüpft seinkönnen)? Können Fälle, in denen besse-re Teamleistung beobachtet wird, wirk-lich kausal auf verbesserte Kommunikati-
on zurückgeführt werden (anstatt auf an-dere Faktoren und Prozesse)? Es wurdekeine Studie gefunden, die explizit tradi-tionelle und agile SE hinsichtlich Kom-munikation vergleicht oder unterschei-det (z. B. mittels eines Feldexperiments).Die systematischen Karten zeigen auch,dass außer zu Pair Programming undDaily Scrums Forschung bezüglich an-derer Scrum- und XP-Praktiken fehlt.Konsequenterweise sollten daher die inTab. 6 zusammengefassten Forschungs-lücken rigoros untersucht werden.
Die identifizierten Forschungslückenkönnen sowohl durch verhaltenswissen-schaftliche als auch gestaltungsorientier-te Forschungsansätze adressiert werden.Explizit sind aber bestätigende und erklä-rende Untersuchungen der identifiziertenForschungslücken gefordert, da die sys-tematischen Karten zeigen, dass erste Er-
356 WIRTSCHAFTSINFORMATIK 5|2013
WI – STATE OF THE ART
kenntnisse zu vielen der Bereiche aus Be-richten der Praxis und aus explorativenFallstudien bereits vorhanden sind. DieErarbeitung weiterer und tieferer Ein-blicke in die theoretischen und empiri-schen Aspekte der oben dargestellten For-schungslücken kann Aufschluss über dasVerständnis der Kommunikation als kri-tischen Erfolgsfaktor agiler SE geben. Zu-gleich können gestaltungsorientierte Stu-dien in Kombination mit Aktionsfor-schung („Action Research“) bspw. die Ef-fekte der Nutzung verschiedener Prak-tiken in verteilten SE-Teams in Kom-bination mit neuen Werkzeugen unter-suchen, die darauf abzielen, spezifischeFaktoren im Hinblick auf Kommunikati-on zu unterstützen. All dies wird zu neu-em Wissen über die theoretischen Fun-damente führen, die den Erfolg agiler SEausmachen.
Als Limitation dieses Literaturüber-blicks ist zu nennen, dass trotz des sorg-fältigen Vorgehens ggf. einige Beiträ-ge nicht identifiziert und berücksichtigtwurden. Es wurde nur nach dem Schlüs-selwort „Kommunikation“ gesucht undverwandte Schlüsselwörter wie „Kollabo-ration“ und „Interaktion“ wurden nichteingeschlossen, da davon auszugehen ist,dass die zusätzlichen Suchergebnisse dieErgebnisse nicht signifikant verbesserthätten. Statt möglichst in der Breite nachverschiedenen Schlüsselwörtern in Bezugzu Kommunikation zu suchen wurde ei-ne Suche in der Tiefe durchgeführt, in-dem die kompletten Texte der gefunde-nen Studien zu agiler SE und Kommu-nikation überprüft wurden. Es wird da-von ausgegangen, dass die wichtigstenErkenntnisse der Literatur identifiziertwurden, da zu erwarten ist, dass alle Stu-dien mit wertvollen Informationen zumThema agile SE und Kommunikation zu-mindest Kommunikation im Titel, in derZusammenfassung oder in den Schlüssel-wörtern enthalten. Außerdem ist es mög-lich, dass Erkenntnisse zu anderen agi-len Methoden neben XP und Scrum nichterfasst wurden, da keine anderen agilenMethoden in die Suchanfrage einbezogenwurden.
5 Schlussfolgerung
Der vorliegende Beitrag hat vorhandenesWissen und Erkenntnisse über die Rolleder Kommunikation innerhalb von agi-len SE-Projekten aggregiert und zusam-mengefasst. Durch die Nutzung des Uni-fied Model of SD Success als theoreti-schen Rahmen hebt die Analyse den Wert
Zusammenfassung / AbstractMarkus Hummel, Christoph Rosenkranz, Roland Holten
Die Bedeutung von Kommunikation bei der agilenSystementwicklung
Aktueller Stand der Forschung
Agile Systementwicklung (SE) ist eine kooperative Aktivität aus Innovation und Kom-munikation, bei der sich Entwicklungsteams stark auf informale Kommunikationsme-chanismen verlassen. Der aktuelle Wissensstand bezüglich der tatsächlichen Kom-munikationsprozesse in agilen SE-Projekten ist fragmentiert und es fehlt eine inte-grierte Sichtweise über einzelne Studien hinweg. Der Beitrag erzeugt basierend aufdem Unified Model of Systems Development Success eine integrierte Sichtweise aufdie Rolle der Kommunikation bei der agilen SE. Dafür wird eine strukturierte, systema-tische Literaturanalyse durchgeführt. Die Datensammlung ergab 333 relevante Stu-dien zu agiler SE und Kommunikation. Obwohl Kommunikation als wichtiger Faktoridentifiziert wird, ist das Wissen in Bezug auf Kommunikation und agile SE begrenzt.Die bisherigen Erkenntnisse sind verteilt, unvollständig, und widersprüchlich. Es wirdaufgezeigt, dass weiterer Forschungsbedarf bezüglich des Kommunikationsprozes-ses in der SE besteht, und dass die Auswirkungen von Kommunikationshäufigkeitund -qualität, die durch agile SE ausgelöst werden, empirisch zu untersuchen sind.
Schlüsselwörter: Agile Systementwicklung, Organisatorische Kommunikation, Li-teraturreview, State of the Art, Software Engineering
The Role of Communication in Agile Systems Development
An Analysis of the State of the Art
Agile systems development (SD) is described as a cooperative game of inventionand communication, in which teams are characterized by relying heavily on informalcommunication mechanisms such as face-to-face conversations. Our current stateof knowledge about the actual communication process in agile SD projects is frag-mented because of the lack of an integrative lens across different studies. On the ba-sis of the Unified Model of SD Success, we provide an integrated view on the role ofcommunication in agile SD by conducting a structured, systematic literature review.Our data collection process resulted in 333 relevant papers on agile SD and commu-nication. We find that despite its acknowledged importance, our knowledge on com-munication and agile SD is limited and research is scattered, inconclusive, as well ascontradictory. In consequence, we present several research gaps that deserve futureresearch attention. Specifically, we call for research that opens up the communicationprocess and empirically validates the implications for communication frequency andquality triggered by agile SD.
Keywords: Agile systems development, Organizational communication, Literaturereview, State of the art, Software engineering
WIRTSCHAFTSINFORMATIK 5|2013 357
WI – STATE OF THE ART
der Kommunikation für agile SE hervor.Jedoch zeigt sich, dass der Kommunikati-onsprozess trotz seiner Bedeutung inner-halb der agilen SE immer noch nicht voll-ständig verstanden wird. Konsequenter-weise wurden mehrere Forschungslückenidentifiziert, die wichtig für eine tiefer-gehende Untersuchung empfunden sind.Die Untersuchung der Bedeutung undRolle der Kommunikation kann ggf. auchdazu beitragen, eines der dringendstenForschungsprobleme im Bereich der SEzu adressieren: Die fehlende theoretischeVerankerung („theoretical glue“; Conboy2009, S. 330) agiler SE. Zum Beispielkönnten Theorien aus der Forschung zuKommunikation, Kollaboration, Wahr-nehmung und Sinneswahrnehmung (z.B. Clark 1996; Garrod und Pickering2009; Weick et al. 2005) angewendet wer-den, um auf der zentralen Rolle der Kom-munikation in der agilen SE aufzubauenund somit als Startpunkt für Studien die-nen, die den agilen SE-Prozess erklären,vorhersagen oder gestalten wollen.
Literatur
Aaen I (2008) Essence: facilitating agile in-novation. In: Abrahamsson P, Baskerville R,Conboy K, Fitzgerald B, Morgan L, WangX (Hrsg) Agile processes in software en-gineering and extreme programming (XP2008). Springer, Heidelberg, S 1–10
Abbas N, Gravell AM, Wills GB (2010) Us-ing factor analysis to generate clusters ofagile practices (a guide for agile processimprovement). In: Freudenberg S, Chao J(Hrsg) AGILE 2010, Orlando. IEEE Press, NewYork, S 11–20
Adolph S, Kruchten P, Hall W (2012) Rec-onciling perspectives: a grounded the-ory of how people manage the processof software development. J Syst Softw85(6):1269–1286
Ågerfalk PJ, Fitzgerald B, Slaughter SA (2009)Flexible and distributed information sys-tems development: state of the art and re-search challenges. Inf Syst Res 20(3):317–328
Asnawi AL, Gravell AM, Wills GB (2011) Em-pirical investigation on agile methods us-age: issues identified from early adoptersin Malaysia. In: Sillitti A, Hazzan O, Bache E,Albaladejo X (Hrsg) Agile processes in soft-ware engineering and extreme program-ming (XP 2011). Springer, Heidelberg, S192–207
Back RJ, Hirkman P, Milovanov L (2004) Eval-uating the XP customer model and designby contract. In: Euromicro conference. IEEEPress, New York, S 318–325
Baskerville R, Levine L, Pries-Heje J, RameshB, Slaughter S (2002) Balancing quality andagility in Internet speed software develop-ment. In: ICIS proceedings, S 859–864
Beck K (1999) Extreme programming ex-plained: embrace change. Addison-Wesley,Boston
Beck K, Beedle M, van Bennekum A, CockburnA, Cunningham W, Fowler M, Grenning
J, Highsmith J, Hunt A, Jeffries R, Kern J,Marick B, Martin RC, Mellor S, Schwaber K,Sutherland J, Thomas D (2001) Agile man-ifesto. http://www.agilemanifesto.org/.Abruf am 2013-03-28
Begel A, Nagappan N (2008) Pair program-ming: what’s in it for me? In: Internationalsymposium on empirical software engi-neering and measurement, Kaiserslautern.ACM Press, New York, S 120–128
Bless M (2010) Distributed meetings in dis-tributed teams. In: Sillitti A, Martin A, WangX, Whitworth E (Hrsg) Agile processes insoftware engineering and extreme pro-gramming (XP 2010). Springer, Heidelberg,S 251–260
Bocock L, Martin A (2011) There’s somethingabout lean: a case study. In: AGILE 2011,Salt Lake City. IEEE Press, New York, S 10–19
Boden A, Nett B, Wulf V (2007) Coordinationpractices in distributed software develop-ment of small enterprises. In: Internationalconference on global software engineer-ing. IEEE Press, New York, S 235–246
Braithwaite K, Joyce T (2005) XP expanded:distributed extreme programming. In:Baumeister H, Marchesi M, Holcombe M(Hrsg) Extreme programming and agileprocesses in software engineering (XP2005). Springer, Heidelberg, S 180–188
Cao L, Mohan K, Peng X, Ramesh B (2009) Aframework for adapting agile developmentmethodologies. Eur J Inf Syst 18(4):332–343
Cao L, Ramesh B (2008) Agile requirementsengineering practices: an empirical study.IEEE Softw 25(1):60–67
Clark HH (1996) Using language. CambridgeUniversity Press, New York
Cockburn A (2002) Agile software develop-ment. Addison-Wesley, Boston
Coman ID, Succi G (2009) An exploratorystudy of developers’ toolbox in an agileteam. In: Abrahamsson P, Marchesi M, Mau-rer F (Hrsg) Agile processes in software en-gineering and extreme programming (XP2009). Springer, Heidelberg, S 43–52
Conboy K (2009) Agility from first principles:reconstructing the concept of agility in in-formation systems development. Inf SystRes 20(3):329–354
Conboy K, Coyle S, Xiaofeng W, PikkarainenM (2011) People over process: key chal-lenges in agile development. IEEE Softw28(4):48–57
Conboy K, Pikkarainen M, Wang X (2007) Agilepractices in use from an innovation assimi-lation perspective: a multiple case study. In:ICIS proceedings
Dall’Agnol M, Janes A, Succi G, Zaninotto E(2003) Lean management – a metaphorfor extreme programming? In: Marchesi M,Succi G (Hrsg) Extreme programming andagile processes in software engineering (XP2003). Springer, Heidelberg, S 26–32
Dorairaj S, Noble J, Malik P (2012a) Knowl-edge management in distributed agilesoftware development. In: AGILE 2012, Dal-las. IEEE Press, New York, S 64–73
Dorairaj S, Noble J, Malik P (2012b) Under-standing team dynamics in distributed ag-ile software development. In: Wohlin C(Hrsg) Agile processes in software engi-neering and extreme programming (XP2012). Springer, Heidelberg, S 47–61
Dybå T, Dingsøyr T (2008) Empirical studies ofagile software development: a systematic
review. Inf Softw Technol 50(9–10):833–859
Dybå T, Dingsøyr T (2009) What do we knowabout agile software development? IEEESoftw 26(5):6–9
Elshamy A, Elssamadisy A (2007) Applying ag-ile to large projects: new agile softwaredevelopment practices for large projects.In: Concas G, Damiani E, Scotto M, SucciG (Hrsg) Agile processes in software en-gineering and extreme programming (XP2007). Springer, Heidelberg, S 46–53
Erickson J, Lyytinen K, Keng S (2005) Ag-ile modeling, agile software development,and extreme programming: the state of re-search. Int J Database Manag Syst 16(4):88–100
Estler HC, Nordio M, Furia CA, Meyer B,Schneider J (2012) Agile vs structureddistributed software development: a casestudy. In: International conference onglobal software engineering. IEEE Press,New York, S 11–20
Fernando BAJ, Hall T, Fitzpatrick A (2011)The impact of media selection on stake-holder communication in agile global soft-ware development: a preliminary industrialcase study. In: Proceedings of the 49th SIG-MIS annual conference on computer per-sonnel research, San Antonio. ACM Press,New York, S 131–139
Fitzgerald B, Hartnett G, Conboy K (2006)Customising agile methods to softwarepractices at Intel Shannon. Eur J Inf Syst15(2):200–213
Fruhling A, de Vreede G-J (2006) Field expe-riences with extreme programming: devel-oping an emergency response system. JManag Inf Syst 22(4):39–68
Garrod S, Pickering MJ (2009) Joint action, in-teractive alignment, and dialog. Top CognSci 1(2):292–304
Hanakawa N (2010) Project reliability growthmodel based on curves of accumulatedcommunication topics for software de-velopment. Int J Softw Eng Knowl Eng20(5):665–677
Hansson C, Dittrich Y, Gustafsson B, ZarnakS (2006) How agile are industrial soft-ware development practices? J Syst Softw79(9):1295–1311
Haugset B, Hanssen GK (2008) Automated ac-ceptance testing: a literature review andan industrial case study. In: Melnik G,Kruchten P, Poppendieck M (Hrsg) AGILE2008, Toronto. IEEE Press, New York, S27–38
Hazzan O, Dubinsky Y (2003) Bridging cogni-tive and social chasms in software devel-opment using extreme programming. In:Marchesi M, Succi G (Hrsg) Extreme pro-gramming and agile processes in softwareengineering (XP 2003). Springer, Heidel-berg, S 47–53
Hoda R, Noble J, Marshall S (2011) Support-ing self-organizing agile teams. In: Sillitti A,Hazzan O, Bache E, Albaladejo X (Hrsg) Ag-ile processes in software engineering andextreme programming (XP 2011). Springer,Heidelberg, S 73–87
Holmström H, Fitzgerald B, Ågerfalk PJ,Conchúir EÓ (2006) Agile practices reducedistance in global software development.Inf Syst Manag 23(3):7–18
Hossain E, Ali Babar M, Verner J (2009a) To-wards a framework for using agile ap-proaches in global software development.In: Bomarius F, Oivo M, Jaring P, Abra-hamsson P (Hrsg) Product-focused soft-ware process improvement (PROFES 2009).Springer, Heidelberg, S 126–140
Hossain E, Babar MA, Hye-young P (2009b)Using scrum in global software develop-ment: a systematic literature review. In:International conference on global soft-ware engineering. IEEE Press, New York, S175–184
Hossain E, Babar MA, Hye-young P, Verner J(2009c) Risk identification and mitigationprocesses for using scrum in global soft-ware development: a conceptual frame-work. In: Asia-Pacific software engineer-ing conference. IEEE Press, New York, S457–464
Juric R (2000) Extreme programming andits development practices. In: Internationalconference on information technology in-terfaces. IEEE Press, New York, S 97–104
Kajko-Mattsson M (2008) Problems in agiletrenches. In: International symposium onempirical software engineering and mea-surement, Kaiserslautern. ACM Press, NewYork, S 111–119
Karhatsu H, Ikonen M, Kettunen P, FagerholmF, Abrahamsson P (2010) Building blocksfor self-organizing software developmentteams a framework model and empirical pi-lot study. In: International conference onsoftware technology and engineering. IEEEPress, New York, S 297–304
Karlström D, Runeson P (2006) Integratingagile software development into stage-gate managed product development. Em-pir Softw Eng 11(2):203–225
Keeling M, Velichansky M (2011) Makingmetaphors that matter. In: AGILE 2011. IEEEPress, New York, S 256–262
Korkala M, Abrahamsson P (2007) Communi-cation in distributed agile development: acase study. In: EUROMICRO conference onsoftware engineering and advanced appli-cations. IEEE Press, New York, S 203–210
Korkala M, Abrahamsson P, Kyllonen P (2006)A case study on the impact of customercommunication on defects in agile soft-ware development. In: Chao J, Cohn M,Maurer F, Sharp H, Shore J (Hrsg) AGILE2006, Minneapolis. IEEE Press, New York, S76–88
Korkala M, Pikkarainen M, Conboy K (2009)Distributed agile development: a casestudy of customer communication chal-lenges. In: Abrahamsson P, Marchesi M,Maurer F (Hrsg) Agile processes in soft-ware engineering and extreme program-ming (XP 2009). Springer, Heidelberg, S161–167
Koskela J, Abrahamsson P (2004) On-site cus-tomer in an XP project: empirical resultsfrom a case study. In: Dingsøyr T (Hrsg)Software process improvement. Springer,Heidelberg, S 1–11
LaToza TD, Venolia G, DeLine R (2006) Main-taining mental models: a study of devel-oper work habits. In: International confer-ence on software engineering, Shanghai.ACM Press, New York, S 492–501
Lavazza L, Morasca S, Taibi D, Tosi D (2010) Ap-plying SCRUM in an OSS development pro-cess: an empirical evaluation. In: Sillitti A,Martin A, Wang X, Whitworth E (Hrsg) Ag-ile processes in software engineering andextreme programming (XP 2010). Springer,Heidelberg, S 147–159
Layman L, Williams L, Cunningham L (2004)Exploring extreme programming in con-text: an industrial case study. In: AGILE2004, Salt Lake City. IEEE Press, New York,S 32–41
Layman L, Williams L, Damian D, Bures H(2006) Essential communication practicesfor extreme programming in a global soft-
ware development team. Inf Softw Technol48(9):781–794
Lee G, Xia W (2010) Toward agile: an inte-grated analysis of quantitative and qualita-tive field data. MIS Q 34(1):87–114
Li J, Moe NB, Dybå T (2010) Transition froma plan-driven process to scrum: a longi-tudinal case study on software quality.In: International symposium on empiricalsoftware engineering and measurement,Bolzano-Bozen. ACM Press, New York
Mann C, Maurer F (2005) A case study on theimpact of scrum on overtime and customersatisfaction. In: AGILE 2005, Denver. IEEEPress, New York, S 70–79
Maruping LM, Venkatesh V, Agarwal R (2009a)A control theory perspective on agilemethodology use and changing user re-quirements. Inf Syst Res 20(3):377–399
Maruping LM, Zhang X, Venkatesh V (2009b)Role of collective ownership and codingstandards in coordinating expertise in soft-ware project teams. Eur J Inf Syst 18(4):355–371
Melnik G, Maurer F (2004) Direct verbal com-munication as a catalyst of agile knowl-edge sharing. In: AGILE 2004, Los Alamitos.IEEE Press, New York, S 21–31
Melnik G, Maurer F, Chiasson M (2006) Exe-cutable acceptance tests for communicat-ing business requirements: customer per-spective. In: Chao J, Cohn M, Maurer F,Sharp H, Shore J (Hrsg) AGILE 2006, Min-neapolis. IEEE Press, New York, S 35–46
Melo C, Cruzes DS, Kon F, Conradi R (2011)Agile team perceptions of productivity fac-tors. In: AGILE 2011, Salt Lake City. IEEEPress, New York, S 57–66
Mishra D, Mishra A (2009) Effective commu-nication, collaboration, and coordinationin extreme programming: human-centricperspective in a small organization. Humanfactors and ergonomics in manufacturing&. Serv Ind J 19(5):438–456
Mishra D, Mishra A, Ostrovska S (2012) Im-pact of physical ambiance on communi-cation, collaboration and coordination inagile software development: an empiricalevaluation. Inf Softw Technol 54(10):1067–1078
Misra SC, Kumar V, Kumar U (2009) Identifyingsome important success factors in adopt-ing agile software development practices.J Syst Softw 82(11):1869–1890
Molokken-Ostvold K, Furulund KM (2007) Therelationship between customer collabora-tion and software project overruns. In: Eck-stein J, Maurer F, Davies R, Melnik G, Pol-lice G (Hrsg) AGILE 2007, Washington. IEEEPress, New York, S 72–83
Murru O, Deias R, Mugheddue G (2003) As-sessing XP at a European Internet com-pany. IEEE Softw 20(3):37–43
Nawrocki J, Jasinski M, Walter B, Woj-ciechowski A (2002) Extreme programmingmodified: embrace requirements engi-neering practices. In: Joint internationalconference on requirements engineering.IEEE Press, New York, S 303–310
Nevo S, Chengalur-Smith I (2011) Enhanc-ing the performance of software develop-ment virtual teams through the use of agilemethods: a pilot study. In: Hawaii interna-tional conference on system sciences. IEEEPress, New York, S 1–10
Niinimäki T (2011) Face-to-face, email and in-stant messaging in distributed agile soft-ware development project. In: Interna-tional conference on global software engi-neering workshop. IEEE Press, New York, S78–84
Overhage S, Schlauderer S, Birkmeier D,Miller J (2011) What makes IT person-nel adopt scrum? A framework of driversand inhibitors to developer acceptance. In:Hawaii international conference on systemsciences. IEEE Press, New York, S 1–10
Paasivaara M, Durasiewicz S, Lassenius C(2008) Distributed agile development: us-ing scrum in a large project. In: Interna-tional conference on global software engi-neering. IEEE Press, New York, S 87–95
Paasivaara M, Durasiewicz S, Lassenius C(2009) Using scrum in distributed agile de-velopment: a multiple case study. In: Inter-national conference on global software en-gineering. IEEE Press, New York, S 195–204
Paasivaara M, Lassenius C (2010) Using scrumpractices in GSD projects. In: Agility acrosstime and space. Springer, Heidelberg, S259–278
Park S, Maurer F (2009) Communicating do-main knowledge in executable acceptancetest driven development. In: Abrahams-son P, Marchesi M, Maurer F (Hrsg) Agileprocesses in software engineering and ex-treme programming (XP 2009). Springer,Heidelberg, S 23–32
Petersen K, Wohlin C (2009) A comparisonof issues and advantages in agile and in-cremental development between state ofthe art and an industrial case. J Syst Softw82(9):1479–1490
Petersen K, Wohlin C (2010) The effect of mov-ing from a plan-driven to an incrementalsoftware development approach with agilepractices. Empir Softw Eng 15(6):654–693
Peterson K, Feldt R, Mujtaba S, Mattsson M(2008) Systematic mapping studies in soft-ware engineering. In: International con-ference on evaluation and assessment insoftware engineering, S 68–77
Pikkarainen M, Haikara J, Salo O, Abrahams-son P, Still J (2008) The impact of agile prac-tices on communication in software devel-opment. Empir Softw Eng 13(3):303–337
Pikkarainen M, Salo O, Kuusela R, Abrahams-son P (2012) Strengths and barriers be-hind the successful agile deployment – in-sights from the three software intensivecompanies in Finland. Empir Softw Eng17(6):675–702
Piri A, Niinimäki T (2011) Does distributionmake any difference? Quantitative com-parison of collocated and globally dis-tributed projects. In: International confer-ence on global software engineering work-shop. IEEE Press, New York, S 24–30
Plonka L, Segal J, Sharp H, Linden J (2011)Collaboration in pair programming: drivingand switching. In: Sillitti A, Hazzan O, BacheE, Albaladejo X (Hrsg) Agile processes insoftware engineering and extreme pro-gramming (XP 2011). Springer, Heidelberg,S 43–59
Poole C (2004) Distributed product develop-ment using extreme programming. In: Eck-stein J, Baumeister H (Hrsg) Extreme pro-gramming and agile processes in softwareengineering (XP 2004). Springer, Heidel-berg, S 60–67
Rajlich V (2006) Changing the paradigmof software engineering. Commun ACM49(8):67–70
Ramesh B, Cao L, Baskerville R (2010) Ag-ile requirements engineering practices andchallenges: an empirical study. Inf Syst J20:449–480
Ramesh B, Mohan K, Cao L (2012) Ambidex-terity in agile distributed development:an empirical investigation. Inf Syst Res23(2):323–339
WIRTSCHAFTSINFORMATIK 5|2013 359
WI – STATE OF THE ART
Reeves M, Zhu J (2004) Moomba – a col-laborative environment for supportingdistributed extreme programming inglobal software development. In: Eck-stein J, Baumeister H (Hrsg) Extremeprogramming and agile processes insoftware engineering (XP 2004). Springer,Heidelberg, S 38–50
Sarker S, Munson CL, Sarker S, ChakrabortyS (2009) Assessing the relative contribu-tion of the facets of agility to distributedsystems development success: an analytichierarchy process approach. Eur J Inf Syst18(4):285–299
Sarker S, Sarker S (2009) Exploring agility indistributed information systems develop-ment teams: an interpretive study in an off-shoring context. Inf Syst Res 20(3):440–461
Schwaber K, Beedle M (2002) Agile softwaredevelopment with scrum. Prentice Hall,Upper Saddle River
Sharp H, Giuffrida R, Melnik G (2012) In-formation flow within a dispersed agileteam: a distributed cognition perspective.In: Wohlin C (Hrsg) Agile processes in soft-ware engineering and extreme program-ming (XP 2012). Springer, Heidelberg, S 62–76
Sharp H, Robinson H (2004) An ethnographicstudy of XP practice. Empir Softw Eng9(4):353–375
Sharp H, Robinson H (2006) A distributedcognition account of mature XP teams.In: Abrahamsson P, Marchesi M, SucciG (Hrsg) Extreme programming and ag-ile processes in software engineering (XP2006). Springer, Heidelberg, S 1–10
Sharp H, Robinson H, Petre M (2009) The roleof physical artefacts in agile software de-velopment: two complementary perspec-tives. Interact Comput 21(1–2):108–116
Sharp H, Robinson H, Segal J, Furniss D (2006)The role of story cards and the wall inxp teams: a distributed cognition perspec-tive. In: Chao J, Cohn M, Maurer F, SharpH, Shore J (Hrsg) AGILE 2006, Minneapolis.IEEE Press, New York, S 65–75
Siau K, Long Y, Ling M (2010) Toward a uni-fied model of information systems devel-opment success. Int J Database Manag Syst21(1):80–101
Sindhgatta R, Sengupta B, Datta S (2011) Cop-ing with distance: an empirical study ofcommunication on the jazz platform. In:Proc international conference companionon object oriented programming systemslanguages and applications companion,Portland. ACM Press, New York, S 155–162
Stapel K, Knauss E, Schneider K, Becker M(2010) Towards understanding communi-cation structure in pair programming. In:Sillitti A, Martin A, Wang X, WhitworthE (Hrsg) Agile processes in software en-gineering and extreme programming (XP2010). Springer, Heidelberg, S 117–131
Svensson H, Höst M (2005) Views from anorganization on how agile developmentaffects its collaboration with a softwaredevelopment team. In: Bomarius F, Komi-Sirviö S (Hrsg) Product focused softwareprocess improvement. Springer, Heidel-berg, S 487–501
Szoke Á (2011) A feature partitioning methodfor distributed agile release planning. In:Sillitti A, Hazzan O, Bache E, AlbaladejoX (Hrsg) Agile processes in software en-gineering and extreme programming (XP2011). Springer, Heidelberg, S 27–42
Urbach N, Smolnik S, Riempp G (2009) Thestate of research on information systemssuccess. Bus Inf Syst Eng 1(4):315–325
Vidgen R, Wang X (2009) Coevolving sys-tems and the organization of agile softwaredevelopment. Inf Syst Res 20(3):355–376
Webster J, Watson RT (2002) Analyzing thepast to prepare for the future: writing aliterature review. MIS Q 26(2):13–23
Weick KE, Sutcliffe KM, Obstfeld D (2005) Or-ganizing and the process of sensemaking.Organ Sci 16(4):409–421
Whitworth E, Biddle R (2007) The social na-ture of agile teams. In: Eckstein J, Maurer F,Davies R, Melnik G, Pollice G (Hrsg) AGILE2007, Washington. IEEE Press, New York, S26–36
Wijnands R, Dijk I (2007) Multi-tasking agileprojects: the pressure tank. In: Concas G,Damiani E, Scotto M, Succi G (Hrsg) Ag-ile processes in software engineering andextreme programming (XP 2007). Springer,Heidelberg, S 231–234
Wojciechowski A, Wesolowski M, Complak W(2010) Experimental evaluation of ’on-sitecustomer’ XP practice on quality of soft-ware and team effectiveness. In: On themove to meaningful Internet systems: OTM2010 workshops. Springer, Heidelberg, S269–278
Xiaohu Y, Bin X, Zhijun H, Maddineni S (2004)Extreme programming in global softwaredevelopment. In: Canadian conference onelectrical and computer engineering. IEEEPress, New York, S 1845–1848
Young C, Terashima H (2008) How did weadapt agile processes to our distributed de-velopment? In: AGILE 2010. IEEE Press, NewYork, S 304–309
Zarb M (2012) Understanding communica-tion within pair programming. In: Proc con-ference on systems, programming, and ap-plications: software for humanity, Tucson.ACM Press, New York, S 53–55
