Edu-Scrum – eine Variante für die Schule

Flavio Carrera

Marwin-Tristan soll einen einen Vortrag halten. Gemeinsam mit seiner Sitznachbarin Jovita. Er investiert Stunden in die Recherche, bemüht sich den Vorgaben seiner Lehrerin zu Gestaltung und Layoutierung der Folien und inhaltlichem Aufbau gerecht zu werden, lässt den Text von seiner Mutter korrigieren, trifft sich mehrmals mit Jovita und die beiden schauen sich Lernvideos zum Thema an. Dann kommt der Tag, an dem die beiden ihre Präsentation halten. Sie dauert 10 Minuten, wie vorgegeben, und gelingt sehr gut. Oder das denken zumindest die beiden. Die Lehrerin gibt ihnen eine 4.5. Sie lobt die Folien, kritisiert den Inhalt. Der Vortrag gehe am Thema vorbei, der rote Faden sei nicht immer klar erkennbar, Jovita spreche zu leise, Marwin-Tristan lese zu viel ab. Die Zwei sind enttäuscht. Das ausführliche Bewertungsblatt werfen sie ins Altpapier, die Folien löschen sie von ihren Computern, ihren Eltern verschweigen sie wie’s gelaufen ist. Zusammen arbeiten werden Jovita und Marwin-Tristan nicht mehr. 

Scrum vs. Wasserfall

In seinem neuesten Buch «Scrum: The Art of Doing Twice the Work in Half the Time» verspricht der Erfinder von Scrum, Jeff Sutherland, eine massive Erhöhung der Effektivität von Arbeitsprozessen, wenn ein häufig auftretendes Problem behoben wird, nämlich dass der Fokus in der Produktentwicklung zu stark auf die Planung gelegt und erst viel zu spät Feedback von jenen Personen eingeholt wird, die die Produkte letztlich nutzen sollen. Diese Art des planungs-zentrierten Vorgehens wird als «Wasserfallmodell» bezeichnet, weil die verschiedenen Phasen der Projektentwicklung kaskadenartig aufeinander folgen und das Ergebnis einer Phase die jeweils nächste Phase einleitet. Das Problem einer solchen Arbeitsweise ist offensichtlich:

You might be heading completely in the wrong direction for months and not suspect it.

Dem Wasserfallmodell stellt Sutherland als Alternative «Scrum» gegenüber. In Scrum laufen die Phasen nicht linear, sondern iterativ ab, das heißt Verbesserungen werden schrittweise durchgeführt und Feedback wird so rasch wie möglich eingeholt, indem man das Produkt bereits in rudimentären Vorstufen von Kund*innen testen lässt.

The sooner you give things to your customers, the quicker they can tell you if you’re making something they need.

In Scrum wird in sogenannten Sprints gearbeitet, das sind kurze Zeiteinheiten von wenigen Wochen, im Zuge derer ein Produkt ständig weiterentwickelt, getestet und optimiert wird. Innerhalb eines Sprints durchläuft ein Produkt immer wieder von Neuem vier Phasen:

• Eine Phase der Planung
• Eine Phase der Ausführung
• Eine Phase der Überprüfung
• Eine Phase der Anpassung

Das Durchlaufen dieser Phasen in der Entwicklung eines Produktes führt dazu, dass eine schnelle und agile Anpassung an komplexe und sich wandelnde Umstände und Anforderungen möglich ist. Der Leitsatz, nach dem sich diese Art der Arbeit richtet, lautet in den Worten Jeff Sutherlands:

Fail fast so you can fix early.

Durch die so erlangte «Wendigkeit» im Arbeitsprozess sind Unternehmen, die nach Scrum arbeiten, jenen, die das Wasserfallmodell praktizieren, in einem komplexen und dynamischen Kontext überlegen.

Warum Scrum an Schulen?

So wie viele Arbeitsprozesse in Unternehmungen, ist auch der Unterricht an Schulen in aller Regel nach dem Wasserfallmodell konzipiert. Zumindest insofern überhaupt ein Produkt erarbeitet wird. Im produkt- oder projekt-orientierten Unterricht liegt der Schwerpunkt meistens auf der gründlichen Planung und Erarbeitung eines Produkts.

