Digitale Retrospektive mit ScrumWoran hat es gelegen?

Erwin Lang

Hochschule fur angewandte Wissenschaften HamburgEmail: erwin.lang@haw-hamburg.de

I. EINFUHRUNG

A. MotivationSoftwareentwicklung ist ein Feld mit zunehmend steigen-

der Relevanz. Die entwickelten Systeme haben jedoch eineimmer großer werdende Komplexitat und erfordern daher eingeordnetes und dennoch flexibel gestaltetes Vorgehen. Ausdiesem Grund werden heute eine Vielzahl von Softwarepro-jekten mit agilen Prozessen umgesetzt. Die Vorteile sind unteranderem eine hohere Qualitat, Transparenz und Motivation derEntwickler. Laut einer Umfrage von VersionOne [1] sind imJahr 2013 52% der Softwareprojekte in den befragten Firmenmit einem agilen Modell umgesetzt worden. Das am weitestenverbreitete dieser Methoden war mit großem Abstand Scrummit 55%.

Doch die Anforderungen an ein Team durch Methodenwie Scrum sind trotz der oftmals positiven Ergebnisse nichtzu unterschatzen. So ist es haufig nicht moglich, dass alleEntwickler gemeinsam und zur gleichen Zeit arbeiten. Dieserschwert die personliche Kommunikation welche zentral furagile Methoden ist. Diese Ausarbeitung beschaftigt sich damit,wie Scrum mit Hilfe von einer eigenen Software unterstutztwerden kann um derartige Probleme zu losen. Der klare Fokusliegt hierbei auf dem Aspekt der Retrospektive. Die Ansatzehierfur basieren auf den Forschungsgebieten Enterprise 2.0und Computer Supported Collaborative Work (CSCW). Im fol-genden werden zunachst die festgestellten Probleme erlautert.Anschließend werden bekannte Ansatze vorgestellt auf denenweiter aufgebaut wird. Ziel ist es den Grundstein fur einProjekt zu legen in dem die vorgestellten Losungen umgesetztund validiert werden sollen.

B. Einleitung in ScrumUm das Verstandnis fur das Themengebiet dieser Aus-

arbeitung zu verbessern folgt nun eine kurze Einleitung zudem Kern des Scrum-Frameworks. Scrum wurde im Jahre1993 von Jeff Sutherland entwickelt. Es gibt ein simplesRahmenwerk aus Rollen, Meetings und Artefakten vor, welcheim Entwicklungsprozess verwendet werden. Wie diese Teiledes Prozesses konkret umgesetzt werden ist dabei nicht vorge-geben. Lediglich der Zweck der einzelnen Aspekte ist definiert.Im Laufe der Zeit haben sich jedoch einige Best Practicesentwickelt welche uber das grundlegende Scrum hinausgehen.Abbildung 1 zeigt den Ablauf im Scrumprozess.

Die Prinzipien auf denen der gesamte Prozess aufgebaut istsind Transparency, Inspection und Adaption. Im Kern bedeutetdies, dass die Aufgabe und das Ziel klar ist, die Arbeitregelmaßig evaluiert wird auf sich andernde Umstande reagiert

Abbildung 1. Ablauf von Scrum [2]

werden kann. Diese Prinzipien werden durch die folgendenAspekte von Scrum gestutzt [2] [3].

1) Rollen:

• Product Owner: Verantwortlicher fur den Erfolg desProdukts.

• Scrum Master: Verantwortlicher fur den Erfolg desTeams.

• Developer: Entwickler.

2) Meetings:

• Daily: Kurze Besprechung am Anfang des Tages umzu kommunizieren wo man gerade steht.

• Sprint Planning: Planung des nachsten Sprints von 2-4 Wochen. Basis der Iteration welche Inspection undAdaption fordert.

• Sprint Review: Inspection der Arbeit des vergange-nen Sprints bezuglich des Produkts.

• Sprint Retrospective: Inspection der Arbeit des ver-gangenen Sprints bezuglich der Arbeitsweise. Fokusdieser Arbeit.

3) Artefakte:

• Product Backlog: Liste der gesamten bekannten An-forderungen im Projekt. Kann jederzeit erweitert wer-den um Flexibilitat zu gewahrleisten.

• Sprint Backlog: Liste der Umzusetzenden Anforde-rungen im aktuellen Spring

• Increment: Fur sich funktionierendes Produkt amEnde eines jeden Sprints.

C. ProblemstellungIm folgenden werden die Probleme genauer erlautert wel-

che durch eine digitale Unterstutzung gelost werden sollen.Ein entscheidender Punkt bei allen agilen Techniken ist einFokus auf personliche und direkte Kommunikation [3]. In eineridealen Welt wurde das gesamte Entwicklungsteam durch-gehend gemeinsam im selben Buro sitzen. Dies ist in derRealitat allerdings nicht immer umzusetzen. Flexible Arbeits-zeiten, Verantwortung fur mehrere Projekte und Homeofficesind Alltag in vielen Softwarefirmen. Hinzu kommt noch dasOutsourcing von ganzen Teilen der Entwicklung an andereStandorte, oftmals uber Landesgrenzen hinweg. Typische Her-ausforderungen bei der verteilten Softwareentwicklung sind [4]

