Artikel und Medien

Im Folgenden wird der übergeordnete Ablauf der Veranstaltung umrissen. (Einen detaillierten Ablaufplan finden Sie in der Seitenleiste.) Die Bilder setzen sich aus verschiedenen Semestern der Durchführung zusammen, da nicht immer die Zeit vorhanden war, von jedem Stand ein Foto zu machen. Der erste Durchlauf fand auf Deutsch statt, die darauffolgenden auf Englisch.

Der Raum muss genügend Wandfläche für die Planungswände zur Verfügung haben. Der erste Durchlauf zeigte eine Gesamtfläche von 8m² der Planungswände als guten Richtwert für 10 Teams mit je maximal 8 Studierenden. Diese Fläche muss möglichst gut erreichbar sein und sollte einen ausreichenden Abstand zu den Tischen haben. Sie dient als Planungswand für die Studierenden für gemeinsame Zusammenarbeit. Jedes Team besitzt einen Doppeltisch und in der Mitte des Raumes ist ein leerer Doppeltisch, welcher später für die Marsstadt vorgesehen ist. Für die User Stories werden große Post-Its in drei Farben benötigt, dazu Duct-Tape (ein spezielles Klebeband) zum Abtrennen verschiedener Bereiche auf der Planungswand. Um die Kommunikation in den Teams zu erleichtern, sollten alle Studierende einen Namensschild-Aufkleber tragen. Um den Scrum Master eines jeden Teams sofort zu erkennen, hilft eine gelbe Armbinde. Pro Team sollte genügend Klemmbausteine zur Verfügung stehen. Der genaue Bedarf ist in Tabelle 1 dargestellt. Wichtig zu erwähnen ist noch, dass der_die Lehrende während der Lehrveranstaltung zwei verschiedene Rollen einnehmen wird/muss: Die des Product Owners und die des_der Erklärdenden/Dozierenden.

Nachdem sich alle Studierenden an die Gruppentische gesetzt haben – und die Studierenden ihr Team bereits unwissender Weise ausgewählt haben, werden die Studierenden in das Thema der Serious Games eingeführt (Folien können auf Anfrage über „Kontakt in einfachlehren.de“ zur Verfügung gestellt werden.), da in etwa so lautet:

„Umweltkatastrophen, Umweltverschmutzung, Überbevölkerung und Krieg – die Menschheit steht am Rande des Aussterbens… durch ihre eigenen Handlungen! Konglomerate haben Regierungen abgelöst und kämpfen um die verbleibenden Ressourcen des Planeten. Einige haben es sich zur Aufgabe gemacht, die Überbevölkerung durch Umsiedlung in den Griff zu bekommen. Dafür birgt die Kolonisierung des Mars einen Funken Hoffnung. Die Ingenieure der Terra Industrial Mining Corporation (TIM Corp.) planen bereits die erste Stadt auf dem Mars. Autark, sicher vor Angriffen von Söldnertruppen und anderen Kompanien und doch verbunden mit dem blauen Planeten, der manchmal nur ein Schatten seiner selbst ist…“

Anschließend findet eine kurze Diskussionsrunde statt, was gute Teamleitende ausmacht und was sie vor allem nicht tun dürfen. Sobald die Qualitäten guter Teamleitung im Bewusstsein aller Studierenden präsent sind, soll jedes Team eine Teamleitung (später Scrum Master) mit Schere-Stein -Papier auswählen, ohne dass sie bereits wissen, was die konkreten Aufgaben sein sollen. Der Scrum Master holt sich eine Armbinde ab, zieht sie sich an und scheint zu wissen, was seine Aufgabe ist (siehe Schritt 6).

