Agiles Lernen

Im November haben die Bildungspunks als Thema “Agiles Lernen” gewählt. Als jemand, der im Bildungsbereich und in der Elternvertretung engagiert ist und beruflich auch im Bereich der Softwareentwicklung zu tun hat, bin ich der Meinung, dass die Verwendung einiger Begriffe und Konzepte aus dem agilen Bereich im Bildungssektor der genaueren Betrachtung bedürfen.

Agiles Lernen?
Gelernt wurde doch schon immer – warum muss das jetzt agil sein?

Lernen

Gleich zu Beginn eine provokante These: es gibt einen Unterschied zwischen dem Ergebnis von Lehren und dem Ergebnis von Lernen. Nicht jede auf der Empfangsseite einer Lehrveranstaltung wird an deren Ende auch alles Erwähnte auch gelernt haben (sonst würde das Konzept des Nürnberger Trichters ja auch prächtig funktionieren).

Lernen hingegen erfordert die Motivation dazu. Habe ich keine Lust, mich damit zu beschäftigen, dass die Summe der Winkel in einem Dreieck immer 180° ergibt, kann man mir das fünf Mal lehren, hängen bleiben wird nichts. Erst wenn ich den Nutzen sehe, den mir dieses Wissen bringt, dann werde ich auch lernen.

Was auch einige der “Herausforderungen” erklärt, denen sich Lehrerinnen und Lehrer ausgesetzt sehen, wenn die Klasse gerade nicht einsieht, sich damit zu beschäftigen, dass die Summe der Winkel in einem Dreieck immer 180° ergibt 😄 …

Aber das ist ein anderes Thema. Dieses Mal geht es um das “agile” beim Lernen.

Agilität

Die pädagogische Zunft ist recht eifrig dabei, diesen agilen Ansatz für den Unterricht zu übernehmen, schießt aber im Eifer des Gefechts aber gerne über das Ziel hinaus. Mehr als einmal stellen sich mir die Nackenhaare auf, wenn ich Erklärungen lese, bei denen Scrum munter mit Kanban gemischt, vorgegebene Strukturen bei Scrum eingeführt und andere Dinge geschrieben werden, die auch in den Beiträgen dieser Blogparade auftauchen. Abgesehen davon, dass agile Ansätze ihre historische Wurzel gar nicht komplett in der Software-Welt haben und durch die Übernahme in Bereich ausserhalb der Softwareentwicklung jetzt wieder in Ursprungsbereiche zurück kehren (Stichwort Toyota Kanban, Deming & PDCA und andere), sind meiner Meinung nach ein paar Zeilen zur Klärung von Begriffen und vor allem dem “Warum?” angebracht. Ich bin mir darüber im Klaren, dass Dinge für den Einsatz in der Bildung angepasst werden können (und müssen), aber fröhlich völlig neue Bedeutungen für eingeführte Begriffe zu definieren, führt beim Kontakt von SuS (und auch LuL bei Besuchen in der Wirtschaft) zu Verwirrung und Frustration. Also lassen Sie uns ein paar Büsche abklopfen …

Zuerst einmal bedeutet Agilität nichts anderes als die Reaktionsfähigkeit auf veränderte Anforderungen zu erhöhen. Provokante Frage: muss Lernen in der Schule dann überhaupt agil sein? Schließlich gibt es ein fixes Curriculum, dass sich zumindest innerhalb eines Schuljahres nicht ändern wird. Damit ist auch das Ziel festgelegt. So gesehen lässt sich natürlich diskutieren, ob Agilität im Schulbetrieb wirklich notwendig ist. Muss nun plötzlich alles “agil” sein? Die Wahrheit ist: nein, muss es nicht und ja, war oft schon sehr lange, wurde aber nur anders genannt. Auch die Ideen, die 2001 im Agile Manifesto festgehalten wurden, fielen ja nicht vom Himmel. Eines der ältesten Zitate aus der Industrie zum Thema iteratives und schrittweises Vorgehen ist

Nothing is particularly hard if you divide it into small jobs
– HenryFord

Wer meine Blogposts liest, weiß, dass ich ein Anhänger des Standpunktes “je krasser, desto Beispiel” bin. Das agile Konzept hat mir vor Jahren mal jemand so erklärt: “wenn ich ein Ziel treffen möchte, kann ich meinen Standort und den des Ziels bestimmen, Winkel und Geschwindigkeit meines Projektils messen, den Wind einkalkulieren, ein paar Formeln berechnen und dann hoffen, dass alles glatt geht. Oder aber ich lade alle paar Projektile Leuchtspurmunition und bewege den glühenden Streifen dann einfach ins Ziel”.