• Strategisch: Best Practice Methoden konnen nichtverwendet werden, da das Verhaltnis zum Aufwandsie nicht rechtfertigt. Beispiele hierfur kann ein DailyScrum sein welches uber Zeitzonen hinweg durch-gefuhrt werden muss.

• Projekt- und Prozessmanagement: Die Arbeit derverschiedenen Teams muss korrekt Synchronisiertwerden. der Managementaufwand von 2 oder meh-reren isolierten Teams ist naturgemaß großer als beieinem lokalen Team.

• Kommunikation: Die Moglichkeiten der Entwicklermiteinander zu kommunizieren ist eingeschrankt. Esmuss starker auf asynchrone Kommunikation ausge-wichen werden wie E-Mail. Synchrone Mittel wieSofortnachrichten sind oft nicht fur die Diskussionkomplexer Themen geeignet und sind schwer fur drit-te Nachzuvollziehen. Die Meetings im Scrumprozesssind nicht leicht umzusetzen [5].

• Kulturelle Aspekte: Landeskultur und Unterneh-menskultur haben einen Einfluss auf das Verstand-nis und die Arbeitsweise von Mitarbeitern. DiesesVerstandnis zu vereinen wird schwieriger je mehrunterschiedliche Kulturen beteiligt sind und je distan-zierter sie voneinander sind [6].

• Technisch: Unterschiedliche Dateiformate,Schnittstellen und Entwicklungswerkzeuge fuhren zuSchwierigkeiten bei der Integration eines Projektes.

• Sicherheit: Die verwendeten Kommunikationsmittelmussen sicherstellen, dass die Daten vertraulich be-handelt werden und sicher sind.

Diese Punkte sind fur alle verteilten Projekte relevant. Bezogenauf die Retrospektive ist es jedoch besonders wichtig darauf zuachten, dass vereinbarte Best Practices umgesetzt werden unddie Kommunikation unterstutzt wird. Kulturelle Unterscheidesind ebenfalls besonders interessant, da es in einigen Kulturennicht unublich ist Kritik als respektlos zu empfinden. Einedigitale Plattform kann helfen derartige Missverstandnisse zulosen.

Doch auch in nicht verteilten Projekten gibt es Potenzialzur Verbesserung. Nach einer Studie von [7] fuhren nur 62%aller Scrumprojekte eine Retrospektive nach jedem Sprintdurch. 13% haben eine Retrospektive nach Durchfuhrungdes Projektes und 25% arbeiten vollig ohne. Dies zeigt einProblem des Scrum-Frameworks auf. Da viele Aspekte vonScrum flexibel gestaltet sind kann es leicht passieren, dassauch essentielle Punkte in der Praxis entfernt werden. Da die

Retrospektive auf den ersten Blick nicht unmittelbar mit demProjekterfolg zusammenhangt passiert dies hier besonders oft.Die Umfrage zeigt auch, dass 35% der befragten keine ScrumMaster Rolle definiert haben. Eine digitale Plattform kann hierhelfen den Zweck der Retrospektive deutlicher zu machen undBest Practices zu fordern.

Hinzu kommt noch, dass auch wenn die Retrospektivedurchgefuhrt wird es fur die Entwickler nicht immer leicht istpotenzielle Probleme auch zu erkennen und wiederzugeben.Auch kann es dazu kommen, dass nicht alle Teammitgliederihre Meinung aktiv wiedergeben und es zu einem Ungleich-gewicht in der Beteiligung bei der Retrospektive gibt. Hierkann beispielsweise eine Visualisierung des Projektverlaufesbereits eine große Unterstutzung darstellen und die beteiligtenPersonen ermutigen ihre Meinung zu außern.

II. SCHNITTSTELLEN ZU ANDEREN PROJEKTEN

Das Projekt zur Erstellung einer Software um den agilenProzess zu unterstutzen soll gemeinsam mit den KommilitonenLeon Fausten und Alexander Kaack durchgefuhrt werden. Da-bei soll eine gemeinsame Grundlage geschaffen und implemen-tiert werden auf der die Arbeiten aufbauen konnen. Wahrendsich diese Ausarbeitung vorwiegend mit der Verbesserung derRetrospektive beschaftigt liegt der Fokus bei Leon Fausten aufSoftwarearchitekturen im Rahmen des Sprint Plannings undAlexander Kaack konzentriert sich besonders auf StakeholderAwareness.

Die Problematik bei Softwarearchitekturen im Rahmen vonagilen Methoden besteht darin, dass die Anforderungen, funk-tionierende Software so schnell wie moglich zu entwickeln,und gleichzeitig eine qualitativ hochwertige Architektur zuhaben, nicht einfach miteinander zu vereinbaren sind. Dieskann darin resultierten, dass die Architektur nicht ausreichenddurchdacht wird. Ein moglicher Losungsansatz ist hier dasAgile Model Driven Development [8].

