Agile Softwareentwicklung gewinnt zunehmend an Bedeutung. In den letzten beiden Jahrzehnten wurde der Anteil agil entwickelnder Firmen immer größer. Die Entscheidung, ob in einem Team plangetrieben oder agil entwickelt wird, wirkt sich auf die gesamte Organisation des Projekts und damit auf alle Beteiligten aus.
Dadurch wird es auch für Studierende immer wichtiger, in Lehrveranstaltungen nicht nur Einblicke in traditionelle, dokumentenzentrierte Vorgehensmodelle zu gewinnen, sondern auch Erfahrungen mit agilen Prozessen zu sammeln.
In Softwareprojekten an Hochschulen sollen Studierende vor allem Soft Skills wie Team- und Kommunikationsfähigkeit erlernen oder ausbauen. Dabei beeinflusst die Art, wie Software entwickelt wird, die Lernerfahrungen der Studierenden maßgeblich. Um diese Einflüsse genauer zu klassifizieren, untersuchen wir hybride und plangetriebene studentische Softwareprojekte in Bezug auf die Intensität der Kommunikation im Team und das Auftreten von Konflikten.
Unsere Erkenntnisse erlauben Rückschlüsse auf den Einfluss hybrider Entwicklungsmethoden auf soziale Aspekte und spiegeln demnach wieder, ob der Einsatz hybrider Methoden in der Lehre an Hochschulen dazu führt, dass Studierende diese Fähigkeiten ausbauen, oder ob sich das Verhalten im Vergleich zu plangetriebenen Projekten nicht verändert.
Agile Softwareentwicklung gewinnt zunehmend an Bedeutung. Um eine gute Vorbereitung von Studierenden auf die Wirtschaft zu gewährleisten, ist es deshalb erforderlich, in der universitären Lehre agile Softwareprojekte zu integrieren. Der Einsatz verschiedener Arten von Arbeitsorganisation (dokumentenzentriert oder agil) ändert jedoch nicht nur die Organisation des Projekts, sondern auch den Ablauf und damit den Lernerfolg der Studierenden.
Die Auswahl der verwendeten Arbeitsorganisation hat einen Einfluss auf die Kommunikation [1]. Der Projekterfolg hängt wiederum zu 20 % von der Kommunikation des Teams ab [2].
Bei dokumentenzentrierten Vorgehensweisen ist der Softwarelebenszyklus [3] mit seinen Phasen maßgeblich. Diese unterteilen sich in Anforderungsanalyse, Entwurf, Implementierung, Überprüfung und Wartung. Der Ablauf hat sich seit 1956 zunehmend etabliert, führte jedoch nicht immer zu einem erfolgreichen Abschluss des Projekts. Aus diesem Grund rückte die agile Softwareentwicklung seit 1990 zunehmend in den Fokus und sollte deshalb auch in der universitären Lehre berücksichtigt werden.
In universitären Softwareprojekten sollen Studierende ihre sozialen Fähigkeiten ausbauen und zudem ihre Programmierfähigkeiten erweitern. Aus diesem Grund ist es wichtig, dass der Projekterfolg nicht unter einer Agilisierung der Lehrveranstaltung leidet.
Wir untersuchen traditionelle und hybride studentische Softwareprojekte hinsichtlich des Kommunikationsverhaltens und dem Auftreten von Konflikten. Die Projekte stimmen in wesentlichen Projektparametern wie Dauer, Aufwand und Komplexität überein, unterscheiden sich aber in der Art der Arbeitsorganisation.
Die Struktur des Papiers ist wie folgt: Im folgenden Abschnitt präsentieren wir verwandte Arbeiten. Danach werden die unterschiedlichen Arbeitsorganisationen vorgestellt. Im vierten Abschnitt wird das methodische Vorgehen mit der Stichprobe, dem Matching, der verwendeten Maße und dem Vorgehen bei der statistischen Analyse beschrieben. Die Ergebnisse werden im darauf folgenden Abschnitt festgehalten, bevor das Fazit gezogen wird. Die Zusammenfassung unserer Ergebnisse beendet das Papier.
Der Einfluss von der Arbeitsorganisation auf Kommunikationsverhalten und Konflikte ist nicht unbekannt und war bereits Gegenstand vorheriger Forschungen.
Bindrees et al. [1] untersuchten die Kommunikation in verschiedenen Projektphasen. Sie konnten nachweisen, dass in den Projektphasen unterschiedlich intensiv kommuniziert wird. Auf diesen Ergebnissen aufbauend, möchten wir die Aussage konkretisieren und auf unterschiedliche Arbeitsorganisationen beziehen.
In der agilen Entwicklung fordern Beck und Andres [4], dass die Kommunikation zwischen den Stakeholdern maximiert werden müsse. Wie die Kommunikation in agilen Teams tatsächlich abläuft, wurde bislang jedoch noch nicht näher untersucht und ist unter anderem Bestandteil unserer Arbeit.
Brügge et al. [5] analysierten studentische Softwareprojekte. Sie präsentierten eine Vorgehensweise, die die Fähigkeiten der Studierenden verbessern und zu in der Wirtschaft verwendbaren Ergebnissen führen soll. Um schnelles Feedback und kurzzeitige Releases zu ermöglichen sowie Kommunikation zu fördern, verwendeten sie die Tools Rugby und Tornado. In dem Papier beschreiben sie ihre Erfahrungen mit dem Einsatz der Tools in studentischen Lehrveranstaltungen. Die Tools unterstützten die Studenten hinsichtlich ihrer technischen und nicht-technischen Fähigkeiten wie bspw. Kommunikation und Teamwork.
Schneider et al. [6] analysierten studentische traditionell entwickelnde Teams hinsichtlich ihrer Stimmung, des Konfliktpotenzials und des Kommunikationsverhaltens. Sie fanden heraus, dass der Anteil der sozialen Konflikte über die Projektlaufzeit ansteigt, während aufgabenbezogene Konflikte zunächst zunahmen und schließlich wieder abfielen. Wir nutzen diese Ergebnisse für Vergleiche zwischen agiler und traditioneller Softwareentwicklung.
Dieses Kapitel dient als eine kurze Einführung in die hier betrachteten Arbeitsorganisationen: die traditionelle, die agile und die hybride Softwareentwicklung.
In der traditionellen Softwareentwicklung durchläuft das Projekt sequenziell die Phasen des Software-Development-Cycles [7]. Um mit der nächsten Phase beginnen zu können, muss die vorherige Phase vollständig abgeschlossen sein. Diese Vorgehensweise wurde als Nine-Phase-Stage-Wise-Modell bereits 1956 von Bennington [8] vorgestellt und 1970 von Royce [9] weiterentwickelt. Royce [9] ordnete die Phasen in seinen grafischen Darstellungen als Kaskade bzw. Wasserfall an, woraus sich die Bezeichnung Wasserfall-Modell ergibt. Dabei handelt es sich um das bekannteste traditionelle Entwicklungsmodell.
Der Ablauf im Wasserfall-Modell ist sequenziell. Das Projekt startet mit einer Anforderungsanalyse, während der die Anforderungen mit dem Kunden herausgearbeitet und schließlich in einer Anforderungsspezifikation mit einem Lasten- und Pflichtenheft festgehalten werden. Nach dieser Phase folgen der Entwurf, die Implementierung und schließlich die Überprüfung durch den Kunden.
Diese Arbeitsorganisation wird auch heute noch vielfach genutzt. Sofern es sich um Projekte mit stabilen Anforderungen handelt, bei denen Kosten und Umfang genau abgeschätzt werden können, stellt der sequenzielle Ablauf keine großen Schwierigkeiten dar. Da dies jedoch oftmals nicht möglich ist, gewinnt die agile Softwareentwicklung zunehmend an Bedeutung.
Basierend auf sich ständig ändernden
Kundenwünschen, dem Wunsch nach zuverlässigerer
Kundenzufriedenheit und Projekterfolg formulierten Beck
et al. [
Kundenzufriedenheit hat höchste Priorität und
wird durch die regelmäßige Präsentation von
funktionsfähigen und ausführbaren Inkrementen
sichergestellt [
Seit Beginn der 1990er Jahre etablierten sich
verschiedene Vorgehensweisen und Formate. Eine
der bekanntesten ist Scrum. Scrum wurde für die
Softwareentwicklung erstmals 2002 ausformuliert
[
Wesentlicher Bestandteil von Scrum sind die Daily Scrums, in denen jeder Entwickler innerhalb von zwei Minuten über den Fortschritt seit dem letzten Daily, über Pläne bis zum nächsten Daily und über eventuell auftretende Probleme berichtet. Neben dem Daily gibt es noch weitere Meetings, die zum Teil mit und teilweise ohne Kunden abgehalten werden. Der Scrum Master koordiniert die Meetings, sofern dies vonnöten ist, und sorgt für die Wahrung der agilen Werte und Prinzipien.
Die hybride Softwareentwicklung vereint Elemente
der traditionellen, dokumentenzentrierten
Vorgehensmodelle mit agilen Artefakten [
Die Projekte benötigen Organisation und
müssen zudem in die Unternehmensstruktur und die
Vorgehensweisen eingegliedert werden. Agile
Methoden geben für einige Unternehmen nur
unzureichende Hilfestellung bei der Eingliederung der
agilen Methoden in die Unternehmensstruktur. Da
viele Entwickler agil vorgehen, entsteht ein
Konflikt in Bezug auf die Organisation. Dieser soll
gelöst werden, indem hybride Ansätze verfolgt
werden. Das Ziel ist dabei die Nutzung der Vorteile
beider Entwicklungsmethoden: der Organisation
und der Vorgaben in der plangetriebenen
Softwareentwicklung und der Flexibilität der agilen
Entwicklung [
Um die studentischen Softwareprojekte miteinander vergleichen zu können, mussten zunächst geeignete Projekte ausgewählt und ein analoger Ablauf sichergestellt werden.
Gersick [15] fand heraus, dass ein Team in einem Projekt nach der Hälfte der Projektlaufzeit seine Strategie wechselt. Diesen Zeitpunkt nannte er Midpoint. In den hier betrachteten studentischen Softwareprojekten markiert der Midpoint den Beginn der Implementierung. Wir betrachten im Folgenden die beiden Bereiche des Projekts vor und nach dem Midpoint.
Nach Bindrees et al. [1] ist die Kommunikationsintensität in der Anforderungs- und Entwurfsphase am höchsten. Die Anforderungsphase legt den Grundbaustein für den weiteren Projektverlauf und ist demnach von besonderer Bedeutung [7]. Aus diesem Grund nehmen wir an:
In der agilen Entwicklung spielt die Kommunikation zu jeder Zeit eine wichtige Rolle. In den hier betrachteten hybriden Projekten gibt es einen OnSite-Customer, der wöchentlich vor Ort ist. Da die Kommunikation mit dem Kunden demnach über die gesamte Projektlaufzeit konstant bleiben sollte und wir annehmen, dass die team-interne Kommunikation während der Implementierungsphase aufgrund von Absprachen mit den Teammitgliedern zunimmt, können wir folgende Hypothese formulieren: Teams, die nach hybriden Methoden entwickeln, kommunizieren nach dem Midpoint intensiver als davor.
Als Aufgabenkonflikte werden Konflikte bezeichnet,
bei denen sich die Teammitglieder aufgrund
unterschiedlicher Ansichten, Meinungen und Ideen
nicht über die Inhalte einer Aufgabe einigen
können [
Da wir bei Teams, die nach dem Wasserfallmodell arbeiten, von einem Anstieg der Kommunikation von der ersten zur zweiten Projekthälfte ausgehen, nehmen wir dies dementsprechend ebenso für Aufgabenkonflikte an. Dies würde sich zudem mit den Ergebnissen von Schneider et al. [6] decken, die einen Anstieg aufgabenbezogener Konflikte zum Midpoint verzeichneten, bevor die Anzahl in der zweiten Projekthälfte abfiel:
Teams, die nach dem Wasserfall-Modell entwickeln, haben vor dem Midpoint mehr Aufgabenkonflikte als danach.
In den hybriden Softwareprojekten gehen wir aufgrund der ansteigenden Kommunikation nach Hypothese 2 von einem Anstieg der Aufgabenkonflikte von der ersten zur zweiten Projekthälfte aus. Dementsprechend formulieren wir die folgende Hypothese: Teams, die nach hybriden Methoden entwickeln, haben nach dem Midpoint mehr Aufgabenkonflikte als davor.
Diese Hypothesen wollen wir im Folgenden validieren.
Im Rahmen einer Lehrveranstaltung an der Leibniz Universität Hannover entwickeln Studierende im fünften Semester ihres Informatik-Bachelorstudiums in Teams über einen Zeitraum von 15 Wochen ein Softwareprodukt. Der Umfang und der Aufwand aller Projekte sind annähernd vergleichbar. Aus jedem Team übernehmen zwei Studierende die Rollen des Projektleiters und des Qualitätsbeauftragten. Der Kunde ist meistens ein Mitarbeiter des Fachgebiets Software Engineering und hat ein großes Interesse an einem erfolgreichen Projektabschluss. Er möchte die entwickelte Software langfristig nutzen. Unterstützt werden die Teams außerdem von einem erfahrenen Tutor, der bei zwischenmenschlichen und anderen nicht-technischen Fragen zur Verfügung steht. Technische Fragen sollen die Teams direkt mit dem Kunden oder team-intern klären.
Das Softwareprojekt folgte lange Zeit dem Wasserfallmodell. Seitdem wurde die Lehrveranstaltung durch Integration einiger agiler Artefakte zunehmend hybrider.
Traditionelle Softwareprojekte. Bis einschließlich dem Wintersemester 2013/2014 folgten die Softwareprojekte dem traditionellen dokumentenzentrierten Ansatz. Entwickelt wurde nach dem Wasserfall-Modell in Teams von drei bis fünf Studierenden in mehreren Phasen [7].
Das Projekt startete mit einer dreiwöchigen Anforderungsanalyse. Währenddessen fand das erste Kundengespräch zur Klärung der Anforderungen statt. Die Studierenden mussten eigenständig den Kontakt zum Kunden herstellen und einen Termin vereinbaren. Das Treffen musste vorbereitet, abgehalten und nachbereitet werden, da die Zeit, in der der Kunde zur Verfügung stand, auf 90 Minuten während der gesamten Projektlaufzeit begrenzt war. Die Phase endete mit dem Verfassen einer Anforderungsspezifikation, die mit dem Kunden abgestimmt und schließlich auch von ihm unterzeichnet werden musste. Danach passierte das Team das erste Quality-Gate.
Es folgte eine Phase über zwei Wochen, in denen der Entwurf verfasst oder ein Prototyp entwickelt wurde. Um den Erfahrungsschatz der Studierenden zu erweitern, musste zudem der Entwurf oder der Prototyp eines anderen Teams gereviewt werden. Dazu gab es ein reguläres Review-Meeting mit Moderator, in dem sämtliche Befunde zusammengetragen wurden. Ebenso wie die Anforderungsanalyse endete auch die Entwurfsphase mit einem Quality-Gate.
Die restliche Projektlaufzeit stand im Wesentlichen für die Implementierung zur Verfügung. Hier mussten nachweislich alle Teammitglieder eingebunden werden. Diese Phase dauerte je nach Leistung des Teams und Fortschritt ungefähr fünf bis sechs Wochen.
Danach hatte das Team in der Polish-Phase die Möglichkeit, letzte Änderungswünsche des Kunden einzupflegen und die Qualität der Software zu steigern.
Nach dieser Phase gab es ein letztes QualityGate, in dem im Wesentlichen das Erfüllen der Anforderungsspezifikation und das Einhalten von vorgegebenen Code-Konventionen überprüft wurden.
Das Projekt endete mit der Kundenabnahme, die über den erfolgreichen Abschluss entschied. Hybride Softwareprojekte. Seit dem Wintersemester 2014/2015 werden einige agile Artefakte in die Lehrveranstaltung integriert. Zudem bestehen die Teams nun aus acht oder neun Studierenden.
In Anlehnung an das Konzept des On-SiteCustomers steht der Kunde wöchentlich zu einem fest vorgegebenen Termin zur Verfügung, um über den Projektverlauf und den aktuellen Stand informiert zu werden. Dieses Meeting ist vergleichbar mit einem Review-Meeting in der agilen Softwareentwicklung, wenngleich die wöchentlichen Iterationen nicht als Sprints angesehen werden können.
Das gesamte Team-Meeting umfasst ungefähr eine Stunde und beginnt mit einem Weekly Scrum, in dem jedes Team-Mitglied über seinen Fortschritt seit dem letzten Scrum-Meeting, über die Pläne bis zum nächsten Scrum-Meeting und über Probleme spricht. Nach dem Weekly Scrum kommt der Kunde hinzu und wird über die wesentlichen Punkte informiert, äußert Änderungswünsche oder geänderte Anforderungen und steht für offene Fragen zur Verfügung.
Wie auch in der plangetriebenen Entwicklung
gibt es angelehnt an den Ablauf nach Kent et al.
[
Für die Validierung der Hypothesen verwenden wir Daten aus dem TeamFLOW-Forschungsprojekt [19], die in den zuvor beschriebenen studentischen Softwareprojekten erhoben wurden.
Wir betrachten Daten aus zwei Kohorten: 2013/14 und 2015/2016. Die erste Kohorte folgte dem traditionellen Ansatz nach dem WasserfallModell und die zweite Kohorte dem hybriden Ansatz.
In der ersten Kohorte haben 20 Teams an der Datenerhebung teilgenommen. Da die Teams in den hybriden Projekten größer waren, liegen hier nur Daten von acht Teams vor. Aus diesem Grund musste zunächst ein Matching der vorhandenen Daten durchgeführt werden, um acht geeignete Projekte aus der ersten Kohorte auszuwählen. Dieses Matching erfolgte auf Basis von Alter und Geschlecht, da sich die beiden Kohorten nicht signifikant in den Mittelwerten des Alters unterscheiden (hybrid: M = 21.9, SD = 1.05; Wasserfall: M = 21.9, SD = 1.01; t(7) = -.413, p = .692). Ferner wurden Teams mit unvollständigen Datensätzen nicht berücksichtigt.
Auf Basis dieses Matchings erhielten wir insgesamt acht Teams aus der Wasserfall-Kohorte, die wir mit den acht Teams aus der Hybrid-Kohorte vergleichen konnten.
Kommunikationsintensität. Die Kommunikationsintensität wurde durch Abfragen nach der wahrgenommenen 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 Verfügung. Auf diese Art entstand eine Matrix mit Einträgen aij, die angeben, wie intensiv TeamMitglied i die Kommunikation mit Team-Mitglied j in der vergangenen Woche wahrgenommen hat. Die ungerichtete Kommunikationsintensität cij zwischen den beiden Team-Mitgliedern i und j ergibt sich dann durch den Durchschnitt der beiden Werte:
cij = avg(aij, aji).
Um den Teamwert zu erhalten, wird der Durchschnitt aller ungerichteten Kommunikationswerte im Team berechnet.
Konflikte. Aufgabenkonflikte wurden mit der
deutschen Version der Intragroup Conflict Scale
von Jehn [
Messzeitpunkte. In Abb. 1 ist die Datenerhebung nach Kohorten dargestellt. Es wird ersichtlich, dass die Daten zum Kommunikationsverhalten in der Kohorte, die nach dem Wasserfallmodell arbeitete, wöchentlich erhoben wurden, während sie in der Kohorte, die hybrid arbeitete, nur an drei ausgewählten Messpunkten abgefragt wurden. Die Erhebung von Konflikten erfolgte jeweils zu drei Messpunkten: in der ersten Woche, in der Mitte des Projektes und nach Projektabschluss. Die grau hinterlegten Wochen kurz vor Projektende spiegeln die Weihnachtsferien wieder, in denen die Studierenden zwar an der Software weiterarbeiten durften, aber nicht dazu verpflichtet waren.
Basierend auf den Messzeitpunkten betrachten wir in diesem Papier drei Zeitpunkte: unmittelbar nach Projektstart, in der sechsten Woche mit den Erhebungen in den beiden Kohorten und in der letzten Woche.
Abbildung 1: Datenerhebung nach Kohorten
Die Datenerhebung wurde vom Ethik-Komitee der Leibniz Universität Hannover genehmigt. Die Studierenden wurden vorab über die Datenerhebung und die weitere Verwendung der gesammelten Daten informiert und stimmten dieser zu. Darüber hinaus wurden die gesammelten Daten vor der weiteren Verwendung vollständig anonymisiert. Eine Teilnahme an der Befragung hatte keinen Einfluss auf das Bestehen der Lehrveranstaltung.
Alle Hypothesentests wurden jeweils aufgrund der geringen Stichprobengrößen von acht Teams zunächst einem Test auf Normalverteilung unterzogen. Dafür wurde der Shapiro-Wilk-Test verwendet, da dieser Test bei kleinen Stichproben unter 30 1 Cronbachs Alpha spiegelt die interne Konsistenz einer verwendeten Skala wieder. Es gibt an, inwiefern alle Items das gleiche Konstrukt messen. eine größere Teststärke aufweist als andere Normalverteilungstests [21]. Die erste Hypothese wird mittels t-Test für abhängige Stichproben überprüft.
Für die erste Hypothese werden die Kommunikationsintensitäten der Wasserfall-Kohorte dahingehend überprüft, ob die Intensität in der zweiten Projekthälfte niedriger ist als in der ersten Projekthälfte: μ1 > μ2.
Für die zweite Hypothese werden die Kommunikationsintensitäten der Hybrid-Kohorte dahingehend überprüft, ob die Intensität in der zweiten Projekthälfte höher ist als in der ersten Projekthälfte: μ1 < μ2.
Für die dritte Hypothese werden die Aufgabenkonflikte der Wasserfall-Kohorte dahingehend überprüft, ob ihre Ausprägung in der zweiten Projekthälfte niedriger ist als in der ersten Projekthälfte: μ1 > μ2.
Für die vierte Hypothese werden Aufgabenkonflikte der Hybrid-Kohorte dahingehend überprüft, ob ihre Ausprägung in der zweiten Projekthälfte höher ist als in der ersten Projekthälfte: μ1 < μ2.
Da ausschließlich gerichtete Hypothesen aufgestellt wurden, wurde bei der Hypothesenprüfung einseitig getestet. Wir legten das Signifikanzniveau auf 5% fest. Um eine bessere Interpretierbarkeit der Ergebnisse zu erzielen, werden in dieser Arbeit neben der Betrachtung signifikanter Befunde zusätzlich die Effektgrößen dargestellt. Cohens d [22], das zur Einschätzung der Größe eines Effekts verwendet wird2, ist für die verwendeten t-Tests relevant.
Wie aus Abb. 1 ersichtlich wird, liegen für die beiden Stichproben unterschiedlich viele Daten vor. Die Probanden aus der ersten Kohorte gaben 14 Wochen lang wöchentlich Auskunft. Die Studierenden aus der zweiten Kohorte gaben nur in den Wochen eins bis zwei (Projektbeginn), sechs (Midpoint) und vierzehn (Projektabschluss) Auskunft über Konflikte und Kommunikation. Dementsprechend wurden zum Vergleich die Werte aus genau diesen Wochen von der Wasserfall-Kohorte gewählt. Der Midpoint in der Mitte der Projektlaufzeit liegt demnach in Woche sechs.
Kommunikationsintensität. Bei den hybrid arbeitenden Teams wurden lediglich in den Wochen zwei, sechs und vierzehn Daten erhoben. Deshalb gingen auch nur diese drei Wochen der traditionell organisierten Teams als zeitliches Äquivalent in die 2 Bei einem Wert von d ≥ 0.20 spricht man von einem kleinen Effekt, bei d ≥ 0.50 von einem mittleren Effekt und ab d ≥ 0.80 von einem großen Effekt. Berechnungen der Ergebnisse ein. Den Wert für die erste Projekthälfte stellt die Differenz zwischen dem Wert für den Midpoint und der Baseline (Projektbeginn) dar. Da in einem der hybridorganisierten Teams zu wenige Teammitglieder die Fragen zur Kommunikation beantworteten, wurde dieses Team für diesen Zeitpunkt aus der Analyse ausgeschlossen. Demnach liegt die Stichprobengröße für Kommunikationswerte zur ersten Projekthälfte bei N=7.
Konflikte. Fragebögen zur Erhebung von Konflikten wurden auch bei traditionell organisierten Teams zu lediglich drei Messzeitpunkten erhoben. Die erste Erhebung fand in beiden Kohorten in der ersten Woche statt. Die zweite Erhebung stellt den Midpoint dar. Die letzte Erhebung fand in beiden Kohorten nach dem Projektabschluss in Woche 14 statt. Den Wert für die erste Projekthälfte stellt die Differenz zwischen dem Wert für den Midpoint und der Baseline (Projektbeginn) dar.
Zunächst wurde der Datensatz aller Teams aus der Wasserfall-Kohorte aufgrund der geringen Stichprobengröße (N = 7 bzw. N = 8) mit dem ShapiroWilk-Test auf Normalverteilung geprüft. Dies traf bei den Daten zu Überprüfung aller vier Hypothesen zu.
Die Hypothesen 1, 2 und 3 konnten bestätigt werden; die Hypothese 4 konnte nicht bestätigt werden.
Hypothese 1. Ein t-Test für verbundene Stichproben ergab einen signifikanten Unterschied zwischen der Kommunikationsintensität vor dem Midpoint (M = .45, SD = .68) und den Mittelwerten der Kommunikationsintensität nach dem Midpoint (M = -.53, SD = .68), t(7) = 4.46, p = .003, d = 1.57. Hypothese 1 kann somit bestätigt werden. Es handelt sich um einen großen Effekt.
Hypothese 2. Ein t-Test für verbundene Stichproben ergab einen signifikanten Unterschied zwischen der Kommunikationsintensität vor dem Midpoint (M = .15, SD = .43) und den Mittelwerten der Kommunikationsintensität nach dem Midpoint (M = .38, SD = .37), t(6) = -2.13, p = .039, d = 0.83. Hypothese 2 kann somit bestätigt werden. Es handelt sich um einen großen Effekt.
Hypothese 3. Ein t-Test für verbundene Stichproben ergab einen signifikanten Unterschied zwischen Aufgabenkonflikten vor dem Midpoint (M = .57, SD = .52) und den Mittelwerten der Aufgabenkonflikte nach dem Midpoint (M = .38, SD = .57), t(7) = 2.03, p = .041, d = 0.74. Hypothese 3 kann somit bestätigt werden. Es handelt sich um einen mittleren Effekt.
Hypothese 4. Ein t-Test für verbundene Stichproben ergab keinen signifikanten Unterschied zwischen Aufgabenkonflikten vor dem Midpoint (M = .25, SD = .51) und den Mittelwerten der Kommunikationsintensität nach dem Midpoint (M = .06, SD = .50), t(6) = 1.00, p = .353. Hypothese 4 musste demnach abgelehnt werden.
In dieser Studie untersuchten wir die Einflüsse der Arbeitsorganisation auf die Intensität der Kommunikation und die Konflikte in Teams. Grundlage der Untersuchungen waren drei Messzeitpunkte über den Projektverlauf.
Zunächst wurde der Verlauf der Kommunikationsintensität nur für Teams, die nach dem Wasserfall-Modell oder hybrid arbeiten, untersucht. Dabei sollte herausgefunden werden, ob die Intensitäten gemäß der arbeitsorganisatorischen Modelle und der Theorie verlaufen. Anschließend wurden die Kommunikationsintensitäten beider Arbeitsorganisationen gegenüber gestellt und zusammen untersucht. Die Ergebnisse unterstützen drei der vier formulierten Hypothesen: Teams, die nach dem Wasserfall-Modell entwickeln, kommunizieren vor dem Midpoint intensiver als danach. Teams, die nach hybriden Methoden entwickeln, kommunizieren nach dem Midpoint intensiver als davor.
Teams, die nach dem Wasserfall-Modell entwickeln, haben vor dem Midpoint mehr Aufgabenkonflikte als danach.
Teams, die nach hybriden Methoden entwickeln, haben nach dem Midpoint mehr Aufgabenkonflikte als davor.
Dennoch unterliegen diese Ergebnisse einigen Einschränkungen in Bezug auf Validität und Verallgemeinerbarkeit.
Unsere Untersuchung basiert auf einer Erhebung in studentischen Softwareprojekten. Daraus ergeben sich einige Einschränkungen in Bezug auf die Verallgemeinerbarkeit der Ergebnisse für die Industrie. Rückschlüsse für studentische Lehrveranstaltungen sind jedoch möglich. Trotzdem soll im Folgenden auf Bedrohungen der Validität eingegangen werden. Dabei beziehen wir uns auf die Klassifizierung der Threats to Validity nach Wohlin et al. [23]. Wir differenzieren zwischen interner, externer und Konstruktvalidität und Verlässlichkeit der Ergebnisse. Interne Validität: Einen team-internen Austausch über die Fragebögen und Absprachen hinsichtlich der Beantwortung der Fragen konnten wir nicht verhindern. Dies kann die Ergebnisse unserer Berechnungen beeinflusst haben. Da die Beantwortung der Fragebögen und die Teilnahme an der Datenerhebung keinen Einfluss auf das Bestehen der Lehrveranstaltung hatte, schätzen wir den Anteil an falschen Antworten als ziemlich gering ein, da die Studierenden dadurch keinen Vorteil hätten. Externe Validität: Durch das akademische Umfeld lassen sich unsere Ergebnisse nur bedingt auf die Industrie anwenden. Das liegt an der geringen Stichprobe, die die Gültigkeit der Ergebnisse auch für andere studentische Projekte einschränkt. Zudem lagen uns nur Daten zu drei Messzeitpunkten vor. Ein detaillierterer Vergleich würde in Bezug auf den Verlauf der Kommunikationsintensität vermutlich zu ähnlichen Ergebnissen führen. Möglicherweise könnten mit einer größeren Stichprobe auch projektphasenabhängige Muster aufgedeckt werden, die bislang nicht erkannt wurden.
Darüber hinaus hatten die Studierenden nur zum Teil Erfahrungen in Softwareprojekten oder gar in der Industrie. Ferner betrachteten wir nur sehr vergleichbare Projekte mit einem ähnlichen Umfang und Übereinstimmungen in verschiedenen Projektparametern wie Dauer oder dem Erfahrungsschatz der Teammitglieder.
Konstruktvalidität: Die Fragebögen waren sehr allgemeinverständlich formuliert, sodass wir keine Einschränkungen der Validität aufgrund von falsch verstandenen Fragen erwarten.
Dennoch könnte die Erhebung der Intensität könnte als problematisch aufgefasst werden, da es sich hierbei um eine sehr subjektive Einschätzung handelt. Von Klünder et al. [24] konnte nachgewiesen werden, dass die Inkonsistenzen zwischen den wahrgenommenen Intensitäten hinreichend gering sind, sodass die Erhebung der Intensität auf diese Weise möglich ist.
Darüber hinaus können wir Auswirkungen der Teamgrößen auf Kommunikation und Konflikte nicht ausschließen. Steigende Teamgröße führt nachweislich zu Motivations- und Koordinationsverlusten in Gruppen [25]. Zudem konnten Amason und Sapienza [26] zeigen, dass Teamgröße positiv mit kognitiven Konflikten (welche Aufgabenkonflikten stark ähneln) korreliert. Da in unserer Studie die hybriden Teams auch gleichzeitig deutlich größer als die Teams der WasserfallKohorte waren, können wir eine Konfundierung mit dem Faktor Teamgröße demnach nicht ausschließen.
Verlässlichkeit: Eine erneute Durchführung dieser Untersuchung auf Basis einer anderen Datenerhebung könnte zu anderen Ergebnissen führen, sofern unterschiedliche Aufgabenstellungen, Teilnehmende mit einer anderen Wissensbasis, Projektabläufe und Teamstrukturen betrachtet werden. Darüber hinaus hängt das Kommunikationsverhalten stark vom Charakter der Teammitglieder ab. Demnach beeinflusst die Teamkonstellation die Ergebnisse zusätzlich. Die Betrachtung einer Datenerhebung mit vergleichbaren Projektparametern sollte aber zu ähnlichen Ergebnissen führen.
Unsere Ergebnisse zeigen, dass traditionell organisierte Teams in der ersten Hälfte des Projekts deutlich intensiver kommunizieren als in der zweiten Projekthälfte. Hybrid arbeitende Teams kommunizieren hingegen vermehrt in der zweiten Projekthälfte.
Neben der Kommunikationsintensität wurden noch aufgabenbezogene Konflikte untersucht. Dieses Konstrukt wurde ebenfalls zu drei Messzeitpunkten erhoben, jedoch lediglich als aggregierte Werte pro Arbeitsorganisation gegenübergestellt. Hier konnte festgestellt werden, dass – analog zur Kommunikationsintensität – traditionell organisierte Teams in der ersten Projekthälfte mehr aufgabenbezogene Konflikte erleben. Für hybrid organisierte Teams konnten keine Unterschiede hinsichtlich aufgabenbezogener Konflikte zwischen den beiden Projekthälften festgestellt werden.
Kommunikationsintensität. Traditionell organisierte Teams kommunizieren in der ersten Projekthälfte deutlich mehr als in der zweiten Projekthälfte. Dies geht mit den Erkenntnissen von Bindrees et al. [1] einher. Sie fanden heraus, dass traditionell organisierte Teams in den ersten Projektphasen am intensivsten kommunizieren. Dieser Verlauf der Kommunikationsintensität lässt sich mit dem Wasserfall-Modell begründen, da die Anforderungsund Entwurfsphase ohne Kommunikation nicht erfolgen können, während Kommunikation für die Implementierung nicht mehr in großem Ausmaß vonnöten ist, nachdem die Anforderungen klar herausgearbeitet und ausreichend dokumentiert wurden.
Neu hingegen ist die Erkenntnis, dass hybrid entwickelnde Teams in der zweiten Projekthälfte mehr kommunizieren. Dies lässt sich damit erklären, dass die Kommunikation mit dem Kunden über den gesamten Projektverlauf nahezu konstant bleibt, während in der Implementierungsphase mehr team-interne Absprachen notwendig sind, da zwar – im Falle der hier betrachteten Softwareprojekte – eine Spezifikation existiert, diese aber nicht bindend ist, da auf Änderungswünsche des Kunden eingegangen werden soll. Aus diesem Grund sind möglicherweise klärende Absprachen vonnöten, wodurch die Intensität der Kommunikation zunimmt.
Konflikte. Unsere Untersuchung zeigt, dass bei Teams mit traditioneller Softwareentwicklung aufgabenbezogene Konflikte über die Zeit bzw. nach dem Midpoint abnehmen. Dies lässt sich u.a. über die erhöhte Kommunikationsintensität zu Projektbeginn erklären.
Die Ergebnisse erlauben auch einige für die universitäre Lehre interessante Rückschlüsse. So wird beispielsweise deutlich, dass die Wahl der Arbeitsorganisation einen Einfluss auf das Kommunikationsverhalten hat. Damit beeinflusst sie zudem den Lernerfolg der Studierenden, die während der Arbeit im Team vor allem soziale Fähigkeiten wie beispielsweise die Kommunikationsfähigkeiten erlernen oder ausbauen sollen. Vor allem die Kommunikationsfähigkeit ist in industriellen Projekten von äußerster Bedeutung. Daher empfiehlt es sich, Elemente wie beispielsweise den On-SiteCustomer in studentischen Arbeitsprojekten zu integrieren, um den Studierenden einen intensiven Kundenkontakt zu ermöglichen, für den eine adäquate Kommunikation unabdingbar ist. Darüber hinaus stellt ein Weekly Scrum ein Minimum an Informationsweitergabe sicher. Zudem lernen die Studierenden, sich adäquat untereinander auszutauschen und im anschließenden Kundengespräch die Informationen an den Kunden weiterzugeben. Durch den wöchentlichen persönlichen Kontakt mit dem Kunden wird der Umgang routinierter. Außerdem wirkt der hybride Ansatz einer Verringerung der Kommunikationsintensität in der zweiten Projekthälfte entgegen. In der zweiten Projekthälfte liegt der Schwerpunkt auf der Implementierung der Software. Eine Verringerung der Kommunikationsintensität in der zweiten Projekthälfte, wie sie bei den traditionell organisierten Projekten auftritt, deutet auf weniger Teamarbeit und Austausch während der Implementierung hin. Dies reduziert unter Umständen den team-internen Wissensaustausch und die Kompetenzen der Teammitglieder können möglicherweise nicht optimal genutzt werden.
In dieser Studie untersuchten wir den Einfluss der Arbeitsorganisation auf die Intensität der Kommunikation eines Teams und ihre Konflikte. Die Intensität der Kommunikation ist in den untersuchten traditionell entwickelnden Teams in der ersten Projekthälfte deutlich höher als in der zweiten Projekthälfte. Bei den hybrid organisierten Teams gilt das Gegenteil. Entgegen unserer Annahmen unterschieden sich aufgabenbezogene Konflikte bei hybrid organisierten Teams zwischen der ersten und zweiten Projekthälfte nicht.
Die Verwendung von agilen Artefakten wie beispielsweise dem On-Site-Customer oder dem Weekly Scrum in der studentischen Lehre fördert die Kommunikationsfähigkeiten der Studierenden, ohne die Arbeit im Team zu erschweren. Deshalb kann das Arbeiten in hybriden Projekten die Studierenden ohne zusätzliche Schwierigkeiten auf das spätere Arbeitsumfeld vorbereiten.
Diese Arbeit wurde von der Deutschen Forschungsgesellschaft (DFG) unter der Projektnummer 263807701 (Projekt: TeamFLOW) gefördert. Literatur
Bindrees, M. A.; Pooley, R. J.; Ibrahim, I. S.; Taylor, N. K.: Re-Evaluating Media Richness Theory in Software Development Settings. In: Journal of Computer and Communications 02 (2014) 14, S. 37–51.
Mohamed, J. M.; Qubaisi, L. F. A.; Elanain, H. M. A.; Badri, M. A.; Ajmal, M. M.: Leadership, Culture and Team Communication. Analysis of project success causality - A UAE case. In: International Journal of Applied Management Science 7 (2015) 3.
ISO/IEC 12207:2008: Systems and software engineering - Software life cycle processes. Beck, K.; Andres, C.: Extreme Programming Explained. Embrace Change, 2nd ed. Boston, MA 2005.
Brügge, B.; Krusche, S.; Alperowitz, L.: Software Engineering Project Courses with Industrial Clients. In: ACM Transactions on Computing Education 15 (2015) 4.
Schneider, K.; Liskin, O.; Paulsen, H.; Kauffeld, S.: Media, Mood, and Meetings. Related to Project Success. In: ACM Transactions on Computing Education 15 (2015) 4.
Stoica, M.; Mircea, M.; Ghilic-Micu, B.: Software Development. Agile vs. Traditional. In: Informatica Economica 17 (2013) 4/2013.
Benington, H. D.: Production of Large Computer Programs. In: Proceedings, ONR Symposium (1956). [9]
Royce, W. W.: Managing the Development of Large Software Systems: Concepts and Techniques. In: Proceedings of the 9th International Conference on Software Engineering,
Monterey, California, USA (1987).
Latané, B.; Williams, K.; Harkins, S.: Many hands make light the work. The causes and consequences of social loafing. In: Journal of Personality and Social Psychology 37 (1979) 6.