Ein Gastbeitrag von Tom Mittelbach
Das Vorgehen in der Praxis
Ganz zu Beginn spielen wir ein Spiel, welches den Wert von Teamarbeit verdeutlicht (und dabei auch noch sehr viel Spaß macht): Jedi21.
Danach führen wir eine praktische Übung durch, die erste Erfahrungen mit dem iterativen Vorgehen ermöglicht: Das Pizzagame.
Dann steigen wir direkt in Scrum ein und ich händige den Lernenden das Backlog aus.
Das Backlog umfasst das von mir (Stakeholder/Auftraggeber:in) geforderte Produkt und zusätzliche Erklärungen als Akzeptanzkriterien und unter Umständen als sogenannte userstories. In der Schule gebe ich das Backlog analog in Papierform und als Onlinevariante heraus. In das Backlog schreibe ich zusätzlich noch Informationen zum Ablauf von Scrum sowie Erklärungen zu den einzelnen Rollen im Scrum Team. Somit werden die Schüler:innen in die Lage versetzt etwaige Nachfragen selbst zu klären.
Das Backlog ist die Grundlage für die folgende Arbeit in den Scrumteams. Die Inhalte des Backlog – die Ausführlichkeit oder eben die Knappheit der Informationen – bestimmen, wie sehr die Lernenden geleitet werden oder wie frei sie arbeiten können. Je mehr Informationen und Anforderungen, desto weniger Freiheit in der Arbeit und mehr Orientierung. Je weniger Kriterien und Anforderungen, desto mehr Freiheit und selbstbestimmtes Arbeiten. Das ist abhängig von der Zielgruppe und den individuellen Bedingungen an der Schule.
Ein Beispiel eines Backlog kann man hier finden.
Nach dem gemeinsamen Verstehen der Inhalte im Backlog folgt die Zusammenstellung der crossfunktionalen Teams. Dies erfolgt bestenfalls durch Selbsteinschätzung der Schüler:innen, die Einteilung kann beispielsweise durch solche Rollenkarten erfolgen.
Nach der Zusammenstellung der Teams erfolgt die Erläuterung der Aufgaben der einzelnen Rollen: Product Owner, Scrum Master und Developer (alle sind Ergebnisverantwortliche).
Anschließend planen die nun zusammengestellten Scrum Teams eigenverantwortlich und autonom im Sprintplanning die Arbeitsschritte und Zuständigkeiten, die ihrer Meinung nach notwendig sind, um das im Backlog formulierte Ziel erfolgreich zu erreichen. Diese Arbeitsphase nenne ich das sogenannte „Juwel“ des framework Scrum. In dieser Arbeitsphase machen sich Schüler:innen Gedanken über die benötigten Arbeitsschritte, bevor sie in die Arbeit einsteigen. Dies erfordert eine intensive Auseinandersetzung mit dem Lerngegenstand, möglichen Herausforderungen und/oder Schwierigkeiten und es kommen Themen und Notwendigkeiten auf den Tisch, die sonst vielleicht gar nicht an die Oberfläche gelangt wären. In diesem Arbeitsschritt werden auch die vom Team formulierten Schritte bewertet. Die Bewertung erfolgt nach Aufwand und Schwierigkeit entweder in einfacher Art und Weise durch T-Shirt-Größen oder in aufwändiger Art und Weise durch den Einsatz von Planning Poker. Bei der Verwendung von Planning Poker besteht dann zudem die Möglichkeit der Visualisierung der Arbeitsschritte durch den Einsatz der Burn-down-Chart.