Alexander Kaack hingegen betrachtet welche Herausfor-derungen es im Bezug auf die Stakeholder in einem agi-len Projekt gibt und wie diese angegangen werden konnen.Stakeholder sind die jeweiligen Interessenten des Projektes.Bei Stakeholder Awareness geht es vor allem darum denInformationsfluss zu den jeweiligen Parteien zu optimieren.Je besser die Informationen fur die Stakeholder aufgearbeitetsind, desto schneller und besser lassen sich wichtige Entschei-dungen treffen und Probleme finden und losen.

Das Ziel ist es ein gemeinsames Werkzeug zu entwickeln,welches diese Probleme lost und als ein Ganzes verwendetwerden kann. Die Basis dieser Arbeiten wird es sein einegemeinsame Schnittstelle zu bestehenden Ticketsystemen zunutzen.

III. BESTEHENDE ARBEITEN

In diesem Abschnitt wird auf den aktuellen Forschungs-stand naher eingegangen und relevante Arbeiten werden vorge-stellt. Interessant sind hier Ansatze um agile Softwareentwick-lung mit digitalen Mitteln weiter zu unterstutzen und Arbeitenwelche die Retrospektive im speziellen betrachten.

A. Activity Based ComputingDer vorgestellte Ansatz des Activity Based Computing

konzentriert sich vor allem auf die Probleme der verteilten

Softwareentwicklung in Scrum. Eine Abgrenzung dieses An-satzes gegenuber dem Projekt dieser Arbeit ist, dass nicht imspeziellen auf die Retrospektive eingegangen wird. ABC ist einParadigma oft assoziiert mit Ubiquitous Computing bei demAktivitaten im System verwaltet werden und fur alle Nutzersichtbar sind. Folgende Prinzipien sind grundlegend fur ABC[9] [10].

• Activity basierte Ressourcen: Bei ABC geht esvorwiegend darum die Aktivitaten des Menschen ab-zubilden. Daher sollen weitere Ressourcen an diesegeknupft werden. Artefakte wie User Stories oderDokumentationen sollen nicht alleine stehen sondernimmer an einer Activity hangen. Zusatzlich sind Infor-mationen wie verantwortliche Personen, die Historieund eine klare Beschreibung Teil einer jeder Acti-vity. Diese Bausteine sollen die reale Welt so gutwie moglich nachbilden. Der Vorteil einer solchenModellierung ist zum einen eine Ubersicht die alleTeilnehmer unabhangig von ihrem realem Standorterhalten und zum anderen eine Festlegung auf dieWerkzeuge die verwendet werden sollen. Dies hilft umdie technischen Probleme und die des Managementszu losen.

• Activity Unterbrechen und Wiederaufnehmen: DaABC oftmals im Bezug auf reale Tatigkeiten umge-setzt wird ist es essentiell diese auch unterbrechenzu konnen. Fur den Anwendungsfall der Softwareent-wicklung ist dies meist weniger wichtig, da es seltenpositiv ist zwischen vielen verschiedenen Aktivitatenhin- und her zu springen. Interessant wird das Pau-sieren erst wenn mehrere Personen an einer Activitybeteiligt sind.

• Activity Bewegen: Unter Bewegung von Activitesversteht man den einfachen Transfer zwischen Work-stations und Devices. Dies kann zum Beispiel furMeetings interessant sein bei denen eine Activity voneinem Laptop auf den Beamer transferiert werden.Eine Aufgabe fur alle sichtbar zu machen mit allenzugehorigen Ressourcen fordert die Kommunikationund Kollaboration im Team. Zusatzlich konnen Aciti-vies zwischen den Teams bewegt werden wodurch dieArbeitsteilung erleichtert wird.

• Activity Teilen: Das Teilen verhalt sich ahnlich zumBewegen. Alle zugeordneten Benutzer konnen dieActivity starten und pausieren. Dabei wird zwischensynchronem, asynchronem und temporalen Teilen un-terschieden. Synchron bedeutet, dass mehrere Per-sonen gleichzeitig an der Activity arbeiten konnen.Dies kann mit Hilfe von Chat- oder Videofunktionenunterstutzt werden. Bei asynchronen oder temporalenTeilen wird die Activity blockiert wenn ein Nutzer andiese arbeitet bzw. nach festgelegten Zeitslots. Dieskann genutzt werden um Arbeitsergebnisse zu teilen,z.B. uber Zeitzonen hinweg.

• Activity Awareness: Awareness ist das Bewusstseinfur eine Sache. Dieses Bewusstsein wird geschaffenindem Informationen klar sichtbar dargestellt. In loka-len agilen Projekten schafft ein Taskboard Awarenessfur das Projekt in dem der aktuelle Projektzustandimmer fur jeden Sichtbar ist. ABC bietet immer einen

Uberblick uber alle Activities mit allen moglichenInformationen. Um Awareness auf Projektebene zuschaffen mussen die Daten jedoch noch weiter aggre-giert werden.

• Activity Integration: Activity Integration beschreibtdie Verknupfung von den digitalen Aktivitaten mitrealen Objekten und Vorgangen. Ziel ist es die realeWelt und das ABC Modell moglichst konsistent zuhalten. Ein typisches Beispiel konnte eine Verbindungvon physischen Taskboards mit ABC sein.

