Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
1
Agile Methoden bei Hochschulprojekten in
Kooperation mit Vodafone
Einige werden den Begriff noch nie gehört haben:
„Scrum“. Er geistert seit gut fünf Jahren weltweit
durch die Flure der Softwareentwicklungsabteilungen
und IT-Konzerne. Riesen wie Amazon, Facebook,
Microsoft oder BMW wenden diese Methode an,
ebenso wie kleinere und mittlere Unternehmen, vor-
nehmlich in der Tech-Branche. Es hat aber auch die
vertriebsorientierten Unternehmen erwischt, weil sie
von jeher am Markt schnell agieren müssen. Wo star-
re Planungen und Roadmaps in einem Marktumfeld
keinen Sinn mehr machen, stellen Unternehmen mit
großem Aufwand ihre bisherige Arbeitsweise grund-
sätzlich um.
Die steigende Schlagzahl an Produktanpassungen, verur-
sacht durch ein sich kontinuierlich änderndes Kunden-
verhalten, ist für einen Anbieter überlebenswichtiger
denn je geworden. Die Anwendung „agiler“ Methoden,
zu denen Scrum zählt, verspricht eine effiziente und fle-
xible Umsetzung von Projekten, wie man sie im klassi-
schen Projektmanagement so nicht finden kann. Die Zahl
der gescheiterten Softwareprojekte wird jährlich mit rund
siebzig Prozent angegeben1. Mit Scrum sinkt diese Rate
erheblich. Angesichts der immensen Investitionssummen,
die weltweit in Softwareprojekte einfließen, ist dies eine
1 https://www.pressebox.de/pressemitteilung/alfabet-ag/Studie-belegt-In-70-
der-Unternehmen-scheitern-IT-Projekte-wegen-unterschiedlicher-
Planungssichten/boxid/596894
reizvolle Perspektive für jedes, auf diesem Gebiet tätigen
Unternehmen. Wie sieht das Wunder Scrum in der Um-
setzung genau aus? Dies zu vermitteln hat sich der Lehr-
stuhl für Wirtschaftsinformatik an der Hochschule
Coburg, zusammen mit der Universität Novosibirsk und
dem Software Entwicklungsbereich der Vodafone
Deutschland in zwei, von Vodafone finanzierten Projek-
ten, zur Aufgabe gemacht. Eine Zusammenarbeit zwi-
schen Hochschulen und Unternehmen ist bei dem Thema
Scrum sinnvoll, da hier der seltene Fall vorliegt, dass ein
Trend nicht aus der Wissenschaft heraus in die Unter-
nehmen getragen wird, sondern das Konzept der Wirt-
schaft entspringt. Des Weiteren ist die Einrichtung, Um-
setzung und Vermittlung von Scrum eine didaktische
Herausforderung, welcher man mit Seminaren und Pro-
jekten gut begegnen kann. Zahlreiche kommerzielle
Schulungs- und Consultingfirmen begleiten Unterneh-
men bei ihrer Umstellung auf agile Arbeitsweisen. Diese
Beratungsunternehmen haben somit einen starken Ein-
fluss auf die Umsetzung und Weiterentwicklung der agi-
len Konzepte. Hierfür einen wissenschaftlichen Unterbau
zu entwickeln, insbesondere, wenn die Möglichkeit einer
Zusammenarbeit mit Consultingfirmen besteht, kann für
die Lehre sowie Studierenden eine spannende Aufgabe
sein. Dies bezieht nicht nur die Fakultät Wirtschaft mit
ein. Da Scrum ein „Framework“ mit umfangreichen so-
ziologischen Einflüssen beschreibt, in dem das Verhal-
ten, die Rollen und die Pflichten von einzelnen Mitglie-
dern eines Teams festgelegt werden, sind auch die sozia-
len und psychologischen Akademien eingeladen, die
wissenschaftliche Basis dieser Methoden zu bestimmen.
Im Rahmen des „Coburger Wegs“, der interdisziplinäres
Lehren fördert, wurde eine Zusammenarbeit bereits vor-
geschlagen.
Die agile Methode Scrum
Zunächst für die, die noch keine Erfahrung mit Scrum
haben, eine kurze Einführung. Ein Hinweis sei vorausge-
schickt: Über Scrum zu lesen oder Schulungen hierfür zu
besuchen ist nur ein kleiner Teil des Weges. Scrum lernt
Stellenanzeigen für agile Funktionen
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
2
Abbildung 1: Bild einer wohlformulierten Story in Jira
man nur bei der Anwendung, ähnlich wie man das Fahr-
radfahren nur durch praktische Erfahrung lernen kann.
Bei Scrum vereinbart ein interdisziplinäres Team in so-
genannten „Sprints“ zu arbeiten. Ein Sprint hat eine ver-
einbarte Dauer. Es sind ein, zwei, drei, vier oder acht
Wochen üblich. In dieser Zeit wird eine Anzahl Aufga-
ben von diesem Team eigenverantwortlich fertiggestellt.
Zu Anfang festgelegt, wird die Sprintlänge nicht geän-
dert.
Die Fertigstellung dieser Aufgaben, deren Bewertung
und Auswahl, folgen in einem vorgeschriebenen Muster.
In diesem Muster, welches Scrum vorgibt, sind die Be-
grifflichkeiten und Rollen klar vorgegeben. Gestartet
wird mit dem sogenannten „Sprint Planning“. An diesem
Meeting nehmen das gesamte Team, der „Product Ow-
ner“ und der „Scrum Master“ teil. Product Owner und
Scrum Master sind jeweils eine Person, die diese Rolle
dauerhaft wahrnimmt.
Der Product Owner stellt dem Team die einzelnen Auf-
gaben gemäß ihrer Priorität vor. Jede Aufgabe wird in
einer sogenannten „Story“ formuliert. Damit wird zum
Ausdruck gebracht, dass die Aufgabe in nutzenstiftender
Form aus Sicht des späteren Verwenders anzugeben ist.
Dies hat den Vorteil, dass sich eine Aufgabe schon bei
der Formu-
lierung auf
den Kun-
den fokus-
sieren
muss. Ist
eine solche
Darstel-
lung nicht
möglich,
ist meis-
tens auch
die Auf-
gabe obso-
let. Wie
der Begriff
„Story“
schon
impliziert, wird die Aufgabe und ihr Zweck ausführlich
erläutert. Es ist in einer Story sicherzustellen, dass alle
relevanten Informationen und Hintergründe zur Aufgabe
angegeben sind.
Die Rolle des Product Owners ist in Scrum von zentraler
Bedeutung. Er ist der Einzige, der Aufgaben priorisieren
darf. Er alleine bestimmt, was das Team im Sprint um-
setzt, und damit, welche Aufgaben momentan am drin-
gendsten von einem Scrum Team bearbeitet werden müs-
sen. Das Team wiederum bestimmt, wie viel es in einem
Sprint umsetzen kann. Nur das Team hat die Kompetenz
festzulegen, wie aufwendig die Umsetzung einer Story
sein wird. In klassischen Ansätzen ist üblich, dass der
Aufwand durch einen Projektleiter oder Programmmana-
ger beschlossen wird. Vorteil bei der Anwendung von
Scrum ist folglich, dass unrealistische Zeitpläne oder
Zielsetzungen von fachfremden Entscheidern vermieden
werden. In Scrum gilt das Team als Ressource, welches
sich selbst am besten einschätzen kann. Hat der Product
Owner eine Story vorgestellt, spricht das Team über die
Aufgabe, fragt bei Unklarheiten beim Product Owner
nach und kommt so zu einer Entscheidung, welchen
Aufwand es für die Erledigung der vorgestellten Aufgabe
erwartet. Es empfiehlt sich für den Product Owner, die
Aufgabe sehr genau in der Story zu beschreiben. Unge-
nauigkeiten führen dazu, dass das Team kein Verständnis
bzw. kein einheitliches Verständnis für die Story ge-
winnt. In diesem Fall dauert die Abstimmung länger oder
das Team lehnt die Bearbeitung der Aufgabe in der vor-
liegenden Beschreibung gänzlich ab, wozu es im Scrum
Prozess berechtigt ist. Dies hat sich in der Praxis als sehr
sinnvoll herausgestellt, denn ein Team kann nur Aufga-
ben erledi-
gen, die aus-
reichend
definiert
sind. Der
Product Ow-
ner hat sei-
nerseits
größtes Inte-
resse, dass er
die von ihm
priorisierten
Ergebnisse
möglichst
rasch gelie-
fert be-
kommt. In
der beruf-
lichen Praxis bedeutet dies, dass präzises Delegieren von
Aufgaben immer wieder geübt und sichergestellt werden
muss. Die Erfahrungen zu Beginn der Hochschulprojekte
waren dementsprechend. Die Auftraggeber mussten es
lernen, die geforderten Arbeitspakete in Stories präzise
zu formulieren. Die Auftragnehmer ihrerseits mussten
das Selbstbewusstsein entwickeln, schlecht formulierte
Arbeitspakete abzulehnen. Da die Stories genau und in
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
3
Vorstellung einer komplexeren Figur, die zu schätzen ist
einer nutzenstiftenden Art zu formulieren sind, ist ein
Arbeiten mit stichpunktartiger Aufzählung der Anforde-
rungen häufig nicht ausreichend. Es besteht die Notwen-
digkeit, dem Team komplexe Sachverhalte zu vermitteln.
Daher sind alle Mittel der sprachlichen und visuellen
Ausgestaltung zu bemühen, um dies zu erreichen. Eine
Fertigkeit, die sich ohnehin die akademische Ausbildung
durch Anfertigung von Seminar- und Abschlussarbeiten
stellt.
Das Projektverwaltungstool, welches für Scrum weltweit
am häufigsten verwendet wird, heißt „Jira“. Der Begriff,
in Anlehnung an den Gegenspieler von Godzilla der ja-
panischen Filmreihe, wird mit „i“ ausgesprochen, nicht
mit einem angelsächsischen „ei“.
Für jede Story wird in Jira ein sogenannter „Issue“ er-
stellt. In diesem Issue werden die Informationen der zu
erledigenden Aufgabe, also Story, abgelegt. Über einen
Browser kann man die Informationen zu einer Story je-
derzeit nachlesen bzw. bearbeiten. Das Ziel einer Story
kann technischer, organisatorischer, akademischer oder
sonstiger Natur sein. Von Bedeutung ist, dass die Aufga-
be von einem Team kooperativ durchgeführt werden
kann. Zu diesem Zweck wird der Aufwand zur Lösung
einer Story vom gesamten Team geschätzt. Eine zutref-
fende Schätzung ist, wie bei jeder anderen Projektma-
nagementmethode auch, der Schlüssel für eine erfolgrei-
che Planung. Abläufe und Abhängigkeiten zwischen
Aufgaben, sowie deren Kosten, alles wird davon be-
stimmt, dass der Aufwand für einzelne Aufgaben richtig
geschätzt wird. Treffen Schätzungen nicht zu, wird es
kompliziert, die Folgen der Abweichungen zu steuern.
Bestes Beispiel hierfür sind die Schwierigkeiten beim
Bau des Berliner Flughafens BER.
Eine für viele Einsteiger bei Scrum ungewohnte Vorge-
hensweise ist, beim Schätzen der Aufwände vom Begriff
Zeit loszulassen. Es wird nicht mehr in Zeit geschätzt,
sondern in Komplexität. Das Verfahren, das man bei
Scrum zum Schätzen anwendet heißt „Planning-Poker“.
Lässt man vom bisher Gewohnten ab, ist der Umgang mit
Komplexitätspunkten schnell gelernt.
Betrachtet man diese Legofigur, kann man ein Gefühl
dafür entwickeln, welchen Aufwand deren Bau für einen
selbst bedeutet. Den Aufwand, diese Legofigur zu bauen,
beziffert man beispielsweise mit drei Komplexitätspunk-
ten, im Fachjargon auch Story Points genannt. Die Drei
ist ein beliebig gewählter Zahlenwert. Ausgehend von
der „3“ soll nun bestimmt werden, welchen Aufwand
man für sich selbst angibt, sollte die hier abgebildete
Legofigur erstellt werden.
Für die Schätzung gibt es keinen Determinismus. Man
schätzt aus dem Gefühl heraus, mit der Maßgabe, dass
drei Story Points für eine mutmaßlich weniger aufwändi-
gere Figur notwendig sind. Lässt man diese Aufgabe von
mehreren Personen geheim und unbeeinflusst in einem
Versuch schätzen, konvergieren die Werte der Schätzen-
den oft zwischen fünf und acht Story Points für das ab-
gebildete Lego-Schiff.
Läge man ein Team zugrunde, welches seit langer Zeit
zusammenarbeitet und schon viele Legofiguren mitei-
nander gebaut hat, würde man feststellen, dass die Schät-
zungen annähernd immer die gleichen Werte von den
einzelnen Teammitgliedern ergäben. Dies ist ein Zeichen
dafür, dass die, ursprünglich willkürlich gewählte Skala
für ein Team beim Aufwand Einschätzen funktioniert.
Gibt es erhebliche Unterschiede bei den geschätzten Sto-
ry Points, stellen die Personen mit dem jeweils höchsten
und niedrigsten Wert dem Team vor, welche Beweg-
gründe sie für ihre Wahl hatten. Dies eröffnet dem Team
neue Perspektiven, die sie selbst eventuell nicht beachtet
haben bzw. es können neue Beweggründe für das Zu-
standekommen der stark abweichenden Schätzungen
Schätzen des Aufwandes zum Bau einer Figur
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
4
ausgeräumt werden. Wird man sich nicht einig, nimmt
man den Durchschnitt aller Schätzungen und bewertet in
einer Nachbetrachtung, welche Argumente bei der Schät-
zung zuvor stichhaltig waren und welche sich bei der
Umsetzung nicht bewahrheiteten.
In Scrum sind Besprechungen definiert, die verpflichtend
stattzufinden haben, deren Teilnehmer feststehen und
deren Ziele genau vorgegeben sind. Die Serie beginnt mit
einem „Sprint-Planning“, welches das Vorstellen der
Aufgaben und das Schätzen für deren Aufwand vorsieht.
In diesem Meeting stellt der Product Owner die Stories
nacheinander vor. Für jede Story wird, wenn sie vom
„PO“ (gern verwendete Kurzform für „Product Owner“)
vorgestellt und vom Team verstanden worden ist, ein
Planning Poker der Teammitglieder durchgeführt. Jede
Aufgabe erhält somit einen, mit dem Team abgestimmten
Schätzwert in Form von Story Points. Für die Sammlung
aller Aufgaben – sortiert nach Priorität – gibt es einen
Fachbegriff. Man spricht in dem Fall von einem Backlog.
Im Backlog führt der PO alle Aufgaben auf, die er für das
Team vorsieht, in Sprints umgesetzt zu werden. Im gera-
de vorgestellten Sprint Planning Meeting beginnt er mit
der Vorstellung der obersten Aufgabe. Es werden so viele
Aufgaben vorgestellt, bis das Team seine Kapazität für
die Umsetzung in einem Sprint als erschöpft ansieht. Die
Auswahl der Aufgaben ist nach einer Priorität festgelegt,
die der Product Owner bestimmt hat und die er durch die
Reihenfolge der Stories von Oben nach Unten in der
Backlog Liste ausdrückt. Nur der PO bestimmt die Priori-
täten der Aufgaben für das Team, indem er sie der Wich-
tigkeit nach anordnet. Diese kann er jederzeit bis zum
nächsten Sprint Planning ändern. Im Sprint Planning
werden die Aufgaben und Gültigkeit der Reihenfolge für
den nächsten Sprint festgelegt. Aufgabe für Aufgabe
wird nun, der Reihenfolge im Backlog folgend, im Sprint
Planning vorgestellt, geschätzt und in den bevorstehen-
den Sprint aufgenommen. Das Team bestimmt die An-
zahl der Story Points für einen Sprint, die es meint, in
dem Sprint Zeitraum umsetzen zu können. Das Team
orientiert sich hierbei an der Anzahl der Story Points, die
in den vergangenen Sprints fertiggestellt wurden. Beim
ersten Sprint, bei dem noch keine Erfahrungswerte vor-
liegen, beginnt man mit einer beliebigen, plausibel er-
scheinenden Zahl. Im Laufe der ersten Sprints stellt sich
ein fester Wert an Story Points ein, den ein Team erfolg-
reich umzusetzen kann. Dieser wird der Erfahrung nach
mit der Zeit immer höher. Dies bedeutet, ein gleich auf-
gestelltes Team wird mit der Zeit seiner Zusammenarbeit
immer effizienter und daher leistungsfähiger. Dies spie-
gelt sich durch die Anzahl der in einem Sprint umsetzba-
ren Story Points wieder. Hier manifestiert sich der große
Unterschied zum klassischen Projektmanagement, da
ausschließlich das Team bestimmt, wie viele, deutlich
beschriebene, Aufgaben in einen bevorstehenden Sprint
aufgenommen werden. Zur Verdeutlichung, der Product
Owner bestimmt die Aufgaben und deren Reihenfolge,
das Team bestimmt, wie viele der Aufgaben im Sprint
aufgenommen werden. Zusammengefasst sieht der Ver-
lauf eines Sprint Plannings wie folgt aus:
1. Die vom Team vereinbarte Referenz-Story, auf der alle
Schätzungen beruhen, wird kurz ins Gedächtnis gerufen.
2. Das Team legt fest, wie viele Story Points im nächsten
Sprint maximal durchführbar sind.
3. Der Product Owner stellt dem Team die oberste Story
im Backlog detailliert vor.
4. Der Product Owner stellt die Akzeptanzkriterien vor,
nach denen er eine Aufgabe zusammen mit dem Team als
korrekt umgesetzt bewertet.
5. Das Team stellt Rückfragen bis ein vollständiges Ver-
ständnis für die Zielsetzung der Story erreicht ist.
6. Das Team schätzt die Aufgabe anhand von Story
Points. Abweichende Schätzungen werden teamintern
Vorgang eines Planning Pokers im Scrum Team
Das Backlog mit allen priorisierten Aufgaben
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
5
und mit Rückfragen an den Product Owner diskutiert, bis
ein einvernehmlicher Wert von allen Teammitgliedern
gefunden wurde.
7. Die Aufgabe wird „in den Sprint gezogen“. Dies be-
deutet, die Aufgabe ist freigegeben und muss bis zum
Ende des Sprints erledigt werden.
8. Der Product Owner stellt die nächste Aufgabe aus dem
Backlog vor.
Die Schritte drei bis acht werden so oft wiederholt, bis
keine Story mehr nachgezogen werden kann, da die vom
Team festgelegte maximale Summe an Story Points er-
reicht wurde.
9. Das Team betrachtet zuletzt alle Aufgaben, die in den
kommenden Sprint gezogen wurden und beschließt deren
Umsetzung. Man nennt diesen Vorgang auch „Commit-
ment“, nach neuer Definition verwendet man nun den,
noch unbekannten Begriff, „forecast“. Er gibt zum Aus-
druck, dass das Team die an sich gestellte Verantwortung
versteht und ernst nimmt.
Damit ist der Sprint gestartet und der Product Owner
kann zu dessen Ende mit der Fertigstellung seiner Auf-
gaben rechnen. Er wird sich nun bis zum nächsten Sprint
Planning um die Definition und das Priorisieren der
kommenden Stories kümmern. Sollte er im Rahmen die-
ser Tätigkeit eine Auskunft aus dem Team benötigen, ist
hierfür Zeit eingeplant. Ansonsten hat er mit dem laufen-
den Sprint keine Berührungspunkte. Vielmehr darf er
explizit keinen Einfluss auf die Arbeit des Teams neh-
men. Dies ist ein wesentlicher Bestandteil des Konzepts,
da Scrum das Team im Mittelpunkt der Umsetzungsver-
antwortung und als Kompetenzträger anerkennt. Eine
Todsünde ist es, wenn ein Product Owner sich in die
Aufgabenbearbeitung aktiv einmischt. So wird zum Bei-
spiel von disziplinarisch vorgesetzten Teamleitern gerne
während eines laufenden Sprints eine Aufgabe noch
„nachgeschoben“. Dies ist nicht möglich, denn das Team
hat sich beim Sprint Planning genau für die Fertigstel-
lung der Aufgaben verpflichtet, die in den Sprint gezogen
wurden. Wenn zusätzliche Aufgaben in dem Zeitraum
anfallen, sind die vorherige Schätzung und die vom Team
abgegebene Zusicherung nicht mehr gültig. In solchen
Fällen muss das Team über die, sich in der Rolle des
Scrum Masters befindende Person, sofort beim Product
Owner intervenieren.
Es kann während eines Sprints natürlich immer zu Zwi-
schenfällen kommen, die in den Planungen nicht vorge-
sehen waren. Es können außergewöhnliche Umstände
eintreten, die ein sofortiges Handeln des Teams erfordern
oder Voraussetzungen sich soweit ändern, dass die ur-
sprünglich geplanten Tätigkeiten nicht mehr möglich
sind. Diese Unwägbarkeiten wurden in Scrum bedacht.
Die Maßnahme dagegen lautet Sprint Abbruch. Der
Sprint Abbruch sieht vor, die getroffene Vereinbarung
mit dem Team sofort aufzulösen. Damit ist das Team frei
von den Verpflichtungen aus dem Sprint und kann der
Situation entsprechend agieren. In diesem Fall kann auch
der Vorgesetzte oder Weisungsbefugte wieder das Team
direkt steuern. Der Sprint gilt als abgebrochen und es
wird, nachdem sich die Lage beruhigt hat, mit einem
neuen Planning ein neuer Sprint gestartet, das Verfahren
geht wieder seinen normalen Weg.
Damit sich das Team während der Sprint Durchführung
gut koordinieren kann, gibt es, meist unmittelbar nach
dem Sprint Planning, das „Sprint Planning 2“. Es findet
ohne den Product Owner statt. Hier verabredet das Team
die detaillierte Vorgehensweise. Es werden hierbei häufig
Unteraufgaben für jede, im Sprint befindliche Story ver-
einbart. Diese können dann einzelnen Personen oder
Personengruppen aus dem Team zugewiesen werden. In
dem Projektverwaltungstool Jira können diese Unterauf-
gaben innerhalb einer Story eingetragen werden.
Schätzung und Zusammenstellen eines Sprints
Unteraufgaben einer Story
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
6
Stand Up Meeting eines Scrum Teams
Wie die Verteilung der Aufgaben innerhalb des Teams
und wie deren Abarbeitung erfolgt, ist nicht vorgegeben.
Es können zum Beispiel Aufgaben auf Tagesbasis ein-
zeln zugewiesen oder in Zweierteams bearbeitet werden.
Die Entscheidung, wie die Aufgaben am besten zu be-
wältigen sind, trifft das Team selbst. Diese Vorgehens-
weise stellt das Team im Sprint Planning 2 sicher. Im
Verlauf des Sprints sind dann sogenannte „Daily Stand
Up“-Veranstaltungen für alle Teammitglieder Pflicht.
Dies stellt der Scrum Master sicher. Sie muten für Unge-
übte zu Beginn etwas esoterisch an, man gewöhnt sich
aber schnell daran. Mehr und mehr gehört dieses Ritual
auch zum Alltag in vielen Büros, die nicht mit Scrum
arbeiten. In allen Fällen trifft sich das Team einmal täg-
lich und stellt sich im Kreis auf. Es wird, mittels Beamer,
großem Monitor oder Post-Its an der Wand ein Board der
anstehenden Aufgaben angezeigt.
Auf Grundlage der am Board aufgeführten Teamaufga-
ben stellt jedes Teammitglied nacheinander seine aktuel-
len Aufgaben vor. Dabei soll nicht mehr als eine Minute
Zeit pro Vorstellung verstreichen. Jede längere Diskussi-
on die entsteht, wird
dadurch unterbun-
den, dass mindestens
zwei der Anwesen-
den die Hand heben.
So wird signalisiert,
dass dies ein Thema
ist, was nicht für die
ganze Runde inte-
ressant ist. Die Dis-
kussionen können
im Verlauf des Ar-
beitstages von den
Betroffenen bi- oder
multilateral in einer
Besprechung behan-
delt werden, nicht
aber im Stand Up.
Das Stand Up ist
lediglich dazu da, eventuell bestehenden, tieferen Ab-
stimmungsbedarf zu identifizieren. Weiterhin soll für alle
Teilnehmenden transparent werden, ob Unklarheiten bei
den Aufgaben aufkamen oder -kommen, sowie, ob eine
Fertigstellung bei Themen gefährdet ist. Der wichtigste
Punkt ist sicherzustellen, wie man sich gegenseitig in den
kommenden Stunden unterstützen kann, um die anste-
henden Aufgaben effizient zu lösen. Dies wird in ge-
meinsamer Runde ohne Agenda besprochen. Jeder ist
dabei aufgefordert bei den einzelnen Schilderungen Auf-
fälligkeiten zu äußern und aus seiner speziellen Erfah-
rung heraus Hinweise oder Lösungswege anzubieten. Auf
dem Board findet sich das Ergebnis der Absprachen wie-
der, sei es durch Kommentare, die bei den Jira Issues der
Aufgaben hinterlassen werden oder durch Verschieben
der Aufgaben in ihren jeweiligen Bearbeitungsstatus. Oft
wird im Team, um die Übersicht zu wahren, die Verein-
barung getroffen, dass sowohl der Lösungsansatz, als
auch der Arbeitsfortschritt im Jira Issue als Kommentar
notiert wird. Dies erleichtert es, unter allen Beteiligten
ihre jeweilige Zuarbeit für die einzelnen Aufgaben zu
regeln. Ferner ist das Team besser vorbereitet, sollte bei-
spielsweise ein Bearbeiter durch Krankheit ausfallen oder
ein Wechsel in der Verantwortlichkeit beschlossen wer-
den. Durch die Notizen im Jira Issue sind die Informatio-
nen und der Arbeitsstand zur Aufgabe für jeden nach-
vollziehbar. Darüber hinaus – und hier ist Disziplin bei
allen Beteiligten erforderlich – ist der Arbeitsstatus, häu-
fig in den Ausprägungen „Offen“, „in Bearbeitung“, „in
Review“ oder „Fertig“, zu pflegen. Wenn eine Aufgabe
im Bearbeitungsstatus „in Bearbeitung“ steht, wird diese
kein anderes Team-
mitglied behandeln.
Wurde, zum Beispiel,
am Abend vergessen,
den Status „in Bear-
beitung“ anzupassen,
ist der tatsächliche
Arbeitsstand von
anderen Teammit-
gliedern nicht ersicht-
lich und es besteht die
Gefahr, dass sich der
Aufgabe niemand
annimmt. Gegen Ende
eines Sprints befinden
sich mehr und mehr
Aufgaben im abge-
schlossenen Status.
Einer Erklärung bedarf
der Status „in Review“. Hier wird ein „Vier-Augen-
Prinzip“ bei der Arbeitsweise im Team zugrunde gelegt.
Dies ist in Scrum nicht zwingend vorgegeben, findet sich
in der Praxis jedoch sehr häufig. Das Prinzip besagt, dass
die Lösung einer Aufgabe von einem zweiten, während
der Umsetzung nicht beteiligten Teammitglied geprüft
wird. Dieser Prozess wird als Review bezeichnet. Es wird
die Lösungsfindung dem „Reviewer“ in einem kurzen
Termin vorgestellt bzw. er kann auch autark das Ergebnis
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
7
prüfen. Ist die Prüfung erfolgt, sind keine Nachfragen
mehr beim ursprünglichen Bearbeiter notwendig und das
Ergebnis für den Reviewer zufriedenstellend, setzt er den
Bearbeitungsstatus auf „Fertig“.
Während eines Sprints kann es zu Hindernissen oder
Problemen kommen, bei denen das Team weder Schuld
trifft, noch Lösungen von ihm bereitgestellt werden kön-
nen. In diesem Fall spricht man im Scrum-Fachjargon
von sogenannten „Impediments“. Es ist Aufgabe des
Teams diese Störungen unverzüglich an den Scrum Mas-
ter zu melden (beispielsweise im Daily Stand Up). Der
Scrum Master hat dann die Aufgabe, die Probleme aktiv
zu lösen. Ist er dazu nicht in der Lage und kann er auch
durch Delegation nicht rechtzeitig für eine zufriedenstel-
lende Lösung sorgen, wäre ein Sprint Abbruch die logi-
sche Konsequenz. In die Rolle des Scrum Masters fallen
daher folgende Aufgaben. Er kümmert sich um alle, vom
Team selbst nicht lösbaren Probleme und hält dem Team
den Rücken frei. Weiterhin sorgt er dafür, dass alle Ter-
mine, die der Scrum Prozess vorsieht, eingehalten und
inhaltlich korrekt durchgeführt werden. Zuletzt stellt er
sicher, dass sich jeder, insbesondere auch der Product
Owner, an seine Rolle hält und seine Pflichten ordnungs-
gemäß erfüllt.
Ein Sprint endet immer mit einem Review Meeting und
einem Retro(spective) Meeting. Die Termine werden
vom Scrum Master eingerichtet. Die beiden Besprechun-
gen können in einem Termin nacheinander erfolgen, sind
aber thematisch zu trennen. Begonnen wird immer mit
dem Review. Dort sind der Product Owner und Scrum
Master anwesend, sowie das gesamte Team, in manchen
Fällen noch zusätzlich die sogenannten Stakeholder, also
Beteiligte die an der Aufgabenerfüllung ein direktes Inte-
resse haben oder mittelbar Auftraggeber sind. Das Team
stellt diesem Personenkreis seine Ergebnisse vor. Es be-
ginnt mit der ersten Story im Sprint. Hierzu werden, je
nach Natur der Aufgabe, an einem Beamer oder großen
Monitor die Ergebnisse, seien es nun Unterlagen, Soft-
ware, Oberflächen oder Skizzen, vorgestellt. Dies erfolgt
immer durch ein Mitglied des Teams, welches die Auf-
gabe maßgeblich umgesetzt hat. Der psychologische
Effekt hierbei ist nicht zu unterschätzen. Der Umsetzer
bekommt direkt die Gelegenheit seine Arbeit dem Anfor-
dernden und dem Team vorzustellen. In Zeiten speziali-
sierter und anonym verlaufender Aufgabenerfüllung wird
mit dieser direkten Kommunikation wieder ein Verständ-
nis für die geleistete Arbeit beim Anfordernden (Product
Owner und Stakeholder) erreicht. Dies hilft zum einen
dem Mitarbeiter, der die Wertschätzung seiner Arbeit
wahrnehmen kann, zum anderen wird es für den Product
Owner, sowie den Stakeholdern transparent, wo die
Aufwände entstanden sind, wie die Umsetzung erfolgte,
wer diese durchführte und welche Details zu beachten
waren. Diese Informationen sind für den Product Owner
von besonderer Bedeutung, da ihm dieser Einblick bei
der Erstellung seiner Stories eine Vorstellung vom Auf-
wand und den Zusammenhängen der Tätigkeiten des
ausführenden Teams vermittelt. Er wird als Auftraggeber
ein besseres Verständnis für seine Anforderungen entwi-
ckeln, die Zusammenarbeit mit seinen Auftragnehmern
wird vertrauensvoll und eng; es entsteht eine zielgerichte-
te Kommunikation und Atmosphäre zwischen den
Scrum-Beteiligten. Formal wird der Product Owner die
Akzeptanzkriterien einer Story Punkt für Punkt im Re-
view Meeting durchgehen und deren korrekte Umsetzung
bewerten. Hier wird es, insbesondere zu Beginn der Zu-
sammenarbeit zwischen Team und Product Owner zu
manchen Überraschungen und Missverständnissen kom-
men. Bei der Definition der Stories und Formulierung der
Akzeptanzkriterien können sich Fehler einschleichen, die
erst zum Zeitpunkt der Abnahme offensichtlich werden.
Es wurde dann sprichwörtlich am Ziel vorbei gearbeitet.
Mit zunehmender Anzahl gemeinsamer Sprints wird die
Fehlerquote deutlich geringer.
Dies wird, nicht zuletzt durch das Retrospektive Meeting,
gerne mit „Retro“ abgekürzt, sichergestellt. Diese Ab-
stimmung ist ein wichtiger Teil für die erfolgreiche An-
wendung von Scrum. Nach jedem Sprint wird in der Ret-
ro im Team, sowie mit Scrum Master und Product Owner
darüber gesprochen, was bei der Durchführung der Auf-
gaben gut und was schlecht lief. Für solche Besprechun-
gen gibt es verschiedene Formate. Am einfachsten ist es,
mit Post-Its die Beobachtungen aus dem letzten Sprint an
ein Flipchart, sortiert von positiv und negativ zu heften.
Whiteboard mit Punkten aus einem Retrospektive Meeting
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
8
Dabei stellt jeder seine Punkte der Reihe nach vor. Bei
der Vorstellungsrunde werden diese nicht diskutiert, son-
dern lediglich vom vorstellenden Teammitglied erläutert.
Der Scrum Master achtet auf die Einhaltung dieser Regel.
Nachdem die letzte Vorstellung absolviert ist, gliedert
der Scrum Master die Kritikpunkte in Themengruppen
und es werden die Themenblöcke im Team diskutiert.
Der Scrum Master moderiert die Diskussion und notiert
die dabei aufkommenden „Action Items“, also Maßnah-
men, auf die man sich im Team verständigt. Droht die
Diskussion zeitlich zu umfangreich zu werden, vereinbart
man im Team Klärungstermine, um den Zeitrahmen der
Retro einzuhalten. Die Action Items können als Stories
oder als Notiz für eine folgende Retro aufgenommen
werden, um deren Nachverfolgung sicherzustellen. In
einem Umfeld, wo gute Zusammenarbeit im Team wich-
tig ist – derer gibt es in der wachsenden Wissensgesell-
schaft viele – sollte ein regelmäßiges Abstimmen der
gemeinsamen Arbeit selbstverständlich sein. Sowohl für
Projekte in Unternehmen, wie auch bei Studierenden gilt,
dass es für zahlreiche Problemstellungen wenige Best-
Practice Anleitungen gibt. Die Tätigkeiten heutzutage
sind derart spezialisiert und einzigartig, dass denen nur
mit kreativer Lösungsfindung entgegnet werden kann.
Der Bedarf für einen intensiven Austausch ist daher dop-
pelt gegeben, muss ein Lösungsansatz erst einmal gefun-
den werden und im Nachgang dessen Eignung auch kri-
tisch beäugt sein. Der Scrum-Ansatz sorgt durch diese
Maßnahmen für einen kontinuierlichen Anstieg der
Lernkurve eines Teams und lädt auch gerade deshalb
dazu ein, an Hochschulen gelehrt und angewendet zu
werden.
Die Umsetzung in den Hochschulseminaren
Die tatsächliche Umsetzung dieser agilen Methode in den
Seminaren der beteiligten Hochschulen war ein Experi-
ment. Die begleitenden MitarbeiterInnen, Werkstuden-
tInnen und PraktikantInnen hatten bereits Erfahrung bei
der Bildung und Begleitung von Scrum Teams im Rah-
men ihrer Tätigkeit bei Vodafone gewinnen können. Ein
Ausrollen auf fünf Seminar Teams im akademischen
Umfeld war aber für alle neu. Auch Literatur oder andere
Quellen für eine Anwendung im akademischen Umfeld
waren kaum vorhanden. Folglich wurde vieles erdacht,
frisch konzipiert und einfach ausprobiert. Um erfolgreich
arbeiten zu können, wurden den Teilnehmern Jira Instal-
lationen zur Verfügung gestellt. Auf diese wurde mit
einem Browser über das Internet zugegriffen. Für bis zu
zehn Benutzer, was für ein einzelnes Scrumteam immer
ausreichend sein sollte, kostet eine Lizenz vernachlässig-
bare 10$ U.S. im Jahr. Die Wahl fiel auf Jira, um bei der
Hochschulausbildung möglichst praxisnah die Tools
einzusetzen, die sich später auch im Berufsleben wieder-
finden werden.
Auf den Jira Instanzen der einzelnen Projektgruppen
wurden zu Beginn vorbereitend „einfache“ Stories ange-
legt. Diese hatten zum Inhalt, den Gruppen ihre Themen
vorzustellen und sollten die Übung des Verfahrens unter-
stützen. Vor dem eigentlichen Start des ersten Sprints
wurden den Teilnehmern die Grundlagen von Scrum in
einer separaten Veranstaltung erklärt. Diesem Zweck
galten auch die ersten „Übungsstories“. Das Team selbst
muss sich kennenlernen, die Wertigkeit der Story Points
muss geübt werden. Zu Beginn jeden Review-, Retro-
und Sprint Planning Meetings wurden Ziel und Zweck
der Besprechung kurz wiederholt. Es war der beste Weg
den Beteiligten die vielen neuen Begriffe durch Wieder-
holung näher zu bringen. Auch das Schätzen nach Gefühl
verwirrte zu Beginn, wurde nach den ersten Sprints je-
doch sehr gut angenommen.
Zentraler Bedeutung kam die Formulierung der Stories
zu. Hier war auf Seite des Lehrenden, wie auf der des
Lernenden, Abstimmung und Kenntnisaufbau notwendig.
Eine Aufgabe musste so artikuliert werden, dass sie zu
dem Team passt. Das bedeutete insbesondere, dass auf
Vorwissen, auf Fachtermini und auf Hintergründe team-
spezifisch eingegangen werden musste. Der Verfasser
kann von seinem Wissen nicht auf das der Teammitglie-
der schließen. Des Weiteren musste sich bei allen Teil-
nehmern erst verfestigen, dass einzig die Beschreibung
die Maßgabe für die zu erledigende Aufgabe ist. Zusätz-
liche mündliche Erläuterungen können zwar im Sprint
Planning geäußert werden, sind diese aber von Relevanz
für die Aufgabe, müssen sie schriftlich in der Story fi-
xiert werden. Dies war für beide Seiten zunächst unge-
wohnt. Die Studierenden, und das zu Recht, wollten ihre
Bewertung nicht durch Ungenauigkeiten gefährdet wis-
sen, sollte eine der Stories unklar formuliert sein. Analog
findet sich dieses Motiv bei Mitarbeitern in einem Unter-
nehmen wieder, setzen sie Stories in Scrum um.
Die Aufgaben konnten sowohl eine Umsetzung, als auch
akademischer Natur sein. Für alle Aufgaben galt, dass
neben deren Erledigung auch deren Dokumentation prä-
zise zu erfolgen hatte. Die Dokumentation war genauso
in wissenschaftlicher Form zu erstellen, wie bei her-
kömmlichen Seminararbeiten. Der einzige Unterschied
besteht darin, dass das Dokument als Anhang in der Sto-
ry übergeben wurde und vom Umfang her im Zeitraum
eines Sprints erstellt werden konnte. Die Dauer eines
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
9
Webseite mit den vollständigen Daten für ein Scrum Team
Sprints wur-
de auf zwei
Wochen
festgesetzt.
In Jira steht,
wie schon
erwähnt, eine
Kommentar-
funktion zur
Verfügung.
In jeder Story
können diese
Kommentare
personalisiert
hinterlegt
werden.
Diese waren
hilfreich, um den jeweiligen Arbeitsstand zwischen den
Teammitgliedern während eines Sprints auszutauschen.
Da unter den Studierenden eine asynchrone Arbeitstei-
lung aufgrund unterschiedlicher Tagesplanungen unter-
stützt werden musste, sie gleich-
zeitig aber aufgefordert waren,
eng zusammenzuarbeiten, war
Kommunikation und Koordina-
tion von ihnen gefordert. Dies
ist ein Unterschied zu dem Vor-
gehen bei individuell anzuferti-
genden Seminararbeiten. Die
Übung hierbei, im Rahmen des
Seminars gemeinsam die Ziel-
setzungen umzusetzen, findet
sich im späteren Berufsleben mit
Sicherheit so wieder. Dort ist es Gang und Gäbe, inner-
halb eines Teams oder einer Abteilung, die über viele
Standorte oder Länder verteilt sind, Ergebnisse zu produ-
zieren.
Die mündliche Präsentation der Arbeitsergebnisse fand,
wie bereits ausgeführt, im Review Meeting statt. In die-
sen Meetings wurden die von den Seminarteilnehmenden
erledigten Aufgaben durch den Product Owner bewertet.
Daher war es sinnvoll, dass der bewertende Lehrbeauf-
tragte zugleich auch die Rolle des Product Owners inne-
hatte. Da das den Projektauftrag stellende Unternehmen
Vodafone war, war eine enge Abstimmung zwischen
dem Product Owner und dem Auftraggeber notwendig.
Als Auftraggeber stellte das Unternehmen eine Assisten-
tin, die die Stories in Abstimmung mit dem betreuenden
Professor verfasste. Der Aufwand hierfür war hoch. Zum
einen galt es, die
Projektziele in pas-
sende Stories für das
Team zu übertragen.
Zum anderen waren
die akademischen
Ansprüche an die
Aufgabenstellungen
zu definieren. Beide
Teile mussten in die
Formulierung der
Stories, sowie der
Akzeptanzkriterien,
aufgenommen wer-
den. Im Review
waren diese gemein-
schaftlich abzuneh-
men, erforderte also
eine enge Abstimmung in den Review Meetings. In den
Retrospektive Meetings bot sich die ideale Plattform, die
Bewertungen zu begründen und Wege aufzuzeigen, wie
Verbesserungen umgesetzt werden können. Hier bietet
der Scrum Ansatz eine hervorragende Grundlage, einer
für den Studierenden überraschenden oder ungerechtfer-
tigten Bewertung die Grundlage zu entziehen. Klassisch
erstellte Projektarbeiten leiden wie Projekte im Allge-
meinen unter einem unzureichenden Feedback während
der Umsetzungsphase. Hier erwies sich der Scrum An-
satz, mit seiner, durch die Iterationen bedingten Transpa-
renz, für die Studierenden als sehr lehrreich. Die teil-
nehmenden Studierenden eines Teams erhielten zweiwö-
chentlich eine Beurteilung durch den betreuenden Profes-
sor und das betreuende Unternehmen. Die Noten wurden
auf jede fertiggestellte Story vergeben. Die Seminarbe-
wertung ergab sich dann aus dem Mittel der einzelnen
Noten. Die Teilnehmer empfanden es als angenehm, dass
die Beurteilung fortwährend stattfand. Somit konnte auf
etwaige Verbesserungsvorschläge frühzeitig eingegangen
werden. Anfängliche Fehlschläge fielen nicht so sehr ins
Kommentar in Jira mit wissenschaftlichem Inhalt
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
10
Gewicht und die Zielsetzung entwickelte sich fortwäh-
rend weiter. Eine Themaverfehlung oder überraschende
Abschlussnoten waren faktisch ausgeschlossen. Die
Kommunikation mit den Lehrenden ist regelmäßiger,
zielorientierter und im Kontext angepasster, als wenn
individuelle Abstimmungen mit einer ProfessorIn verein-
bart werden müssen. Für die Abstimmung und Planung
jedes Seminars wurden die Rahmendaten zentral über
eine dedizierte Webseite zur Verfügung gestellt. Die
Teilnahme an den drei Besprechungen, Retro, Review
und Sprint Planning, waren für die Beteiligten, wie be-
reits beschrieben, verpflichtend. Ferner die Teilnahme
am teaminternen Sprint Planning 2. Um dies sicherzustel-
len wurden die Termine, das Projektziel, die Teilnehmer-
daten, sowie der Link zum Jira Board zu Beginn des Se-
mesters auf einer Webseite für jedes Scrum-Team einge-
richtet und im Vorfeld an die Teilnehmer versendet. Zu-
sätzlich wurde ein Mailverteiler an alle Teilnehmer und
ein Link zu einer Skype Gruppe auf der Webseite einge-
richtet. Da dies den organisatorischen Rahmen betraf,
den der Scrum Master zu verantworten hatte, war es sei-
ne Aufgabe, die Daten zu sammeln und die Einrichtung
zu veranlassen. In diesem Zusammenhang mussten auch
die regelmäßigen Abstimmungen, als „Daily Stand Ups“
vorgestellt, während eines Sprints organisiert werden.
Für gewöhnlich stellt sich zum „Daily“ ein Scrum Team
bei Vodafone in Kreisform in einen Raum, welcher mit
einem Videokonferenzsystem ausgestattet ist. Abwesen-
de Teilnehmer, beispielsweise wegen Homeoffice-
Regelung oder Dienstreise, werden über Video-
Konferenz und ein Screenshare auf das Jira Board hinzu-
geschaltet. Diese Abstimmung ist in einem Unternehmen
leicht einzurichten, da alle Beteiligten innerhalb ihrer
Arbeitszeit erreichbar und einplanbar sind. Bei den Teil-
nehmern in einer studentischen Seminararbeit wird es
jedoch schwieriger, einen täglich stattfindenden Termin
zu planen. Es war an der Vorstellung und dem Ergebnis
der Aufgaben ablesbar, inwiefern es den Seminarteil-
nehmern gelang, eine regelmäßig stattfindende Abstim-
mung einzurichten. Der Erfolg des Scrum Konzepts lebt
in erheblichem Maß von der Kommunikation im Team.
Teams, die sich von Anfang an regelmäßig abstimmten,
waren augenscheinlich erfolgreicher bei der Durchfüh-
rung ihrer Aufgaben im Sprint. Die Ergebnisse der Sto-
ries hingen ferner davon ab, wie gut das Sprint Planning
2 durchgeführt wurde. Im Fall guter Vorbereitung orga-
nisierten sich die StudentInnen im jeweiligen Scrum un-
tereinander sehr gut. Sie sahen für verschiedene Aufga-
ben Gruppen innerhalb des Teams vor, die einzelne Auf-
gaben miteinander lösten. Innerhalb dieser Gruppen
konnte sich während des Sprints gut abgestimmt werden.
Ein weiterer Erfolgsfaktor der Teams war, der in Scrum
vorgesehenen Dynamik wechselnder Anforderungen
begegnen zu können. Stellten die Teilnehmer im Verlauf
eines Sprints fest, dass Anteile für eine Aufgabe bisher
vergessen wurden, wurden in Zusammenarbeit mit dem
Product Owner die fehlenden Aufgaben als Stories im
Backlog hinzugefügt. Da die Aufgabenstellungen in den
Seminaren natürlich Unwägbarkeiten im Verlauf des
Semesters mit sich brachten, war dies ein geeigneter
Weg, diesen organisatorisch zu entgegnen. Im Fall einer
klassischen Planung wird mit einer Rückwärtsrechnung
des Aufwands begonnen. Es wird ein möglichst detail-
lierten Abfolgeplan für die Seminaraufgaben erstellt. Die
Studierenden identifizieren zu Beginn alle Arbeitspakete
und bringen diese in eine Reihenfolge. Wäre bei der an-
schließenden Bearbeitung eine neue Aufgabe aufgekom-
men, wäre die gesamte Planung durcheinander gekom-
men. Je nachdem, wie schwerwiegend der neue Punkt
wäre, müsste der gesamte Plan neu durchdacht werden.
Die Teammitglieder müssen zusammenkommen und die
Abfolge der Aufgaben neu regeln. Bei erneut vergesse-
nen Aufgaben wäre diese Abstimmung abermals not-
wendig. Hier ist die Methode Scrum, die diese Agilität
berücksichtigt, klar überlegen. Dies wurde in den Semi-
naren entsprechend wahrgenommen, da naturgemäß die
Aufgaben zu Beginn nicht vollständig bekannt sein konn-
ten. Scrum bildet damit ein probates Mittel, diesem Teil
der akademischen Herausforderung praktisch zu entgeg-
nen, in Seminaren sukzessive Erkenntnisse zu gewinnen
und diese in einem Endergebnis zu vereinen.
Während der Durchführung fiel auf, dass dem studenti-
schen Alltag Rechnung zu tragen ist. So konnte durch
den Seminartermin zwar sichergestellt werden, dass die
Studierenden an den vereinbarten Terminen, Sprint Plan-
ning, Retro und Review teilnehmen konnten. Schwieriger
gestaltete sich jedoch das Einhalten täglicher Abstim-
mungen. Die Teilnehmer hatten vielfach divergierende
Stundenpläne, die ein regelmäßiges, tägliches Abstim-
men oder einen festen täglichen Termin unmöglich
machten. Da zusätzlich die im Sprint anfallenden Ar-
beitspakete zum einen asynchron von den Mitgliedern im
Scrum Team umgesetzt wurden und zum anderen Kom-
munikation untereinander erforderten, fehlte schlichtweg
dieser eine, wichtige Termin zur Abstimmung. Die Stu-
dierenden koordinierten ihre Arbeiten vornehmlich durch
unregelmäßige Treffen, an denen über ein paar Stunden
hinweg gemeinsam an den verschiedenen Aufgaben im
Sprint gearbeitet wurde. Die Ergebnisse der Aufgaben
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
11
Erstes Sprint Planning Meeting des internationalen Teams
waren zwar zufriedenstellend, jedoch wurde der Vorteil,
den der Scrumansatz mitbringt, asynchron im Team ar-
beiten zu können nicht so optimal genutzt, wie er es hätte
sein können. Die Ursache lag hierbei zunächst im Fehlen
der regelmäßigen Abstimmung in Form eines Daily
Stand Ups. Ein entsprechender Passus in der Studienord-
nung oder eine grundsätzliche Einrichtung von Semina-
ren, die eine regelmäßige, wochentägliche Abstimmung
vorsähe, würde beim Lehren agiler Methoden an der
Hochschule sehr helfen. Sehr unterstützend wirkte der
Einsatz von Technologien, welche eine Zusammenarbeit
ohne physische Anwesenheit der Beteiligten erforderte.
Vodafone, als ein Keyplayer auf dem Markt für solche
Lösungen, unterstützte diese Vorgehensweise durch seine
eigenen Erfahrungen mit einem mobilen Arbeitsumfeld.
Die dazu gehörende Infrastruktur, seien es Mobilfunk,
Internet-Connectivity, Konferenzsysteme und Software-
lösungen, waren für die Hochschulprojekte daher leicht
zugänglich. So konnten die Arbeitspakete zwischen den
Studierenden in Russland und Deutschland abgestimmt
werden, die betreuenden Scrum Master ihre Teams von
München aus betreuen und die Product Owner zugeschal-
tet werden, da eine Anreise nach Coburg aus München
(oder gar Novosibirsk) nicht immer möglich war. Bei
Vodafone verrichten MitarbeiterInnen bis zu vierzig Pro-
zent ihrer Arbeitszeit im Home Office. Weiterhin erhal-
ten MitarbeiterInnen in den Geschäftsräumen der ver-
schiedenen Standorte, darunter die größten München und
Düsseldorf, weit über tausend Mitarbeitern, keinen fest
zugeteilten Schreibtisch. Dieser wird jeden Tag individu-
ell bezogen. Diese Tatsache erfordert ein Maximum an
mobilen und virtuellen Arbeitsmitteln. Meetings können
gleichzeitig von MitarbeiterInnen abgehalten werden, die
im In- und Ausland in Videokonferenzräumen sitzen,
zuhause Arbeiten oder im Auto / Zug fahren. Alle Teil-
nehmenden sind durch Verwendung virtueller Räume,
die mobile Geräte, Kameras und PCs integrieren, mitei-
nander verbunden.
Sie teilen Präsentationen, können die freigegebenen Bild-
schirme anderer verfolgen und via Videokonferenz die
Teilnehmer sehen. Eine weitere Herausforderung bei der
Planung der Kommunikation war die Zeitverschiebung
zwischen Russland und Deutschland. Ein Problem der
Globalisierung für jedes Unternehmen wurde so auch für
Studierende real, genauso wie Sprachbarrieren und die
Erstellung englischer Projektunterlagen. Im Zentrum der
Abstimmungen stand stets das Jira Board des jeweiligen
Scrum Teams. Dies war bei der Koordination von gro-
ßem Wert, weil alle Beteiligten in einem Team ein zent-
rales System hatten, in dem die Informationen aktuali-
siert und ausgetauscht wurden. Es war so keine bilaterale
Kommunikation notwendig, in der die Gefahr besteht,
dass Informationen aufkommen, die unter Umständen
anderen Teilnehmenden nicht bekanntgemacht wurden.
Voraussetzung hierfür war, dass die Kommentarfunktio-
nen von Jira auch genutzt wurden. Flankiert wurde die
Projekt Organisation und deren Koordination durch die
zentrale Webseite für jedes Scrum Team. Ein verlässli-
ches Maß an Terminplanung konnte so sichergestellt
werden. Schließlich waren weitaus mehr Termine und
Abgaben zu steuern, als in einem herkömmlichen Semi-
nar – circa zehn Mal so viele. Eine Verschiebung oder
ein Ausfall waren schlecht realisierbar, daher wurden alle
Termine über das Semester hinweg bereits im Vorfeld
unverrückbar gesetzt. Die Festlegungen für jedes Scrum
Team auf dieser Webseite waren essentiell für den Erfolg
der Seminare. Für die Verwirrungen und Unklarheiten,
die sich berechtigterweise zu Beginn bei allen Teilneh-
menden und Funktionstragenden einstellten, waren die
Webseite und das Jira Board der geeignete Regulator.
Die Ergebnisse der einzelnen Seminargruppen waren
exzellent, nachdem die Vorgehensweise mit Scrum ver-
standen war. Übereinstimmend wurde von Teilnehmen-
den, wie Bewertenden festgestellt, dass das regelmäßige
Feedback in den Sprints das Arbeiten erleichterte. Die
Ziele waren klar vorgegeben, was das fokussierte Umset-
zen für die Studierenden sehr unterstützte. Zum anderen
wurde von den Teams als angenehm wahrgenommen,
dass die Auslastung durch die Auswahlmöglichkeiten im
Sprint Planning den Erfordernissen des Teams angepasst
werden konnten. Fiel es einem Team schwerer in das
Thema zu finden, regulierte sich das Tempo der Einarbei-
tung ganz automatisch anhand der Stories, die für einen
kommenden Sprint aufgenommen wurden. Allen Teams
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
12
Abschlusspräsentationen der Scrum Teams in den Räumen von Vodafone
war gemein, dass sie zu Beginn viel zu viele Aufgaben in
den Sprint aufnahmen. In den Retrospektive Meetings
wurde dies offensichtlich. Dies führte aber nicht etwa zu
unerledigten Aufgaben sondern die Teams haben, auf-
grund ihrer hohen Motivation, deutlich mehr Zeit für die
Erfüllung der Stories in den Sprints aufgewendet. Eine
Lösung, nicht im Sinne agiler Projektplanung, da der
zeitliche Aufwand pro Sprint eine Konstante ist. Diese
Größe ist nicht veränderbar, und, setzt man eine normale
Arbeitswoche eines Mitarbeiters in einem Unternehmen
an, auch nicht veränderbar, die Möglichkeit von Über-
stunden bei Seite gelassen. Genau dies war die Lösung
der Studierenden. Sie gingen über den, für das Seminar
veranschlagte Zeitraum hinaus und leisteten Mehrarbeit.
Für den Zeitraum, der im Seminar aufzuwenden ist,
konnte während der gesamten Laufzeit der Veranstaltun-
gen keine echte Metrik gefunden werden. Hier gilt es bei
zukünftigen Scrum Anwendungen an Hochschulen eine
bessere Vereinbarung vor Beginn zu treffen. Der Zeit-
raum für einen Sprint sollte klar definiert sein, sodass die
Aufgaben in einem Sprint auch diesen Zeitraum benöti-
gen. Nicht zuletzt ist es Sinn und Zweck dieser Veran-
staltung, das Verfahren richtig anzuwenden. Diese Pla-
nungen noch genauer zu beobachten, ist ein Learning aus
der Seminarreihe in Coburg. Die Ergebnisse waren exzel-
lent, der Aufwand übertraf den zu Beginn vorgesehenen
Zeitraum. Diese Metrik kann, will man es sehr genau
bestimmen, durch Einsatz von Jira Funktionen erreicht
werden. Eine Einstellung in dem Tool erlaubt es den
Bearbeitenden einer Story bzw. derer Unteraufgaben, die
darauf verwandte Zeit einzutragen. Eine mitgelieferte
Statistik Funktion in Jira ermöglicht deren spätere Analy-
se. Im Idealfall entspricht die Summe der für einen Sprint
aufgewendeten Zeit zur Fertigstellung der Stories den im
Vorfeld vereinbarten Zeitraum. Ist dies nicht der Fall,
müssen die Gründe in der Retro klar angesprochen wer-
den und sind in der Planung des nächsten Sprints zu be-
rücksichtigen. Hinweise zum verbesserbaren Zeitma-
nagement fanden sich in den Retrospektive Meetings
aller fünf Scrum Teams wieder. Die hohe Motivation
durch die Teilnehmenden war ein Stück weit durch die
immer wieder bevorstehenden Präsentationen in den
Reviews zurückzuführen.
Mit besonderen Anfangsschwierigkeiten hatte das inter-
national besetzte Team aus Russland und Deutschland zu
kämpfen. Das Tempo der Abstimmung war durch den
räumlichen Abstand bestimmt. Die Teams kommunizier-
ten regional, jedoch fehlte es an der Kommunikation
zwischen den Gruppen. Zusätzlich war der Umgang mit-
einander in der Sprache Englisch zu etablieren, die weder
beim deutschen, noch beim russischen Team die Mutter-
sprache darstellten. Nach den ersten Sprints wurde die
Erfahrung gemacht, die zu besprechenden Themen nicht
eine bestimmte Komplexität überschreiten zu lassen.
Während man gewohnt war, in der jeweiligen Landes-
sprache auch komplexere Zielstellungen in einer Bespre-
chung durchgehen zu können, war es für ein internationa-
les Team, in dem niemand nativ englisch sprach, bedeu-
tend schwieriger. Hier empfahl es sich, Besprechungs-
themen in einzelne, kleinere Themenblöcke zu untertei-
len und diese separat durchzugehen. Dies setzte sich zu-
nehmend auch im thematischen Schnitt der Stories fort.
In dem international aufgestellten Scrum Team wurde der
Sprache und dem internationalen Abstimmungsaufwand
geschuldet, eine kleinteilige inhaltliche Aufteilung einge-
führt.
Die immer präziser formulierten Stories waren eine wei-
tere Erfahrung, die in den ersten Sprints gemacht wurde.
Man konnte zu Beginn beobachten, wie die Akzeptanz-
kriterien beim Review zum ersten Mal von den Teilneh-
mern richtig gelesen wurden. Es wurde allen Beteiligten
klar, von welcher Bedeutsamkeit die Akzeptanzkriterien
sind und wie ernsthaft deren Umsetzung im Review Mee-
ting kontrolliert wurde. Sie fanden nach jedem Sprint
mehr Beachtung und wurden viel intensiver während der
Planung der Stories diskutiert, als zu Beginn.
Dies führte zu der Entscheidung, die ersten drei Sprints
nicht für die Notenbewertung heranzuziehen. So wurde
die Einarbeitung mit dem noch unbekannten Verfahren
berücksichtigt. Da sowohl das Scrum Verfahren, als auch
das Ergebnisformat vollkommen unbekannt waren, haben
die Studierenden die berechtigte Forderung, die von
ihnen erwartete Leistung erst einmal kennenzulernen.
Fehlschläge zu Beginn wurden so von den Teilnehmen-
den weniger hektisch aufgenommen. Um den Studieren-
den die, für sie berechtigterweise bedeutende Orientie-
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
13
rung hinsichtlich der Leistungsbeurteilung zu geben,
wurden die einzelnen Stories für die ersten drei Sprints
jedoch benotet. Die Noten hatten aber keinen Einfluß auf
die endgültige Bewertung, sondern gaben lediglich eine
Indikation der Leistung wieder. Die Notenvergabe erfolg-
te für die Leistung des gesamten Scrum Teams. Es wur-
den einzelne Bewertungen für die Stories vorgenommen
und am Schluss gemittelt. Aus akademischer Sicht ist
eine Story mit dem Erfüllen der Akzeptanzkriterien nicht
zwangsläufig mit einer Note 1,0 zu bewerten. Es kam
zusätzlich darauf an, wie die Präsentation der Ergebnisse
und in besonderem Maße, die Dokumentation und For-
mulierung der Ergebnisse umgesetzt wurde. Es war ge-
nauso auf eine wissenschaftlich korrekte Form zu achten,
wie bei einer herkömmlichen Abschlussarbeit. Die in der
Kommentarfunktion der Stories von den Studierenden
erstellten Graphiken, Tabellen und anderen Elemente
waren qualitativ hochwertig und die Funktionen von Jira
wurden umfangreich verwendet.
Die Themen der Seminare zeichneten sich in der Wahr-
nehmung der Teilnehmenden dadurch aus, dass an „ech-
ten“ Firmen-Kooperationsprojekten teilgenommen wur-
de. Die Aufgabenstellungen waren keine rein akademi-
schen, sondern reale Herausforderungen aus der Unter-
nehmenswelt.
Da ein klassisches Projektmanagement vielen nur theore-
tisch bekannt war und ein agiles Projektmanagement
überhaupt nicht, sowie ein komplexes Projektmanage-
ment Tool verwendet werden musste, konnten die Ein-
drücke intensiv erlebt, statt nur gelehrt werden. Diese
Herausforderung galt es mit den gewohnten Mitteln des
wissenschaftlichen Arbeitens zu vereinen. Es war bei der
Erstellung der schriftlichen Anteile eine kontinuierliche
Betreuung notwendig. Um die, als Kommentar in einem
Jira Issue formulierten Teile der Arbeit nach allen An-
sprüchen einer wissenschaftlichen Auseinandersetzung
zu erfüllen, wurden die folgenden Regeln entwickelt:
Es wurde das Thema in den Stories selbständig
mit den im Bearbeitungsstatus angegebenen Stu-
dierenden erarbeitet
Es wurde aus einer großen Menge von Informa-
tionen das Wesentliche ausgewählt
Es wurden komplexe Sachverhalte verstanden
und schriftlich wiedergegeben
Die Fragestellungen wurden inhaltlich verstan-
den, Lösungsstrategien konzipiert und unter An-
wendung wissenschaftlicher Methoden eine Lö-
sung gefunden
Es wurde für einen gewählten Lösungsweg ar-
gumentiert
Es wurde in schriftlicher Form präzise und ver-
ständlich ein Dokument als Anhang in der betref-
fenden Story verfasst
Es wurden die in den Stories zu wissenschaftli-
chen Klärung angegebenen Punkte inhaltlich re-
cherchiert und bibliographiert
Es wurden Referenzen im Text durch Referenz-
angaben ergänzt und die Literatur in einem Lite-
raturverzeichnis aufgeführt
Optisch aussagekräftige Visualisierungen wur-
den, wenn notwendig, erstellt und in einem Ab-
bildungsverzeichnis aufgeführt
Um diese Anforderungen zu erfüllen, mussten die Teil-
nehmenden zunächst üben, die Kommentarfunktion in
Jira richtig zu nutzen. Insbesondere die Formatierung in
den Kommentaren war wichtig zu erlernen. Viele web-
basierte Applikationen verfügen über eine sogenannte
„Markup“ Sprache. Sie erlaubt es, nicht nur Text, son-
dern auch dessen Formatierung und andere Elemente,
wie Bilder oder Tabellen darzustellen. Um die oben ge-
nannten Forderungen zur Erläuterungen der Ergebnisse
einer Story umzusetzen, reichte Text alleine nicht aus. Er
muss formatiert werden können, mit Überschriften, Ta-
bellen, Bildern oder Verwendung von Farben. All dies ist
mit einer Markup Sprache möglich.
Nachdem die Markup Funktionen verstanden waren,
konnten die Teilnehmenden ihre Tätigkeiten nachhaltig
für andere Teammitglieder in den Kommentaren festhal-
ten, diese mit Skizzen und sinnvollen Zusatzinformatio-
nen ergänzen und als akademischen Beitrag formulieren.
Die Scrum Master übernahmen zusätzlich die Aufgabe
eines Trainers. Es war notwendig, während des Sprints
Ein Kommentar mit Markup Elementen
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
14
immer wieder auf die Möglichkeiten der Dokumentation
hinzuweisen, die Formulierungen zu schärfen und die
Anwendung der Markup Funktionalität zu erklären. Wie
bereits ausgeführt, waren die schriftlichen Zusammenfas-
sungen in Form und Inhalt ausschlaggebend für die Be-
wertungen. Entsprechend gründlich musste sich mit die-
sem Thema beschäftigt werden. Mit der Zeit nutzte man
für das Sicherstellen der über alle Stories hinweg anfal-
lenden Aufgaben, zu denen die wissenschaftlichen Do-
kumente gehörten, das im Scrum Framework vorge-
schriebene DoD (Definition of Done) Dokument. In die-
sem Dokument wurden Review für Review die Fertig-
stellungskriterien über alle Aufgaben/Stories hinweg
geregelt. Sie sind daher nicht mit den Akzeptanzkriterien
zu verwechseln, die für eine einzelne Story gelten. Die
DoD gelten für alle Aufgaben.
Während des Experiments stellte sich das Vorliegen die-
ser Regelung als große Unterstützung für die Teilnehmer
heraus. Zu Beginn verzichtete man darauf, um die Teil-
nehmenden nicht zu überfordern. Bei Anwendung von
Scrum in der Lehre empfiehlt sich nach dieser Erfahrung
nun die Formulierung einer DoD, um den akademischen
Anspruch der Bearbeitung sicherzustellen. Nach den
ersten Sprints in den verschiedenen Hochschulprojekten
wurde diese Definition of Done formuliert:
Aus den Kommentaren im Jira Issue sind die Lö-
sungsschritte für eine Story klar erkennbar
Die im Jira Issue aufgeführten Unteraufgaben
weisen die Verantwortlichen für die Umsetzung
des jeweiligen Teils einer Story aus
Die in einem Jira Issue aufgeführten Unteraufga-
ben geben die zur vollständigen Umsetzung not-
wendigen, einzelnen Arbeitspakete wieder
Jeder Kommentar, der zur Bewertung einfließen
soll, wurde mit dem Präfix „[Result]“ markiert.
Diese Kommentare sind in wissenschaftlich gül-
tiger Form verfasst. Diese Kommentare sind der
Story, nicht den Unteraufgaben beigefügt
Alle relevanten Ergebnisse einer Story sind als
Anhang in der Story beigefügt. Diese sind eben-
falls in wissenschaftlich gültiger Form verfasst.
Nach Festlegung dieser Regeln konnte die Ergebnisfor-
mulierung gezielter angegangen werden. Zur Sicherheit
wurde dem Team zum Ende jeden Sprint Plannings und
vor Aufnahme des Sprint Planning 2 empfohlen, die De-
finition of Done erneut laut vorzulesen, um deren Bedeu-
tung und deren kontinuierliche Beachtung zu fördern.
Die Referenzstory wurde nach dem ersten Sprint ange-
passt. Da zu Beginn noch keine gemeinsame Aufgabe
vorlag, einigte man sich darauf, den Aufwand, der bei der
Erstellung von fünf PowerPoint Folien entsteht, als Refe-
renzwert heranzuziehen. Die Folien wurden im Vorfeld
des ersten Sprint Plannings vorgestellt und besprochen.
Für die Erstellung dieser fünf Folien wurden acht Story
Points vereinbart. Nach dem ersten Sprint lag eine Reihe
von Umsetzungen vor, die das Team gemeinsam durch-
geführt hatte. Vor dem zweiten Sprint konnte das Team
eine der Stories aus dem ersten Sprint als seine Referenz-
story auswählen. Bei den Sprint Planning Meetings war
den Teilnehmenden häufig unklar, ob noch eine zusätzli-
che Story in einen Sprint aufgenommen werden soll oder
nicht. In diesem Fall bestand die Möglichkeit, Stories in
einen Sprint „nachzuziehen“. Die im Backlog als nächs-
tes fälligen Aufgaben wurden vom Team im Sprint Plan-
ning im herkömmlichen Verfahren mit einer Schätzung
versehen. Das Besondere war nun, dass die Stories nicht
mehr in den Sprint aufgenommen wurden. Sie blieben in
den obersten Reihen des Backlogs stehen. Sollte während
dem Sprint der Fall eingetreten sein, dass es nichts mehr
zu tun gab, also alle Stories bereits fertiggestellt waren,
wurde die oberste Story im Backlog „nachgezogen“. Dies
wurde mit dem Scrum Master abgestimmt. Da die nach-
zuziehenden Stories bereits geschätzt waren, kann das
Team sofort die Abarbeitung beginnen. Es galt dabei
fairerweise, dass die Story nicht bis zum Sprint Ende
fertiggestellt sein musste, da sie ja ursprünglich nicht
vorgesehen war. Daher konnte mit einer tendenziell ge-
ringeren Anzahl an Story Points begonnen werden. Dies
war auch eine geeignete Maßnahme, um die, wie oben
beschrieben, tendenziell zum Überbuchen des Sprints
neigenden Teams zu steuern.
Eine weitere Beobachtung war, dass die Vorteile der
virtuellen Synchronisation von den Teilnehmenden kaum
genutzt wurden. Zum Teil war dies auf die Tatsache
zurückzuführen, dass die Studierenden ohnehin häufig an
der Hochschule waren. In der Planung wurde davon aus-
gegangen, dass die Teilnehmenden in einem asynchron
arbeitenden Team durch den heute üblichen Umgang mit
Skype und sozialen Medien bereits eine dezentrale und
virtuelle Kommunikation gewohnt wären. Nachdem die
Zusammenarbeit an den Grenzen der Hochschulräume,
bzw. im internationalen Projekt an den jeweiligen Lan-
desgrenzen Halt zu machen schien, wurden die Stories
teils neu konzipiert. Es war den Analysen in den Retros
zu entnehmen, dass komplexe Stories für verteilte Teams
schwierig abzustimmen sind. Je enger ein Team Zusam-
menarbeit planen konnte, mit welchen Kommunikati-
onsmitteln auch immer, um so umfangreicher konnte eine
Story sein. Umgekehrt musste eine Story, die in einem
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
15
Professionelles Scrum Training bei Vodafone
physisch verteilten oder mit Kommunikationsmitteln
nicht vertrauten Team zu bearbeiten war, inhaltlich klei-
ner geschnitten sein. Die Problemstellungen wurden da-
her granularer in Stories unterteilt. So war es den Teil-
nehmern möglich, meist nur genau eine komplexe Frage
mit dem Team beantworten zu müssen. Der Kommunika-
tionsaufwand hierfür war geringer, thematisch verschach-
telte Abstimmungen entfielen weitgehend. Die adäquate
Verwendung der Jira Aufgaben und Boards durch die
Mitglieder des Scrum Teams ermöglichte ebenfalls eine
Verbesserung. Der Umgang wurde mit Anwendung und
Hilfestellung kontinuierlich besser. Dies bezog sich auf
das Fortschreiben des Status einer Story im Kommentar-
feld, die verständliche, fachliche Formulierung und die
Pflege der notwendigen Unteraufgaben einer Story im
Verlauf eines Sprints.
Es stand an Tools, Technik, Kommunikation, Aufgaben-
stellungen und Betreuung alles so zur Verfügung, wie es
auch in einem multinationalen Konzern zum Einsatz
kommt. Diese Voraussetzungen konnten effizient dazu
genutzt werden, Teams und Trainern gegenüber die Vor-
gehensweisen so vorzustellen, wie sie in der Unterneh-
menswirklichkeit täglich Anwendung finden.
Zwei notwendige Schwerpunkte der Wissensvermittlung
wurden bei den Projekten an der Hochschule Coburg
offensichtlich. Zum einen das agile Arbeiten zu erlernen
und zu trainieren. Zum anderen die Aufgabenstellung
zielgerichtet bearbeiten, lösen und angemessen zu doku-
mentieren. Zu diesem Zweck wurden die in Retrospekti-
ve Meetings erarbeiteten Action Items einem dieser
Themengebiete zugewiesen. Das bedeutete ganz prak-
tisch, es wurden nicht nur die Action Items für alle ein-
sehbar notiert, sondern auch, ob sie einer dieser beiden
Kategorien zugeordnet werden konnten. War dies der
Fall, fiel es nicht nur dem Team, sondern auch dem
Scrum Master und Product Owner zu, die Action Items
einer Lösung zuzuführen. Thematisch war es sinnvoll,
dass Verbesserungen in der Anwendung des agilen Ar-
beitens tendenziell vom Scrum Master, die inhaltlicher
Art, eher vom Product Owner begleitet wurden. Beide
Rollen mussten sich, abweichend von der Definition in
Scrum, ihrer lehrenden Rolle bei der akademischen An-
wendung von Scrum bewusst sein. Mehr noch erforderte
dies auch die entsprechenden didaktischen Fähigkeiten.
Die Rolle des Scrum Masters wurde in allen fünf Projek-
ten durch Studierende besetzt, die schon Erfahrung mit
der Anwendung von Scrum hatten.
Den Product Owner stellte idealerweise die Hochschule,
besetzt durch ProfessorIn bzw. Lehrbeauftragten. Da fünf
Teams zu betreuen waren, übernahmen teils auch Mitar-
beiterInnen von Vodafone die Rolle des Product Owners,
bzw. erstellten die Stories in Abstimmung mit dem PO.
In der Retro kamen viele Fragen zum Verfahren selbst
auf. In solchen Fällen wurden diese Punkte gesondert
erfasst und besprochen. War es weder dem Scrum Master
in seiner Funktion als Trainer, noch den anderen Teil-
nehmern möglich eine Lösung anzubieten, wurde die
Frage als zu klärender Action Point an einen Experten für
Scrum weitergeleitet. Dessen Antwort wurde vom Scrum
Master im nächsten Retro-Meeting vorgestellt.
Ein weiteres Learning bei der Formulierung von Stories
ist, dass im Rahmen der Vorbereitung künftiger Seminare
die Vorbereitung der Product Owner in einer gesonderten
Veranstaltung vor dem eigentlichen Start der Projekte
erfolgt. Dort können Kenntnisse über den Prozess und
das Verfassen der Stories eingehend trainiert werden.
Als vorteilhaft erwies sich im Rahmen der fünf Scrum
Seminare an der Hochschule Coburg/Novosibirsk, dass
die Betreuung durch Studierende erfolgte, die zeitgleich
als PraktikantInnen / BacherlorantInnen / Werkstuden-
tInnen bei Vodafone in München beschäftigt waren. Dort
ergab sich, neben dem alltäglichen Arbeiten im Scrum
Team, die Möglichkeit der Trainingsbetreuung interner
Schulungen. Die Studierenden betreuten regelmäßig in-
terne Schulungsveranstaltungen in ganz Deutschland.
Hierdurch waren sie herausgefordert, das Scrum Frame-
work nicht nur anzuwenden, sondern erklären zu können,
was den Lerneffekt erheblich steigerte.
Wie eine Betreuung eines Scrum Teams an einer Hoch-
schule aussähe, welches nicht durch die intensiven Un-
ternehmenserfahrungen geprägt wurde, kann daher noch
nicht abschließend bewertet werden. Je intensiver die
Vorbereitung hierzu im Vorfeld erfolgt, um so größer
sind hier die Erfolgsaussichten.
Daneben fanden sich die üblichen Herausforderungen bei
menschlicher Zusammenarbeit, die es immer gibt. Die
Agile Methoden bei Hochschulprojekten in Kooperation mit Vodafone
16
Online-Kickoff mit Team aus Novosibirsk und Coburg bei Vodafone
Anwesenheit in den Meetings und Zuarbeit in den Pro-
jekten steigert sich kontinuierlich, da die Bewertung im
Review und die anschließende Kritik in der Retro uner-
bittlich kommt. Schwächen hierbei werden rigoros und
für Studierende in teils nicht bekannter Klarheit, ange-
sprochen. Dies weniger durch die Lehrbeauftragten, son-
dern mehr durch die Teammitglieder selbst, die man-
gelnde Zuarbeit sofort entlarvten. Weiterhin wollten
Teilnehmende unbedingt in einem Team sein, was sich so
in der Unternehmenswelt mit Sicherheit nicht mehr fin-
den lässt. Da zwei Projektteams wegen ihrer internationa-
len Aufstellung gezwungen waren, ausschließlich auf
Englisch zu arbeiten, wurde dies zu Beginn ebenfalls von
manchen Teilnehmern nicht als Chance verstanden. Auch
dies gilt es mit dem Hinweis auf die Unternehmenswirk-
lichkeit später zu vermitteln.
Abschließenden gilt es festzuhalten, dass Scrum als Er-
gänzung der bestehenden Lehrformate eine spannende
Erfahrung für die Studierenden, wie Betreuenden war.
Die Herausforderungen bei der Arbeit mit diesem
Framework waren die gleichen, wie man sie auch im
Unternehmen wiederfindet. Scrum fordert, crossfunktio-
nale Teams zu bilden. Die Aufgaben sind „Ende zu En-
de“ von einem Team erledigt werden. Wo man früher nur
reine Entwickler-, Analysten, Tester oder Fachexperten
Teams bildete, findet sich in einem Scrum Team aus
jeder Disziplin ein Mitwirkender wieder. Zusammen
stellen sie die Fertigkeiten in enger Kommunikation zur
Verfügung, die notwendig sind, um Anforderungen als
Stories von Entwurf bis zum erfolgreichen Test selbst zu
realisieren. Die Crossfunktionalität ist es, was die Ar-
beitsweise mit Scrum auch für Hochschulseminare inte-
ressant macht. Jeder Studierende, mit unterschiedlicher
Perspektive, Ausbildung und Erfahrungen bringt sich in
das Teams ein, um gemeinsam in iterativen Schritten eine
bislang unbekannte Herausforderung zu meistern. Dies
führt bei den Teilnehmern zu einem lehrreichen Aus-
tausch der Fertigkeiten. Zuletzt sei betont, dass ohne
agile Kenntnisse kein Studierender mehr eine Hochschu-
le verlassen darf. Hier wäre der Lehrauftrag, gerade einer
praktischen Hochschule nicht erfüllt. Das haben alle
Teilnehmenden bei der Auseinandersetzung mit dem
Thema in Zusammenarbeit mit einem agil arbeitenden
Konzern Vodafone während der Projekte erfahren.
Markus Leue
Prof. Dr. Eduard Gerhardt