Soziale Aspekte hybrider und traditioneller Softwareentwicklung Jil Klünder1, Lisa Handke2, Torsten Gfesser2, Kurt Schneider1 und Simone Kauffeld2 1 Fachgebiet Software Engineering, Leibniz Universität Hannover, Deutschland {jil.kluender, kurt.schneider}@inf.uni-hannover.de 2 Lehrstuhl für Arbeits-, Organisations- und Sozialpsychologie, Technische Universität Braunschweig, Deutschland {l.handke, t.gfesser, simone.kauffeld}@tu-braunschweig.de Zusammenfassung verschiedener Arten von Arbeitsorganisation (do- kumentenzentriert oder agil) ändert jedoch nicht Agile Softwareentwicklung gewinnt zunehmend an nur die Organisation des Projekts, sondern auch Bedeutung. In den letzten beiden Jahrzehnten den Ablauf und damit den Lernerfolg der Studie- wurde der Anteil agil entwickelnder Firmen immer renden. größer. Die Entscheidung, ob in einem Team plan- getrieben oder agil entwickelt wird, wirkt sich auf Die Auswahl der verwendeten Arbeitsorganisa- die gesamte Organisation des Projekts und damit tion hat einen Einfluss auf die Kommunikation [1]. auf alle Beteiligten aus. Der Projekterfolg hängt wiederum zu 20 % von der Kommunikation des Teams ab [2]. Dadurch wird es auch für Studierende immer wichtiger, in Lehrveranstaltungen nicht nur Einbli- Bei dokumentenzentrierten Vorgehensweisen cke in traditionelle, dokumentenzentrierte Vorge- ist der Softwarelebenszyklus [3] mit seinen Phasen hensmodelle zu gewinnen, sondern auch Erfahrun- maßgeblich. Diese unterteilen sich in Anforde- gen mit agilen Prozessen zu sammeln. rungsanalyse, Entwurf, Implementierung, Über- prüfung und Wartung. Der Ablauf hat sich seit In Softwareprojekten an Hochschulen sollen 1956 zunehmend etabliert, führte jedoch nicht im- Studierende vor allem Soft Skills wie Team- und mer zu einem erfolgreichen Abschluss des Projekts. Kommunikationsfähigkeit erlernen oder ausbauen. Aus diesem Grund rückte die agile Softwareent- Dabei beeinflusst die Art, wie Software entwickelt wicklung seit 1990 zunehmend in den Fokus und wird, die Lernerfahrungen der Studierenden maß- sollte deshalb auch in der universitären Lehre be- geblich. Um diese Einflüsse genauer zu klassifizie- rücksichtigt werden. ren, untersuchen wir hybride und plangetriebene studentische Softwareprojekte in Bezug auf die In universitären Softwareprojekten sollen Stu- Intensität der Kommunikation im Team und das dierende ihre sozialen Fähigkeiten ausbauen und Auftreten von Konflikten. zudem ihre Programmierfähigkeiten erweitern. Aus diesem Grund ist es wichtig, dass der Projekt- Unsere Erkenntnisse erlauben Rückschlüsse auf erfolg nicht unter einer Agilisierung der Lehrveran- den Einfluss hybrider Entwicklungsmethoden auf staltung leidet. soziale Aspekte und spiegeln demnach wieder, ob der Einsatz hybrider Methoden in der Lehre an Wir untersuchen traditionelle und hybride stu- Hochschulen dazu führt, dass Studierende diese dentische Softwareprojekte hinsichtlich des Kom- Fähigkeiten ausbauen, oder ob sich das Verhalten munikationsverhaltens und dem Auftreten von im Vergleich zu plangetriebenen Projekten nicht Konflikten. Die Projekte stimmen in wesentlichen verändert. Projektparametern wie Dauer, Aufwand und Kom- plexität überein, unterscheiden sich aber in der Art der Arbeitsorganisation. Einleitung Agile Softwareentwicklung gewinnt zunehmend an Bedeutung. Um eine gute Vorbereitung von Studie- Die Struktur des Papiers ist wie folgt: Im folgenden renden auf die Wirtschaft zu gewährleisten, ist es Abschnitt präsentieren wir verwandte Arbeiten. deshalb erforderlich, in der universitären Lehre Danach werden die unterschiedlichen Arbeitsorga- agile Softwareprojekte zu integrieren. Der Einsatz nisationen vorgestellt. Im vierten Abschnitt wird das methodische Vorgehen mit der Stichprobe, Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 100 Jil Klünder, Lisa Handke, Torsten Gfesser, Kurt Schneider und Simone Kauffeld - Soziale Aspekte hybrider und traditioneller Software-Entwicklung dem Matching, der verwendeten Maße und dem Traditionelle Softwareentwicklung Vorgehen bei der statistischen Analyse beschrieben. In der traditionellen Softwareentwicklung durch- Die Ergebnisse werden im darauf folgenden Ab- läuft das Projekt sequenziell die Phasen des Soft- schnitt festgehalten, bevor das Fazit gezogen wird. ware-Development-Cycles [7]. Um mit der nächs- Die Zusammenfassung unserer Ergebnisse beendet ten Phase beginnen zu können, muss die vorherige das Papier. Phase vollständig abgeschlossen sein. Diese Vorge- hensweise wurde als Nine-Phase-Stage-Wise-Modell Verwandte Arbeiten bereits 1956 von Bennington [8] vorgestellt und Der Einfluss von der Arbeitsorganisation auf 1970 von Royce [9] weiterentwickelt. Royce [9] Kommunikationsverhalten und Konflikte ist nicht ordnete die Phasen in seinen grafischen Darstel- unbekannt und war bereits Gegenstand vorheriger lungen als Kaskade bzw. Wasserfall an, woraus Forschungen. sich die Bezeichnung Wasserfall-Modell ergibt. Dabei handelt es sich um das bekannteste traditionelle Bindrees et al. [1] untersuchten die Kommuni- Entwicklungsmodell. kation in verschiedenen Projektphasen. Sie konnten nachweisen, dass in den Projektphasen unter- Der Ablauf im Wasserfall-Modell ist sequenzi- schiedlich intensiv kommuniziert wird. Auf diesen ell. Das Projekt startet mit einer Anforderungsanaly- Ergebnissen aufbauend, möchten wir die Aussage se, während der die Anforderungen mit dem Kun- konkretisieren und auf unterschiedliche Arbeitsor- den herausgearbeitet und schließlich in einer An- ganisationen beziehen. forderungsspezifikation mit einem Lasten- und Pflichtenheft festgehalten werden. Nach dieser In der agilen Entwicklung fordern Beck und Phase folgen der Entwurf, die Implementierung und Andres [4], dass die Kommunikation zwischen den schließlich die Überprüfung durch den Kunden. Stakeholdern maximiert werden müsse. Wie die Kommunikation in agilen Teams tatsächlich ab- Diese Arbeitsorganisation wird auch heute läuft, wurde bislang jedoch noch nicht näher unter- noch vielfach genutzt. Sofern es sich um Projekte sucht und ist unter anderem Bestandteil unserer mit stabilen Anforderungen handelt, bei denen Arbeit. Kosten und Umfang genau abgeschätzt werden können, stellt der sequenzielle Ablauf keine großen Brügge et al. [5] analysierten studentische Schwierigkeiten dar. Da dies jedoch oftmals nicht Softwareprojekte. Sie präsentierten eine Vorge- möglich ist, gewinnt die agile Softwareentwicklung hensweise, die die Fähigkeiten der Studierenden zunehmend an Bedeutung. verbessern und zu in der Wirtschaft verwendbaren Ergebnissen führen soll. Um schnelles Feedback Agile Softwareentwicklung und kurzzeitige Releases zu ermöglichen sowie Basierend auf sich ständig ändernden Kundenwün- Kommunikation zu fördern, verwendeten sie die schen, dem Wunsch nach zuverlässigerer Kunden- Tools Rugby und Tornado. In dem Papier beschrei- zufriedenheit und Projekterfolg formulierten Beck ben sie ihre Erfahrungen mit dem Einsatz der Tools et al. [10] zwölf Prinzipien und agile Werte, die im in studentischen Lehrveranstaltungen. Die Tools Agilen Manifest [10] festgehalten wurden. Der unterstützten die Studenten hinsichtlich ihrer tech- Grundgedanke agiler Softwareentwicklung ist ein nischen und nicht-technischen Fähigkeiten wie iteratives Vorgehen, wie es im Spiralmodell nach bspw. Kommunikation und Teamwork. Boehm dargestellt wird [11]. Das Projekt durchläuft Schneider et al. [6] analysierten studentische mehrfach die Phasen Anforderungsanalyse, Entwurf, traditionell entwickelnde Teams hinsichtlich ihrer Implementierung und Überprüfung in Teilschritten, Stimmung, des Konfliktpotenzials und des Kom- um sich dem gewünschten Endzustand des Kun- munikationsverhaltens. Sie fanden heraus, dass der den immer mehr anzunähern [10]. Anteil der sozialen Konflikte über die Projektlauf- Kundenzufriedenheit hat höchste Priorität und zeit ansteigt, während aufgabenbezogene Konflikte wird durch die regelmäßige Präsentation von funk- zunächst zunahmen und schließlich wieder abfie- tionsfähigen und ausführbaren Inkrementen si- len. Wir nutzen diese Ergebnisse für Vergleiche chergestellt [10]. Dies wird durch iterative kurze zwischen agiler und traditioneller Softwareent- Entwicklungszyklen von wenigen Wochen bis we- wicklung. nigen Monaten erreicht. Arbeitsorganisation Seit Beginn der 1990er Jahre etablierten sich verschiedene Vorgehensweisen und Formate. Eine Dieses Kapitel dient als eine kurze Einführung in der bekanntesten ist Scrum. Scrum wurde für die die hier betrachteten Arbeitsorganisationen: die Softwareentwicklung erstmals 2002 ausformuliert traditionelle, die agile und die hybride Software- [12]. Es wird zwischen drei Rollen unterschieden: entwicklung. Product-Owner, Entwicklungsteam und Scrum Mas- Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 101 Jil Klünder, Lisa Handke, Torsten Gfesser, Kurt Schneider und Simone Kauffeld - Soziale Aspekte hybrider und traditioneller Software-Entwicklung ter. Der Product-Owner ist der Projektverantwortli- Hypothese 1: che, vergleichbar mit einem Kunden, der über das Teams, die nach dem Wasserfall-Modell entwi- weitere Vorgehen und die Priorität der Anforde- ckeln, kommunizieren vor dem Midpoint intensi- rungen entscheidet. Er steht stets für Nachfragen ver als danach. des Teams zur Verfügung und ist möglichst oft vor Ort (On-Site-Customer). In der agilen Entwicklung spielt die Kommunikati- Wesentlicher Bestandteil von Scrum sind die on zu jeder Zeit eine wichtige Rolle. In den hier betrachteten hybriden Projekten gibt es einen On- Daily Scrums, in denen jeder Entwickler innerhalb Site-Customer, der wöchentlich vor Ort ist. Da die von zwei Minuten über den Fortschritt seit dem Kommunikation mit dem Kunden demnach über letzten Daily, über Pläne bis zum nächsten Daily die gesamte Projektlaufzeit konstant bleiben sollte und über eventuell auftretende Probleme berichtet. und wir annehmen, dass die team-interne Kom- Neben dem Daily gibt es noch weitere Meetings, munikation während der Implementierungsphase die zum Teil mit und teilweise ohne Kunden abge- aufgrund von Absprachen mit den Teammitglie- halten werden. Der Scrum Master koordiniert die dern zunimmt, können wir folgende Hypothese Meetings, sofern dies vonnöten ist, und sorgt für formulieren: die Wahrung der agilen Werte und Prinzipien. Hypothese 2: Hybride Softwareentwicklung Teams, die nach hybriden Methoden entwickeln, Die hybride Softwareentwicklung vereint Elemente kommunizieren nach dem Midpoint intensiver als der traditionellen, dokumentenzentrierten Vorge- davor. hensmodelle mit agilen Artefakten [13]. Als Aufgabenkonflikte werden Konflikte bezeichnet, Die Projekte benötigen Organisation und müs- bei denen sich die Teammitglieder aufgrund sen zudem in die Unternehmensstruktur und die unterschiedlicher Ansichten, Meinungen und Ideen Vorgehensweisen eingegliedert werden. Agile Me- nicht über die Inhalte einer Aufgabe einigen thoden geben für einige Unternehmen nur unzu- können [16]. Im Gegensatz zu sozialen Konflikten reichende Hilfestellung bei der Eingliederung der sind aufgabenbezogene Konflikte nicht nur negativ agilen Methoden in die Unternehmensstruktur. Da einzuordnen; sie können sogar leistungsfördernd viele Entwickler agil vorgehen, entsteht ein Kon- wirken [17]. Da Meinungsverschiedenheiten zu flikt in Bezug auf die Organisation. Dieser soll ge- intensiverer Kommunikation führen bzw. selbst als löst werden, indem hybride Ansätze verfolgt wer- Kommunikationsprozess begriffen werden können den. Das Ziel ist dabei die Nutzung der Vorteile [18], liegt die Annahme nahe, dass Kommunikati- beider Entwicklungsmethoden: der Organisation onsintensität und Aufgabenkonflikte eng zusam- und der Vorgaben in der plangetriebenen Soft- menhängen. wareentwicklung und der Flexibilität der agilen Entwicklung [14]. Da wir bei Teams, die nach dem Wasserfallmo- dell arbeiten, von einem Anstieg der Kommunika- Methodisches Vorgehen tion von der ersten zur zweiten Projekthälfte aus- gehen, nehmen wir dies dementsprechend ebenso Um die studentischen Softwareprojekte miteinan- für Aufgabenkonflikte an. Dies würde sich zudem der vergleichen zu können, mussten zunächst ge- mit den Ergebnissen von Schneider et al. [6] de- eignete Projekte ausgewählt und ein analoger Ab- cken, die einen Anstieg aufgabenbezogener Kon- lauf sichergestellt werden. flikte zum Midpoint verzeichneten, bevor die An- Gersick [15] fand heraus, dass ein Team in ei- zahl in der zweiten Projekthälfte abfiel: nem Projekt nach der Hälfte der Projektlaufzeit Hypothese 3: seine Strategie wechselt. Diesen Zeitpunkt nannte er Midpoint. In den hier betrachteten studentischen Teams, die nach dem Wasserfall-Modell entwi- Softwareprojekten markiert der Midpoint den Be- ckeln, haben vor dem Midpoint mehr Aufgaben- ginn der Implementierung. Wir betrachten im Fol- konflikte als danach. genden die beiden Bereiche des Projekts vor und In den hybriden Softwareprojekten gehen wir auf- nach dem Midpoint. grund der ansteigenden Kommunikation nach Hy- Nach Bindrees et al. [1] ist die Kommunikati- pothese 2 von einem Anstieg der Aufgabenkonflik- onsintensität in der Anforderungs- und Entwurfs- te von der ersten zur zweiten Projekthälfte aus. phase am höchsten. Die Anforderungsphase legt Dementsprechend formulieren wir die folgende den Grundbaustein für den weiteren Projektverlauf Hypothese: und ist demnach von besonderer Bedeutung [7]. Aus diesem Grund nehmen wir an: Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 102 Jil Klünder, Lisa Handke, Torsten Gfesser, Kurt Schneider und Simone Kauffeld - Soziale Aspekte hybrider und traditioneller Software-Entwicklung Hypothese 4: mit Moderator, in dem sämtliche Befunde zusam- mengetragen wurden. Ebenso wie die Anforde- Teams, die nach hybriden Methoden entwickeln, rungsanalyse endete auch die Entwurfsphase mit haben nach dem Midpoint mehr Aufgabenkonflikte einem Quality-Gate. als davor. Die restliche Projektlaufzeit stand im Wesentli- Diese Hypothesen wollen wir im Folgenden vali- chen für die Implementierung zur Verfügung. Hier dieren. mussten nachweislich alle Teammitglieder einge- Studentische Softwareprojekte bunden werden. Diese Phase dauerte je nach Leis- tung des Teams und Fortschritt ungefähr fünf bis Im Rahmen einer Lehrveranstaltung an der Leibniz sechs Wochen. Universität Hannover entwickeln Studierende im fünften Semester ihres Informatik-Bachelor- Danach hatte das Team in der Polish-Phase die studiums in Teams über einen Zeitraum von 15 Möglichkeit, letzte Änderungswünsche des Kun- Wochen ein Softwareprodukt. Der Umfang und der den einzupflegen und die Qualität der Software zu Aufwand aller Projekte sind annähernd vergleich- steigern. bar. Aus jedem Team übernehmen zwei Studieren- Nach dieser Phase gab es ein letztes Quality- de die Rollen des Projektleiters und des Qualitäts- Gate, in dem im Wesentlichen das Erfüllen der beauftragten. Der Kunde ist meistens ein Mitarbei- Anforderungsspezifikation und das Einhalten von ter des Fachgebiets Software Engineering und hat vorgegebenen Code-Konventionen überprüft wur- ein großes Interesse an einem erfolgreichen Projekt- den. abschluss. Er möchte die entwickelte Software lang- Das Projekt endete mit der Kundenabnahme, die fristig nutzen. Unterstützt werden die Teams au- über den erfolgreichen Abschluss entschied. ßerdem von einem erfahrenen Tutor, der bei zwi- schenmenschlichen und anderen nicht-technischen Hybride Softwareprojekte. Seit dem Wintersemes- Fragen zur Verfügung steht. Technische Fragen ter 2014/2015 werden einige agile Artefakte in die sollen die Teams direkt mit dem Kunden oder Lehrveranstaltung integriert. Zudem bestehen die team-intern klären. Teams nun aus acht oder neun Studierenden. Das Softwareprojekt folgte lange Zeit dem In Anlehnung an das Konzept des On-Site- Wasserfallmodell. Seitdem wurde die Lehrveran- Customers steht der Kunde wöchentlich zu einem staltung durch Integration einiger agiler Artefakte fest vorgegebenen Termin zur Verfügung, um über zunehmend hybrider. den Projektverlauf und den aktuellen Stand infor- miert zu werden. Dieses Meeting ist vergleichbar Traditionelle Softwareprojekte. Bis einschließlich mit einem Review-Meeting in der agilen Software- dem Wintersemester 2013/2014 folgten die Soft- entwicklung, wenngleich die wöchentlichen Itera- wareprojekte dem traditionellen dokumenten- tionen nicht als Sprints angesehen werden können. zentrierten Ansatz. Entwickelt wurde nach dem Wasserfall-Modell in Teams von drei bis fünf Stu- Das gesamte Team-Meeting umfasst ungefähr dierenden in mehreren Phasen [7]. eine Stunde und beginnt mit einem Weekly Scrum, in dem jedes Team-Mitglied über seinen Fortschritt Das Projekt startete mit einer dreiwöchigen An- seit dem letzten Scrum-Meeting, über die Pläne bis forderungsanalyse. Währenddessen fand das erste zum nächsten Scrum-Meeting und über Probleme Kundengespräch zur Klärung der Anforderungen spricht. Nach dem Weekly Scrum kommt der Kun- statt. Die Studierenden mussten eigenständig den de hinzu und wird über die wesentlichen Punkte Kontakt zum Kunden herstellen und einen Termin informiert, äußert Änderungswünsche oder geän- vereinbaren. Das Treffen musste vorbereitet, abge- derte Anforderungen und steht für offene Fragen halten und nachbereitet werden, da die Zeit, in der zur Verfügung. der Kunde zur Verfügung stand, auf 90 Minuten während der gesamten Projektlaufzeit begrenzt Wie auch in der plangetriebenen Entwicklung war. Die Phase endete mit dem Verfassen einer gibt es angelehnt an den Ablauf nach Kent et al. Anforderungsspezifikation, die mit dem Kunden [10] eine Anforderungsanalyse mit dem Verfassen abgestimmt und schließlich auch von ihm unter- einer Anforderungsspezifikation, eine Entwurfspha- zeichnet werden musste. Danach passierte das se, die Implementierung und eine Überprüfung des Team das erste Quality-Gate. Ergebnisses durch den Kunden. Jedoch werden diese Phasen iterativ durchlaufen. Insgesamt gibt es Es folgte eine Phase über zwei Wochen, in de- in den Projekten zwei Iterationen. nen der Entwurf verfasst oder ein Prototyp entwi- ckelt wurde. Um den Erfahrungsschatz der Studie- Stichprobe und Matching renden zu erweitern, musste zudem der Entwurf Für die Validierung der Hypothesen verwenden oder der Prototyp eines anderen Teams gereviewt wir Daten aus dem TeamFLOW-Forschungsprojekt werden. Dazu gab es ein reguläres Review-Meeting Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 103 Jil Klünder, Lisa Handke, Torsten Gfesser, Kurt Schneider und Simone Kauffeld - Soziale Aspekte hybrider und traditioneller Software-Entwicklung [19], die in den zuvor beschriebenen studentischen = .88 und α = .90.1 Für die Berechnung auf Team- Softwareprojekten erhoben wurden. ebene wurden die Werte zum Teammittelwert ag- Wir betrachten Daten aus zwei Kohorten: gregiert. 2013/14 und 2015/2016. Die erste Kohorte folgte Messzeitpunkte. In Abb. 1 ist die Datenerhebung dem traditionellen Ansatz nach dem Wasserfall- nach Kohorten dargestellt. Es wird ersichtlich, dass Modell und die zweite Kohorte dem hybriden An- die Daten zum Kommunikationsverhalten in der satz. Kohorte, die nach dem Wasserfallmodell arbeitete, In der ersten Kohorte haben 20 Teams an der wöchentlich erhoben wurden, während sie in der Datenerhebung teilgenommen. Da die Teams in Kohorte, die hybrid arbeitete, nur an drei ausge- den hybriden Projekten größer waren, liegen hier wählten Messpunkten abgefragt wurden. Die Er- nur Daten von acht Teams vor. Aus diesem Grund hebung von Konflikten erfolgte jeweils zu drei musste zunächst ein Matching der vorhandenen Messpunkten: in der ersten Woche, in der Mitte des Daten durchgeführt werden, um acht geeignete Projektes und nach Projektabschluss. Die grau hin- Projekte aus der ersten Kohorte auszuwählen. Die- terlegten Wochen kurz vor Projektende spiegeln ses Matching erfolgte auf Basis von Alter und Ge- die Weihnachtsferien wieder, in denen die Studie- schlecht, da sich die beiden Kohorten nicht signifi- renden zwar an der Software weiterarbeiten durf- kant in den Mittelwerten des Alters unterscheiden ten, aber nicht dazu verpflichtet waren. (hybrid: M = 21.9, SD = 1.05; Wasserfall: M = 21.9, Basierend auf den Messzeitpunkten betrachten wir SD = 1.01; t(7) = -.413, p = .692). Ferner wurden in diesem Papier drei Zeitpunkte: unmittelbar nach Teams mit unvollständigen Datensätzen nicht be- Projektstart, in der sechsten Woche mit den Erhe- rücksichtigt. bungen in den beiden Kohorten und in der letzten Auf Basis dieses Matchings erhielten wir insge- Woche. samt acht Teams aus der Wasserfall-Kohorte, die wir mit den acht Teams aus der Hybrid-Kohorte vergleichen konnten. Datenerhebung Kommunikationsintensität. Die Kommunikations- intensität wurde durch Abfragen nach der wahrge- nommenen Intensität der Kommunikation mit den anderen Team-Mitgliedern erhoben. Dabei stand eine Likert-Skala mit fünf Werten von 1 („gar nicht kommuniziert“) bis 5 („sehr hohe Intensität“) zur Abbildung 1: Datenerhebung nach Kohorten Verfügung. Auf diese Art entstand eine Matrix mit Einträgen aij, die angeben, wie intensiv Team- Ethik-Votum Mitglied i die Kommunikation mit Team-Mitglied j in der vergangenen Woche wahrgenommen hat. Die Datenerhebung wurde vom Ethik-Komitee der Die ungerichtete Kommunikationsintensität cij zwi- Leibniz Universität Hannover genehmigt. Die Stu- schen den beiden Team-Mitgliedern i und j ergibt dierenden wurden vorab über die Datenerhebung sich dann durch den Durchschnitt der beiden Wer- und die weitere Verwendung der gesammelten te: Daten informiert und stimmten dieser zu. Darüber hinaus wurden die gesammelten Daten vor der cij = avg(aij, aji). weiteren Verwendung vollständig anonymisiert. Um den Teamwert zu erhalten, wird der Durch- Eine Teilnahme an der Befragung hatte keinen Ein- schnitt aller ungerichteten Kommunikationswerte fluss auf das Bestehen der Lehrveranstaltung. im Team berechnet. Konflikte. Aufgabenkonflikte wurden mit der Statistische Analyse deutschen Version der Intragroup Conflict Scale Alle Hypothesentests wurden jeweils aufgrund der von Jehn [16] von Lehman-Willenbrock et al. [20] geringen Stichprobengrößen von acht Teams zu- erhoben. Insgesamt gab es vier Items für aufgaben- nächst einem Test auf Normalverteilung unterzo- gezogene Teamkonflikte. Ein Beispielitem ist: „Wie gen. Dafür wurde der Shapiro-Wilk-Test verwen- häufig gibt es Ideenkonflikte in der Gruppe?“ Den det, da dieser Test bei kleinen Stichproben unter 30 Studierenden stand eine sechs-stufige Likert-Skala mit Werten zwischen 1 (nie/keine) und 6 (sehr oft/sehr viele) zur Verfügung. Die Reliabilitäten der 1Cronbachs Alpha spiegelt die interne Konsistenz Skala für die drei Messzeitpunkte lagen zwischen α einer verwendeten Skala wieder. Es gibt an, inwie- fern alle Items das gleiche Konstrukt messen. Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 104 Jil Klünder, Lisa Handke, Torsten Gfesser, Kurt Schneider und Simone Kauffeld - Soziale Aspekte hybrider und traditioneller Software-Entwicklung eine größere Teststärke aufweist als andere Nor- Berechnungen der Ergebnisse ein. Den Wert für die malverteilungstests [21]. Die erste Hypothese wird erste Projekthälfte stellt die Differenz zwischen mittels t-Test für abhängige Stichproben überprüft. dem Wert für den Midpoint und der Baseline (Pro- Für die erste Hypothese werden die Kommunika- jektbeginn) dar. Da in einem der hybridorganisier- tionsintensitäten der Wasserfall-Kohorte dahinge- ten Teams zu wenige Teammitglieder die Fragen hend überprüft, ob die Intensität in der zweiten zur Kommunikation beantworteten, wurde dieses Projekthälfte niedriger ist als in der ersten Projekt- Team für diesen Zeitpunkt aus der Analyse ausge- hälfte: μ1 > μ2. schlossen. Demnach liegt die Stichprobengröße für Für die zweite Hypothese werden die Kommuni- Kommunikationswerte zur ersten Projekthälfte bei kationsintensitäten der Hybrid-Kohorte dahinge- N=7. hend überprüft, ob die Intensität in der zweiten Konflikte. Fragebögen zur Erhebung von Konflik- Projekthälfte höher ist als in der ersten Projekthälf- ten wurden auch bei traditionell organisierten te: μ1 < μ2. Teams zu lediglich drei Messzeitpunkten erhoben. Für die dritte Hypothese werden die Aufgaben- Die erste Erhebung fand in beiden Kohorten in der konflikte der Wasserfall-Kohorte dahingehend ersten Woche statt. Die zweite Erhebung stellt den überprüft, ob ihre Ausprägung in der zweiten Pro- Midpoint dar. Die letzte Erhebung fand in beiden jekthälfte niedriger ist als in der ersten Projekthälf- Kohorten nach dem Projektabschluss in Woche 14 te: μ1 > μ2. statt. Den Wert für die erste Projekthälfte stellt die Für die vierte Hypothese werden Aufgabenkon- Differenz zwischen dem Wert für den Midpoint flikte der Hybrid-Kohorte dahingehend überprüft, und der Baseline (Projektbeginn) dar. ob ihre Ausprägung in der zweiten Projekthälfte höher ist als in der ersten Projekthälfte: μ1 < μ2. Vorbereitung und Vorgehen Signifikanzniveau Zunächst wurde der Datensatz aller Teams aus der Wasserfall-Kohorte aufgrund der geringen Stich- Da ausschließlich gerichtete Hypothesen aufgestellt probengröße (N = 7 bzw. N = 8) mit dem Shapiro- wurden, wurde bei der Hypothesenprüfung einsei- Wilk-Test auf Normalverteilung geprüft. Dies traf tig getestet. Wir legten das Signifikanzniveau auf bei den Daten zu Überprüfung aller vier Hypothe- 5% fest. Um eine bessere Interpretierbarkeit der sen zu. Ergebnisse zu erzielen, werden in dieser Arbeit neben der Betrachtung signifikanter Befunde zu- sätzlich die Effektgrößen dargestellt. Cohens d [22], Ergebnisse das zur Einschätzung der Größe eines Effekts ver- Die Hypothesen 1, 2 und 3 konnten bestätigt wer- wendet wird2, ist für die verwendeten t-Tests rele- den; die Hypothese 4 konnte nicht bestätigt wer- vant. den. Hypothese 1. Ein t-Test für verbundene Stichpro- Aggregation ben ergab einen signifikanten Unterschied zwi- Wie aus Abb. 1 ersichtlich wird, liegen für die bei- schen der Kommunikationsintensität vor dem Mid- den Stichproben unterschiedlich viele Daten vor. point (M = .45, SD = .68) und den Mittelwerten der Die Probanden aus der ersten Kohorte gaben 14 Kommunikationsintensität nach dem Midpoint (M Wochen lang wöchentlich Auskunft. Die Studie- = -.53, SD = .68), t(7) = 4.46, p = .003, d = 1.57. Hypo- renden aus der zweiten Kohorte gaben nur in den these 1 kann somit bestätigt werden. Es handelt Wochen eins bis zwei (Projektbeginn), sechs (Mid- sich um einen großen Effekt. point) und vierzehn (Projektabschluss) Auskunft Hypothese 2. Ein t-Test für verbundene Stichpro- über Konflikte und Kommunikation. Dementspre- ben ergab einen signifikanten Unterschied zwi- chend wurden zum Vergleich die Werte aus genau schen der Kommunikationsintensität vor dem Mid- diesen Wochen von der Wasserfall-Kohorte ge- point (M = .15, SD = .43) und den Mittelwerten der wählt. Der Midpoint in der Mitte der Projektlauf- Kommunikationsintensität nach dem Midpoint (M zeit liegt demnach in Woche sechs. = .38, SD = .37), t(6) = -2.13, p = .039, d = 0.83. Hypo- Kommunikationsintensität. Bei den hybrid arbei- these 2 kann somit bestätigt werden. Es handelt tenden Teams wurden lediglich in den Wochen sich um einen großen Effekt. zwei, sechs und vierzehn Daten erhoben. Deshalb Hypothese 3. Ein t-Test für verbundene Stichpro- gingen auch nur diese drei Wochen der traditionell ben ergab einen signifikanten Unterschied zwi- organisierten Teams als zeitliches Äquivalent in die schen Aufgabenkonflikten vor dem Midpoint (M = .57, SD = .52) und den Mittelwerten der Aufgaben- 2Bei einem Wert von d ≥ 0.20 spricht man von ei- konflikte nach dem Midpoint (M = .38, SD = .57), t(7) nem kleinen Effekt, bei d ≥ 0.50 von einem mittleren = 2.03, p = .041, d = 0.74. Hypothese 3 kann somit Effekt und ab d ≥ 0.80 von einem großen Effekt. Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 105 Jil Klünder, Lisa Handke, Torsten Gfesser, Kurt Schneider und Simone Kauffeld - Soziale Aspekte hybrider und traditioneller Software-Entwicklung bestätigt werden. Es handelt sich um einen mittle- auf Bedrohungen der Validität eingegangen wer- ren Effekt. den. Dabei beziehen wir uns auf die Klassifizierung Hypothese 4. Ein t-Test für verbundene Stichpro- der Threats to Validity nach Wohlin et al. [23]. Wir ben ergab keinen signifikanten Unterschied zwi- differenzieren zwischen interner, externer und Kon- schen Aufgabenkonflikten vor dem Midpoint (M = struktvalidität und Verlässlichkeit der Ergebnisse. .25, SD = .51) und den Mittelwerten der Kommuni- Interne Validität: Einen team-internen Austausch kationsintensität nach dem Midpoint (M = .06, SD = über die Fragebögen und Absprachen hinsichtlich .50), t(6) = 1.00, p = .353. Hypothese 4 musste dem- der Beantwortung der Fragen konnten wir nicht nach abgelehnt werden. verhindern. Dies kann die Ergebnisse unserer Be- rechnungen beeinflusst haben. Da die Beantwor- Diskussion und Interpretation tung der Fragebögen und die Teilnahme an der Datenerhebung keinen Einfluss auf das Bestehen In dieser Studie untersuchten wir die Einflüsse der der Lehrveranstaltung hatte, schätzen wir den An- Arbeitsorganisation auf die Intensität der Kommu- teil an falschen Antworten als ziemlich gering ein, nikation und die Konflikte in Teams. Grundlage da die Studierenden dadurch keinen Vorteil hätten. der Untersuchungen waren drei Messzeitpunkte über den Projektverlauf. Externe Validität: Durch das akademische Umfeld lassen sich unsere Ergebnisse nur bedingt auf die Zunächst wurde der Verlauf der Kommunika- Industrie anwenden. Das liegt an der geringen tionsintensität nur für Teams, die nach dem Was- Stichprobe, die die Gültigkeit der Ergebnisse auch serfall-Modell oder hybrid arbeiten, untersucht. für andere studentische Projekte einschränkt. Zu- Dabei sollte herausgefunden werden, ob die Inten- dem lagen uns nur Daten zu drei Messzeitpunkten sitäten gemäß der arbeitsorganisatorischen Modelle vor. Ein detaillierterer Vergleich würde in Bezug und der Theorie verlaufen. Anschließend wurden auf den Verlauf der Kommunikationsintensität die Kommunikationsintensitäten beider Arbeitsor- vermutlich zu ähnlichen Ergebnissen führen. Mög- ganisationen gegenüber gestellt und zusammen licherweise könnten mit einer größeren Stichprobe untersucht. Die Ergebnisse unterstützen drei der auch projektphasenabhängige Muster aufgedeckt vier formulierten Hypothesen: werden, die bislang nicht erkannt wurden. Hypothese 1: Darüber hinaus hatten die Studierenden nur Teams, die nach dem Wasserfall-Modell entwi- zum Teil Erfahrungen in Softwareprojekten oder ckeln, kommunizieren vor dem Midpoint intensi- gar in der Industrie. Ferner betrachteten wir nur ver als danach. sehr vergleichbare Projekte mit einem ähnlichen Umfang und Übereinstimmungen in verschiedenen Hypothese 2: Projektparametern wie Dauer oder dem Erfah- Teams, die nach hybriden Methoden entwickeln, rungsschatz der Teammitglieder. kommunizieren nach dem Midpoint intensiver als Konstruktvalidität: Die Fragebögen waren sehr all- davor. gemeinverständlich formuliert, sodass wir keine Hypothese 3: Einschränkungen der Validität aufgrund von falsch verstandenen Fragen erwarten. Teams, die nach dem Wasserfall-Modell entwi- ckeln, haben vor dem Midpoint mehr Aufgaben- Dennoch könnte die Erhebung der Intensität konflikte als danach. könnte als problematisch aufgefasst werden, da es sich hierbei um eine sehr subjektive Einschätzung Hypothese 4: handelt. Von Klünder et al. [24] konnte nachgewie- Teams, die nach hybriden Methoden entwickeln, sen werden, dass die Inkonsistenzen zwischen den haben nach dem Midpoint mehr Aufgabenkonflikte wahrgenommenen Intensitäten hinreichend gering als davor. sind, sodass die Erhebung der Intensität auf diese Weise möglich ist. Dennoch unterliegen diese Ergebnisse einigen Ein- schränkungen in Bezug auf Validität und Verall- Darüber hinaus können wir Auswirkungen der gemeinerbarkeit. Teamgrößen auf Kommunikation und Konflikte nicht ausschließen. Steigende Teamgröße führt Bedrohungen der Validität nachweislich zu Motivations- und Koordinations- Unsere Untersuchung basiert auf einer Erhebung in verlusten in Gruppen [25]. Zudem konnten Ama- studentischen Softwareprojekten. Daraus ergeben son und Sapienza [26] zeigen, dass Teamgröße sich einige Einschränkungen in Bezug auf die Ver- positiv mit kognitiven Konflikten (welche Aufga- allgemeinerbarkeit der Ergebnisse für die Industrie. benkonflikten stark ähneln) korreliert. Da in unse- Rückschlüsse für studentische Lehrveranstaltungen rer Studie die hybriden Teams auch gleichzeitig sind jedoch möglich. Trotzdem soll im Folgenden deutlich größer als die Teams der Wasserfall- Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 106 Jil Klünder, Lisa Handke, Torsten Gfesser, Kurt Schneider und Simone Kauffeld - Soziale Aspekte hybrider und traditioneller Software-Entwicklung Kohorte waren, können wir eine Konfundierung mehr team-interne Absprachen notwendig sind, da mit dem Faktor Teamgröße demnach nicht aus- zwar – im Falle der hier betrachteten Softwarepro- schließen. jekte – eine Spezifikation existiert, diese aber nicht Verlässlichkeit: Eine erneute Durchführung dieser bindend ist, da auf Änderungswünsche des Kun- Untersuchung auf Basis einer anderen Datenerhe- den eingegangen werden soll. Aus diesem Grund bung könnte zu anderen Ergebnissen führen, so- sind möglicherweise klärende Absprachen vonnö- fern unterschiedliche Aufgabenstellungen, Teil- ten, wodurch die Intensität der Kommunikation nehmende mit einer anderen Wissensbasis, Projekt- zunimmt. abläufe und Teamstrukturen betrachtet werden. Konflikte. Unsere Untersuchung zeigt, dass bei Darüber hinaus hängt das Kommunikationsverhal- Teams mit traditioneller Softwareentwicklung auf- ten stark vom Charakter der Teammitglieder ab. gabenbezogene Konflikte über die Zeit bzw. nach Demnach beeinflusst die Teamkonstellation die dem Midpoint abnehmen. Dies lässt sich u.a. über Ergebnisse zusätzlich. Die Betrachtung einer Da- die erhöhte Kommunikationsintensität zu Projekt- tenerhebung mit vergleichbaren Projektparametern beginn erklären. sollte aber zu ähnlichen Ergebnissen führen. Interpretation Die Ergebnisse erlauben auch einige für die univer- Unsere Ergebnisse zeigen, dass traditionell organi- sitäre Lehre interessante Rückschlüsse. So wird sierte Teams in der ersten Hälfte des Projekts deut- beispielsweise deutlich, dass die Wahl der Arbeits- lich intensiver kommunizieren als in der zweiten organisation einen Einfluss auf das Kommunikati- Projekthälfte. Hybrid arbeitende Teams kommuni- onsverhalten hat. Damit beeinflusst sie zudem den zieren hingegen vermehrt in der zweiten Projekt- Lernerfolg der Studierenden, die während der Ar- hälfte. beit im Team vor allem soziale Fähigkeiten wie beispielsweise die Kommunikationsfähigkeiten Neben der Kommunikationsintensität wurden erlernen oder ausbauen sollen. Vor allem die noch aufgabenbezogene Konflikte untersucht. Die- Kommunikationsfähigkeit ist in industriellen Pro- ses Konstrukt wurde ebenfalls zu drei Messzeit- jekten von äußerster Bedeutung. Daher empfiehlt punkten erhoben, jedoch lediglich als aggregierte es sich, Elemente wie beispielsweise den On-Site- Werte pro Arbeitsorganisation gegenübergestellt. Customer in studentischen Arbeitsprojekten zu Hier konnte festgestellt werden, dass – analog zur integrieren, um den Studierenden einen intensiven Kommunikationsintensität – traditionell organisier- Kundenkontakt zu ermöglichen, für den eine adä- te Teams in der ersten Projekthälfte mehr aufga- quate Kommunikation unabdingbar ist. Darüber benbezogene Konflikte erleben. Für hybrid organi- hinaus stellt ein Weekly Scrum ein Minimum an sierte Teams konnten keine Unterschiede hinsicht- Informationsweitergabe sicher. Zudem lernen die lich aufgabenbezogener Konflikte zwischen den Studierenden, sich adäquat untereinander auszu- beiden Projekthälften festgestellt werden. tauschen und im anschließenden Kundengespräch Kommunikationsintensität. Traditionell organi- die Informationen an den Kunden weiterzugeben. sierte Teams kommunizieren in der ersten Projekt- Durch den wöchentlichen persönlichen Kontakt mit hälfte deutlich mehr als in der zweiten Projekthälf- dem Kunden wird der Umgang routinierter. Au- te. Dies geht mit den Erkenntnissen von Bindrees et ßerdem wirkt der hybride Ansatz einer Verringe- al. [1] einher. Sie fanden heraus, dass traditionell rung der Kommunikationsintensität in der zweiten organisierte Teams in den ersten Projektphasen am Projekthälfte entgegen. In der zweiten Projekthälfte intensivsten kommunizieren. Dieser Verlauf der liegt der Schwerpunkt auf der Implementierung Kommunikationsintensität lässt sich mit dem Was- der Software. Eine Verringerung der Kommunika- serfall-Modell begründen, da die Anforderungs- tionsintensität in der zweiten Projekthälfte, wie sie und Entwurfsphase ohne Kommunikation nicht bei den traditionell organisierten Projekten auftritt, erfolgen können, während Kommunikation für die deutet auf weniger Teamarbeit und Austausch Implementierung nicht mehr in großem Ausmaß während der Implementierung hin. Dies reduziert vonnöten ist, nachdem die Anforderungen klar unter Umständen den team-internen Wissensaus- herausgearbeitet und ausreichend dokumentiert tausch und die Kompetenzen der Teammitglieder wurden. können möglicherweise nicht optimal genutzt wer- Neu hingegen ist die Erkenntnis, dass hybrid den. entwickelnde Teams in der zweiten Projekthälfte mehr kommunizieren. Dies lässt sich damit erklä- Fazit ren, dass die Kommunikation mit dem Kunden In dieser Studie untersuchten wir den Einfluss der über den gesamten Projektverlauf nahezu konstant Arbeitsorganisation auf die Intensität der Kommu- bleibt, während in der Implementierungsphase nikation eines Teams und ihre Konflikte. Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 107 Jil Klünder, Lisa Handke, Torsten Gfesser, Kurt Schneider und Simone Kauffeld - Soziale Aspekte hybrider und traditioneller Software-Entwicklung Die Intensität der Kommunikation ist in den [9] Royce, W. W.: Managing the Development of untersuchten traditionell entwickelnden Teams in Large Software Systems: Concepts and Tech- der ersten Projekthälfte deutlich höher als in der niques. In: Proceedings of the 9th Internatio- zweiten Projekthälfte. Bei den hybrid organisierten nal Conference on Software Engineering, Teams gilt das Gegenteil. Entgegen unserer An- Monterey, California, USA (1987). nahmen unterschieden sich aufgabenbezogene [10] Beck, K.; Beedle, M.; van Bennekum, A.; Konflikte bei hybrid organisierten Teams zwischen Cockburn, A.; Cunningham, W.; Fowler, M.; der ersten und zweiten Projekthälfte nicht. Grenning, J.; Highsmith, J.; Hunt, A.; Jeffries, Die Verwendung von agilen Artefakten wie R.; Kern, J.; Marick, B.; Martin, R.; Mellor, S.; beispielsweise dem On-Site-Customer oder dem Schwaber, K.; Sutherland, J.; Thomas, D.: Weekly Scrum in der studentischen Lehre fördert Agile Manifesto 2001. die Kommunikationsfähigkeiten der Studierenden, [11] Boehm, B. W.: A spiral model of software ohne die Arbeit im Team zu erschweren. Deshalb development and enhancement. In: Compu- kann das Arbeiten in hybriden Projekten die Stu- ter 21 (1988) 5, S. 61–72. dierenden ohne zusätzliche Schwierigkeiten auf das spätere Arbeitsumfeld vorbereiten. [12] Schwaber, K.; Beedle, M.: Agile software development with Scrum. Upper Saddle Ri- ver, NJ 2002. Danksagung [13] West, D.: Water-Scrum-Fall is the Reality of Diese Arbeit wurde von der Deutschen For- Agile for Most Organizations Today. Manage schungsgesellschaft (DFG) unter der Projektnum- The Water-Scrum And Scrum-Fall boundari- mer 263807701 (Projekt: TeamFLOW) gefördert. es To Increase Agility, Technical Report. In: Forrester (2011). Literatur [14] Theocharis, G.; Kuhrmann, M.; Münch, J.; [1] Bindrees, M. A.; Pooley, R. J.; Ibrahim, I. S.; Diebold, P.: Is Water-Scrum-Fall Reality? On Taylor, N. K.: Re-Evaluating Media Richness the Use of Agile and Traditional Develop- Theory in Software Development Settings. ment Practices. In: Abrahamsson, P.; Corral, In: Journal of Computer and Communica- L.; Oivo, M.; Russo, B. (Hrsg.): Proceedings tions 02 (2014) 14, S. 37–51. of the 16th international conference on Pro- [2] Mohamed, J. M.; Qubaisi, L. F. A.; Elanain, duct-focused software process improvement. H. M. A.; Badri, M. A.; Ajmal, M. M.: Lea- PROFES 2015, Bolzano, Italy, 2015. dership, Culture and Team Communication. [15] Gersick, C. J. G.: Time and Transition in Analysis of project success causality - A UAE Work Teams. Toward a New Model of case. In: International Journal of Applied Group Development. In: Academy of Ma- Management Science 7 (2015) 3. nagement Journal 31 (1988) 1, S. 9–41. [3] ISO/IEC 12207:2008: Systems and software [16] Jehn, K. A.: A Multimethod Examination of engineering - Software life cycle processes. the Benefits and Detriments of Intragroup [4] Beck, K.; Andres, C.: Extreme Programming Conflict. In: Administrative Science Explained. Embrace Change, 2nd ed. Boston, Quarterly 40 (1995) 2. MA 2005. [17] Wit, F. R. C. de; Greer, L. L.; Jehn, K. A.: The [5] Brügge, B.; Krusche, S.; Alperowitz, L.: Soft- paradox of intragroup conflict: a meta- ware Engineering Project Courses with In- analysis. In: The Journal of applied psycho- dustrial Clients. In: ACM Transactions on logy 97 (2012) 2. Computing Education 15 (2015) 4. [18] Yang, J.; Mossholder, K. W.: Decoupling task [6] Schneider, K.; Liskin, O.; Paulsen, H.; Kauf- and relationship conflict. The role of in- feld, S.: Media, Mood, and Meetings. Related tragroup emotional processing. In: Journal of to Project Success. In: ACM Transactions on Organizational Behavior 25 (2004) 5. Computing Education 15 (2015) 4. [19] Deutsche Forschungsgemeinschaft (DFG): [7] Stoica, M.; Mircea, M.; Ghilic-Micu, B.: Soft- TeamFLOW: Interaktion und Kommunikati- ware Development. Agile vs. Traditional. In: on in verteilten Softwareteams. Informatica Economica 17 (2013) 4/2013. URL: http://gepris.dfg.de/gepris/projekt/2638 [8] Benington, H. D.: Production of Large Com- 07701. Abrufdatum 31.10.2016. puter Programs. In: Proceedings, [20] Lehmann-Willenbrock, N.; Meyers, R. A.; ONR Symposium (1956). Kauffeld, S.; Neininger, A.; Henschel, A.: Verbal Interaction Sequences and Group Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 108 Jil Klünder, Lisa Handke, Torsten Gfesser, Kurt Schneider und Simone Kauffeld - Soziale Aspekte hybrider und traditioneller Software-Entwicklung Mood. Exploring the Role of Team Planning ings of the the 12th International Conference Communication. In: Small Group Research on Predictive Models and Data Analytics in 42 (2011) 6. Software Engineering (PROMISE 2016). [21] Shapiro, S. S.; Wilk, M. B.: An analysis of ACM, New York, 2016. variance test for normality (complete sam- [25] Latané, B.; Williams, K.; Harkins, S.: Many ples). In: Biometrika 52 (1965) 3-4, S. 591–611. hands make light the work. The causes and [22] Cohen, J.: Statistical Power Analysis for the consequences of social loafing. In: Journal of Behavioral Sciences, 2nd ed. Hillsdale, N.J. Personality and Social Psychology 37 (1979) 1988. 6. [23] Wohlin, C.: Experimentation in software [26] Amason, A.: The effects of top management engineering. Berlin, New York 2012. team size and interaction norms on cognitive and affective conflict. In: Journal of Ma- [24] Klünder, J.; Karras, O.; Kortum, F.; Schnei- nagement 23 (1997) 4, S. 495–516. der, K.: Forecasting Communication Behav- ior in Student Software Projects. In Proceed- Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 109