Das Modell von Activity Based Computation bietet Reihe vonVorschlagen um typische Probleme in der verteilten Software-entwicklung zu losen. Allerdings existiert zum Zeitpunkt dieserArbeit nur ein Konzept welches noch in keiner Implemen-tierung getestet werden konnte. Auch bietet dieses Konzeptzunachst keine konkrete Methodik um die Durchfuhrung einerRetrospektive zu fordern.

B. Fallstudie zur RetrospektiveIn der nachsten Studie wird nun insbesondere die

Retrospektive betrachtet. Im folgenden Fallbeispiel wurdenkeine agilen Methoden verwendet. Stattdessen wurde eineeinzige Retrospektive am Ende des gesamten Projektesdurchgefuhrt. In dieser wurde ein einfaches Trackingtoolverwendet um die Projektarbeit zu rekonstruieren. DasErgebnis dieser Studie sind einige Fragestellung entwickeltdie helfen sollen um Tools zu entwickeln die bei derRetrospektive verwendet werden konnen [11].

1) Versuchsaufbau: Die Studie fand im Rahmen einesProjektes im 6. Semester eines Bachelorstudiengangs miteinem Arbeitsaufwand von etwa der Halfte des gesamtenSemesters statt. Das Projektteam bestand aus 5 Studentenwelche die Spezifikation fur ein komplexes Softwareprojekterhalten und implementiert haben. Am Ende des Semesterswurde die Retrospektive durchgefuhrt. Hierbei wurde zunachstohne Hilfe von Werkzeugen gearbeitet. Die Teammitgliederhaben, zuerst unabhangig voneinander, Zeitleisten konstruiertund Meilensteine gesetzt. Dann folgte eine gemeinsameDiskussion des Projektes. Im Anschluss wurde dasTrackingtool Trac in die Retrospektive miteinbezogen.Trac enthielt die Tickets, ein Wiki und den Changelog imVersionierungssystem. Die Studenten navigierten durch dieInformation in Trac und neue Erkenntnisse wurden in dieRetrospektive aufgenommen.

2) Ergebnisse: Die Individuellen Zeitleisten und Meilen-steine reflektierten zunachst die Rolle im Projekt. Dies istnicht uberraschend, da solche Bereiche sehr prasent sind imGedachtnis. Der Zeitpunkt zu dem die Implementierung anfingwurde zunachst von allen Teilnehmern recht weit nach hintengesetzt. Erst durch die Retrospektive auf Basis des Tracking-tools ist herausgekommen, dass es bereits sehr viel fruhererste Implementierungsversuche gab. Dies wurde anschließenddiskutiert. Ohne einen Ruckblick auf das Projekt mit Hilfeeines Tools ware dieser Aspekt verlorengegangen. Aus denfolgenden Einzelinterviews ergab sich, dass sich einige derTeammitglieder durchaus uber das vorherige Coding im klarenwaren, da aber nicht alle daran teilgenommen hatten wurdedies zunachst nicht in die Diskussion in der Retrospektive

aufgenommen. Das Tool hat hier Ablaufe des Projektes her-vorgebracht, die nicht fur alle sichtbar waren.

Eine weitere interessante Erkenntnis ist der Nutzen dermiteinander verknupften Daten in dem Tool. Da die Ticketsmit den entsprechenden Anderungen in der Versionierungverbunden waren war es recht einfach Ereignisse zu rekon-struieren, in dem die Daten chronologisch durchgegangenwurden. Dies ware nicht moglich gewesen wenn man sich beider Retrospektive vollstandig auf aggregierte Daten verlassenhatte, da die Zusammenhange nicht mehr zu erkennen waren.Tatsachlich konnen aggregierte Daten falsche Eindrucke ver-mitteln, beispielsweise wenn die Anzahl der Dateien die inder Versionierung verandert wurden als Coding gewertet wer-den. Diese Daten konnen auch kleine Bugfixes und minima-le Anpassungen sein und sagen nicht zwingend etwas uberden tatsachlichen Umfang der Programmierung aus. Gezeigtwurde, dass das Einbinden von Werkzeugen mit historischenDaten nutzlich fur den Prozess der Retrospektive sein kann unddie Tools daher mehrfachen nutzen bringen (Siehe Abbildung2). Die folgenden Fragestellungen wurden formuliert um denNutzen einer potenziellen Software fur die Retrospektive zuevaluieren.

Abbildung 2. Trac als Tool wahrend der Entwicklung und Retrospektive [11]

• Welche historischen Daten des Prozesses werden indem Tool abgebildet?

• Konnen diese Daten chronologisch dargestellt wer-den?

• Ist es moglich unterschiedliche Versionen von Arte-fakten anzuzeigen?

• Werden Daten oberflachlich und im Detail angezeigt?• Sind die Daten moglicherweise Privat?• Wie konnen werden die Daten in eine Retrospektive

eingebunden?

Diese Fragen erscheinen auch relevant wenn es um die Umset-zung eines Tools fur agile Retrospektiven geht. Die zusatzlichePerspektive einer detaillierten Sicht fur chronologische Datenist interessant, da das Wort Unterstutzung zunachst eine Ver-einfachung der Daten suggeriert. Diese Studie zeigt jedoch,dass auch eine große Menge von kaum oder nicht gefiltertenInformationen hilfreich sein kann.