Dieses Beispiel zeigt einige Dinge:

• Agil ist nicht das Gleiche wie selbstgesteuertes Lernen. Ich kann eine Haubitze und eine Maschinenkanone selbst bedienen.
• Agil ist nicht das Gleiche wie willkürliches Lernen. Ohne Zielvorgabe und Zielplanung kommt kein Treffer zustande.
• Agil ist nicht das Gleiche wie arbeitsteiliges Lernen. Bei beiden Ansätzen kann Laden und Schießen durch verschiedene Personen erfolgen.
• Abnehmendes Kaliber bedeutet schnellere Schußgeschwindigkeit: verschieße ich weniger auf einmal, kann ich schneller schießen und dazwischen auch neu zielen.
• Die Auswirkungen eines Treffers werden mit abnehmendem Kaliber geringer. Ein einzelner Schuß reicht nicht aus, es muss “iterativ” vorgegangen werden.

Aber genug rumgeballert um des krassen Beispiels Willen, kommen wir zum Punkt.

Kanban, Scrum, Agil – ist doch alles das Gleiche…

Eine Klarstellung gleich zu Beginn: Kanban ist nicht das Gleiche wie Scrum. Ja, beide Ansätze arbeiten oft mit Whiteboards, an denen Zettelchen kleben, aber das rechtfertig nicht das bunte Vermischen dieser beiden Ansätze. Bei Kanban geht es vor allem um Durchfluss und das Vermeiden unproduktiven Multitaskings. Dies geschieht unter anderem durch das Setzen eines sog. “WIP-Limits” (work in progress). Eine neue Aufgabe darf erst dann begonnen werden, wenn eine andere beendet wurde und die Zahl der Aufgaben, an denen gleichzeitig gearbeitet wird, darf nicht über diesem WIP-Limit liegen (meistens eine sehr kleine Zahl, z.B. 2 oder 3). Deshalb findet sich bei Kanban auch oft der Slogan “fang an, fertig zu werden und hör auf, anzufangen”. Kanban ist ein “pull”-System, das Überforderung durch das Zuweisen zu vieler Dinge auf einmal verhindern soll und einen gleichmäßigen, möglichst optimalen Prozess-Durchlauf garantieren soll. Dazu gehört auch das Messen und Optimieren des Arbeitsprozesses. Hinsichtlich eines Lernenden ist Kanban also eher ein “Schutzsystem”, dass Überforderung verhindern soll und sich an Prinzipien von “pull” und “Flow” orientiert.

Scrum hingegen ist eine Möglichkeit eines agilen Vorgehens. Der Begriff entstand als Gegensatz zum Staffellauf, dem Sinnbild für das klassische “Wasserfall”-Vorgehen, bei dem eine Folge von Phasen ohne Interaktion nacheinander abgearbeitet werden. Genau dieses Vorgehen führte bei großen Projekten immer wieder zu Problemen. Als Kontrast dazu wurde Scrum als das Gedränge eines Rugby-Teams verwendet, dass es zusammen in Eigenregie schafft, den Rugbyball ins Ziel zu bringen. Es gibt keine Vorgaben, das Rugby-Team organisiert sich selbst während des Spiels (jetzt kennen Sie auch den Grund für das Banner-Bild zum Post 😄). Während es über den historischen Ursprung von Scrums immer noch Diskussionen gibt, ist das Framework ausdefiniert. Seit 2009 allerdings gibt es mit der Scrum Alliance und scrum.org zwei Organisationen, die Zertifizierungen anbieten und sich nicht freundlich gegenüber stehen (wer mehr wissen möchte, kann hier nachlesen). Die Beliebtheit von Scrum im Bildungsbereich geht soweit, dass es sogar ein eduScrum® gibt. Hauptsache offiziell und zertifiziert… 😏

Es ist auch nicht so, dass agile Prozesse und Scrum synonym sind. Es gibt im Bereich der Softwareentwicklung mehrere agile Prozesse (vom oben genannten Kanban über Scrum und Extreme Programming zu Crystal und Behavior-Driven-Development). Eine der Kern-Erkenntnisse einer Beschäftigung mit dem Thema ist nämlich: “Agile” ist keine Methodik, sondern eine Haltung. Es ist ein Mindset, eine Art des Arbeitens und Vorgehens, viel eher einer Kultur. Das zeigt sich auch daran, dass das Agile Manifesto von Werten und Prinzipien spricht, also Begriffen, die eher mit einer Kultur als einem Werkzeug in Verbindung gebracht werden.

