Um den Ablauf für ein auf einem eduSprint basiertes Projekt zu testen, wollte ich ein Experiment durchführen. Innerhalb dieses eduSprints war es das Ziel, mit der Entwicklungsumgebung Sonic Pi zu arbeiten. Sonic Pi ermöglicht einfache oder komplexere Musikproduktion auf Basis der Programmiersprache Ruby. Ich definierte drei Lernziele als Items im Backlog, erstellte vor dem Workshop ein Wiki mit Informationen und Hilfen zur Erreichung dieser Lernziele und gab den Teilnehmenden eine kurze Einführung in (edu)Scrum.
Dann erarbeiteten sich die Teams ihre Lernziele und gaben am Schluss eine kurze Präsentation über ihre gewonnen Erkenntnisse und Produkte. Innerhalb eines Nachmittags konnte ich so einer Gruppe die Basics einer Programmiersprache vermitteln, ohne dabei klassischen Unterricht zu halten. Die Teams organisierten sich selbständig und übernahmen Verantwortung. Ich konnte also nicht nur Wissen vermitteln, sondern auch Selbst- und Teamkompetenz in einem realen und praxisorientierten Kontext fördern.
Wie kann ich innerhalb eines Nachmittags einer heterogenen Gruppe von Lernenden Freude an einer Programmiersprache vermitteln?
Die Methode wurde mit Jugendlichen unterschiedlichen Alters und Vorbildung getestet. Der Sprint wurde auf einen Nachmittag beschränkt. So konnten innerhalb kurzer Zeit die wichtigsten Aspekte dieser Methode eingesetzt werden. Einige der Jugendlichen waren schon mit Programmiersprachen vertraut, andere hatten sich noch gar nicht damit beschäftigt. Das unterschiedliche Vorwissen der Jugendlichen, sowie die beschränkte Zeit (für Durchführung und Vorbereitung) waren die grössten Herausforderungen.
Einen eduSprint zum Kennenlernen einer Programmiersprache durchzuführen, bietet sich aufgrund der logischen Struktur des Programmierens besonders an. Ich arbeitete mit nur drei Lernzielen (Backlogs), von denen zwei bis zum Ende des Nachmittags für jedes Team gut erreichbar waren. Der Aufwand für die Erstellung des Wikis und die Priorisierung / Gewichtung der Backlogs hielt sich aufgrund der kurzen Dauer des Workshops in Grenzen. Die Teameinteilung, die Vorbereitung des Raums und die technische Infrastruktur konnte ich vor dem Workshop vorbereiten. Mit den Teams machte ich als Erstes eine Einführung in Scrum und dessen Anwendung im Bildungskontext, da vielen dieses Konzept noch neu war. Die Motivation seitens der Teams war von Anfang an sehr hoch. Dies liegt wahrscheinlich daran, dass sie in diesem Umfeld eigenverantwortlich lernen und die Inhalte nicht präsentiert bekommen.
Die Teams überlegten sich dann kurz ihr vorgehen, richteten sich ihre Arbeitsplätze ein und studierten die Backlogs auf den vorbereiteten Flipcharts. Währenddessen übernahm ich meine Rolle als Product Owner und klärte Fragen, half bei der Orientierung der Teams und arbeitete dabei mit dem Scrum Master des jeweiligen Teams zusammen. Die Teams erarbeiteten die Backlogs und hielten am Ende des Nachmittags eine Kurzpräsentation. Wir machten ein Debriefing; die allgemeine Stimmung war während des Nachmittags sehr konzentriert und das Feedback am Schluss positiv.
- Präsenz von Lehrpersonen regulieren (je mehr Anwesenheit, desto mehr direkte Fragen)
- Aufwand für Ersterstellung klein, Aufwand während Durchführung gross
- Eine Methode für Scrum-Einführung wäre ein möglicher nächster Schritt
- Erste Erfahrungen mit Scrum wichtig für Lehrperson
- Schüler*innen / Lernende lernen schon früh über Scrum, was ein wichtiger Vorteil für das spätere Berufsleben sein kann
- Für die Einführung in eduSprint sollte genügend Zeit zur Verfügung stehen
- Für viele Situationen geeignet, evtl. nicht nur im Bildungskontext
