Erprobte Methodenbeispiele
Viele Quellen, die sich mit agiler Lehre beschäftigen, enthalten Beispiele aus dem Informatik-Studium und anderen technischen Fächern. Dies ist damit zu erklären, dass Agilität als Prinzip und z.B. Scrum als Rahmen für agile Projektsteuerung aus der Softwareentwicklung stammen. (Krehbiel et al. 2017) Gleichzeitig können die genutzten Methoden sowie die weiter oben beschriebene Haltung der Studierendenzentrierung auf andere Fächer übertragen und angepasst werden. Wichtig: Wenn Sie agile Herangehensweisen nutzen möchten, müssen Sie diese nicht explizit mit den Begriffen aus der Softwareentwicklung benennen. Vielmehr könnte es zu Ihrem Fach passend sein, ein anderes Vokabular zu nutzen (Krehbiel et al. 2017, S. 103).
Zusammenarbeit organisieren
(Virtuelle) Kanban-Boards eignen sich hervorragend, um anstehende Aufgaben für Teams sowie deren Erledigung durch Teammitglieder sichtbar zu machen. Kanban-Boards schaffen Transparenz, ermöglichen es den Stand eines Prozesses zu verfolgen, und ermöglichen eine fortlaufende Reflexion über Kursinhalte und den Lernprozess (Krehbiel et al. 2017, 98 f.).
Für den Einstieg in Lernsettings eignen sich sogenannte „Ice Breaker“, die Studierende in den Austausch miteinander bringen und so Vertrauen schaffen. Auch „social contracts“, also gemeinsam aufgestellte Regeln für die Zusammenarbeit in der Lehrveranstaltung, sind geeignet für agile Settings (Krehbiel et al. 2017, 99). Häufig werden für die Arbeit in Teams spezifische Rollen verteilt und bestimmte Besprechungsformate genutzt (mehr dazu im Abschnitt zur Nutzung von Scrum in der Lehre).
Lernprozess betrachten
Agile Ansätze folgen häufig einem „fail fast approach“ (Krehbiel et al. 2017, 102): schnell ein erstes Ergebnis produzieren, und dieses stets verbessern. Die dahinter liegende Idee eines iterativen Vorgehens entspricht der wissenschaftlichen Herangehensweise, in der Erkenntnisse immer wieder hinterfragt werden und weiter geforscht wird. Insofern passen agile Denkweisen zum Wissenschaftssystem, auch wenn das Tempo bewusst ein anderes ist. Für den studentischen Lernprozess ist der iterative Charakter sehr gut geeignet. Denn die Diskussion von Ergebnissen mit dem Ziel, sie immer weiter zu verbessern, unterstützt den Lernprozess (vor allem dann, wenn Fehlerfreundlichkeit gegeben ist).
Für die an ihren Universitäten durchgeführten Lehrveranstaltungen haben Krehbiel et al. (2017) Studierende in quantitativen Befragungen um Einschätzungen zu ihrem Lernprozess gebeten. Dabei kam u.a. heraus, dass die Lernenden positive Effekte erkennen: „Most students agreed that the use of Agile contributed to “`a more effective learning experience”´ and supported a “`more efficient use” ´of their time. A clear majority likewise found that Agile techniques enhanced the quality of their class project deliverables.“ (2017, 104) Auch berichten die Autor*innen aus strukturierten Kleingruppengesprächen mit Lehr-Kolleg*innen, dass viele den Einsatz agiler Methoden unterstützten und sehr zufrieden seien mit den studentischen Leistungen (ebd., 105)
Zusammenarbeit reflektieren
Das am häufigsten gewählte Mittel, um bei der Verwendung agiler Ansätze in der Lehre die Zusammenarbeit zu reflektieren, sind Retrospektiven (auch Retros). So werden Besprechungen in Teams genannt, in denen es darum geht, über die Zusammenarbeit zu sprechen und sie so weiter zu verbessern. Auch wenn Sie als Lehrperson nicht erwarten dürfen, dass mit einmaliger Anwendung alle Studierenden zu Teamplayern werden, lohnt es sich, diesen Weg zu verfolgen, wie Rush et al. beispielhaft aus studentischen Rückmeldungen zu einer Lehrveranstaltung festhalten: „These responses suggest that effective self-governance was not achieved on their first attempt, but that students persisted in their refinements, and even at the end of the semester, were considering ways to improve the experience.“ (2020, 205)
eduScrum
Bei eduScrum handelt es sich um die Übertragung des Scrum-Frameworks für agile Projektsteuerung auf Lehr-Lern-Settings in der Hochschulbildung. „Es verbindet klare Rollen (z. B. Product Owner, eduScrum-Master, Team), Artefakte (Backlogs, Definition of Done) und Ereignisse (Planning, Reviews, Retrospektiven) mit didaktischen Prinzipien der Erwachsenenbildung.“ (Sturm 2026, 51) Hier finden sich zentrale Prinzipien agilen Arbeitens wieder:
-
Transparenz
-
Selbstorganisation
-
Iteration
-
Feedback
Das bedeutet konkret: Studierende und Lehrperson haben stets Ziele, Erwartungen und Fortschritt im Blick, so dass ein „gemeinsames Verständnis der Lernziele und der dafür anstehenden Aufgaben“ entsteht (Sturm 2026, 51). Die bereits erwähnten Kanban-Boards können dabei sinnvoll sein. Und Sie als Lehrende*r können bei Bedarf unterstützen. Denn im Idealfall arbeiten die studentischen Teams selbstorganisiert, d.h. weitgehend eigenverantwortlich, um die vorgegebenen Lernziele zu erreichen. Sie als Lehrperson agieren eher als Lernbegleiter*in und geben den inhaltlichen Rahmen vor, ohne sich einzumischen in die Entscheidungen der Studierenden. Somit bewegen Sie sich im Spannungsfeld zwischen Vertrauen und Kontrolle stärker im Bereich des Vertrauens als in klassischen Lehrformaten.
Auch deshalb ist die Iteration sinnvoll, denn durch das Arbeiten in überschaubaren Zyklen (in der Sprache von Scrum „Sprints“ genannt) sorgt dafür, dass Teilergebnisse erarbeitet, überprüft und weiterentwickelt werden können. Kurze Iterationen (z.B. zwei bis vier Wochen) sind sinnvoll, damit die Studierenden aus Feedback lernen können. Dieses kontinuierliche Feedback ist das vierte wesentliche Prinzip, das z.B. in den erwähnten Retrospektiven stattfindet.
Sie als Lehrperson sind im Format eduScrum gefordert, die Gruppenarbeiten zu beobachten, um bei Bedarf zeitnah Anpassungen vor nehmen zu können. Ihr Feedback sollte sich dabei auf die inhaltlichen Lernprodukte als auch auf die Zusammenarbeit im Team beziehen.
SCRUM
Scrum ist ein agiles Framework zur Projektsteuerung, in dem der Fokus auf Teamarbeit, Transparenz und die kontinuierliche Anpassung an neue Anforderungen gerichtet ist. Es stammt aus der Softwareentwicklung. Ein Team besteht dabei klassischerweise aus festen Rollen. So gibt es eine*n Product Owner (vertritt die Interessen der Kundschaft oder Stakeholder, verwaltet die Liste aller Anforderungen und bestimmt die Prioritäten der Aufgaben), ein*e Scrum Master (unterstützt das Team dabei, Scrum richtig anzuwenden, beseitigt Hindernisse und sorgt für reibungslose Zusammenarbeit) und mehrere Developer (ein selbstorganisiertes Team aus Fachleuten, die gemeinsam die eigentliche Umsetzung und Erstellung des Produkts übernehmen). Sie alle agieren transparent, d.h. alle wichtigen Informationen und der Projektfortschritt sind jederzeit einsehbar, sie überprüfen regelmäßig Ergebnisse und Prozesse, um Abweichungen oder Probleme frühzeitig zu erkennen, und sie adaptieren den Prozess oder das Produkt, wenn etwas nicht wie gewünscht läuft oder sich Anforderungen ändern. Gearbeitet wird in Sprints, das sind kurze Zyklen von meist vier Wochen Dauer. Zu Beginn eines Sprints wird geplant, welche Aufgaben aus dem sogenannten Product Backlog im kommenden Sprint erledigt werden können, und diese werden im Sprint Backlog festgehalten. Während des Sprints treffen sich die Teammitglieder täglich kurz, um den Tag zu planen (Daily Standup), und am Ende des Zyklus gibt es zwei Meetings, deren Dauer von der Dauer des Sprints abhängt. Im Review geht es um den Inhalt, ggf. inklusive Stakeholdern für das Produkt, und in der Retro(spektive) schaut das Team auf die vergangene Zusammenarbeit zurück, um sich kontinuierlich zu optimieren.