Feedback-Zyklen werden kaum durchlaufen und von Iteration kann keine Rede sein. Das eingangs beschriebene Fallbeispiel veranschaulicht das damit verbundene Problem: Vom Zeitpunkt der Auftragserteilung bis zur Produktabgabe – hier der Vortrag – holen die Schüler*innen kein Feedback ein. Zumindest nicht von jener Person, die das Produkt in Auftrag gegeben hat. Und ist das Produkt eingereicht und die Benotung erfolgt, wird dieses auch nicht weiterentwickelt. Das Unterfangen gilt als beendet. Selbst, wenn die Lehrperson noch so detaillierte Rückmeldungen gibt, werden diese in den seltensten Fällen dazu verwendet, das Produkt zielgerichtet zu optimieren. Wozu auch? Der Vortrag wird ja kein zweites Mal gehalten.

Egal, ob es sich um einen Essay, einen Vortrag, oder eine andere Art von Projektarbeit handelt – das System krankt häufig daran, dass zwar ein detaillierter Auftrag erteilt und genaue Bewertungskriterien transparent abgegeben werden – während der selbständigen Tätigkeit sind die Schüler*innen oder Teams aber weitgehend auf sich selber gestellt. Und diese Freiheit ist selbst für Erwachsene eine Überforderung.

Was Marwin-Tristan und Jovita gebraucht hätten, damit ihr Vortrag nicht nur befriedigend, sondern ausgezeichnet ausgefallen wäre, sind nicht primär detaillierte Kriterien- und Bewertungsformulare, sondern regelmäßiges Feedback. Feedback zu ihrem Schaffen. Feedback zum Produkt. Feedback von der Lehrperson, von Mitschüler*innen, von Expert*innen und von den Eltern.

Wenn in der Produktentwicklung im Unterricht an Schulen ähnliche Mechanismen ablaufen, wie es in der Produktent-wicklung von Firmen der Fall ist und Scrum sich bereits als erfolgreiches Modell in Unternehmungen erwiesen hat, so könnte Scrum auch für Schulen zumindest eine interessante Idee sein. Und es gibt a priori keinen Grund, weshalb sich Unterricht nicht auch in Sprints konzipieren ließe, in denen iterative Entwicklungsprozesse mit regelmäßigem Feedback-Schlaufen ablaufen (siehe Abbildung 3).

Der Grundgedanke von eduScrum und der eduScrum-Guide

Die Art und Weise wie die Produktentwicklung nach Scrum ablaufen sollte, ist in einem Rahmenwerk von Jeff Sutherland und Ken Schwaber genau definiert. Doch, auch wenn sich vieles in den Unterricht übertragen lässt, existieren auch wesentliche Unterschiede zwischen Unternehmungen und Schulen, weshalb bestimmte Anpassungen am offiziellen Scrum-Rahmenwerk vorgenommen werden müssen. Aus diesem Grund wurde von einer Gruppe rund um den Niederländischen Chemielehrer Willy Wijnands eine für Schulen adaptierte Version von Scrum entwickelt, die eduScrum genannt wird. Auch für eduScrum existiert ein offizielles Rahmenwerk, das die Implementierung in den Unterricht detailliert beschreibt. Lehrpersonen, die sich für eduScrum interessieren, finden in diesem Guide Hilfestellung. Außerdem kann mittlerweile auch eine Vielzahl an Weiterbildungsangeboten in Anspruch genommen werden.

Das Ziel dieses Kapitels besteht darin, der Leser*in einen Einblick in die Arbeit mit eduScrum zu verschaffen und wichtige Aspekte des Paradigmenwechsels zu beschreiben, der notwendig ist, damit eduScrum an Schulen gelingen kann. Deshalb wird an dieser Stelle verzichtet, auf Details einzugehen. Diese können direkt dem eduScrum Guide entnommen werden. Drei fundamentale Säulen von eduScrum, die im Rahmenwerk genannt werden, sollen hingegen im Folgenden kurz erläutert werden:

• Transparenz
• Überprüfung und Anpassung
• Selbstorganisation