Nachdem das Team gebildet ist, wird der Fokus direkt auf das Projekt gerichtet: Wie kann man herausfinden, wie die Stadt auszusehen hat? Hierfür wird der Begriff der User Stories eingeführt. Es wird diskutiert, welche User es in der Stadt geben könnte (bspw. Familien, Investoren, Söldner und Händler), welche Bedürfnisse diese Benutzergruppen haben (bspw. Sicherheit, Ernährung, Infrastruktur) und durch welche konkreten Baumaßnahmen – Lösungen zur Befriedigung der Bedürfnisse – sich diese Bedürfnisse erfüllen lassen (bspw. Verteidigungsanlagen, Schildgeneratoren, Raumhafen, Hydroponics Farmen). Die Studierenden schreiben die Ideen der drei Kategorien (Nutzer_innen, Bedürfnisse und Lösungen) sukzessive auf die Post-Its der entsprechenden Farbe und sortieren sie an der Planungswand zu den User Stories (siehe Abbildung 2). Sind beispielsweise alle Nutzer_innen identifi-ziert (blau), so nimmt sich jedes Team einen blauen Post-It und überlegt sich Bedürfnisse zu diesen Usern. Der Scrum Master bringt dann das Ergebnis zurück an die Planungswand und nimmt ein neues Post-It, bis keines mehr da ist. Ebenso wird mit den Lösungen verfahren.

Als erste Priorisierung werden Release Goals eingeführt, also Meilensteine, die den Entwicklungsstand der Stadt kennzeichnen: 1. Sicherheit und Selbstversorgung, 2. Freizeitaktivitäten, 3. Größere Stadt für mehr Einwohner. Die Studierenden sollen nun die gelben Post-Its nehmen und sie in die einzelnen Release Goals einsortieren. Für den weiteren Verlauf der Veranstaltung wird angestrebt, Release Goal 1 zu erreichen, die anderen Post-Its werden von nun an vernachlässigt.

Die Lösungen sind zu diesem Zeitpunkt noch nicht weiter definiert und umfassen in der Regel nur wenige Wörter (wie beispielsweise: Krankenhaus, Wohnsiedlung, oder Farm). Zunächst muss der Aufwand aller Lösungen für Release Goals 1 grob geschätzt werden, der in „Bauzeit in Klemmbausteinen gemessen an einer Person“ bemessen wird. Das wird dadurch erreicht, dass je ein Teammitglied aus jedem Team nach vorne kommt und, ohne Sprechen, die Lösungen auf einer Aufwands-Skala von 1 – 2 – 3 – 5 – 8 Minuten einsortiert. Post-Its können auch nach dem Platzieren durch ein Teammitglied jederzeit durch ein anderes Teammitglied umpositioniert werden. Sobald der Aufwand geschätzt wurde, nimmt sich wieder jedes Team sukzessive eine Karte, vermerkt den Aufwand in Minuten und detailliert die Lösung zu einem Deliverable, welches dem Bauaufwand entspricht (bspw. ein Raumhafen: Lande-platz für Rakete, Anbindung an Infrastruktur und Treibstoff-Befüllung, mit Wartebereich). Sobald alle Post-Its detailliert sind, wird eine kurze Pause gemacht. Bis hierhin sollte bereits ungefähr eine Stunde vergangen sein.

Während der Pause gliederte der Lehrende, aus Sicht des Product Owners, die Aufgaben entsprechend ihrer Priorität in das Product Backlog ein. In dieser Reihenfolge müssen die Teams später die Post-Its in ihre Sprint-Planung aufnehmen. Ein Product Owner würde hier hauptsächlich nach Priorität sortieren; aus der Sicht des Lehrenden sollten jedoch noch weitere Kriterien berücksichtigt werden: Infrastruktur zuerst, denn sie hilft, den Aufbau der Stadt zu verstehen, aber auch einfache Gebäude in höherer Priorität, da die Teams ein Gefühl dafür entwickeln müssen, wie man einfache Elemente baut und wie viel Zeit sie veranschlagen. Einfache Infrastruktur-Gebäude sollten also idealer Weise im Backlog bevorzugt werden. Erst danach sollten komplexere Gebäude gebaut werden. Der Stand der Planungswand zu diesem Zeitpunkt ist in Abbildung 3 dargestellt.