C. Fallstudie zu Participation BalanceDie letzte hier vorgestellte Arbeit beschaftigt sich mit

der Kollaboration an einem digitalem Tisch im Kontext desgemeinsamen Lernens. [12]. Im speziellen geht es darum

Gruppen mit einem Awareness-Mirror zu zeigen welche Mit-glieder der Gruppe besonders viel oder wenig reden undsomit dazu ermutigt sich starker einzubringen bzw. etwaszuruckzuhalten. Vorherige Studien haben bereits gezeigt, dassein Ungleichgewicht in der Beteiligung die Motivation negativbeeinflusst und den Lernerfolg beeintrachtigt [13]. Der Kontextder Softwareentwicklung ist hier nicht gegeben. Da es jedochinsbesondere bei der Retrospektive auch um gemeinsamesLernen geht kann ein tieferer Einblick in ein System umAwareness zu schaffen von großem Nutzen sein.

1) Funktionsweise: Der Tisch verwendet LEDs um dieBeteiligung der Nutzer an dem Gesprach zu visualisieren.Diese konnen auf verschiedene Art angeordnet werden. Imeinfachsten Fall bilden die verschiedenfarbigen LEDs einfacheBalken pro Person fur bis zu 4 Personen. (siehe Abbildung4). Um festzustellen wer gerade Spricht sind in der Mitte 3Mikrophone im Tisch angebracht. Eine Glasplatte erlaubt esdas System als gewohnlichen Tisch zu nutzen. Das Design desTisches soll nicht zu großen Einfluss auf die regulare Arbeithaben, jedoch trotzdem die Informationen sichtbar darstellen.Ein wichtiges Prinzip hinter Awareness ist es nicht invasivzu arbeiten. Der Tisch stellt die Informationen lediglich zurVerfugung. Es ist der Gruppe uberlassen wie sie damit umgeht.

Abbildung 3. Awareness-Mirror um Gesprachsbeteiligung zu visualisieren.[12]

2) Versuchsaufbau: Um zu untersuchen ob diese Artder Visualisierung das Bewusstsein fur den Umfang derKommunikation steigert und ob Gruppen welche mit dieserVisualisierung arbeiten diesbezuglich ausgeglichener sindwurde ein Versuch mit Studenten durchgefuhrt. 18 Gruppenaus je 4 Studenten wurden gebeten eine Aufgabe zu losen beider jede Person andere und unvollstandige Informationen hatte,so dass sie gezwungen waren miteinander zu kommunizierenum die Aufgabe zu losen. Die Halfte dieser Gruppen arbeitetean dem Tisch mit der Visualisierung der Gesprachsbeteiligung.Die Andere Halfte hatte eine Visualisierung bezuglich Langemit der sie ein Thema diskutierten als Vergleichsgruppe.Diese Arbeiten wurden aufgenommen und gemeinsam mitabschließenden Fragebogen ausgewertet.

3) Ergebnisse: Ein Großteil der Studenten gab an, dass siedie Angaben auf dem Tisch wahrgenommen haben. Nur 5%fanden die Visualisierung der Gesprachsbeteiligung storend.25% gaben jedoch an davon abgelenkt gewesen zu sein.Die Studenten, welche besonders viel oder besonders wenigwahrend des Versuchs gesprochen haben, passten sich in denGruppen welche ein Feedback daruber erhielten haufig uberden Verlauf des Gesprachs an (siehe Abbildung 4).

Insgesamt zeigt die Studie einen klaren Effekt bei derAnwendung des Awareness-Mirrors. Es kann jedoch keineAussage daruber gemacht werden wie ein solches System ineinem Arbeitsumfeld aufgenommen werden wurde. Auch diehaufige Nutzung hat unter Umstanden Auswirkungen darauf obeine Anderung in den Verhaltensweisen stattfindet oder nicht.Interessant ist auch, dass eine Anderung der Verhaltensweisenur bei denjenigen stattfand, welche angegeben haben es warewichtig, dass alle Mitglieder einer Gruppe ahnlich viel Spre-chen. Wenn die angezeigten Informationen nicht als negativEmpfunden werden findet daher auch keine Veranderung statt.Dies ist wichtig wenn dieses Awarenesskonzept auf andereBereiche ubertragen werden soll.

Abbildung 4. Verlauf der Gesprachsbeteiligung bei Ausreißern [12]

IV. PROJEKTANSATZ

Das Ziel der weiteren Arbeit ist es ein System zu ent-wickeln welche die Retrospektive in der Softwareentwicklungfordert und bekannte Probleme vermeidet.In diesem Abschnittwerden die Ansatze welche im Verlauf des Grundprojek-tes weiter verfolgt werden sollen genauer beschrieben. Einzentraler Unterschied zu den vergleichbaren Arbeiten ist dieKonzentration auf die Retrospektive in der agilen Softwa-reentwicklung. Die Umsetzung ist mit der Entwicklung vonPlugins fur Das Trackingssystem Jira von Atlassian geplant.Ein Grund hierfur ist, dass mit dem Fokus auf ein zentralesSoftwaresystem die Probleme besser anzugehen sind.

A. Awareness fur die RetrospektiveEtwa 25% aller agiler Projekte fuhren keine Retrospektiven