Transparenz durch ScrumBoards

Transparenz in eduScrum bedeutet, dass der Arbeitsprozess für diejenigen sichtbar sein muss, die für das Ergebnis letztlich verantwortlich sind und dass das Team ein gemeinsames und explizit ausformuliertes Verständnis darüber besitzt, was überhaupt erarbeitet werden soll. In eduScrum trägt die Verantwortung für ein Lernprodukt ein Team aus Schüler*innen. Sie arbeiten in Sprints, die beispielsweise drei Wochen dauern und jeweils zwei Wochenlektionen umfassen können. Zu Beginn eines Sprints werden die Ziele von der Lehrperson, die die Rolle des Product Owners übernimmt , definiert und in der Form so genannter Akzeptanzkriterien schriftlich festgehalten. Die Schüler*innen entscheiden aber autonom über die Frage, wie die Sprintziele realisiert werden sollen und formulieren im Team «Tasks». Damit ein derartiger, autonomer und selbstgesteuerter Prozess gelingen kann, benötigen das Team, aber auch der Product Owner transparente Einblicke in den Arbeitsprozess. Zu diesem Zweck legen die Teams ScrumBoards an. Dabei handelt es sich um digitale oder analoge «Tafeln», die aufzeigen, welche Tasks von welcher Person in einem Sprint verantwortet werden und sich im Prozess von «To do» über «Doing» bis nach «Done» in welcher Phase befinden.

Überprüfung und Anpassung

Die zweite Säule ist «Überprüfung und Anpassung». EduScrum nennt sechs Ereignisse die dafür sorgen, dass Überprüfung und Anpassung stattfindet. Sie alle sind im Guide beschrieben. Zusammengefasst lässt sich sagen, dass der Sinn von «Überprüfung und Anpassung» darin liegt, sowohl den Arbeitsprozess wie auch das Produkt fortlaufend weiterzuentwickeln. Erreicht wird dieses Ziel durch ritualisierte Abläufe, die regelmäßiges, dafür aber kurzes Feedback ermöglichen. Hervorgehoben werden können drei Rituale: die Stand Ups, das Review und die Retrospektive. Stand Ups werden zu Beginn jeder Lektion im Team durchgeführt und sollten nicht länger als fünf Minuten dauern. In einem Stand Up beantwortet jedes Teammitglied drei Fragen: 

1. Was habe ich seit der letzten Unterrichtseinheit gemacht, um dem Team bei der Erreichung des Sprintziels zu helfen?
2. Was werde ich in dieser Unterrichtseinheit machen, um dem Team bei der Erreichung des Sprintziels zu helfen?
3. Welche Hindernisse gibt es, die mich oder mein Team von der Erreichung des Sprintziels abhalten?

Durch die Stand Ups werden die Teams dazu gebracht, miteinander über den Arbeitsprozess, die eigenen Leistungen und Schwierigkeiten im Prozess zu sprechen. Somit wird die Basis dafür gelegt, dass die Lernenden nicht nur ihre Kommunikation verbessern, sondern auch schrittweise zu einem besser und effektiver arbeitenden Team werden können. 

Die Reviews und Retrospektive werden jeweils am Schluss eines Sprints abgehalten. Im Review geht es darum, dass das Team mithilfe des ScrumBoards und der Lernziele (Akzeptanzkriterien) überprüft, ob das geschaffene Produkt die Bedingungen erfüllt, die einerseits vom Product Owner und andererseits vom Team festgelegt wurden. Während das Review auf das Produkt fokussiert, wird in der Retrospektive der Arbeitsprozess an sich reflektiert. Durch die Retrospektive lernen die Schüler*innen, wie sie zusammen effektiver und effizienter lernen und arbeiten können. Im Rahmen der Retrospektiven können die Teams mit der Zeit einen positiven Umgang mit Kritik trainieren, eine Kompetenz, die auf viele Aspekte des schulischen und außerschulischen Kontextes positiv aus-wirken kann. 

Selbstorganisation

