Agile Methoden bei Hochschulprojekten in Kooperation mit ... · man nur bei der Anwendung, ähnlich...

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


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


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


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


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


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


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


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


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


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


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


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-


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


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


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


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

Agile Methoden bei Hochschulprojekten in Kooperation mit ... · man nur bei der Anwendung, ähnlich...

Documents

Transcript of Agile Methoden bei Hochschulprojekten in Kooperation mit ... · man nur bei der Anwendung, ähnlich...