in ihrem Scrumprozess durch [7]. Dies begrundet sich oftdadurch, dass die Retrospektive keinen unmittelbaren Nutzenfur das aktuelle Projekt zu bringen scheint und sich nur auflangere Sicht auszahlt. Dies ist schwer zu kommunizieren.Eine Moglichkeit den Nutzen der Retrospektive deutlicher zumachen konnte sein einen Awarenes-Monitor im Buro unterzu-bringen. Dieser Sollte Informationen bezuglich der Arbeit desTeams beinhalten anstatt sich auf den Zustand des Projekteszu beziehen. So konnte man darstellten, welche Ziel sich dasTeam in der letzten Retrospektive gesetzt hat und der Gradzu dem diese zu dem Zeitpunkt Team als erfullt angesehenwerden.

Alternativ zu einem Monitor auf Hardwarebasis ließe sichetwas derartiges auch in einem konkreten Screen innerhalbdes Trackingsystems umsetzen. Hier wurde allerdings derunvermeidbare Blick auf den Monitor nicht gewahrleistet sein.Ein Vorteil ware allerdings die direkte Beteiligung des Teams,zum Beispiel uber direktes Feedback in dem System. So ließen

sich bereits vor der Retrospektive Vorschlage sammeln welcheDinge besprochen werden sollten.

B. Kommunikation in MeetingsDie Probleme in der Kommunikation, insbesondere in der

verteilten Softwareentwicklung betreffen alle Prozesse. Mee-tings werden langer wenn diese nicht personlich im gleichenRaum gefuhrt werden konnen und sind gleichzeitig wenigereffektiv. Auch die Kritikfahigkeit ist wesentlich starker ineinem lokalen Umfeld, anstatt in einer beispielsweise einer Te-lefonkonferenz. Um solche Probleme zu losen konnen Audio-und Videoinformationen in das vorhandene Trackingsystemintegriert werden. Ein wichtiger Faktor hier ist das dieserAspekt in die bereits genutzte Software eingebaut wird umden Fluss des Meetings nicht zu storen [14].

C. Visualisierung in MeetingsNeben der Kommunikation soll auch die Visualisierung

wahren der Retrospektive verbessert werden. Diese Hilfestel-lung soll den Entwicklern erlauben ihre Problematik einfachererlautern zu konnen. Ein Beispiel fur eine solche Hilfe ware dieUbertragung des Bildschirms der sprechenden Person auf einenBeamer fur alle sichtbar, ahnlich wie es im Activity BasedComputing [9] vorgesehen ist. Dies ist auch fur lokale Teamsnutzlich, besonders essentiell jedoch fur die Nachvollziehbar-keit in verteilten Teams [15].

D. Monitoring des ProjektesUm den Entwicklern weitere Informationen uber die ge-

redet werden kann zu bieten muss das Projekt analysiert,und die wichtigsten Punkte aggregiert zur Verfugung gestelltwerden. Anders als der bereits vorgestellte Ansatz liegt hierjedoch der besondere Fokus auf der Filterung auf wichtigeInhalte. Dennoch sollten bei Bedarf Details sichtbar gemachtwerden konnen. Diese Daten konnen entweder als Awareness-Monitor eingesetzt werden oder speziell fur das Meeting inder Retrospektive aufbereitet werden. Mogliche interessanteInformationen sind beispielsweise durchschnittliche Bearbei-tungsdauer von User Stories im Vergleich zum Schatzwert bishin zu Anzahl der Tickets welche nach Abschluss nochmalsgeoffnet wurden. Diese Informationen weisen nicht zwingendauf Fehler hin. Jedoch bieten sie in jedem Fall Gesprachsstofffur Verbesserungspotenzial des Teams. [16].

V. ARBEITSPLAN UND RISIKEN

In dem folgenden Teil der Arbeit soll noch genauer aufdie Vorgehensweise wahrend des Grundprojektes eingegangenund mogliche Risiken fur das Projekt sollen deutlich gemachtwerden.

A. ArbeitsplanDas Grundprojekt wird vorwiegend mit dem gesamtem

Team gemeinsam durchgefuhrt werden. Das Ziel wird es vorallen sein eine gemeinsame Basis zu entwickeln auf der diespateren Arbeiten aufgebaut werden konnen. Als Grundlagefur die Software wurde Jira von Atlassian ausgewahlt. Einerder ersten Schritte der Projektarbeit wird es sein Jira naher zubeurteilen. Hier mussen die vorhandenen Features und Pluginsanalysiert und fur den Zweck der Retrospektive bewertet wer-den. In diesem Schritt wird auch die Entwicklung von neuenPlugins fur Jira naher beleuchtet werden. Die Schnittstelle und

die Art und Qualitat der abfragbaren Daten wird analysiert undein erstes minimales Plugin soll entwickelt werden.

Dann werden einzelne Ansatze implementiert und bereitsgrundlegend evaluiert. Dies geschieht auf Basis einer Weban-wendung, so dass die Implementierung sowohl fur normaleMonitore, als auch fur digitale Taskboards und potenziell auchMultitouch Tische anwendbar ist. In dieser Phase wird Usabi-lity einen Schwerpunkt der Implementierung ausmachen. DieUmsetzung selbst erfolgt nach einem agilen Vorgehensmodell,aller Wahrscheinlichkeit nach Scrum.