Die dritte Säule betrifft die Art und Weise, wie die Schüler*innen-Teams organisiert sind. Selbstorganisierte Teams entscheiden autonom darüber, wie sie ihre Arbeit am besten erledigen, anstatt dies durch andere Personen außerhalb des Teams (z.B. der Lehrer*in) vorgegeben zu bekommen. Niemand – auch nicht der Product Owner – diktiert dem Schülerteam, wie sie ihre Lernziele erreichen sollen. Die Lehrperson beschränkt sich darauf die Ziele festzulegen («Was») und den Teams klar zu machen, weshalb es sinnvoll ist, dass sie tun, was sie tun sollen («Warum»). Es sind aber die Teams, die ihren Weg hin zu diesem als sinnvoll empfundenen Ziel bestimmen.

Selbstorganisation und die damit verbundene Autonomie sind unabdingbar dafür, dass eduScrum auch seine Vorteile entfalten kann, denn durch die Autonomie übernehmen Schüler*innen zeitgleich auch Verantwortung und Ownership (Eigentümerschaft) für ihr Produkt, das heißt, sie fühlen sich commited und motiviert, ein qualitativ hochwertiges Produkt herzustellen. Zugleich verabschiedet sich die Lehrperson von der Vorstellung, sie wisse am besten wie Schüler*innen etwas zu lernen hätten.

Besonderheiten von eduScrum  

Die Größe und Zusammensetzung der Teams

Die Teams aus Lernenden sollten in eduScrum ungefähr vier Personen zählen. Die Schüler*innen sollten in die Teambildung zwar einbezogen werden, es ist aber zentral, dass sich nicht Teams aufgrund von Freundschaften, sondern aufgrund von Kompetenzen bilden. Scrum legt den Fokus stark auf das Team, das ein Produkt erarbeiten soll und weniger auf die einzelnen Individuen, die das Team bilden. Der Grund liegt in der wissenschaftlich gut gestützten Annahme, dass es für das Gelingen eines komplexen Projektes die viel wesentlichere Frage ist, wie die Individuen miteinander interagieren, als wer sich in diesem Team befindet.  

Der Product Owner legt also zunächst fest, welche Kompetenzen zur Erreichung der Ziele notwendig sind, damit die Teams dann entsprechend der Kompetenzanforderungen gebildet werden können. Im Scrum ist die Rede von «cross-functional teams». Die Idee ist – an einem konkreten Beispiel aufgezeigt – dass wenn in einer Klasse Lernvideos zu unterschiedlichen Theorien der Evolution erschaffen werden sollen, nicht jeweils alle IT-Cracks, alle Biologie-Affinen und alle Schüler*innen mit einer gepflegten Sprechstimme untereinander Teams bilden. Der Product Owner muss das Teambuilding in solch einer Weise leiten, dass sich Teams bilden, die über alle notwendigen Kompetenzen, Charaktereigenschaften, Ressourcen, oder Fachwissen verfügen, um die gesteckten Ziele erreichen zu können.

Die Rollen in eduScrum

Wie bereits mehrfach beschrieben entspricht der Product Owner in eduScrum der Lehrperson. Sie ist verantwortlich dafür unmissverständlich zu klären, welche Lernziele die Teams aus Schüler*innen erreichen müssen und warum diese Lernziele überhaupt von Bedeutung sind. Zusätzlich übernimmt die Lehrperson – und hier liegt ein wichtiger Unterschied zu Scrum – auch Aufgaben dessen, was in Scrum der Scrum Master ist. In Scrum ist der Scrum Master eine eigene Rolle, die strikt vom Product Owner getrennt ist. In eduScrum wäre diese Trennung nicht sinnvoll. Der eduScrum Master leistet verschiedene Dienste, die im eduScrum Guide festgehalten sind. 

Die wichtigsten Aufgaben sind, dass der eduScrum Master einerseits als Schnittstelle zum Product Owner fungiert und andererseits dafür sorgt, dass das eduScrum-Board aktualisiert bleibt und so einen unverfälschten Einblick in den Arbeitsprozess ermöglicht. Eine Aufgabe, die in Scrum der Scrum Master, in eduScrum aber der Product Owner übernimmt ist die Förderung des Arbeitsprozesses in den Teams und die Beseitigung allfälliger Hindernisse.