Daher lassen sich in der Vergangenheit des Themenfeldes Wissenserwerb und Projektarbeit durchaus Beispiele für ein agiles Vorgehen finden, die weit vor die Zeit um die Jahrtausendwende zurück reichen. Eines meiner Lieblingsprojekte, das amerikanische Mondlande-Programm, weist alle Anzeichen eines agilen Projektansatzes auf. Eine unbekannte Aufgabenstellung, ein “Produkt-Backlog”, schrittweises Vorgehen (bau eine Rakete, mache Sie stärker, unbemannte Missionen, bemannte Suborbitalmissionen, bemannte Orbitalmissionen, Mondflug), damit verbunden “inkrementeller Nutzen”, Anpassen an veränderte Anforderungen (die ersten schlechten Erfahrungen mit EVAs, das Apollo 1-Disaster, etc.), all das hat damals niemand “agil” genannt. Aber es war allen Projektbeteiligten klar, dass Sie (wie beim agilen Lernen) “Laufen lernen, während wir die ersten Schritte gehen”, wie es Christopher C. Kaft einmal formulierte. Diese Selbstorganisation und Ermächtigung anhand von Problemstellung und der Aufgabe, eigenständig zu einer Lösung zu kommen, war damals bei der NASA weit verbreitet, wie das folgende Zitat zeigt.

Another thing that was extraordinary was how things were delegated down. NASA responsibilities were delegated to people who didn’t know how to do these things, and were expected to go find out how to do it
– Howard W. Tindall Jr., Mission Technique Coordinator

Ein klassisches Beispiel aus dieser Zeit für “Ich definiere die Akzeptanzkriterien und wie Ihr zu einer Lösung kommt, ist Eure Sache” ist die Szene aus Apollo 13, in der die CO2-Filter aus dem Service-Modul mit denen des Landemoduls verbunden werden müssen:

All das zeigt auch die Problematik bei der Übertragung dieser Ansätze in den Bildungsbereich. Lernen ist im Bereich von Schule von beruflicher Ausbildung eben kein Projekt, sondern im aktuellen Zustand ein fixiertes Curriculum, dass sich eben schwer in einzelne Sprints zwängen lässt. Was sich auch daran zeigt, dass viele dieser Ausflüge in agile Gefilde eher am Ende des Schuljahres stattfinden. Bob Blume hat im Rahmen dieser Beitragsparade beispielsweise geschrieben: “Zunächst einmal muss ich sagen, dass ich nach dem Monat Arbeit sehr stolz auf die Ergebnisse war, die drei Tage vor Schuljahresende durchgeführt wurden, also ohne eine Möglichkeit, dass das Ganze in die Note eingehen könnte”. Das ist keine Abwertung, im Gegenteil ich bewundere Lehrer wie Bob für seinen Mut, im Web so offen über seine Arbeit zu schreiben. Es zeigt aber, dass es, sagen wir mal, gewisse “Herausforderungen” gibt, agile Ansätze im aktuellen Rahmen bildungspolitischer Vorgaben umzusetzen.

Damit zu einem weiteren Punkt, der gerne unterschätzt wird: der Wichtigkeit des Sprint Plannings. Hier werden aus dem Product Backlog die Punkte in das Sprint Backlog übernommen. Jawohl, es gibt zwei Backlogs! Das Product Backlog ist das Set an Anforderungen, die der Auftraggeber (product owner) für die Abnahme definiert hat. Diese Anforderungen müssen nun für einen Sprint in Stories herunter gebrochen und mit Aufwänden bewertet werden. Nachdem, was ich bis jetzt in Blogs von LuL gelesen habe, wird hier viel Potenzial nicht genutzt, denn in diesem Schritt zeigt sich auch, wie gut das Verständnis des Problemraums durch die Team-Mitglieder ist und wie entwickelt die Fähigkeit sind, den eigenen Kenntnisstand und die eigene Leistung einzuschätzen.

Software-Teams verwenden oft Planning Poker als Werkzeug. Es lohnt sich, sich mit dem Hintergrund des Werkzeugs zu beschäftigen, denn damit lassen sich viele gruppendynamische Aspekte einer solchen Aufwandsschätzung im Team behandeln. Ich habe bei vielen Einsätzen von Planning Poker eine Menge über Teams und das Einschätzung und Abschätzen von Problemen gelernt. Hier zeigt sich auch der Nutzen eines Coaches des Teams (dem scrum master bei Scrum), der durch entsprechend häufiges Feedback in der Lage ist, das Team weiter zu entwickeln. Je weniger Erfahrung ein Team hat, umso wichtiger ist der Feedback-Prozess, da gerade unerfahrene Team-Mitglieder sich dieser Unerfahrenheit weniger bewusst sind als erfahrene.