Nachdem die Methoden in einer relativ simplen Formimplementiert worden sind soll dieser Prototypen in der Praxisgetestet werden. Hierzu soll das System fur einige Wochenin einer oder mehrerer Unternehmen eingesetzt werden. Um-fragen und einzelne Beobachtungen der Meetings helfen beider Auswertung. Ziel dieser Phase ist den praktischen Nutzendes Systems zu evaluieren. Dazu gehoren unter anderem dieRelevanz der dargestellten Daten, der Aufwand der durch dasSystem wegfallt bzw. hinzukommt und die generelle Bedien-barkeit des Systems beispielsweise als Taskboard. Im Idealfallfindet dieser Praxistest sowohl in einem verteilten, als auchlokalen Softwareprojekt statt. Mit den Ergebnissen dieses Testswird das System nun weiter optimiert.

Das Gesamtziel des Projektes ist es gemeinsam mit LeonFausten und Alexander Kaack einen Prototypen zu entwickelnmit dem die gefundenen Ansatze weiter untersucht werdenkonnen. Die Basis dieses System wird eine Schnittstelle zuJira bilden welche alle gemeinsam Nutzen. Die Evaluierungwird sowohl fur das Gesamtsystem als auch fur die einzelnenAspekte stattfinden.

B. RisikenDie folgenden Risiken sind fur das Projekt identifiziert

worden.

• Die Schnittstelle zu Jira ist bisher unbekannt. DieArt und Qualitat der Daten welche abgefragt werdenkonnen ist essentiell fur ein funktionierendes System.

• Die praktische Evaluierung kann nicht zwingend aufalle Softwareprojekte generalisiert werden. Unterneh-men und Softwareentwickler haben ihre Eigenartenwelche sich auf die Nutzung des Systems auswirkenkonnen. Das erhaltene Feedback sollte daher nichtblind umgesetzt werden.

• Im Prozess der Softwareentwicklung werden bereitseine Vielzahl von Werkzeugen zur Unterstutzung vonverschiedenen Prozessen angewendet. Es besteht dieGefahr ein weiteres System zu bauen, welches manuellgestartet und verwaltet werden muss. Eine automati-sche Integration in vorhandene Systeme ist hier derSchlussel um dies zu vermeiden.

• Es ist moglich, dass durch die Software das Arbeitskli-ma verschlechtert wird. Hier ist es wichtig zu entschei-den welche Daten den Teammitgliedern zur Verfugunggestellt werden. So hatte eine Auflistung der Commitsnach Person beispielsweise Implikationen bezuglichder Produktivitat jedes einzelnen. ahnlich ist wennSchuldzuweisungen durch die Informationen moglichsind. Hier wird es wichtig sein genau abzuwagenwelche Daten dargestellt werden sollten um die Pro-duktivitat zu verbessern.

• Die Entwickler konnten sich womoglich beobachtetund kontrolliert fuhlen durch das System. Da es inder Retrospektive um die Arbeitsweise jedes einzelnengeht, was um einiges personlicher ist als der Stand desProjektes, ist es von großer Bedeutung moglichst keineWertung vorzunehmen sondern nur Hilfestellungen zubieten mit denen sich die Benutzer selbst verbessernkonnen. Auch hier ist die Form der verwendeten Datenwichtig.

VI. ZUSAMMENFASSUNG

Im Rahmen dieser Ausarbeitung wurde eine grundlegen-de Untersuchung bezuglich der potenziellen digitalen Un-terstutzung fur Scrum im Bezug auf die Retrospektive durch-gefuhrt. Im ersten Abschnitt dieser Arbeit wurde die Motivati-on dargestellt. Agile Verfahren werde immer beliebter, wobeiScrum das mit Abstand am weitesten verbreitete Verfahrenist. Danach wurde noch eine kurze Einfuhrung in Scrumgegeben. Klar ist, dass auch im Scrummodell nicht alles per-fekt ist. Einige Herausforderungen fur Scrum Teams wurdenidentifiziert und erklart. Diese gelten besonders fur verteilteSoftwareprojekte, jedoch nicht ausschließlich.

Diese Arbeit findet nicht in einem Vakuum statt. LeonFausten und Alexander Kaack befassen sich ebenfalls mit einerdigitalen Unterstutzung fur agile Methoden. Die Perspektiveist hier jedoch eine andere. Leon Fausten konzentriert sich aufArchitekturplanung in Verbindung mit dem Sprint Planningwahrend Alexander Kaack seinen Fokus auf Stakeholder Awa-reness legt.