Das Product Backlog

Das Product Backlog entspricht einer Liste von Lernzielen, die der Product Owner den Bildungsplänen eines Faches entnimmt und für die Schüler*innen aufbereitet. Im Gegensatz zu Scrum, wo das Product Backlog nie vollständig ist, sind in eduScrum die Lernziele schon im Vorhinein bekannt. «Der Product Owner ist…» – so hält der eduScrum Guide fest – «…für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich.» Der Product Owner stellt den Teams vor Beginn eines Sprints das Product Backlog zur Verfügung, sodass die Teams dann mit der Priorisierung und Planung beginnen können. 

Die Lernziele im Product Backlog werden im Idealfall als sogenannte «User Stories» verfasst (siehe unten). User Stories sind «Nutzergeschichten», die eine Aufgabe produktorientiert und aus Sicht des Users beschreiben und sind somit nicht mit Tasks (Aufgaben) zu verwechseln. Es ist jedoch üblich, dass die Teams zu den User Stories selber Tasks anfertigen.

Es braucht eine neue Kultur

Die Hauptschwierigkeit in der Einführung von eduScrum in den eigenen Unterricht besteht aber nicht darin, die Prozesse, Ereignisse und Artefakte originalgetreu gemäß «eduScrum Guide» zu übernehmen. Die Hauptschwierigkeit ist vielmehr, dass im Unterricht ein Kulturwandel stattfinden muss. Wenn sich sowohl bei den Schüler*innen, als auch bei den Lehrpersonen nicht ein neues Mindset einstellt, ist eduScrum, trotz der Genialität dieses Ansatzes, zum Scheitern verurteilt. Für die Lehrperson bedeutet das neue Mindset, allem voran sechs wichtige Punkte zu beachten:

eduScrum benötigt einen respektvollen Umgang im Team

Der respektvolle Umgang mit anderen muss von Kindern und Jugendlichen aber teilweise noch erlernt werden – unter anderem deswegen gehen sie auch zur Schule. Das heißt, dass ein erster Schritt sein muss Teamarbeit überhaupt zuzulassen. Dann können Reibungen, Widersprüche und Unstimmigkeiten auftreten, von denen Schüler*innen lernen und an denen sie wachsen können. Von Schüler*innen kann kein respektvoller Umgang erwartet werden, wenn sie in Unterrichtsformen sozialisiert wurden, die praktisch nie Teamarbeit erforderlich gemacht haben. 

In eduScrum werden komplexe Probleme bearbeitet; diese bedingen Kollaboration

Viele relevante Probleme zeichnen sich durch ihre Komplexität aus. Und komplexe Probleme lassen sich selten von einer einzigen Person bewältigen. Das ist ein Grund, weshalb es so wichtig ist, dass wir Lehrpersonen Kinder und Jugendliche dazu befähigen miteinander zu arbeiten, um ihre unterschiedlichen Begabungen und Talente zu bündeln. Wir müssen jedoch darauf acht geben, dass sich im Unterricht nicht primär Teams aus Schüler*innen bilden, die sich besonders gut mögen, sondern «cross-funktionale» Teams, die in der Summe über jene Kompetenzen und Fertigkeiten und jenes Fachwissen verfügen, das nötig ist, um ein solches komplexes Problem zu bewältigen.

In eduScrum wird kein finales Produkt erschaffen, das Team tastet sich iterativ und inkrementell an eine Lösung heran

In eduScrum wird von den Teams erwartet, dass sie möglichst rasch eine rudimentäre Version ihres Produktes erstellen, das sie der Kritik des Product Owners und der Klasse aussetzen. Es geht also nicht darum, sich in ewige Planungssitzungen zurückzuziehen und im Geheimen an einer genialen Lösung für ein Problem zu arbeiten, stattdessen soll die Arbeit in kleinen und transparenten Schritten ablaufen, die jeweils zur Weiterentwicklung des Produktes führen. Im Vergleich zu dem, was Schüler*innen üblicherweise gewohnt sind, sind das komplett neue Spielregeln. Es ist wichtig, dass die Lehrperson diese neuen Spielregeln sachte aber klar einführt. Der Grundsatz soll lauten, dass die Projektarbeit in eduScrum eine stetige Verbesserung zulässt, ja sogar fordert. 