Zum Sprint selbst sei vor allem darauf verwiesen, dem Team auch die Eigenständigkeit bei der Erarbeitung zuzugestehen. Gerade deshalb sind “Dailies” so wichtig (und nein, die Tatsache, dass dies im Stehen passieren soll, ist nicht der Knackpunkt. Man kann ein “Daily” auch im Stehen verbocken. Wichtig ist der Grund für “Standup” statt “Meeting”, das gilt aber nicht nur hier). Es bringt eben nichts, wie ebenfalls in einem Beitrag der Blogparade gelesen, das so zu definieren: “Für jeden Sprint legt das Team fest, was wie in welcher Zeit von wem erarbeitet werden soll”. Scrum ist Scrum. Das Team entscheidet eigenständig, wie es seine Stories im Sprint abarbeitet (auch dazu dienen die daily standups) und der Scrum Master sorgt für die Beseitigung von Hindernissen. Alles andere ist eben nicht agil.

Am Ende eines Sprints gibt es bei Scrum zwei Ereignisse, die oft vermischt oder gleichgesetzt werden: Sprint Review und Sprint Retrospective. Beim Sprint Review zeigt das Team dem Product Owner das Ergebnis des Sprints. Da die Akzeptanzkriterien für eine Story während des Sprint Plannings definiert wurden, ist hier auch nicht nötig, über das Erreichen der Anforderungen zu diskutieren, da klar ist, ob diese erreicht wurden oder nicht.

Die Sprint Retrospective dient der Weiterentwicklung des Teams. Hier diskutiert das Team, moderiert vom Scrum Master, was gut gelaufen ist, welche Bereiche für Verbesserungen es gibt und welche neuen Erkenntnisse gewonnen wurden. Im Bildungsbereich ist dieses Meeting relativ wichtig, denn manche Bildungsorganisationen wechseln nach jedem Sprint die Zusammensetzung des Teams, um eben die Fähigkeit zu fördern, sich nach der Ausbildung auf wechselnde Team-Zusammensetzungen einzustellen. Da ist das Mitnehmen entsprechender Erkenntnisse, was gut funktioniert und wo Verbesserungen möglich sind, entsprechend wichtig.

Und das Lernen? Kann ich jetzt agil lernen?

Wozu dient Agilität? Warum wollen wir Feedback-Schleifen verkürzen, zerteilen wir Stories in Sprints, planen wir iterative Verbesserung und nicht den einen “großen Wurf”? Um Komplexität zu reduzieren, Überforderungen zu vermeiden und Unsicherheiten zu reduzieren. Um schneller reagieren zu können und schneller zu wissen, ob wir auf dem richtigen Weg sind.

Agile Lernmethoden eigenen sich dann vor allem, wenn ich Erkenntnisse jetzt brauche, nicht zu viel oder (aktuell) Unnötiges lernen möchte (es gibt in der agilen Softwareentwicklung das Konzept des YAGNI). Dennoch ist agiles Lernen nicht synonym zu selbstgesteuertem Lernen (das ging früher auch nicht-agil). Agiles Lernen ist aber auch nicht willkürliches, exploratives Lernen, denn es gibt Anforderungen des Product Owner, die erfüllt werden sollen.

Wo sich agiles Lernen aufgrund seines iterativen Charakters gut eignet, ist ein schrittweises Erarbeiten eines bestimmten Wissensniveaus. Hierfür startet das Product Backlog des Lernen mit einem (ich klaue den Begriff mal aus dem Bereich lean startup) Minimal Viable Product, also dem kleinsten Satz an Wissen und Fähigkeiten, der die Anforderungen erfüllt, z.B. dem elementaren Wissen über den Absolutismus oder über Räuber/Beute-Beziehungen. Nach der Präsentation der Ergebnisse im Sprint Review kann im nächsten Sprint Planning die inkrementelle Verbesserung geplant werden.

Dies ist der Grund, warum agiles Lernen im Bereich der beruflichen Bildung aktuell so beliebt ist. “Learning on the job”, also aktuelle Lernanforderungen zu erfüllen und schnell produktiv einzusetzen, hat aus Sicht der Personalabteilungen einen wirtschaftlichen Charme, dem sich kaum jemand entziehen kann. 😏

Zusammengefasst: ja, agiles Lernen macht durchaus Sinn, wenn nicht um jeden Preis versucht wird, jegliche Aufgabenstellung im Bereich der Bildung in ein agiles Schema zu pressen. Als Vorbereitung auf die Lebens- und Arbeitswelt, das ja originäre Aufgabe der Schule und anderer Bildungsinstitutionen ist, sollten agile Ansätze aber auf jeden Fall einen festen Platz in der Bildung haben.