Im Sprintplanning definieren die Teams ihre Definition „of done“ in Bezug auf das Produkt. Sie definieren, wann das Produkt ihrer Meinung nach fertig ist. Das kann beispielsweise der Zeitpunkt sein, zu dem das Produkt vor der Abgabe auf Rechtschreibfehler überprüft wird.
In der Definion „of fun“ definieren die Teams, wie sie es schaffen können, mit Freude zusammen zu arbeiten.
Die vom Team definierten Arbeitsschritte (inklusive Bewertung und Verantwortlichkeit) werden vom Scrum Master in das Scrumboard eingetragen. Dafür verwende ich ein Kanbanboard. Alle Arbeitsschritte stehen in der Spalte „Zu erledigen“.
Alle Festlegungen sind variabel und können in der Arbeitsphase bei Bedarf angepasst werden. Eine Überprüfung findet immer in den Meetings statt.
Dann beginnt die iterative Arbeitsphase, der Sprint. Ein Sprint läuft immer gleich ab:
Im Stehen bespricht das Team unter Moderation des Scrum Masters die drei W-Fragen:
Was habe ich getan, um mein Team beim Erreichen des Ziels zu unterstützen?
Was werde ich heute tun, um mein Team beim Erreichen des Ziels zu unterstützen?
Was für Herausforderungen sehe ich mir gegenüber, welche Probleme habe ich?
In dieser Phase arbeiten die Schüler:innen selbstständig und autonom entsprechend ihrer Planung an ihren Arbeitsschritten. Sollte ein Arbeitsschritt fertiggestellt werden, wird er im Scrumboard von „In Arbeit“ auf „Erledigt“ verschoben. Diese Arbeitsphase muss weit gedacht werden. Es ist (fast) alles erlaubt. Warum sich nicht im Sozialraum informieren oder eine Fachperson anrufen? Auch hybride Settings sind möglich und durchführbar.
In diesem Meeting schaut das Team auf den IST-Stand des Produkts. Der Product Owner ist die verantwortliche Person, die den aktuellen Stand des Produkts abnimmt, das heißt genehmigt. Normalerweise erfolgt nach jedem Sprint auch eine Retrospektive, in diesem Meeting wird die Kommunikation und die Zusammenarbeit im Team thematisiert und verbessert. Dieses Meeting integriere ich in die Review, da oft nicht genügend Zeit für ein eigenes Meeting besteht. Das bedeutet also für die Review: Wie ist der Stand des Produkts und kann in der Kommunikation und Zusammenarbeit etwas verbessert werden?
Je nachdem wie umfassend das Lernziel (Produkt) oder wie die Lehrkraft den zeitlichen Umfang definiert, finden meist zwischen vier und sechs Sprints statt. Natürlich kann nach oben und nach unten skaliert werden. Ob ein Sprint eine Doppelstunde oder drei Schulstunden umfasst oder einen ganzen Tag im Rahmen einer Projektwoche, das sind individuell zu planende Gegebenheiten.
Am Ende steht dann die termingerechte Abgabe des Produkts und eine umfassende Retrospektive, in der mit allen Schüler:innen gemeinsam auf die Zusammenarbeit geschaut wird.
Scrum ist eine sehr gute Methode, die den Unterricht verändert und bereichert. Das framework schafft Leitplanken, in deren Rahmen die Schüler:innen das Zu- und Vertrauen erhalten, mit Kopf, Herz und Hand mithilfe ihrer Kompetenzen, Erfahrungen und Interessen gemeinsam mit einem Team einen Lernweg zu gehen, den sie selbst definieren.
Weitere | Angebote zum Thema |
---|---|
„Scrum in die Schule!“, visual books, Herausgeber Tom Mittelbach | https://visual-books.com/scrum-in-die-schule |
Kuratierte digitale Sammelmappe | https://wakelet.com/wake/1d5Q7tiE3i9ZchwP2Bt6h |
Podcast Retrospektiv | https://podcasts.apple.com/de/podcast/retrospektiv/id1618602905 |

Tom Mittelbach ist Fachoberlehrer in Baden-Württemberg und in der Lehrerfortbildung tätig. Agilität in der Bildung ist für ihn eine Selbstverständlichkeit, im Jahr 2020 hat er das Buch „Scrum in die Schule!“, ein gemeinschaftliches kollaboratives Buchprojekt, herausgegeben. Tom Mittelbach gibt im DACH-Raum Fortbildungen zu Scrum in der Bildung, Design Sprints und Agilität, auch plant und moderiert er Barcamps. Er ist Autor und Podcaster, unter Anderen mit dem Podcast “Retrospektiv”, der sich mit Agilität in der Bildung beschäftigt. Kontakt und weitere Infos zum Angebot: tommittelbach@web.de