eduScrum benötigt eine tolerante Fehlerkultur

«Fail fast so you can fix early.», schreibt Jeff Sutherland und diese Devise muss man sich als Lehrperson zu Herzen nehmen. Die Arbeit in eduScrum bedingt sozusagen, dass die Teams rasch Lösungen für Produkte erarbeiten, die sie Tests unterziehen und somit müssen die Schüler*innen darin bestärkt werden, dass Fehler per se nichts Schlechtes, sondern notwendige Schritte auf dem Weg hin zu einem gelungenen Produkt sind. Im Unterricht herrscht häufig das Gegenteil einer toleranten Fehlerkultur, weshalb sich Schüler*innen zunächst auch nicht daran gewöhnt sind, Fehler machen zu dürfen. 

In eduScrum müssen die Schüler*innen Ownership erfahren

Nebst der Definition des «Was» muss der Product Owner auch dafür sorgen, dass er die Schüler*innen davon überzeugen kann, dass (und warum) es sinnvoll ist, die gewählten Lernziele zu erfüllen. Dadurch kann er deren intrinsische Motivation steigern. Lässt er den Teams, wie in eduScrum vorgeschrieben, zusätzlich den Raum, eigene Wege hin zu den Zielsetzungen einzuschlagen, so werden die Schüler*innen sich auch mit dem Produkt, das entsteht, zu identifizieren beginnen. Kaum eine Schüler*in wird sich mit einem Lückentext identifizieren können. Mit einem kollaborativ erarbeiteten Essay, einem Theaterstück, einem Zeitungsartikel, einem Kino-Trailer, einem Song oder einem Spiel hingegen sehr wohl.

In eduScrum muss Feedback gelebt werden

Der letzte Punkt ist ein Aspekt, dessen Bedeutung schon mehrfach betont wurde. Das Unterrichtszimmer in eduScrum muss zu einem Ort werden, an dem Feedback auf allen Ebenen gelebt wird. Feedback von den Lehrpersonen, Feedback von Mitschüler*innen, Feedback von sich selber (Selbstreflexion).

Auch in einem Unterricht nach eduScrum wäre es möglich gewesen, dass Marwin-Tristan und Jovita die gleichen Fehler begangen hätten: dass Jovita im Vortrag zu leise gesprochen und Kevin-Tristan zu stark abgelesen hätte; dass die Folien zwar schön, der rote Faden in der Präsentation aber nicht klar genug erkennbar gewesen wäre. Allerdings hätten sie diese Mängel viel früher festgestellt. Und sie hätten an den Mängeln arbeiten können. In eduScrum hätten die Teams nämlich – durch das Unterrichtssetting erzwungen – rasch eine frühe Version ihres Vortrages erstellt und zeitnahe Peers oder der Lehrperson gezeigt oder gar vorgeführt. Ihr Vortrag wäre lange vor dem Vortragstermin auf den Prüfstand gestellt worden und Jovita und Marwin-Tristan hätten Antworten auf Fragen von fundamentaler Bedeutung erhalten:

• Spreche ich laut genug?
• Ist meine Präsentation gut gestaltet?
• Verwende ich viele Füllwörter?
• Langweile ich das Publikum?
• Ist die Präsentation zu schwierig, zu einfach, genau richtig?

Die Rückmeldungen auf diese und ähnliche Fragen wären es gewesen, die Jovita und Marwin-Tristan sowohl in ihrem Produkt, wie auch in ihrem Arbeitsprozess weitergebracht hätten. 

Quellen

• Wijnands, Willy, et al. «eduScrum Guide.» eduScrum Homepage, Der eduScrum Guide, Sept. 2015, eduscrum.nl/en/file/CKFiles/Der_eduScrum_Guide_DE_1.2.pdf
• Sutherland, Jeffrey Victor. Scrum: the Art of Doing Twice the Work in Half the Time. Random House, 2019.

---

Zum nächsten Kapitel…