Nach der Pause sollen die Teams den ersten Sprint planen: Sie werden gemeinsam eine Stadt bauen und sich die Gebäude entsprechend des Backlogs untereinander aufteilen. Hierbei ist es zweitrangig, welches Team welche Gebäude baut, auch wenn einige Teams meist bestimmte Präferenzen haben. Die Zuteilung muss daher innerhalb von 5 Minuten durch die Studierenden selbst erfolgen und eine Einigung muss schnell passieren. Meist liegt hier der Fokus der Studierenden zunächst mehr auf dem Ergattern der „besten“ Gebäude, als den Aufwand im Blick zu behalten. Dieser „Fehler“ ist durchaus beabsichtigt und wird in Schritt 6 ausführlicher erläutert. Wichtig ist, dass sich an dieser Stelle der Scrum Master nicht beteiligen darf – das Team entscheidet Anzahl und Umfang der zu erledigenden Tätigkeiten. Warum, wird bis zu diesem Zeitpunkt nicht erklärt, interessanter Weise wird danach aber auch nicht gefragt. Die Planungswand für die Sprints ist in Abbildung 4 dargestellt. Während des ersten Sprints befindet sich noch keine Aufgabe unter „Done“ und die Sprints sind meist gut gefüllt.

Nun geht es los. Die Studierenden haben nun wenige Minuten Zeit, um die Aufgaben aus ihrem Sprint Backlog zu erledigen (siehe Abbildung 5). Während dieser Zeit geht der Lehrende aus dem Raum, um für Rückfragen nicht zur Verfügung zu stehen. Niemand hat gefragt, wo die Gebäude nach dem Sprint stehen sollen oder wie genau die Gebäude eigentlich aussehen sollen. Alle denken, sie wissen was zu tun ist, und irren sich damit gewaltig. Die Gebäude stehen lose im Rau verteilt, teilweise unfertig, haben ganz unterschiedliche Bauarten und man kann kein übergeordnetes Konzept erklären. Der Scrum Master hat im Zeitdruck selbst angefangen mitzubauen – oder weil es ihm/ihr einfach Spaß macht – anstatt das Team zu koordinieren. Tatsächlich hat sich zu diesem Zeitpunkt aber auch noch niemand Gedanken gemacht, was überhaupt koordiniert werden soll. Um dieses Dilemma zu unter-streichen, geht der Lehrende in die Mitte des Raumes zum leeren Tisch und rufe sinngemäß in der Rolle des Product Owners (gespielt) verärgert: „Wo ist denn jetzt meine Stadt? Das hier? Das ist doch keine Stadt! Das ist eine Hütte! Und die ist noch nicht mal auf dem Mars! Und das? Soll das fertig sein? Was habt ihr in den letzten Minuten eigentlich gemacht?!“ Der Lehrende verlangt, dass alle nun ganz schnell die Ergebnisse „auf den Mars“ (auf den Tisch in der Mitte) bringen, um das Ergebnis besser begutachten zu können. Die Studierenden merken, dass sie sich nicht genug abgesprochen haben und keine Ahnung haben, wie die Stadt eigentlich aussehen soll (siehe Abbildung 6). An dieser Stelle versuchen sich natürlich alle, sich zu erklären, unterstützen sich gegenseitig mit ihren

Argumenten und tauschen sich über die Teamgrenzen hinweg aus mit dem Ziel, den Lehrenden zu überreden, dass sie gute Arbeit geleistet haben. Wenn alles läuft, wie geplant, dann hat sich spätestens zu diesem Zeitpunkt eine Gemeinschaft gebildet, die über die Teamgrenzen hinausgewachsen ist, um sich gegen den „bösen“ Product Owner zu verbünden. Sobald dies geschehen ist, wechselt der Lehrende die Rolle, stellt sich auf die Seite der Teams und leitet den Review des ersten Sprints ein.

Jetzt hören alle zu, der Lehrende hat die volle Aufmerksamkeit und kann erklären, was Scrum wirklich ausmacht und wir diskutieren gemeinsam, was eigentlich falsch lief. Hätte der Lehrende alles zu Beginn erklärt, wäre das Verständnis und die Bedeutung der Inhalte vermutlich nicht so hoch, da die Studierenden den Wert der hier vermittelten Informationen noch nicht zu den Tätigkeiten hätten zuordnen können. An dieser Stelle wird auch das Rollenverständnis von Scrum Master, Product Owner und Team im Detail erklärt und alle Fragen beantwortet, die aufkommen. Würde es dabeibleiben, wären die weiteren Sprints ab nun an einfach, aber die Realität sieht schließlich auch nicht so einfach aus. Um die Komplexität weiter zu erhöhen, aber auch, um ein wichtiges Element der agilen Arbeitsweise einzuführen, erläutert der Lehrende, was sich hinter einer „Definition of Done“ verbirgt und wie diese für die Marsstadt aussieht; Sie definiert, welche Produkte von dem Product Owner akzeptiert werden und welcher Entwicklungsstand nach einem Sprint zu erwarten ist:

• 1. Flache Teile (Straßen usw.) des Produkts können gezeichnet werden.
• 2. Eine erkennbare stadtähnliche Struktur muss erreicht werden.
• 3. Alle Gebäude müssen im Größenverhältnis zueinander und zu ihrer Funktion stehen.
• 4. Die Gebäude im Zentrum der Stadt sollten höher sein als die am Stadtrand.
• 5. Alle Gebäude benötigen eine Tür und mindestens ein Fenster pro Stockwerk.
• 6. Gebäude mit ähnlicher Funktion haben ähnliche Farben.

Gerade der sechse Punkt lässt die Studierenden meist laut seufzen, da es bedeutet, dass nicht nur alles noch einmal komplett neu gemacht werden muss, sondern dass man irgendwie die Farben sortieren muss und man irgendwie schaffen muss, sich bezüglich der Stadtstruktur zu koordinieren. Genau dafür sind aber die Scrum Master der Teams da, und spätestens jetzt wird das den Teams bewusst. Sobald der Lehrende, nach einer Neuplanung der Sprints, alle wieder in den nächsten Sprint schicken möchte, verlangen die Studierenden meist nach etwas mehr Zeit, um sich zumindest etwas zu koordinieren. Der Lehrende gewährt ihnen für den zweiten Sprint deshalb eine Minute mehr Zeit. Die Definition of Done lässt der Lehrende dabei nochmals extra auf einem Flipchart stehen, damit sie jederzeit für alle einsehbar ist.

Ohne, dass der Lehrende es angeordnet oder vorgeschlagen hat, beginnen die Teammitglieder idealer Weise nach Sprintbeginn sofort damit, die Farben innerhalb ihres Teams zu sortieren, während sich alle Scrum Master zusammenfinden, um das Projekt zu koordinieren (Abbildung 7). So wird eine Skizze der Stadt erstellt, die Höhe von Gebäuden festgelegt, es werden Farben definiert und vieles mehr.

Insgesamt haben die Teams nach dem gescheiterten Sprint nur zwei weitere Sprints, um das erste Release Goal erfolgreich abzuschließen, also insgesamt nur 15 Minuten, um die Stadt zu bauen. Arbeiten die Teams effizient, ist noch Zeit für einen dritten Sprint welcher meist aber nicht mehr gebraucht wird. Innerhalb dieser zwei Sprints merken die Teams schnell, dass sie mit ihren eigenen Klemmbausteinen nicht auskommen, da sie einheitliche Farben benötigen. Wird es richtig gemacht, so kümmert sich der Scrum Master um die Beschaffung der Ressourcen aus anderen Teams. Erstaunlich schnell entsteht so die Stadt und es ist immer wieder überraschend, welch kreative Lösungen die Teams finden, um die Stadt darzustellen (siehe Abbildung 8).

Dieser Schritt ist fast der Wichtigste der gesamten Lehreinheit und hierfür sollte auf jeden Fall genug Zeit bleiben. Hier versucht der Lehrende sich soweit wie möglich im Hintergrund zu halten und in erster Linie geht es auch nicht darum, was der Lehrende gut (oder schlecht) gemacht hat, sondern darum, was die Studierenden gelernt haben. Die Studierenden sollen in eigenen Worten wiederholen, was Scrum bedeutet und wie die Methode funktioniert – und wie sie nicht funktioniert. Dabei sollen sich die Studierenden gegenseitig ergänzen. In letzter Instanz ergänzt der Lehrende die letzten Punkte und fasse alles möglichst auf den Punkt zusammen. Die gesamte Lehreinheit dauert in etwa zweieinhalb Stunden.