Der nachste Teil der Ausarbeitung hat einige Ansatzevorgestellt welche fur das Projekt relevant sind. Activity BasedComputing macht die Arbeit der Teammitglieder auch uberweite Entfernung fur alle Sichtbar. Der Informationsaustauschist simpel wodurch die verteilte Arbeit erleichtert wird [9][10]. Diese Prinzipien lassen sich auch auf die Retrospektiveubertragen. Die zweite vorgestellte Arbeit untersuchte eineRetrospektive am Ende eines Projektes mit Hilfe eines ein-fachen Trackingtools. Die Erkenntnisse hieraus zeigen, dassder Zugang zu detaillierten historischen Informationen neueAspekte der vergangenen Arbeit hervorbringen kann welchein der Retrospektive diskutiert werden konnen [11]. Bei derletzten vorgestellten Studie ging es um Participation Balancingmit einer digitalen Anzeige auf einem Tisch. Hier wurdegezeigt wie eine Hardwarelosung Einfluss auf das Verhaltender Teilnehmer in einem Gesprach haben kann und ein ausge-glicheneren Austausch fordert [13].

Auf Basis dieser und weiterer Arbeiten wurden nun eineAnsatze Punkte fur die Unterstutzung der Retrospektive for-muliert. So konnte ein Awareness-Monitor dabei helfen dasVerstandnis fur die Retrospektive zu steigern. Die Kommu-nikation konnte durch Integration von Audio und Video inbereits genutzten Trackingsystemen verbessert werden. DasMonitoring und die Visualisierung von relevanten Daten aufbeispielsweise einem Taskboard kann von großem Wert seinum die Qualitat des Meetings zu verbessern und Teammitglie-der zu ermutigen ihre Meinung zu außern.

Im letzten Abschnitt dieser Arbeit ging es nun darum einenpassenden Arbeitsplan fur das weitere Vorgehen in dem Projektauszuarbeiten und die Risiken des Projektes zu formulieren.Im Grundprojekt soll zunachst Jira als potenzielles Grund-system bewertet werden und ein Prototyp entwickelt werden.

Dieser soll dann in einem oder mehreren Unternehmen durchmehrwochige Tests evaluiert werden.

LITERATUR[1] VersionOne, “8th annual state of agile survey,” 2014.

[Online]. Available: http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf

[2] J. S. P. D, K. Schwaber, C. creators Of Scrum, C. J. Sutherl, and P. D,“The scrum papers: Nuts, bolts, and origins of an agile process.”

[3] K. Schwaber and J. Sutherland, “The scrum guide,” 2013.[4] K. E. Nidiffer and D. Dolan, “Evolving distributed project manage-

ment,” IEEE Software, vol. 22, no. 5, 2005, pp. 63–72.[5] J. D. Herbsleb and A. Mockus, “An empirical study of speed and

communication in globally distributed software development,” IEEETrans. Softw. Eng., vol. 29, no. 6, Jun. 2003, pp. 481–494. [Online].Available: http://dx.doi.org/10.1109/TSE.2003.1205177

[6] J. S. Olson and G. M. Olson, “Culture surprises in remote softwaredevelopment teams,” Queue, vol. 1, no. 9, Dec. 2003, pp. 52–59.[Online]. Available: http://doi.acm.org/10.1145/966789.966804

[7] ScrumAlliance, “The state of scrum: Benchmarks and guidelines,”2014. [Online]. Available: https://www.scrumalliance.org

[8] Y. Zhang and S. Patel, “Agile model-driven development in practice,”Software, IEEE, vol. 28, no. 2, march-april 2011, pp. 84 –91.

[9] J. E. Bardram, “Activity-based computing support for agileand global software development,” 2008. [Online]. Available:http://www.citeulike.org/user/bardram/article/6535062

[10] M. Esbensen and J. Bardram, “Tool support for globallydistributed scrum,” 2014. [Online]. Available: http://nexgsd.org/wp-content/uploads/2014/02/Esbensen-Bardram-2014-Tool-Support-for-Globally-Distributed-Scrum CSCW 2014 GSD Workshop.pdf

[11] B. Krogstie and M. Divitini, “Supporting reflection in software deve-lopment with everyday working tools,” 2010.

[12] K. Bachour, F. Kaplan, and P. Dillenbourg, “An interactive tablefor supporting participation balance in face-to-face collaborativelearning,” TLT, vol. 3, no. 3, 2010, pp. 203–213. [Online]. Available:http://doi.ieeecomputersociety.org/10.1109/TLT.2010.18

[13] J. M. DiMicco, A. Pandolfo, and W. Bender, “Influencing groupparticipation with a shared display,” in Proceedings of the 2004 ACMConference on Computer Supported Cooperative Work, ser. CSCW’04. New York, NY, USA: ACM, 2004, pp. 614–623. [Online].Available: http://doi.acm.org/10.1145/1031607.1031713

[14] S. Dorairaj, J. Noble, and P. Malik, “Understanding lack of trustin distributed agile teams: A grounded theory study,” in EvaluationAssessment in Software Engineering (EASE 2012), 16th InternationalConference on, May 2012, pp. 81–90.

[15] J. Paredes, C. Anslow, and F. Maurer, “Information visualization foragile software development,” in Software Visualization (VISSOFT),2014 Second IEEE Working Conference on, Sept 2014, pp. 157–166.

[16] I. Omoronyia, J. Ferguson, M. Roper, and M. Wood, “A review ofawareness in distributed collaborative software engineering,” Software:Practice and Experience, vol. 40, no. 12, 2010, pp. 1107–1133.[Online]. Available: http://dx.doi.org/10.1002/spe.1005