Kitabı oku: «Agile Schule (E-Book)»

Peter Brichzin, Petra Kastl, Ralf Romeike

Agile Schule

Methoden für den Projektunterricht

in der Informatik und darüber hinaus

ISBN Print: 978-3-0355-1053-9

ISBN E-Book: 978-3-0355-1247-2

1. Auflage 2019

Alle Rechte vorbehalten

© 2019 hep verlag ag, Bern

www.hep-verlag.com

Inhalt

1.Einleitung

Schule entwickelt sich weiter

2.Hintergrund

Agile Kultur in Unternehmen und Schulen

2.1Geschichte und Entwicklung

2.2Agiles Arbeiten – ein Zusammenspiel aus Werten und Praktiken

2.3Unternehmen werden agil – Beweggründe und Erfahrungen

3.Im Unterrichtseinsatz

Erfahrungen mit agilen Schulprojekten

3.1Best Practice – das Spiel «Pengu»

3.2Im Anfangsunterricht durch Gestaltungsfreiräume begeistern

3.3In der Oberstufe komplexe Anwendungssoftware agil entwickeln

3.4Agile Softwareentwicklung als ganzjährige Lernmethode im Pflichtunterricht

3.5Ein geskriptetes Projekt als Methodik für den Anfangsunterricht

3.6Reflexionskompetenz stärken durch Weiterentwicklung des eigenen agilen Prozesses

4.Agiler Methodenkoffer I

Grundlegende Techniken und Praktiken

4.1Iterationen – der agile Prozess

4.2User-Storys – Anforderungen aus Kundensicht

4.3Das Project-Board – Planung und Stand im Blick

4.4Tasks – Arbeitspakete aus Entwicklersicht

4.5Stand-up-Meetings und andere Besprechungsformen

4.6Pair-Programming – Zusammenarbeit mit klarer Rollenverteilung

4.7Prototypen – funktionsfähige Produkte ab der ersten Iteration

4.8Agile Spiele – agiles Denken und Handeln erleben

5.Agiler Methodenkoffer II

Weitere Techniken und Praktiken

5.1Reflexion in Review und Retrospektive – Nachdenken über Inhalt und Prozess

5.2Timeboxing – fokussiert arbeiten in festen Zeitrahmen

5.3Testen – systematisch Qualität hinterfragen

5.4Feedback und Bewertung – Rückmeldungen zur Weiterentwicklung nutzen

5.5Dokumentation – Transparenz durch aufgezeichnete Absprachen

5.6Refactoring – Qualität verbessern und dabei lernen

5.7Aufwandsabschätzung – gemeinsam das Machbare ermitteln

5.8Repositorys und andere kollaborative Werkzeuge

6.Agile Methoden für alle

Schule agil gestalten

6.1Agile Methoden in Theorie und Praxis

6.2Agile Schule über den Informatikunterricht hinaus

Glossar

Einleitung

1

Schule entwickelt sich weiter

Schule prägt einen der wichtigsten Lebensabschnitte der Menschen. Von der Grundschule bis zum Abitur sammeln Schülerinnen und Schüler wichtige Erfahrungen, die sie für den Rest ihres Lebens prägen. Damit geht es in der Schule um mehr als nur um die Vermittlung von Wissen. Neben fachbezogenen Inhalten kommt auch allgemeinen Kompetenzen eine zunehmend größere Bedeutung zu, wie sich auch in Bildungsstandards und kompetenzorientierten Lehrplänen zeigt. Dazu gehören beispielsweise die Fähigkeiten, effektiv zu kommunizieren und zu kooperieren sowie Lern- und Problemlösestrategien zielgerichtet einzusetzen.

Projektunterricht als wichtige Unterrichtsmethode

Projektunterricht gilt als besonders dazu geeignet, das selbstgesteuerte, selbstorganisierte und kooperative Lernen der Schülerinnen und Schüler zu fördern. Hierbei wird typischerweise in für die Lernenden relevanten Kontexten die Anwendung fachbezogener und verschiedener allgemeiner Kompetenzen gefördert, bspw. Teamarbeit und die Planung selbstorganisierter Unterrichtsphasen.

Im Informatikunterricht haben Projekte darüber hinaus eine besondere Bedeutung, da sie hier nicht nur als Unterrichtsmethode fungieren, sondern zugleich auch einen Einblick in die meist in Projekten organisierte Berufsrealität der Softwareentwicklung ermöglichen.

Der klassische Projektunterricht ist in der Regel klar sequenziell strukturiert. Zunächst wird ein umfangreicher Plan aufgestellt, dann wird er realisiert. In der Praxis haben sich allerdings in den letzten 15 Jahren rasch agile Methoden, verbreitet, und zwar in kleinen wie großen Softwareunternehmen. Oft sind agile Teams besonders motiviert, sie arbeiten fokussiert, pflegen einen wertschätzenden Umgang unter den Mitgliedern und sehen Fehler als eine wichtige Möglichkeit, etwas zu lernen. Sie bestimmen ihren Weg zum Ziel selbst, reflektieren diesen regelmäßig und begreifen Veränderung als Chance. Die meisten Teams und Kunden, die einmal agile Luft geschnuppert haben, wollen nicht mehr zurück, weil sie nun flexibel auf Anforderungsänderungen und andere sich im Prozess ergebende Herausforderungen reagieren können. So verändern agiles Denken und Handeln die Unternehmenskultur, da mit ihnen eine Reihe zentraler Werte, wie offene Kommunikation auf Augenhöhe und Selbstverantwortung im Team, verbunden sind.

Betrachtet man als Lehrkraft die agilen Methoden etwas genauer, offenbart sich ihr didaktisch-pädagogisches Potenzial für die Unterrichtsgestaltung schnell: Die Praktiken und Techniken fördern und fordern Kommunikation im Team, unterstützen die Strukturierung der inhaltlichen Arbeit in gut bearbeit bare Teilziele und erleichtern die Mitgestaltung des Lernprozesses durch die Schülerinnen und Schüler. Kurze Zyklen sorgen schnell für erste Erfolgserlebnisse, die motivieren, regen aber auch zum Innehalten und Nachdenken über das Produkt und die Zusammenarbeit an: Was haben wir bis jetzt erreicht? Sind wir damit auf dem richtigen Weg? Was sind unsere nächsten Schritte? Was lief gut? Was wollen wir im nächsten Zyklus besser machen? Hierdurch wird Lernen auch zu einem wichtigen Prozessbestandteil.

Unser Erfahrungshorizont

In unserem Buch «Agile Schule» greifen wir das Potenzial der Agilen Werte, Praktiken und Techniken auf und machen sie für die Schule nutzbar. Das tun wir weder, weil es gerade angesagt ist, noch, um ein Agiles Coaching zu verkaufen oder die nächste Zertifizierung zu bewerben. Uns geht es darum, eine Begeisterung weiterzugeben, die uns selbst in unserer Arbeit mit agilen Methoden gepackt hat. Wir wollen zeigen, welchen Wert agile Methoden für den Unterricht haben können, denn mit unserer Begeisterung sind wir nicht allein. Das Buch basiert auf Erfahrungen und der langjährigen Begleitforschung zum Einsatz agiler Projekte in unterschiedlichen Schulen in ganz Deutschland. Mit den beteiligten Lehrkräften haben wir uns mehrmals im Jahr getroffen, um gemeinsam die Methoden weiterzuentwickeln und für die Schule hinsichtlich ihres didaktischen Mehrwerts anzupassen. Die so entstandene Agile Schule ist keine Blaupause, die als festgelegtes Projektmodell im Unterricht Schritt für Schritt befolgt werden muss. Vielmehr stellt sie einen Rahmen an Möglichkeiten dar, verschiedene Praktiken und Techniken den Unterrichtsanforderungen entsprechend zu verwenden und anzupassen. Der erste eigene Versuch ist selten perfekt und selbst wenn, so wird im Laufe der Jahre immer auch mal eine Schülergruppe ihr Ziel nicht erreichen. Wichtig ist es, sich in regelmäßigen Abständen die Frage zu stellen, was warum gut oder ungünstig verlaufen ist, und entsprechende Anpassungen vorzunehmen. Auch wenn es sich bei den meisten Beispielen um Erfahrungen aus dem Informatikunterricht handelt, beschränkt sich die Agile Schule nicht darauf. Es zeigt sich zunehmend, dass die Agile Schule auch in anderen Fächern oder Kontexten eine Bereicherung darstellen kann.

Zum Aufbau des Buchs

Im auf die Einleitung folgenden Kapitel 2 stellen wir die wesentlichen Hintergründe agiler Methoden dar und geben einen Einblick, wie unterschiedlich der Weg zum Einsatz agiler Methoden in Unternehmen gestaltet werden kann. Die in diesem Kapitel präsentierten Agilen Werte werden in den folgenden Kapiteln immer wieder aufgegriffen.

In Kapitel 3 wird ein Best-Practice-Beispiel vorgestellt, welches kompakt die Kernideen agiler Projekte illustriert. Im Folgenden berichten Lehrkräfte von ihren Motivationen und Umsetzungen agiler Projekte in unterschiedlichen Kontexten. Die Berichte zeigen, wie flexibel sich die Methoden, Techniken und Praktiken an die individuelle Unterrichtsgestaltung anpassen und neben fachlichen auch pädagogische Ziele umsetzen lassen.

Kapitel 4 enthält einen Methodenkoffer mit acht grundlegenden Praktiken und Techniken, ihrer theoretischen Fundierung, Varianten der schulischen Umsetzung, Stolpersteinen sowie Tipps und Tricks. Diese acht Methoden sind ein guter Einstieg in erste agile Projekte.

Kapitel 5 umfasst weitere acht Praktiken und Techniken. Sie dienen der methodischen Vertiefung.

In Kapitel 6 reflektieren wir die gewonnenen Erfahrungen aus wissenschaftlicher Sicht und skizzieren Möglichkeiten für den Einsatz agiler Methoden außerhalb des Informatikunterrichts.

Die Pfeile im Fließtext verweisen auf Methodenbausteine (bei ihrer Erstnennung), die weiterführende Informationen beinhalten. Das Glossar erklärt Begriffe aus der agilen Welt, die im didaktischen Kontext nur am Rande vorkommen. Weiter beschreibt es die wichtigsten Methoden.

Zum Einsatz dieses Buchs

Sie können dieses Buch zusammenhängend von vorn nach hinten lesen, aber auch als Nachschlagewerk für Agile Werte, Praktiken und Techniken in der Schule nutzen. Wenn Sie sich vor allem für konkrete Umsetzungsbeispiele interessieren, können Sie direkt mit den Praxisberichten in Kapitel 3 einsteigen. Sie beginnen alle mit einem Überblick über den Kontext, die Zielrichtung und den zeitlichen Ablauf des Unterrichtsprojekts. Sollten Sie nicht Informatik unterrichten, mag für Sie Kapitel 6.2 ein guter Start sein, da dort Unterrichtsbeispiele außerhalb der Informatik vorgestellt werden. Sie können Ihre Aufmerksamkeit auch erst den Agilen Werten widmen, da sie die Basis agilen Handelns und Denkens sind, und dann direkt zu den Methodenbausteinen springen. Den Baustein ↑ Iterationen – der agile Prozess empfehlen wir Ihnen, wenn Sie zunächst einen Überblick gewinnen möchten. Seien Sie sich beim Lesen aber bewusst, dass der agile Prozess nur als Ausgangspunkt für Ihren eigenen, auf den individuellen Kontext zugeschnittenen Prozess dienen soll. Es geht weniger um die perfekte Umsetzung des agilen Prozesses und der damit verbundenen Techniken und Praktiken als um die Schülerinnen und Schüler, die sich selbst organisieren, effektiv kollaborativ arbeiten und dabei wichtige projektbezogene Kompetenzen erwerben; die Lernenden stehen im Zentrum.

Dank

Ein Buch wie «Agile Schule» kann nicht ohne die Mitarbeit und Unterstützung zahlreicher Kolleginnen und Kollegen entstehen. Wir danken insbesondere den Lehrerinnen und Lehrern, die durch ihre Erfahrungen und Beobachtungen die Grundlage für die Praxisberichte geschaffen haben: Andreas, Lennard, Leo und Uli.

Des Weiteren danken wir den Teilnehmerinnen und Teilnehmern der Workshops, die an den Grundlagen für die Methodenkoffer mitgearbeitet haben: Andreas, Christian, Conny, Dorothea, Julia, Lennard, Leo, Mareen, Matthias, Melanie, Mike, Sebastian, Thomas, Timo, Tobias und Uli.

Darüber hinaus danken wir der Sybit GmbH, insbesondere Johannes, Thomas, Fritz und Stephan, die uns auf der «Agile Bodensee» einen Einblick in die agile Welt der Profis und die Realisation unseres Workshops in Radolfszell ermöglicht haben.

Unser Dank gilt außerdem Gerald von der Lenovate GmbH für die engagierte Bereicherung unseres Workshops in Kloster Zinna, insbesondere für das Spiel «Kekse backen» und die markanten Sprüche zu Agilen Werten. Weiterhin gebührt unser Dank Bernd (stellvertretend für die ganze QAware GmbH), der einem der Autoren für ein Jahr die Mitarbeit im Unternehmen ermöglicht und ihm damit zu einem vertieften Einblick in die agilen Praktiken, Techniken und Werte von Profis verholfen hat.

Im Rahmen der Königsteiner fachdidaktischen Gespräche haben viele Kolleginnen und Kollegen mit uns an den Methodenbausteinen weitergearbeitet; auch ihnen gebührt unser Dank.

Schließlich bedanken wir uns bei der Google-CS4HS-Initiative für die finanzielle Beteiligung an den Workshops sowie an den Druckkosten dieses Buches.

Hintergrund

2

Agile Kultur in Unternehmen und Schulen

Agile Methoden einzusetzen bedeutet auch zu verstehen, wo sie herkommen, welche Werte mit ihnen verbunden sind und wie diese in der Praxis zum Tragen kommen. In diesem Kapitel werden zunächst die wichtigsten Entwicklungsschritte und Vorgehensmodelle agiler Methoden beschrieben. Anschließend werden Agile Werte als ideelles Fundament und ihre Bedeutung für Unterrichtsprojekte dargestellt. Unterschiedliche Beweggründe und Erfahrungen bei der Einführung agiler Methoden werden schließlich durch Schilderungen aus der Praxis dreier Unternehmen skizziert.

2.1 Geschichte und Entwicklung
Softwareentwicklung wird Teamarbeit

Allein entwickelte Software ist typischerweise nicht sehr komplex, wird von wenigen genutzt oder hat eine kurze Lebenszeit. Anders ist es mit großen Softwaresystemen: Sie werden von vielen für viele geschrieben und meist über Jahrzehnte genutzt und weiterentwickelt.

Die Entwicklung solcher Softwaresysteme begann Mitte des letzten Jahrhunderts mit Steuerelementen für Raumfahrt und militärische Streitkräfte. Anfangs wurde im Großen ebenso «intuitiv» wie im Kleinen entwickelt. In den folgenden Jahrzehnten beauftragten Banken, Telefon- und Transportgesellschaften, Unternehmen für Medizintechnik und viele weitere Branchen zunehmend umfangreichere Softwarelösungen, die nur noch von Teams entwickelt werden konnten. Rasch wurde klar: Das Risiko zu scheitern war ohne ein strukturiertes Vorgehen groß. Dass es damals, als sich die Informatik als Wissenschaft erst entwickelte, noch kaum systematisch ausgebildete Informatiker, aber viele Ingenieure in der Softwareentwicklung gab, mag erklären, weshalb man in den 1960er-Jahren bewährte Vorgehensweisen aus Bau- und Produktionsprozessen übernahm und sie für die Softwareentwicklung anpasste. So entstand ein wasserfallähnlicher Verlauf in Phasen, der einen Schwerpunkt auf die sehr präzise Analyse und Definition der Anforderungen legte, um dadurch, analog zum Bauwesen, teure oder gar unmögliche spätere Änderungen zu vermeiden. Anschließend wurde gemäß den Anforderungen ein detaillierter Plan ausgearbeitet und im Folgenden genau umgesetzt. Kommuniziert wurde dabei im Wesentlichen durch das Weiterreichen der umfangreichen Dokumentation. Diese heute als klassisch bezeichneten Vorgehensweisen brachten Struktur in den Prozess, aber auch neue Probleme. Planungsfehler wurden beispielsweise oft erst am Ende des Projekts erkannt und waren zu diesem Zeitpunkt nur mit erheblichem Zusatzaufwand meist in Form von Überstunden behebbar. Außerdem beschrieben die verschriftlichten Wünsche des Kunden aufgrund von Kommunikationsschwierigkeiten oder unzureichender Kenntnisse oft nicht das, was eigentlich gebraucht wurde, sodass die Arbeit von Monaten oder Jahren «umsonst» war. Nach Abschluss einer klassischen Planung eingebrachte Wünsche durften nicht mehr berücksichtigt werden, auch wenn eine Planänderung aus Sicht des Entwicklerteams möglich und sinnvoll gewesen wäre. Die Praxis der Softwareentwicklung zeigte Ende des 20. Jahrhunderts immer deutlicher, dass langfristige Pläne oft nur für kurze Zeit gute Pläne sind, insbesondere in einer Welt, deren Anforderungen und Einsatzszenarien immer volatiler, komplexer, unsicherer und mehrdeutiger werden.

Abbildung 2.1: Probleme bei klassischem Vorgehen: Was der Kunde beschreibt, was er anfangs bräuchte, was umgesetzt wird, was noch gerettet werden kann und was er am Ende tatsächlich gebraucht hätte

Auf dem Weg zu mehr Flexibilität

Vor dem Hintergrund dieser auch für die Softwareentwickler oftmals frustrierenden Erfahrungen diskutierten in den 1990er-Jahren immer mehr Informatikerinnen und Informatiker darüber, welche neuen Wege beschritten werden könnten, um Software für alle Beteiligten besser zu entwickeln. Hierbei entstanden Vorgehensmodelle wie Extreme Programming, Scrum und Feature Driven Development, die zunächst unter das Prädikat «leichtgewichtig» fielen. Die Ideen für Veränderungen waren nun da, aber noch fehlte eine positive charakteristische Bezeichnung, die, vergleichbar mit einem Siegel, die verknüpften Werte bündelte, ihnen eine unverkennbare Identität gab und beim Kunden Neugier und Vertrauen für das damit verbundene Versprechen, besser zu sein, weckte.

Das änderte sich, als 17 erfahrene Softwareentwickler mit sehr unterschiedlichem Hintergrund im Jahr 2001 in den schneebedeckten Rocky Mountains zusammenkamen, um eine gemeinsame Basis und einen Begriff für die neuen Herangehensweisen zu finden. Nachdem ein Teilnehmer vorgeschlagen hatte, das, was man in der praktischen Arbeit mehr schätzen gelernt hat, dem gegenüberzustellen, was traditionell wichtig war, ging es sehr schnell. Dann standen vier Sätze, aus denen das Agile Manifest wurde, an der Wandtafel.

Abbildung 2.2: Das 2001 formulierte Manifest für Agile Softwareentwicklung

Der Moment wird von Teilnehmern später als überwältigend beschrieben. Es gab keine Gegenargumente, es bedurfte keiner Abstimmung. Alle sahen die Sätze und sagten: «Ja, das ist es!» Am zweiten Tag wählte die Gruppe das Wort «agil», das mit «beweglich», «flink» oder «wendig» ins Deutsche übersetzt werden kann, als positiv besetzten Begriff für das nun zum Ausdruck gebrachte gemeinsame Wertesystem und die daraus abgeleiteten Prinzipien. Die neuen Vorgehensmodelle, die sich darauf stützen, wurden von nun an als agile Methoden bezeichnet. Da sich der Begriff «Methode» sowohl auf Vorgehensmodelle als auch auf hierin verwendete Techniken, Praktiken und Hilfsmittel beziehen kann, verwenden wir im Folgenden den weiteren Methodenbegriff, der auch gut zum Verständnis von Methoden im Unterricht passt.

Zehn Jahre Agiles Manifest – eine Zwischenbilanz

Was agile Methoden in den folgenden Jahren verändern sollten, damit hatte 2001 niemand gerechnet, sagten die Teilnehmer übereinstimmend anlässlich des zehnten Jahrestags. Denn im Gegensatz zu vielen anderen Bewegungen, die verebbten, wuchs in der Praxis die Zahl der agil arbeitenden Teams und Unternehmen unaufhaltsam und immer schneller, insbesondere im IT-Bereich. Oft begann ein Team damit, es «mal auszuprobieren», und erlebte dabei, wie Kolleginnen und Kollegen neugierig wurden und fragten: «Was macht ihr denn da, warum seid ihr so gut drauf?» So sprang die Idee von einem Team zum nächsten und veränderte nicht nur deren Stimmung, sondern auch die Qualität der Produkte, die Effektivität, die Motivation der Projektbeteiligten und letztlich die gesamte Unternehmenskultur. In agilen Unternehmen geht man beispielsweise davon aus, dass man die besten Ergebnisse erhält, wenn man kleinen, sich selbst organisierenden Teams statt einer klaren Arbeitsanweisung ein inhaltliches Ziel gibt. Es liegt dann in der Verantwortung und der Freiheit des Teams, den für sich besten Weg zum Ziel zu bestimmen. Die in den Vorgehensmodellen beschriebenen Techniken und Praktiken unterstützen sie dabei. Agile Werte haben im Bereich der Kooperation und Teamarbeit, aber auch weit darüber hinaus viel bewegt, lautet die Bilanz nach zehn Jahren, auch wenn der Wandel noch lange nicht abgeschlossen ist: Agil sein bedeutet, sich ständig zu bewegen, zu verändern und neuen Umgebungen anzupassen, sodass die Weiterentwicklung des agilen Ansatzes wohl auch nie abgeschlossen sein wird.

Agile Vorgehensmodelle aus der Softwaretechnik

Kleinster gemeinsamer Nenner der agilen Vorgehensmodelle sind die im Agilen Manifest ausgedrückten Leitgedanken und Werte. Gemeinsam ist ihnen darüber hinaus, dass sie alle empirisch sind, also auf möglichst systematischem und datengestütztem Lernen aus Erfahrungen basieren, und dass damit iterativ, also in kleinen Zeitintervallen Inkremente entwickelt werden, die das Produkt um etwas für den Kunden Nützliches erweitern.

Scrum

Der Begriff «Scrum» steht symbolisch für das Gedränge im Rugby als Analogie für sich in komplexen Situationen erfolgreich selbst organisierende (Produktentwicklungs-)Teams. Besondere Rollen nehmen in Scrum der Product Owner, der im Sinne des Kunden und mit dem Ziel der Wertschöpfungsmaximierung entscheidet, was gemacht wird, und ein Scrum Master, der das Team wo nötig unterstützt, ein. Darüber hinaus beschreibt Scrum eine Reihe von Meetings und Praktiken. Die Selbstverpflichtung des Teams, seine Fokussiertheit sowie Offenheit, Respekt und Mut sind Werte, die besonders betont werden. Scrum stammt aus der Softwaretechnik, wird aber inzwischen auch in anderen Bereichen erfolgreich als Vorgehensmodell für das Projektmanagement verwendet.

Extreme Programming (XP)

XP hat viele Ähnlichkeiten zu Scrum, stellt aber neben Mut und Respekt direkte Kommunikation und Feedback ins Zentrum sowie Einfachheit, welche die Denkweise und den Codierstil der Entwicklerinnen und Entwickler prägt. Von den vielen XP-Praktiken ist Pair-Programming wohl die bekannteste.

Feature Driven Development (FDD)

Die Organisation der Produktentwicklung erfolgt bei FDD dem Namen entsprechend anhand einer Liste von Funktionalitäten, die nach und nach umgesetzt werden. FDD harmoniert, anders als Scrum oder XP, gut mit existierenden klassisch hierarchischen Projektstrukturen. Es erfordert keinen kulturellen Wandel der Unternehmen, hat insgesamt eine deutlich andere Ausprägung, kann aber bei agilen Vorgehensweisen verortet werden.

Verwandte Vorgehensmodelle

Kanban, Lean Management und Design Thinking bringen Ideen aus anderen produzierenden Bereichen, wie etwa der Autoindustrie, in die IT:

Kanban

Ziel des Kanban-Vorgehensmodells ist es, die Wertschöpfungskette eines mehrstufigen Prozesses kostenoptimal mittels Hol-Prinzip (Pull-Prinzip) ohne schwerfällige zentrale Planung zu steuern. Der Prozess wird dazu mithilfe eines Project-Boards und Karten, auf denen die zu erledigenden Aufgaben stehen, visualisiert. Da jeder Wechsel zwischen unterschiedlichen Aufgaben, die ein Mitarbeiter oder eine Mitarbeiterin quasi parallel bearbeitet, Zeit kostet, legt das Team eine maximale Zahl an Arbeiten fest, die jeder und jede gleichzeitig bearbeiten darf. Bis zu dieser Zahl können die Mitarbeitenden Aufgaben auf dem Board in die Spalte «In Bearbeitung» verschieben. Für Probleme wie beispielsweise Flaschenhälse im Prozess, die so sichtbar werden, überlegt sich das Team Maßnahmen, die es ergreifen will.

Lean Management

Die Methoden des Lean Managements zielen darauf ab, die Prozessorganisationen und das Qualitätsniveau zu verbessern, und sind heute weltweit verbreitet. Im Kern stellt Lean Management eine Unternehmenskultur dar, in der sich alle Tätigkeiten auf den Kunden ausrichten, in der die Teams im Rahmen dieses Unternehmensleitbildes eigenverantwortlich und autonom arbeiten und in der großer Wert auf offene Informations- und Feedbackprozesse gelegt wird, die die Basis kontinuierlicher Verbesserung sind.

Design Thinking

Design Thinking ist ein Ansatz für praktisches und kreatives Problemlösen, der in Projekten und anderen Kontexten, in denen es um Innovation geht, genutzt werden kann. Er stellt eine breite Palette an Methoden zur Verfügung, die sich durch Benutzerorientierung, Visualisierung, Simulation sowie durch iteratives und oft auch durch forschendes Vorgehen auszeichnen.

Wohin geht der Weg?

Während um das Jahr 2000 herum die Mehrheit der agil arbeitenden Teams in der Softwareentwicklung angaben, dass sie sich an Extreme Programming orientieren, war 2017 Scrum die meistgenutzte agile Methode. Je nach Umfrage arbeiten 85 Prozent oder mehr aller befragten Teams in der IT mit «Scrum», wobei jedes Team mit der Zeit sein eigenes Scrum entwickelt. Wie viel Software in den vergangenen Jahren prozentual mit klassischen bzw. mit agilen Vorgehensmodellen entwickelt wurde, ist schwer zu sagen. Ein Trend zeichnet sich jedoch klar ab: In der Softwareentwicklung gibt es kaum noch ein Unternehmen, in dem nicht zumindest einzelne Teams «agile Luft» schnuppern. Laut dem Unternehmen VersionOne, das seit 2006 jährlich eine Umfrage zum Stand agiler Softwareentwicklung durchführt, setzten im Jahr 2018 bereits 97 Prozent aller Unternehmen in der Softwareentwicklung agile Methoden ein. Die meisten amerikanischen IT-Riesen arbeiten agil, aber auch namhafte europäische und deutsche Unternehmen vergeben IT-Aufträge inzwischen bevorzugt an agile Teams und arbeiten selbst daran, agil zu werden. Über die Erfahrungen auf dem Weg dorthin gibt es bis heute einen regen Austausch auf Konferenzen und an «agilen Stammtischen», um auch Neulinge auf dem Weg zum agilen Denken und Handeln zu unterstützen. Für viele gilt in Anlehnung an die als Sprint bezeichneten Iterationen: «Wir sind einfach losgesprintet – und es hat gut geklappt.»

Wie verändert agiles Denken die Arbeit?

Sicherlich kann man hier aus heutiger Sicht viele Auswirkungen beschreiben, die auf die Verbreitung agiler Methoden zurückzuführen sind, und sie lassen sich je nach Fokus unterschiedlich gewichten. Im Folgenden werden deshalb nur exemplarisch zwei ganz unterschiedliche Aspekte aufgegriffen:

Agile Methoden haben sich in der zunehmend komplexen Welt, in der sich die Softwareentwicklung heute bewegt, bewährt. Selbst «einfache» Suchmaschinen sind inzwischen so komplex, dass auch Experten oft nicht mehr vorhersagen können, wie sich eine Änderung im Algorithmus auswirkt. Also formuliert man im Laufe der (Weiter-)Entwicklung Hypothesen, stellt die veränderte Suchmaschine für kurze Zeit online und wertet die Ergebnisse anschließend aus. Validiertes Lernen aus Experimenten ist eine unverzichtbare Methode moderner Softwareentwicklung geworden, die in klassischen Vorgehensmodellen kaum Platz findet. In agilen Methoden stellt die Freiheit zum Experimentieren hingegen einen Wert dar. Validiertes Lernen fügt sich auf natürliche Weise in die iterativ inkrementelle Entwicklung von Produkten mit regelmäßigen Feedbackschleifen ein, in welcher Kunde und Nutzer eine zentrale Rolle einnehmen.

Agile Methoden stoßen in IT-Unternehmen einen kulturellen Wandel an. Dieser Wandel hat in der Softwareentwicklung sichtbar positive Wirkungen gezeigt, sodass sich die Ideen inzwischen (obwohl Lean Management sie bereits Mitte des letzten Jahrhunderts aufgegriffen hat) auch im modernen Management und außerhalb der IT-Branche wiederfinden. Bildlich gesprochen: Schwerfällige Tanker, in denen oben auf der Brücke getrommelt und unten gerudert wird, sind in bewegter See zu träge. Stattdessen setzt man auf viele kleine, autonome Teams in Kanus, die eigenverantwortlich rudern. Die Klammer, die diese Kanus «lose zusammenhält» und Richtung Ziel lenkt, ist die Kommunikation. Statt als feste Rolle wird Führung als temporäre und «dienende» Aktivität gesehen, die jeder und jede von Zeit zu Zeit ergreift. Agile Unternehmen schätzen ihre Mitarbeiterinnen und Mitarbeiter, sie vertrauen ihren Fähigkeiten und ihrem Engagement, setzen auf ihre Motivation und sorgen für ein Klima, in dem offen, respektvoll und transparent kommuniziert wird und Erfolge auch gefeiert werden. So macht Arbeit einfach mehr Spaß!

2.2 Agiles Arbeiten – ein Zusammenspiel aus Werten und Praktiken
Agile Werte

Agile Projekte zeichnen sich nicht nur durch den Einsatz verschiedener agiler Methoden aus, auch wenn diese am sichtbarsten sind, wie etwa die vielen bunten Klebezettel an einem Board. Vielmehr basieren agile Projekte auf einer Reihe von Werten, welche die grundlegende Orientierungs- und Entscheidungshilfe für agile Teams auf ihrem selbstgestalteten Weg zum gesetzten Ziel bilden. In Form von konkreten und erprobten Techniken werden die Werte umgesetzt und die agilen Teams bei ihrer Selbstorganisation ideal unterstützt.

Unter Werten werden grundlegende erstrebenswerte Merkmale und Eigenschaften agiler Projekte subsumiert. Typisch positive personenbezogene Wesensmerkmale wie Eigenverantwortung, Zielstrebigkeit, Offenheit und Respekt sind damit korreliert und tragen zu einer positiven Unternehmens- bzw. Schulkultur bei. Als die beiden zentralen Werte agiler Methoden gelten Kommunikation und Einfachheit. Gemeinsam mit den Werten Feedback, Selbstorganisation und Transparenz werden sie nicht nur in der Softwarepraxis gelebt, sondern bilden auch die Basis für die Agile Schule. Darüber hinaus können in agilen Projekten je nach Schwerpunktsetzung auch andere Werte wie bspw. Commitment, Mut oder Fokus wichtig werden.

Abbildung 2.3: Werte, auf die sich die Prinzipien und Methoden der agilen Projektarbeit beziehen

Im Folgenden werden die wichtigsten Werte der Agilen Schule genauer charakterisiert:

Kommunikation

Kommunikation ist die Grundlage für gemeinsames Arbeiten und Lernen. In agilen Projekten ist sie die Voraussetzung dafür, dass Wissen regelmäßig und bestmöglich ausgetauscht und innerhalb des Teams verteilt wird. Bei der Übernahme klassischer Vorgehensmodelle wird mitunter auch in Schulen versucht, durch die fließbandartige Abarbeitung von Dokumenten wie Lasten- und Pflichtenheft, Modellen, Klassendokumentationen und Anderem die zwischenmenschliche Kommunikation zu ersetzen. Für agiles Vorgehen ist dagegen die direkte Kommunikation aller Beteiligten zentral. Sie sollte regelmäßig, zielorientiert, offen, ehrlich, und respektvoll erfolgen. Das betrifft auch die Absprachen über (Zwischen-)Ziele und Machbarkeiten im Projekt sowie den Austausch über Einschätzungen, Lösungswege, Entscheidungen und Probleme mit den Teammitgliedern.

Einfachheit

Um Ziele zu erreichen, ist Einfachheit sowohl bei der inhaltlichen Arbeit als auch bei der organisatorischen Durchführung eines agilen Projekts zentral. Dabei ist die Leitfrage des KISS-Prinzips («Keep it small and simple») hilfreich für die Fokussierung auf das Wesentliche: Kann ich es sinnvoll einfacher gestalten? Konkret soll in der inhaltlichen Umsetzung nur das implementiert werden, was für die unmittelbare Zielstellung benötigt wird. Unnötige Details hingegen gefährden den Projektfortschritt. Gibt es mehrere Lösungswege, so ist der einfachere zu bevorzugen; er ist leichter nachzuvollziehen und zu verstehen. Dadurch werden später auch die Fehlersuche, das Erweitern und die Pflege erleichtert. Auch zur Projektorganisation werden nur diejenigen Techniken und Praktiken herangezogen, die einen Mehrwert bieten. Welche das sind, muss abhängig vom konkreten Projekt entschieden werden bzw. kann nach Reflexionsphasen angepasst werden. Beispielsweise kann in der Schule auf Rollen, wie sie in Scrum existieren, weitestgehend verzichtet werden.

Feedback

Feedback ist eine der konstruktivsten Formen der Kommunikation und grundlegend für individuelle und gemeinsame Lern- und Weiterentwicklungsprozesse. In sequenziell verlaufenden Projekten erhalten die Teams erst beim Abschluss ein Feedback. Stärken und Schwächen bei der Planung etwa werden so zwar benannt, aber die Gelegenheit, daraus Gelerntes unmittelbar anzuwenden, wurde verpasst. In agilen Projekten werden die Phasen zyklisch in ↑ Iterationen durchlaufen, um das Zwischenprodukt (↑ Prototyp) schrittweise zu erweitern, woraus sich eine regelmäßige Rückkopplung ergibt. Unmittelbare Bedeutung für die Schülerinnen und Schüler hat die frühe Rückmeldung auf der Ebene der umgesetzten Lösungen, die sie in agilen Projekten in der Beurteilung der Zwischenprodukte im Review (↑ Reflexion) erhalten. Feedback auf (Selbst-) Steuerungsebene bezieht sich auf die Selbstorganisation und Selbstreflexion des Teams und des Einzelnen und kann ebenso wie Feedback auf der Personalebene in den Retrospektiven (↑ Reflexion) gegeben werden.

Selbstorganisation

In klassischen professionellen Projekten, die in Phasen verlaufen, gibt es Taktgeber: Das Entwicklerteam trifft kaum organisatorische Entscheidungen, sondern setzt lediglich von Vorgesetzten genehmigte Pläne in vorgegebenen Zeiträumen um, weshalb Selbstorganisation nur in begrenztem Umfang erforderlich ist. In Schulprojekten hingegen sind Selbstorganisation und Eigenverantwortung zwar seit jeher gewünscht, in der Umsetzung aber nur schwer zu erreichen, da konkrete, unterstützende Methoden fehlen. Agile Methoden beheben diesen Mangel. Sie helfen den Teams, in einem vorgegebenen Rahmen selbst zu entscheiden, welche Ziele sie sich setzen und wie sie ihre (Lern-)Arbeit inhaltlich und zeitlich gestalten und strukturieren. Da das Vorgehen in agilen Projekten transparent ist, erkennt auch der Agile Coach bzw. die Lehrkraft, welche Art der Unterstützung das jeweilige Team (noch) benötigt, bis die Selbstorganisation tatsächlich gelingt.

Transparenz

Klarheit über die Aktivitäten im Team, offene Kommunikation und aktiver Informationsaustausch sind entscheidend für den Erfolg kollaborativer Arbeit und kooperativen Lernens. Klassische, in Phasen ablaufende Projektarbeit ist vergleichbar mit einem U-Boot, das regelmäßig für längere Zeit abtaucht. Was in dieser Zeit passiert, ist von außen nicht einsehbar. In agilen Projekten hingegen sind Strukturen und Prozesse transparent, für die Teams (von innen) und die Lehrkraft/Projektleiter/Kunden (von außen). Jeder kann die Ziele und Abläufe sehen, da der Projektstand und die aktuellen Tätigkeiten visualisiert werden und so jederzeit auf einen Blick erfassbar ist, wer wann woran arbeitet, was noch zu tun ist und was bereits erledigt wurde. Probleme werden offen angesprochen, Entscheidungen gemeinsam getroffen und Wissen und Informationen werden aktiv untereinander geteilt. Dieses Hineinsehen und Verstehen ist für Schülerinnen und Schüler eine wesentliche Voraussetzung zur Partizipation, und für Lehrkräfte ist es die Basis, auf der sie entscheiden, welche Rolle für sie gerade passend ist: die eines Trainers, eines Coaches oder eines Beobachters. Insbesondere als Beobachter kann die Lehrkraft dank der Transparenz die Kompetenzentwicklung der Schülerinnen und Schüler verfolgen und somit ein fundiertes Feedback geben.

Agile Werte durch Praktiken und Techniken zum Leben erwecken

Der agile Prozess gibt einen Rahmen vor, in dem Projekte so strukturiert werden, dass zu jedem Zeitpunkt das Richtige richtig getan wird. Insbesondere mittels verschiedener Praktiken und Techniken zum Visualisieren, Austauschen und Nachdenken werden dabei die Agilen Werte zur Basis des Handelns gemacht.

Visualisieren

Eine zentrale Rolle spielen Praktiken und Techniken, die den Stand und die Aufgaben des gesamten Projekts und insbesondere des aktuellen Zyklus auf einen Blick erfassbar und damit für alle transparent machen. Das Visualisieren erfolgt in der Agilen Schule ebenso wie in professionellen Projekten durch das ↑ Project-Board mit seinen drei Spalten für geplante, in Arbeit befindliche und erledigte Aufgaben sowie durch priorisierte ↑ User-Storys und die Beschreibung damit verbundener Aufgabenpakete in Form von ↑ Tasks, für die Einzelne für alle sichtbar die Verantwortung übernehmen. Die Visualisierung unterstützt die Selbstorganisation, zeigt das Commitment des Teams bzw. der einzelnen Teammitglieder, fordert Einfachheit bei der Planung ein und sorgt für ein fokussiertes Arbeiten.

Austauschen

Ebenso wesentlich ist eine Reihe von Techniken und Praktiken, die den Austausch von Informationen und Wissen unterstützen, wobei sie jeweils nicht nur einen Anlass zur Kommunikation bieten, sondern diese auch strukturieren. So erfolgt der Austausch in der Agilen Schule analog zu professionellen agilen Projekten bspw. vor dem Hintergrund der täglichen Absprachen (↑ Stand-up-Meeting), zum Besprechen des Vorgehens bei der Projektumsetzung im Planungsmeeting (↑ Stand-up-Meeting und andere Besprechungsformen), beim Beschreiben und Diskutieren konkreter Umsetzungen (↑ Pair-Programming), beim Nutzen ↑ kollaborativer Werkzeuge, bei der Beurteilung des entwickelten (Zwischen-)Produkts im Review (↑ Reflexion) sowie bei der Reflexion des Arbeitsablaufs, der Zusammenarbeit und des Umgangs miteinander in der Retrospektive. Jede der Praktiken setzt auf Offenheit und Respekt im Gespräch, aber auch auf den Mut, beispielsweise Fehler anzusprechen und Wünsche zu artikulieren, sowie auf Fokussierung. Die Kommunikation sorgt für Transparenz und Feedback, da Informationen ausgetauscht, Entscheidungen gemeinsam getroffen und fachliche Probleme ebenso wie Stärken und Schwächen des Teams angesprochen werden.

Nachdenken

Der dritte zentrale Aspekt, das Nachdenken, löst insbesondere durch den ↑ iterativen Prozess regelmäßig ein «Inspizieren und Adaptieren» aus. Dieses macht das Team und seine Arbeit agil, indem es ein Lernen aus Fehlern und Erfahrungen unterstützt, ein Verbessern in kleinen Schritten ermöglicht und die Umsetzung von Änderungen begünstigt. Neben den kommunikativen Praktiken (↑ Reflexion in Review und Retrospektive) gehören dazu weitere wie ein konkretes Prüfen und Korrigieren der erreichten Ergebnisse bezüglich der geplanten Ziele (↑ Testen) vor einem Review, ein Überarbeiten der Struktur des Zwischenprodukts (↑ Refactoring), ein Beschreiben des Erreichten (↑ Dokumentation) und ein Überdenken und Ergänzen noch offener Aufgaben und ihrer Priorität.

Die agile Szene drückt das, was für sie Agile Werte und agiles Handeln bedeuten, gern auch in markanten Sprüchen aus (Abbildung 2.4).

Abbildung 2.4: Markante Sprüche aus einem Alltag mit Agilen Werten

Das Agile Schulmanifest

Das Agile Manifest von 2001 gilt als Start für einen Kulturwandel in der Softwareentwicklung. In der Agilen Schule sind Agile Werte essenziell für das Gelingen der Projekte sowie für die individuelle Entwicklung und den Lernprozess der Schülerinnen und Schüler.

Auf Grund unserer Erfahrungen auf dem Weg zu besseren Projekten haben wir ein Agiles Schulmanifest formuliert (Abbildung 2.5). Es soll dazu anregen, den Wandel auch in der Schule einzuleiten:

Abbildung 2.5: Manifest für einen agilen Wandel in der Schule

2.3 Unternehmen werden agil – Beweggründe und Erfahrungen

Warum werden immer mehr Unternehmen – nicht nur solche aus dem IT-Bereich – agil? Was bedeutet «agil werden» und «agil sein» für sie? Wie gehen sie vor, welche Hürden gilt es zu überwinden und welche Erfahrungen machen sie? Wir, die Autoren, haben nicht die Erfahrung Agiler Coaches, die unterschiedlichste Teams dabei begleitet haben, agiles Denken und Handeln zu lernen, und deshalb aus dem Nähkästchen plaudern können. Wir haben auch nicht erlebt, wie es sich anfühlt, aus einem klassischen Prozess in einen agilen zu wechseln. Aber wir haben Kontakt gesucht zu Profis aus der Praxis und haben insbesondere auf der «Agile Bodensee», der Konferenz für agile Softwareentwickler und Projektentwickler im Bodenseeraum, über mehrere Jahre Einsicht gewonnen in die agile Bewegung. Wir fühlten die Begeisterung und die Lust der Vortragenden, andere Teams zu unterstützen und etwas zu bewegen, indem sie ihre eigenen Erfahrungen teilten, und wir saßen mit Teams am Mittagstisch, die erst noch agil werden wollten und viele Fragen hatten. Die folgenden Ausschnitte aus Berichten von Praktikerinnen und Praktikern illustrieren die Erfahrungen.

«Einfach losgesprintet» – im agilen Testprojekt

Stefan Kirch und Henning Pautsch berichteten auf der Agile Bodensee 2014 vom Umstieg auf agile Methoden bei der Bauer+Kirch GmbH in Aachen:

Ausgangspunkt des Ausprobierens agiler Methoden war, dass die Erfahrungen im Unternehmen zunehmend eine Ahnung bestärkten, dass die klassische Art, Software zu entwickeln, auf Dauer in eine Sackgasse führen würde. Ein idealer Zeitpunkt, um ein agiles Vorgehen zu erproben, war gekommen, als ein hausinternes Werkzeug neu entwickelt werden musste. Unglücklicherweise erkrankte gerade zu diesem Zeitpunkt der Agile Coach, der das Entwicklerteam begleiten sollte. Was also tun? Zwar finden sich in Büchern und Blogs viele Informationen zum methodischen Vorgehen, aber sie können keine Erfahrungen ersetzen. Um die Gelegenheit nicht verstreichen zu lassen, wollte man es dennoch wagen, und obwohl das Team keinen Coach haben würde, wurde es auf den Weg geschickt. Bald mussten die ersten Entscheidungen getroffen werden: Wie lang sollte ein Sprint (↑ Iteration) dauern, also die Entwicklung von jeweils einem weiteren Inkrement der Software? Eine Woche erschien dem Team zu kurz, vier Wochen zu lang, also entschied es sich kurzerhand für zwei Wochen. Das grundsätzliche Ziel wiederum war klar und einiges ergab sich im Verlauf des Projekts, etwa wie viel das Team in zwei Wochen schafft. Die Anforderungen in Form von ↑ User-Storys wurden elektronisch erstellt, aber das Team wollte sie auch ausgedruckt als Zettel an einem großen, übersichtlichen ↑ Project-Board an einer Wand im Büro haben. Die detaillierten Teilaufgaben (↑ Tasks) wurden der Einfachheit halber nur am Project-Board verwaltet. Dort traf sich das Team auch jeden Morgen für 10 Minuten zum ↑ Stand-up-Meeting, um sich gegenseitig zu informieren.

Bereits nach den ersten Sprints war sich das Team einig: Über die anstehenden User-Storys zu sprechen und die Tasks gemeinsam zu planen, bringt alle fachlich voran und liefert qualitativ bessere Entwürfe. Die Besprechungen des jeweiligen Zwischenprodukts (↑ Prototyp) mit dem hausinternen Kunden motivieren: Rückmeldungen wie «Ja, genau so wollte ich das haben» spornen an. Es wurden auch Fehler gemacht, diese waren aber stets mit einem Lerneffekt verbunden. Insgesamt verlief das agile Testprojekt erfreulich erfolgreich, was unmittelbare Auswirkungen auf weitere Projekte nach sich zog. Nicht nur die Entwicklerinnen und Entwickler dieses Teams sprachen sich in neuen Projekten sofort für ein agiles Vorgehen aus, auch andere Kolleginnen und Kollegen äußerten sich interessiert, wenn sie am Project-Board vorbeigingen oder das Team bei der Arbeit erlebten. Ohne genau zu wissen, was da gemacht wurde, sahen sie, dass die Beteiligten eine ganz andere Motivation hatten, und meinten: «Das wollen wir auch!»

Deshalb ist das Fazit von Kirch und Pautsch: «Sprinten Sie einfach los! Sprinten Sie los, wenn Sie motiviert sind und wissen, dass nicht alles von Anfang an perfekt sein wird. Schauen Sie sich an, was Sie falsch gemacht haben und versuchen Sie es beim nächsten Mal besser zu machen – das ist erstaunlich einfach. Sprinten Sie los! Sie werden feststellen, dass Ihr Team mit einer ganz anderen Motivation, mit einer ganz anderen Identifikation an die Sache herangeht!»

«Können wir das auch umsetzen?» – Wie die agile Denkweise alle ansteckt

Robert Misch von gutefrage.net und Sascha Rehbock berichteten auf der Agile Bodensee 2014 über den agilen Wandel im ganzen Unternehmen:

Es begann damit, dass die IT-Abteilung agile Methoden einführte. Schnell wurde das auch für Kolleginnen und Kollegen aus anderen Abteilungen sichtbar: An den Project-Boards mit den bunten Zetteln, an den täglichen Stand-up-Meetings sowie generell an der gesteigerten Motivation. Klar, dass diese Änderungen ihre Neugier weckten. Sie stellten Fragen – und wollten einen ähnlichen Prozess auch für sich einführen. Deshalb organisierten die Agilen Coaches der IT-Abteilung bald auch für andere Abteilungen Workshops, sodass sich die agile Arbeitsweise erst langsam und dann immer schneller im Unternehmen ausbreitete: vom Community-Management über Marketing, Sales und Finances sogar bis in die juristische Abteilung der Unternehmensgruppe. Deren Leiter hatte zwar zunächst noch keine Vorstellung davon, wie agiles Vorgehen in der Rechtsabteilung der Holding aussehen könnte, aber er glaubte daran.

Alle angepassten Prozesse bei gutefrage.net wurden nun iterativ aufgebaut und insbesondere drei agile Praktiken etablierten sich überall: Das Project-Board visualisiert die Arbeit im Team und schafft Transparenz. Damit kann fokussiert gearbeitet werden, es lassen sich wiederkehrende Probleme im Arbeitsablauf identifizieren, Veränderungen planen und deren Wirksamkeit prüfen. In einem täglichen Stand-up-Meeting werden Informationen ausgetauscht und der Tag geplant, und nach jeder Iteration werden Prozesse, Ergebnisse und die Zusammenarbeit in der ↑ Reflexion bewertet und wo nötig Verbesserungen initiiert.

Als wesentlicher Faktor für das Gelingen der agilen Transformation erwies sich, dass alle im Team nicht nur etwas über agile Praktiken erfuhren, sondern verstanden, welche Denkweise dahintersteckt. Da Agile Werte die gesamte Arbeitskultur verändern, war es wichtig, den Teams genügend Zeit für die Umstellung zu lassen. Zuerst wurde eine kleine Änderung eingeführt und begleitet. Daraus entwickelten sich adaptierte Praktiken und die Teams verbesserten sich stetig.

Was die Mitarbeiterinnen und Mitarbeiter nach der agilen Transformation besonders zu schätzen gelernt haben, ist unterschiedlich: Das Marketing-Team beispielsweise schätzt die durch das Project-Board gewonnene Transparenz und insbesondere die Priorisierung von Arbeiten: «Wir fangen weniger an, aber dafür wird mehr fertig. Das hilft, sich auf Resultate zu fokussieren.»

Die juristische Abteilung hat das Arbeiten in Paaren eingeführt. Nun ist nicht mehr nur eine einzelne Person als Experte oder Expertin für einen Bereich verantwortlich. Verträge werden nun zu zweit entworfen und gegenseitig begutachtet. «Wenn ich jetzt krank werde oder in den Urlaub gehe», berichtete eine Juristin, «bin ich dank der neuen Arbeitsweise entspannter, weil das Projekt trotzdem weitergeht.» Auch in der Unternehmensgruppe ist die Erfahrung mit der neuen juristischen Abteilung sehr positiv: Anfragen werden nun effizienter und besser bearbeitet. Die Managerinnen und Manager begrüßten zwar die Motivation in agilen Teams, stellten sich aber bald die Frage «Welche Aufgaben bleiben uns denn nun? Braucht es überhaupt noch eine Kontrolle der Arbeitsprozesse?» Es ist verständlich, dass die Idee von selbstorganisierten Teams sie zunächst verunsicherte. Ein Workshop zu «Management 3.0» inspirierte sie jedoch und weckte die Experimentierfreude. Beispielsweise wurde ein sogenanntes Delegation-Board installiert, auf dem alle sehen können, wer welche anstehenden Entscheidungen treffen darf. Für die Teams ist diese Klarheit eine große Hilfe.

«Entscheidend ist der Kulturwandel» – Organisationsentwicklung durch agile Transformation

Stefano Trentini, Leiter des Bereichs Software Engineering bei den Schweizerischen Bundesbahnen (SBB) und Mischa Ramseyer, Agiler Coach bei pragmatic solutions, berichteten auf der Agile Bodensee 2016 über den Beginn einer «agilen Transformation» bei den SBB:

Wie kommt ein konservatives Traditionsunternehmen wie die SBB dazu, in seinem IT-Bereich flächendeckend Agilität einführen zu wollen? Der Handlungsbedarf entstand, weil andere IT-Unternehmen zunehmend kundennäher arbeiten und ihre Produkte immer schneller, kostengünstiger, aber mit konstanter Qualität auf den Markt bringen. Die einzige Möglichkeit, als unternehmensinterner Anbieter von IT-Lösungen in diesem Umfeld konkurrenzfähig zu bleiben, war es, einen Paradigmenwechsel einzuleiten. Entscheidend schien dabei nicht die Wahl eines bestimmten agilen Frameworks, sondern vielmehr ein Kulturwandel. Dieser lässt sich nicht vorschreiben, vielmehr müssen die Beschäftigten mitgenommen werden. Das wurde erreicht, indem dieser Kulturwandel bei den SBB anhand von fünf werteorientierten Prinzipien beschrieben, kommuniziert und zunehmend umgesetzt wurde:

Schaffe Wert und Nutzen! Bei den SBB wurde sehr langfristig und detailliert geplant und jeder Bereich hielt sich stark an seine Pläne. Von dieser planorientierten Steuerung galt es nun zu einer Steuerung zu kommen, die stets dem jeweiligen Projektziel dient und sich am Schaffen von Wert und Nutzen orientiert.

Übernimm Verantwortung! Bisher trafen die Vorgesetzten die Entscheidungen und übernahmen die Verantwortung, weshalb sich die Beschäftigten kaum innovativ einbringen konnten. Als neues Ziel sollen die Mitarbeitenden mit der Zeit befähigt werden, sich auf ihrem Fachgebiet mehr zu trauen und zu lernen, mit Verantwortung umzugehen und vor allem Fehler offen zuzugeben.

Unterstütze Veränderung! Bei den SBB wird ein freundlicher und netter Umgang gepflegt. Das führte in der Vergangenheit aber auch dazu, dass jemand, ehe er Kritik an anderen übte, nach Behelfslösungen suchte. Um Veränderung zukünftig als positiv wahrzunehmen und zu unterstützen, soll sich nun jeder und jede kritisch mit den Ergebnissen der Arbeit auseinandersetzen und somit besser aus Erfahrungen lernen.

Macht’s zusammen! Bisher hatte jede Person eine klar definierte Rolle, die ihre Tätigkeit festlegt und eingrenzt. Zukünftig sollen nun Aufgaben zusammen im Team erledigt werden, ohne Rollen, und die Verantwortung soll dabei gemeinsam getragen werden. Das bedeutet, dass die Teams eine funktionierende Form der Kooperation entwickeln sollen.

Mach’s einfach! Aus der Tradition heraus gab es bei den SBB seit jeher viele Regularien, Abläufe waren relativ kompliziert. Dinge einfach zu machen bedeutet, diese Regularien sinnvoll abzubauen und es zu wagen, Entscheidungen mit dem gesunden Menschenverstand zu treffen.

Nach der Einigung auf diese Prinzipien als Grundlage für den Wandel begann die Umsetzung, wobei – wie im agilen Umfeld üblich – in kleinen Schritten, also iterativ vorgegangen wurde. In jedem Quartal wurden Teilziele entsprechend der Priorisierung mit Feature-Teams an einem Nachmittag geplant und während des Quartals ausgearbeitet. Am Ende jeder Iteration wurden die Resultate präsentiert. So ist unter anderem ein Vorgehensmodell der SBB entstanden, das den werteorientierten Rahmen vorgibt. Nun kann jedes Team, das in ein neues Projekt startet, für sich selbst entscheiden, ob es sich an Scrum, Kanban oder einem anderen agilen Vorgehensmodell orientiert, denn jedes passt in den vorgegebenen Rahmen und erlaubt es beispielsweise, während der Produktentwicklung regelmäßig zu prüfen, ob Wert und Nutzen geschaffen werden. Zudem wurde Raum für Vernetzung und Dialog in der Organisation geschaffen, damit jeder den Zielen Sinn geben und eigene Ideen entwickeln kann, unabhängig von seiner Aufgabe und Position im Unternehmen. Der Stand der agilen Transformation wurde von Beginn an anhand von Kriterien gemessen. Diese Daten wurden um eine Selbsteinschätzung der Teams ergänzt und es zeigt sich inzwischen: «Agilität ist bei den Mitarbeiterinnen und Mitarbeitern angekommen. Agilität gilt als erstrebenswert.» Viel Zeit und Reflexion, laufende Anpassungen und eine Begleitung waren dabei wichtige Faktoren.

Im Unterrichtseinsatz

3

Erfahrungen mit agilen Schulprojekten

Im ersten Teil dieses Kapitels wird ein mehrfach erprobtes Beispiel vorgestellt, das die wesentlichen Kernideen agiler Projekte verdeutlicht. Daran schließen Erfahrungsberichte agiler Schulprojekte an, die illustrieren, wie agile Methoden bei unterschiedlichen Lerngruppen, fachlichen Vorkenntnissen und Zielsetzungen flexibel und gewinnbringend eingesetzt werden können. Ziel dieser Berichte ist es, den Leserinnen und Lesern Anregung zu geben, die Unterrichtsprojekte ihrer Schülerinnen und Schüler durch Auswahl und Anpassung agiler Praktiken individuell zu gestalten.

3.1 Best Practice – das Spiel «Pengu»

Ein lohnenswertes Projektziel ist für viele Schülerinnen und Schüler die Konzeption und Implementierung eines Computerspiels. Sehr gut eignet sich das Jump-’n’-Run-Spiel «Pengu», bei dem eine Spielfigur auf einer bewegten Wolke über einen Abgrund gesteuert werden muss. Umgesetzt wird dieses Szenario in diesem Beispiel mit Greenfoot. Greenfoot stellt auf der Programmiersprache Java basierende Miniwelten zur Verfügung, die insbesondere für zweidimensionale Spiele und Simulationen geeignet sind. Greenfoot ermöglicht es Programmieranfängern somit, die objektorientierte Programmierung auf interaktive Weise kennenzulernen. Im Folgenden soll nun die Spielidee konkret mit Hilfe agiler Techniken und Praktiken umgesetzt werden. Hierzu wird das Szenario zuerst in ↑ User-Storys festgehalten und in ↑ Tasks aufgeteilt. Anschließend wird das weitere Projektvorgehen beschrieben.

Abbildung 3.1: Das Pengu-Spiel

Funktionalitäten in User-Storys festhalten

User-Storys beschreiben in kurzer Form Funktionalitäten der zu entwickelnden Software, die dem Nutzer zur Verfügung stehen sollen. Jede User-Story soll sich dazu auf eine konkrete Aktivität beschränken und wird aus Sicht des Kunden beschrieben. Typischerweise erfolgt die Erstellung der User-Storys unter Einbeziehung des Auftraggebers und erfordert domänenspezifisches Wissen aus dem Kontext der zu erstellenden Software. In diesem Beispiel übernehmen die Schülerinnen und Schüler selbst die Kundenrolle, um zu entscheiden, wie das Spiel ausgestaltet werden soll. Deshalb ist es erforderlich, dass das Team eine Vorstellung vom Spielfluss und den Möglichkeiten solcher Jump-‘n’-Run-Spiele besitzt, um die Anforderungen klar aufzustellen und auch eigene Ideen mit einzubringen. User-Storys helfen nun, das umfangreiche Spiel in kleine und damit gut umsetzbare Teile zu gliedern. Als Grundsatz sollte für jede Aktivität einer Figur (hier z. B. «Pinguin kann sich bewegen», «Wolke bewegt sich zwischen den Klippen») eine eigene User-Story erstellt werden. Anhand der User-Storys kann dann auch überprüft werden, ob etwas Wichtiges vergessen wurde.

Abbildung 3.2: Die ersten User-Storys zum Pengu-Spiel

Die ersten drei User-Storys dienen in unserem Beispiel der Grundfunktionalität des Spiels: «Spielfläche», «Pinguin bewegen» und «Pinguin fällt». Weitere User-Storys beinhalten die nächsten Spielfunktionen sowie weitere Ausbaumöglichkeiten. Die Zettel zeigen die entsprechenden Beschreibungen der User-Storys sowie deren Prioritäten, welche die Bearbeitungsreihenfolge vorgeben. Da alle drei User-Storys für das Spiel grundlegend sind, wurden sehr hohe Prioritäten festgelegt (je kleiner die Zahl, umso höher die Priorität). Aus den Prioritäten können auch implizite Abhängigkeiten ersichtlich werden (bspw. nur wenn das Szenario erstellt ist, ergibt eine dazu implementierte Aktivität Sinn).

Die erste Iteration planen und Tasks erstellen

Nach der Priorisierung der User-Storys wird im Team festgelegt, wie viele User-Storys in der ersten ↑ Iteration umgesetzt werden sollen. Da die Schülerinnen und Schüler zunächst noch wenig Erfahrung haben, den Arbeitsaufwand für die Umsetzung der User-Storys einzuschätzen, erfolgt hier die erste Auswahl «nach Gefühl». Hilfreich ist dabei, wenn die User-Storys anfangs sehr klein sind. Wir wählen entsprechend die drei User-Storys mit der höchsten Priorität aus. Nun werden diese User-Storys in Tasks gegliedert. Ein Task ist eine grobe Beschreibung eines überschaubaren Arbeitspakets, die auf einem eigenen Klebezettel (Post-it) steht. Während User-Storys die Ziele des Pengu-Spiels aus Sicht des Kunden beschreiben, müssen die Schülerinnen und Schüler nun ihre Perspektive ändern und die Teilziele aus Sicht eines Softwareentwicklers betrachten. Dabei sind bereits verschiedene Designentscheidungen zu treffen. Die resultierenden Tasks der drei User-Storys der ersten Iteration von Pengu sind in der folgenden Abbildung dargestellt.

Abbildung 3.3: Tasks als Planungsergebnis für die erste Iteration des Pengu-Spiels

Es wird deutlich, dass Tasks auch konkrete, technische Begriffe oder kurze Quellcodehinweise enthalten dürfen. Soll auch die Zeitplanung im Projekt berücksichtigt werden, wird zusätzlich eine ↑ Aufwandsabschätzung auf dem Task-Zettel festgehalten. Im Beispiel wird eine relative Schätzung des Aufwands in Form von den T-Shirt-Größen S, M und L vorgenommen. Die User-Storys und Tasks der ersten Iteration werden nun auf die linke Seite des Project-Boards gehängt.

Alles im Blick: Project-Board und Stand-up-Meetings

Das ↑ Project-Board dient als zentraler Informations- und Organisationsort des Projekts. Es visualisiert die Ziele und den Status der aktuellen Iteration und unterstützt zielgerichtete Diskussionen anhand der angebrachten User-Storys und Tasks. Zu Beginn einer Iteration befinden sich alle Karten auf der linken Seite. Sobald ein Schülerpaar mit einer Aufgabe beginnt, wird ein Klebezettel mit dem entsprechenden Task aus der To-do-Spalte genommen, mit Namenskürzel versehen (sodass alle Beteiligten genau sehen können, wer welche Tasks übernommen hat) und in die Spalte «In Progress» gehängt. Sobald der Task bearbeitet wurde, wird der Klebezettel nach rechts auf «Done» verschoben. Das Project-Board macht den Stand des Projektes sichtbar:

Abbildung 3.4: Project-Board in einer Iteration

Vor dem Project-Board finden auch die regelmäßigen ↑ Stand-up-Meetings statt, in denen zu Beginn einer Unterrichtsstunde organisatorische Aspekte der Projektdurchführung besprochen werden. Sie stellen eine geschickte Möglichkeit dar, den Stand des Projekts, das Geleistete der letzten Unterrichtsstunde und Probleme, aber auch die Ziele des Tages zu besprechen. In der Regel sind diese Meetings so kurz, dass es sich gar nicht lohnt, sich erst hinzusetzen. Durch das Stehen bemüht sich auch jeder, sich kurz zu fassen und sich auf das Wesentliche zu beschränken. Reihum beantwortet hier jede Schülerin und jeder Schüler die Fragen: Was habe ich seit dem letzten Mal getan? Was werde ich heute in Angriff nehmen? Welche Probleme hatte ich oder sehe ich auf mich zukommen und welche Hilfe brauche ich?

Schritt für Schritt vom Basic Pengu zum Advanced Pengu

Nachdem die Planungsphase der ersten Iteration abgeschlossen und das Project-Board eingerichtet wurden, beginnt nun die arbeitsteilige Implementierung, bei der die Schülerinnen und Schüler immer paarweise (↑ Pair-Programming) an einem selbst gewählten Task arbeiten. Während ein Schüler oder eine Schülerin die aktiv programmierende Rolle übernimmt und dabei das Vorgehen und die Arbeitsschritte erläutert, behält der oder die andere das große Ganze im Blick und stellt ggf. Fragen, sodass fortwährend kommuniziert wird. Alle 15 Minuten werden die Rollen getauscht. Bevor ein Task als erledigt gekennzeichnet werden darf, wird der resultierende Quelltext getestet. Am Ende der Implementierungsphase wird der neue Quelltext in die bestehende Codebasis integriert. Eine Viertelstunde vor Ende der Doppelstunde sind alle drei User-Storys fertig umgesetzt und integriert, sodass das Team auch das Ergebnis ausgiebig testen kann. Sind alle Tests erfolgreich bestanden, ist der erste ↑ Prototyp des Pengu-Spiels fertig und die somit vollständig bearbeiteten User-Storys können am Project-Board in die Spalte «Done» gehängt werden.

Ein Vorteil der iterativen Entwicklung ist es, dass die Schülerinnen und Schüler die Möglichkeit bekommen, Prototypen des Spiels in verschiedenen Entwicklungsphasen zu erstellen, auszuprobieren und dabei zu überprüfen, ob die Teilziele erreicht wurden. Im «Pengu»-Beispiel wird die erste Iteration bestimmt durch die Herstellung der Grundfunktionalitäten des Spiels. Der Vorteil der iterativen Vorgehensweise wird unmittelbar deutlich: Bereits so früh im Projekt ist das Spiel «spielbar», der erste Erfolg kann bereits getestet und gegenüber Mitschülerinnen und Mitschülern und der Lehrkraft demonstriert werden. Sogar das Hinzufügen weiterer Spielideen (Features) oder ein Umpriorisieren ist vor einer Iteration noch möglich, was bei linearen Vorgehensmodellen nahezu ausgeschlossen wäre. Zum Abschluss jeder Iteration kann und sollte reflektiert werden, wie gut der Prozess bis dahin gelaufen ist und ob sich das Team auf dem richtigen Weg befindet (↑ Reflexion).

In den weiteren Iterationen kommen nun nach und nach, der zuvor bestimmten Priorität entsprechend, die weiteren in den User-Storys festgehaltenen Funktionalitäten hinzu: das Bewegen der Wolke, Überqueren des Abgrunds und Springen in Iteration 2, Punktezähler, Sternenhimmel und Sternesammeln in Iteration 3 sowie das Berücksichtigen verschiedener Leben und das Gewinnen in Iteration 4. Erweiterungen des Spiels wie beispielsweise die Eiszapfen (Abbildung 3.5) können als niedrig priorisierte User-Story je nach Zeitvorrat gegen Projektende umgesetzt werden oder fallen weg.

Abbildung 3.5: Aufteilen einer umfangreichen User-Story in Tasks

In der Umsetzung des Spiels werden innerhalb jeder Iteration jeweils alle Phasen des klassischen Softwareentwicklungsprozesses (Anforderungsanalyse, Entwurf, Implementieren, Integrieren und Testen) einmal durchlaufen. Die Schülerinnen und Schüler erhalten entsprechend die Gelegenheit, diesen Prozess mehrfach in einem Projekt zu bestreiten und aus Erfahrungen zu lernen.

Praxiserfahrungen

Das beschriebene Spiel wurde inzwischen an verschiedenen Schulen in der Unterrichtspraxis, aber auch in Lehrerfortbildungen eingesetzt. Dabei war das Spiel als Unterrichtsgegenstand sehr motivierend und die Methoden erwiesen sich als sehr flexibel und für Projekte unterschiedlichster Ausprägungen geeignet. So können sowohl die Lerngruppen, Vorkenntnisse als auch die zeitlichen Gegebenheiten ganz unterschiedlich sein, weshalb in diesem Beispiel auf die Konkretisierung der Rahmenbedingungen verzichtet wurde. Schwierigkeiten ergaben sich mitunter aus der Notwendigkeit, die agilen Praktiken zuerst selbst erfassen zu müssen, z.B. wie User-Storys formuliert sein sollen und wie man diese in Tasks überführt. Mit diesem Beispiel ist nun eine Vorlage gegeben, die zur Orientierung für das Erlernen agiler Techniken und Praktiken und die Durchführung agiler Softwareentwicklungsprojekte im Informatikunterricht dienen kann.

Abbildung 3.6: Weitere User-Storys zum Pengu-Spiel

3.2 Im Anfangsunterricht durch Gestaltungsfreiräume begeistern

Ein Unterrichtsprojekt von Andreas Gramm

Steckbrief

Klassenstufe: 9 (Gymnasium, Wahlpflichtkurs)

Klassenstärke: 20 Schülerinnen und Schüler

Thema: Jump-’n’-Run-Spiel

Besonderheiten: Kollaboration lernen, «geplant-unfertiges» Produkt, Berufsbild Informatiker/Informatikerin

Agile Praktiken: Project-Board, User-Storys, Prototypen, Stand-up-Meeting, Pair-Programming, Reflexion

Programmiersprache/Entwicklungsumgebung: Scratch

Dauer und Frequenz: sechs Wochen mit einer Doppelstunde pro Woche

Zeitlicher Ablauf:

Gerade im Anfangsunterricht geht es mir darum, erlebbar zu machen, dass im Beruf der Informatikerin/des Informatikers das Gestalten von Produkten und das Arbeiten im Team im Vordergrund stehen. Dabei ist es wichtig, sich gut zu organisieren, um gemeinsam zu einem tollen Ergebnis zu kommen. Ziel und Motivation war es, den Schülerinnen und Schülern früh im Lernprozess zu zeigen, wie sie mit ihrem Wissen schon selbst etwas schaffen können, und sie so für das Fach zu begeistern und ihnen ein inspirierendes Berufsbild zu vermitteln.

Ausgangspunkt meiner Projektgestaltung war die Frage, wie ich im gegebenen zeitlichen Rahmen Vorgehensweisen bei der Entwicklung größerer Softwaresysteme für Lernende auf motivierende Art und Weise umsetzen und erlebbar machen kann. Ein typisches Problem, das ich in meinen bisherigen plangetriebenen, wasserfallähnlichen Projekten beobachtet habe, ist, dass Schülerinnen und Schüler mit ihrer Erfahrung kaum Anforderungen sinnvoll analysieren und Software entsprechend entwerfen konnten. Bis sie über die Voraussetzungen verfügen, um solche Projekte anzugehen, ist bei vielen das Interesse für das Fach schon der Auffassung gewichen, dass Informatik viel zu schwer sei. Unzufrieden war ich auch damit, dass Tests aus Zeitgründen zurückgestellt werden mussten und für eine Reflexion trotzdem viel zu wenig Zeit blieb.

Deshalb fand ich ein iteratives Vorgehen sehr verlockend. Man hat hierbei kurze Zyklen, sodass die Schülerinnen und Schüler in der ersten ↑ Iteration, den agilen Prozess und die agilen Praktiken kennenlernen und das erste interessante Zahnrädchen einer größeren Lösung entwickeln können. In den nächsten Iterationen kommen Schritt für Schritt weitere Zahnrädchen dazu. Dieses iterative Vorgehen ist mehr als die Aneinanderreihung von Umsetzungen kleiner, unabhängiger Probleme, denn die Teile fügen sich zu etwas Größerem zusammen. Wenn dabei sechs Schülerinnen und Schüler in Kooperation arbeiten, entsteht schnell etwas Spannendes. Das Endprodukt muss nicht perfekt sein, es muss nicht jede Idee umgesetzt sein. Trotzdem haben die Schülerinnen und Schüler einen lauffähigen ↑ Prototyp, den sie selbst gemeinsam entwickelt haben, und sie wissen, dass und wie es weitergehen könnte.

Projektvorbereitung
Rahmenbedingungen

Für die Schülerinnen und Schüler war es ihr erstes Schuljahr mit Informatikunterricht. Das Projekt wurde in der frühen Phase des Kurses mit Scratch durchgeführt und es sollten exemplarische Komponenten eines Jump-’n’-Run-Spiels entwickelt werden. Entgegen der Planung musste das Projekt zweimal für einen längeren Zeitraum unterbrochen werden. So fanden je eine Doppelstunde für Vorübungen im Herbst und für die Formulierung der User-Storys im Januar statt sowie vier Doppelstunden für die Realisierung im Frühjahr.

Agile Praktiken in der Vorbereitung

Vor dem Projekt hatten die Schülerinnen und Schüler grundlegende Programmierkenntnisse mit Scratch erworben und mit Kollisionen und Variablen wichtige Konzepte für das Spiel kennengelernt. Sie konnten auch Zustände und Abstandsveränderungen (z.B. die Anzahl der «Leben» einer Spielfigur) speichern und wussten, wie eine Kollision als Ereignis erfasst werden kann. Auf dazugehörige Arbeitsblätter mit erklärenden Beispielen konnten sie im Projekt zurückgreifen. Außerdem wurde vorbereitend auf das Projekt geübt, wie der Code einzelner Figuren (Sprites) in Scratch exportiert und importiert wird, wobei deutlich wurde, dass eine Quelltextintegration relativ einfach abläuft, solange man nicht in gleichen Figuren arbeitet. Diese Übung haben die Schülerinnen und Schüler im ↑ Pair-Programming durchgeführt und damit diese Praktik bereits vorbereitend geübt.

Warm-up-Spiel

Als Einstieg wurde mit allen 20 Schülerinnen und Schülern gemeinsam das Ball-Point-Game (↑ agile Spiele) gespielt, bei dem sie einen Heidenspaß hatten und eine deutlich sichtbare Optimierung erzielten. Es war eine gelungene Motivation, die zeigte, wie wichtig Absprachen für eine erfolgreiche Kooperation sind und wie man einen iterativen Prozess durch stringentes Planen, Handeln und Reflektieren optimieren kann.

Projektdurchführung
Themenwahl und Teams

Der Kurs wurde nun in drei etwa gleich große Gruppen geteilt, wobei die Schülerinnen und Schüler selbst die Teamzusammensetzung wählten. Sie waren von Anfang an interessiert und konnten ihre Erfahrung mit Computerspielen beim Sammeln und Diskutieren erster Ideen für ihr Jump-’n’-Run-Spiel einbringen. Anschließend formulierten sie erste User-Storys, die sie in einer weiteren Doppelstunde konkretisierten, um weitere ergänzten und am ↑ Project-Board befestigten. Auf eine Unterscheidung zwischen ↑ User-Storys und ↑ Tasks wurde in diesem Projekt verzichtet, da sich in Scratch die Beschreibung aus Kunden-und Entwicklersicht wenig unterscheidet. Zusätzlich wurde darauf geachtet, dass die User-Storys klein waren, also nur wenige, einfache Aufgaben umfassten. Eine ↑ Aufwandsabschätzung erfolgte relativ über die T-Shirt-Größen S, M, L:

Abbildung 3.7: Aufwandseinschätzung mit Hilfe von den T-Shirt-Größen S (small), M (middle) und L (large)

Eine logische Bearbeitungsreihenfolge ergab sich im Verlauf von selbst, d. h. auf ein Priorisieren vorab konnte verzichtet werden, wodurch die Vorarbeiten weiter verkürzt wurden.

Stand-up-Meetings und Planung

Die Umsetzung erfolgte in zwei Iterationen von jeweils zwei Doppelstunden. Die zu Beginn jeder Doppelstunde stattfindenden ↑ Stand-up-Meetings gaben den Lernenden eine Struktur vor, in der sie den Stand ihrer Arbeit selbstständig rekapitulieren konnten. Anschließend planten sie für die kommende Doppelstunde, sodass es entsprechend zwei Planungen pro Iteration gab. Dieser Ablauf mit zwei Planungen verhinderte, dass sich die Schülerinnen und Schüler Teile ihrer Planung bis zur nächsten Doppelstunde merken mussten, und ermöglichte gleichzeitig, nur jede zweite Doppelstunde zu integrieren und einen lauffähigen Prototyp zu erzeugen. In den Planungen konnten weitere User-Storys ergänzt werden, soweit dies die Umsetzung der Spielidee erforderlich machte. Falls am Ende einer Doppelstunde nicht alle ausgewählten User-Storys umgesetzt waren, wurden sie in die Folgestunde geschoben, auch wenn sie so nicht mehr Teil des jeweiligen Prototyps waren. Genauso gut konnten Programming-Pairs auch nicht ausgewählte User-Storys vorziehen, wenn zu wenig Aufgaben geplant waren.

Fragen und Probleme, die sich während der Umsetzung ergaben, konnten von den Teams in zusätzlichen Spontan-Meetings vor dem Board gelöst werden. Zwei oder drei Mal traten im Projektverlauf organisatorische bzw. fachliche Probleme auf, die entweder alle hatten oder auf die sie in Kürze stoßen würden. In diesen Situationen habe ich das Thema, beispielsweise das Abspeichern der Dateien in einem für alle zugänglichen Netzlaufwerk, zu Beginn der folgenden Doppelstunde kurz im Plenum aufgegriffen und, wenn es sich anbot, von einzelnen Teams erarbeitete Lösungen für das Problem dem gesamten Kurs vorstellen lassen.

Pair-Programming und Einzelarbeit zu Hause

Die konkrete Umsetzung mit Scratch erfolgte im Pair-Programming, wobei der Navigator aufgrund der wenigen Konzepte und Datenstrukturen, die bekannt waren, weniger auf alternative Umsetzungsmöglichkeiten der konkreten Story, sondern mehr auf das Zusammenspiel der unterschiedlichen arbeitsteilig umgesetzten Spielereignisse achten musste. Wichtig war auch, dass der Driver stets seine Ideen bei der Umsetzung ausdrückte und die Schülerinnen und Schüler so lernten, ihr Vorgehen beim Programmieren mit Worten zu beschreiben und kritisch zu hinterfragen. Wenn sie wollten, konnten die Schülerinnen und Schüler sich ihr Projekt auf einen USB-Stick kopieren und daran zu Hause weiterarbeiten. Die dabei umgesetzten Funktionalitäten mussten in der folgenden Doppelstunde dem Team im Stand-up-Meeting vorgestellt werden, ehe das Team entschied, ob sie in das Projekt integriert werden durften.

Teamarbeit und Transparenz

Fast alle Schülerinnen und Schüler haben sich für ihr Projekt mitverantwortlich gefühlt. Einzelne, die sich herausnehmen, gibt es wahrscheinlich immer, aber hier ist ein solches Verhalten deutlich aufgefallen und es war für diejenigen unangenehmer als gewöhnlich.

Reflexion

Zum Abschluss des Projekts wurden die letzten Prototypen der drei Teams, die, wie von mir zum Projektstart angekündigt, keine komplette Umsetzung des jeweiligen Spiels waren, im Plenum vorgestellt, zusammen mit einer zu Hause vorbereiteten individuellen ↑ Reflexion des Projekts. Dabei berichteten alle Schülerinnen und Schüler, viel über Softwareentwicklung und Kooperation im Team gelernt zu haben. Letzteres wurde übereinstimmend wie folgt zusammengefasst: Absprachen treffen ist wichtig, aber mühsam und teilweise schwierig. Aber ohne Absprachen kann eine produktive Zusammenarbeit nicht funktionieren. Neben dieser Erfahrung war die Präsentation der Arbeitsergebnisse aber vor allem von Stolz auf das Erreichte geprägt.

Bewertung der kooperativen Projektarbeit

Eine Herausforderung stellt die ↑ Bewertung von Leistungen dar, die von der Gruppe bzw. individuell in einem Projekt erbracht werden, da zwei unterschiedliche Interessen kollidieren: Zum einen will ich die Schülerinnen und Schüler befähigen, etwas zu tun, und gleichzeitig messe ich, was sie tun. Ein weiterer Punkt ist die Frage, welchen Wert eine individuelle Idee hat und welcher Wert der Fähigkeit der Gruppe, sie erfolgreich umzusetzen, zukommt. Nachdem die Schülerinnen und Schüler ihre Projekte bereits weitgehend selbstorganisiert durchgeführt hatten, war es mir wichtig, sie auch in den Prozess der Bewertung einzubeziehen. Gemäß dem Prinzip einer Poolnote bekam jede Gruppe von mir entsprechend ihrer Gesamtleistung eine Anzahl von Punkten. Die Aufgabe der Gruppe bestand nun darin, sich auf eine Verteilung der Punkte auf die Gruppenmitglieder zu einigen und sich so mit der Frage auseinandersetzen, welche Fähigkeiten und Fertigkeiten jedes einzelnen Mitgliedes die Gruppe im Projekt besonders gut vorangebracht haben und welche eher hemmend waren. Die so erzielte Note umfasste sowohl die Leistung bezüglich des Produkts als auch den Beitrag zur Zusammenarbeit.

Zwei Gruppen haben sich sehr schnell geeinigt, die Punkte gleich aufzuteilen. An dieser Stelle war es mir nicht wichtig, einzugreifen oder mir die Überlegungen darlegen zu lassen, da sich meiner Beobachtung nach alle für ein gutes Arbeitsergebnis engagiert hatten. Interessant war eine Gruppe, in der es Spannungen gegeben hatte: Eine leistungsstärkere Schülerin meinte, dass ihr Beitrag mehr Anerkennung finden müsste, die anderen Gruppenmitglieder betonten dagegen, dass erst die Tatsache, dass sie der Gruppe eine Überarbeitung zugesagt, das aber nicht eingehalten hat, ein besseres Gruppenergebnis verhindert hat. Nach langer Diskussion mit wenig Verständnis für die jeweils andere Position haben sie sich als Kompromiss auf die gleiche Punktzahl für alle Gruppenmitglieder geeinigt. Die Schülerinnen und Schüler haben damit eine sehr ambivalente Situation bewältigt, die ihnen auch im späteren Leben begegnen wird.

Beobachtungen und Erfahrungen

Durch die agile Herangehensweise gelang es meinen Schülerinnen und Schülern tatsächlich, bereits früh im Lernprozess gemeinsam, mit Begeisterung und Spaß etwas Tolles zu schaffen. Da sich im Projekt der Ablauf einer Iteration wiederholte und eine klare Struktur hatte, musste ich nicht wie früher in wasserfallähnlichen Projekten moderieren und den nächsten Schritt vorgeben. Die Schülerinnen und Schüler arbeiteten eigenständiger und zunehmend selbstbewusster. Die positive Bestärkung der Selbstwirksamkeit durch die iterative Vorgehensweise und die früh und regelmäßig in den Prototypen sichtbaren Arbeitsergebnisse sehe ich sehr positiv. Die regelmäßigen und häufigen Anlässe zur Kommunikation in der agilen Arbeitsform boten den Schülerinnen und Schülern, die zum größten Teil nicht deutscher Herkunftssprache waren, zudem Gelegenheit zur Verbesserung ihrer Sprachkompetenz im Sinne einer Sprachbildung im Fachunterricht.

Was mir gefehlt hat, war, dass die Schülerinnen und Schüler während des Projekts in fachlicher Hinsicht nicht nur bekannte Fähigkeiten ausbauen und vertiefen, sondern sich im Rahmen des Projekts auch neue Konzepte erarbeiten. Im nächsten Projekt werde ich daher Anregungen bereitstellen, die die Erarbeitung neuer Fachkonzepte initiieren.

Für mich sehr entlastend war, dass von Anfang an klar kommuniziert war: Wir werden nur ein Stück des Spiels implementieren, es wird funktionieren, aber nicht ausgereift sein. Es bestanden weder Anspruch noch Notwendigkeit, in der gegebenen Zeit alle Funktionalitäten umzusetzen, um ein sinnvolles Produkt zu haben. Auch wenn so nur kleine Funktionen entstanden sind: Die Schülerinnen und Schüler haben erfahren, dass und wie sie gemeinsam selbst Informatiksysteme erschaffen und nach ihren eigenen Wünschen und Interessen gestalten können, und waren nun hoch motiviert, weitere Themengebiete der Informatik zu erarbeiten. Insofern ist die Entscheidung, derartige Projekte früh im Schuljahr durchzuführen, sehr gut, weil es bei den Lernenden eine positive Einstellung zum Fach erzeugt. Die agilen Methoden, mit denen ich dieses Ziel tatsächlich erreichen konnte, sind für mich deshalb eine wirkliche Bereicherung.

3.3 In der Oberstufe komplexe Anwendungssoftware agil entwickeln

Ein Unterrichtsprojekt von Peter Brichzin

Steckbrief

Klassenstufe: 11 (Gymnasium, Wahlpflichtunterricht)

Klassenstärke: 20-25 Schülerinnen und Schüler

Thema: Entwicklung einer Anwendungssoftware mit grafischer Benutzeroberfläche, persistenter Datenspeicherung und dynamischer Datenstruktur

Besonderheiten: hohe Komplexität, stark leistungsinhomogene Schülergruppen, thematische Freiheit, methodische Varianten: Student-Story, Modelling-Story, digitales Project-Board

Agile Praktiken: Iterationen, Project-Board, User-Storys, Tasks, Prototypen, Stand-up-Meeting, Pair-Programming, Repository, Testen, Timeboxing, Reflexion, Refactoring

Programmiersprache/Entwicklungsumgebung: Java/BlueJ, Java Editor, IntelliJ oder Eclipse

Dauer und Frequenz: acht Wochen mit drei Stunden pro Woche

Zeitlicher Ablauf:

Software (nach dem Wasserfallmodell) vollständig zu planen, dann einzelne Komponenten umzusetzen, diese zusammenzuführen und zu testen, ist eine sehr anspruchsvolle Aufgabe, die viel Erfahrung voraussetzt. Schülerinnen und Schüler machen diese Erfahrung nur sehr selten: Selbst den Leistungsstärksten bereitet der Entwurf erhebliche Schwierigkeiten und die anderen können sich nur wenig einbringen. Deshalb verpufft leicht die Begeisterung für die Entwicklung einer eigenen Software, wenn am Anfang erst zwei bis drei Wochen geplant wird. Daneben gibt es noch eine weitere kritische Stelle: das Zusammensetzen typischer Komponenten wie Logik, grafischer Benutzeroberfläche und Datenhaltung. Egal wie oft man als Lehrkraft die Wichtigkeit guter Schnittstellenabsprachen und eines rechtzeitigen Zusammensetzens betont, tendieren die Schülerinnen und Schüler dazu, das Zusammensetzen zu verschieben, weil sie mit ihren Komponenten noch nicht zufrieden sind. So musste ich mehrfach miterleben, wie durch das späte Erkennen von unzureichenden Schnittstellenbeschreibungen aufwendige Korrekturen notwendig wurden und die verbleibende Zeit (bis zum Schuljahresschluss) nicht reichte, um darauf zu reagieren. Das resultierende unfertige Ergebnis, eine nur in Teilen laufende Software, ist nicht nur für die Schülerinnen und Schüler unbefriedigend, sondern natürlich frage ich mich als Lehrer auch, wie ich den Rahmen verbessern kann. Eine stärkere Steuerung und Führung von meiner Seite aus ist keine Option, denn wesentliche Ziele einer Projektarbeit sind sich selbst zu organisieren, eigene Entscheidungen zu treffen und Verantwortung zu übernehmen. Das oben geschilderte Scheitern beinhaltet eine oft (schmerzhafte) Erfahrung, die im Lernprozess aber sehr hilfreich sein kann. Damit jedoch am Ende ein Erfolg und damit Begeisterung für das Erstellen einer Software im Team steht, sollten (unvermeidbare) Irrwege und ihre Reflexion möglichst früh im Projektverlauf stattfinden. Genau dies ist einer der Vorteile eines iterativen Vorgehens agiler Projekte mit einem schrittweisen Planen, einer frühen Integration und dem Lernen aus Fehlern. Weitere Vorteile sind eine höhere Transparenz des Projektstands und Erfolgserlebnisse durch funktionsfähige Prototypen.

Projektvorbereitung
Rahmenbedingungen

Mittlerweile zum dritten Mal habe ich ein Softwareprojekt in der Oberstufe agil angeleitet. Die Schülerinnen und Schüler bringen als Vorwissen einerseits aus Jahrgangsstufe 10 Grundlagen zur objektorientierten Modellierung und Programmierung mit, andererseits aus Jahrgangsstufe 11 praktische und theoretische Kenntnisse zu den Datenstrukturen Liste, Baum und Graph. Der mit 26 Stunden ausgewiesene abschließende Lehrplanpunkt «Softwaretechnik» ermöglicht eine ca. achtwöchige reine Projektphase bei drei Stunden Unterricht pro Woche. Die Leistungsstärken der Schülerinnen und Schüler waren immer sehr heterogen. Einige brachten bereits Erfahrungen, z.B. in der Programmierung grafischer Benutzeroberflächen und der Verwendung professioneller Entwicklungsumgebungen, ein, für andere war es bereits eine Herausforderung, auch kleine Teilaufgaben innerhalb des Teams selbstständig zu lösen. Auf Eigeninitiative der Leistungsstärkeren nutzt ein zunehmender Teil der Schülerinnen und Schüler im Projekt auch IntelliJ oder Eclipse, weil dort die automatische Codegenerierung, die Einbindung von Bibliotheken und das Refactoring leichter sind als in den sonst im Unterricht verwendeten didaktischen Entwicklungsumgebungen BlueJ und JavaEditor.

Agile Praktiken in der Vorbereitung

In der Mittelstufe werden (bisher) bei uns Projekte nicht agil durchgeführt, entsprechend sind agile Praktiken und Techniken für die Lernenden neu. Ein wesentlicher Schlüssel für einen Projekterfolg ist meiner Meinung nach das Kennenlernen und Einführen einzelner Techniken bereits im Vorfeld. Dies ist im regulären Unterricht ohne Projektkontext für die Bausteine ↑ User-Storys, ↑ Tasks, ↑ Prototypen, ↑ Pair-Programming, ↑ Testen und ↑ Repositorys sehr gut möglich.

User-Storys: Bei jeder anwendungsbezogenen Aufgabe im regulären Unterricht können zu Beginn eine Kundensicht eingenommen und Anforderungen in Alltagssprache formuliert werden.

Tasks: Teilaufgaben aus Entwicklersicht ergeben sich automatisch bei der Implementierung von User-Storys.

Pair-Programming: Peer-to-Peer-Wissenstransfer, indem für einzelne Stunden Leistungsstärkere mit Leistungsschwächeren ein Paar bilden und dabei der Leistungsschwächere zur Rolle des Drivers verpflichtet wird.

Prototyping: Im folgenden Kasten wird ein exemplarisches Prototyping präsentiert, das im Unterricht (passend zum für mich gültigen Lehrplan) neue informatische Inhalte im Anwendungskontext einer Patientenverwaltung für ein Wartezimmer vergegenständlicht. Parallel zu den Lerninhalten wird über mehrere Wochen im Kurs sukzessive eine einfache Software entwickelt.

Abbildung 3.8: Prototyping für eine Patientenverwaltung

Testen: Die Qualitätskontrolle gehört bei Lehrplaneinheiten mit Programmieren zum Informatikunterricht dazu. In der Oberstufe bietet es sich beispielsweise an, dass die Lehrkraft Testklassen verteilt und Schülerinnen und Schüler durch das Ausführen von Testfällen die Qualität ihrer Programme selbst überprüfen können. Sukzessive können die Schülerinnen und Schüler auch eigene Testklassen schreiben. Auch der Einsatz eines Debuggers ist zu empfehlen, weil er ein Verständnis für den dynamischen Ablauf eines Programms schafft und bei der Fehlersuche hilfreich ist.

Repositorys: Versionskontrollsysteme können im Unterricht bereits zur Verteilung von Programmgerüsten und Musterlösungen verwendet werden. Außerdem lässt sich durch die Vorgabe einer abstrakten Oberklasse der Vorteil verteilten Arbeitens sehr schön demonstrieren: Wenn in einer Klasse mit 20 Schülerinnen und Schülern jede und jeder 15 Minuten für das Schreiben einer Unterklasse benötigt, dann hat man nach den 15 Minuten nicht nur eine, sondern 20 verschiedene Unterklassen. Wenn diese gesammelt und für alle sichtbar vorliegen, ist das beeindruckend.

Für ein Vertiefen dieser agilen Techniken und Praktiken fehlt meist die Zeit, aber bereits dieser erste Einstieg ermöglicht zu Projektbeginn eine höhere Konzentration auf Inhaltliches.

Warm-up

Die Schülerinnen und Schüler erhielten zwei methodisch unterschiedliche Einführungen in die agile Projektorganisation. Zunächst gab ein Kurzvortrag von knapp 20 Minuten einen Überblick über die iterativ-inkrementelle Vorgehensweise als zentralen Prozessgedanken, die Planung von ↑ Iterationen mithilfe von User-Storys und Tasks, Prototypen als Ergebnisse sowie die Methodenbausteine ↑ Timeboxing und Reflexionstreffen (↑ Reflexion).

Als zweiten Impuls wählte ich ein praktisches agiles Arbeiten. Dafür eignen sich ↑ agile Spiele: Mehrfach habe ich die Marshmallow Challenge durchgeführt, um das Prototyping begreifbar zu machen. Beim letzten Kurs bin ich aber dazu übergegangen, den Schülerinnen und Schülern stattdessen eine konkrete Aufgabe zu geben, an der sie in sehr kurzer Zeit (75 Minuten) den agilen Prozess kennenlernen können. Jedes Team sollte ein eigenes Backlog mit priorisierten User-Storys für eine Lernkarten-Software erstellen. Zur ersten User-Story sollten Tasks skizziert und ggf. sogar die ersten Quelltextzeilen programmiert werden. Die Teams wurden zufällig zusammengestellt, um eingespielte Banknachbarn zu trennen. Ziel war es, mit einer anschließend stattfindenden Reflexion (20 Minuten) alle wesentlichen Bestandteile einer Iteration zu durchlaufen: eigenständige Planung in unterschiedlichen Detailgraden, Implementierung (war kein Schwerpunkt, weil die Schülerinnen und Schüler diese aus dem Unterricht kennen) und eine Prozessreflexion. Trotz der extrem kurzen Zeit gab es gute inhaltliche Ergebnisse, wie die folgende Abbildung zeigt.

Abbildung 3.9: Knapp formulierte User-Storys für eine Lernkarten-Software

Die Reflexion brachte die folgenden wichtigen Punkte hervor. Teilweise sind sie allgemeiner Art, teilweise als individuelle Anliegen meiner Schülerinnen und Schüler zu verstehen.

•Bei der Formulierung von User-Storys sind Stichworte zu wenig.

•Die aktive Beteiligung aller Teammitglieder ist wichtig. (Einige äußerten im Vorfeld die Sorge von Trittbrettfahrern im Projekt.)

•Das unerklärte Einbringen von Konzepten, die über den bisherigen Unterricht hinausgehen, grenzt Schülerinnen und Schüler mit weniger Programmiererfahrung aus. Das KISS-Prinzip ist eine mögliche Lösung für dieses Problem.

•Mehrere Schülerinnen und Schüler äußerten den Wunsch, ein digitales Project-Board führen zu dürfen, um auch von zu Hause darauf Zugriff zu haben.

•Die knappe Zeitvorgabe macht es notwendig, sich für einzelne Aufgaben Zeitrahmen zu setzen (↑ Timeboxing), um fokussierter zu arbeiten und «sich im Kreis drehende» Diskussionen zu beenden.

•Zentrale Werte wie Respekt, Mut, Zielstrebigkeit, Einfachheit und Feedback werden angesprochen.

Gegenüber einem agilen Spiel bestand der Vorteil diese Warm-ups darin, das bereits eine ganze Iteration inklusive Reflexion durchlaufen wurde. Zudem erhielten die Schülerinnen und Schüler eine Vorstellung, wie die Arbeit in zufällig ausgewählten Teams mit unterschiedlichen Leistungsniveaus funktioniert. Im Gegensatz dazu stellt ein Einstieg durch ein agiles Spiel das Soziale und Emotionale stärker in den Vordergrund. Ich wähle den Einstieg inzwischen immer möglichst passend zu den Stärken und Schwächen der Schülerinnen und Schüler des jeweiligen Kurses.

Projektdurchführung
Themenwahl und Teams

Die Schülerinnen und Schüler waren frei in der Themenwahl. Einzige fachliche Vorgaben waren, dass eine grafische Benutzeroberfläche, persistente Datenspeicherung und dynamische Datenstrukturen Bestandteile der Software sein müssen. Um die Themenwahl zu fokussieren, hatten vor Projektbeginn alle Schülerinnen und Schüler den Arbeitsauftrag, über einen Forumseintrag in der Lernplattform des Kurses ein Thema für das Projekt vorzuschlagen, was u. a. zu folgenden Themenvorschlägen führte:

Spiele: Black Jack, Poker, Schach, Arcade-Game, Brettspiel TAC, Jump-’n’-Run, Rubiks-Cube-Löser

Anwendungssoftware: individualisierte Anzeige des Vertretungsplanes auf dem Handy/Computer, digitales Hausaufgabenheft, Kassensystem für Pausenverkauf, Wettprogramm für die Fußball-WM, Kochbuch, Reiseführer, Führerscheintraining, Nachhilfevermittlung, eine Software für die Lehrmittelbibliothek und ein Vokabeltrainer mit einem Beispielsatz zu jeder Vokabel.

Ich stellte die eingebrachten Vorschläge vor, kommentierte diese (beispielsweise sind reale Kunden wie bei der Bibliothekssoftware motivierend; eine Nachhilfevermittlung ist nur sinnvoll als Webservice, der aber erst im Lehrplan der Jahrgangsstufe 12 Thema ist) und jedes Team konnte sich dann ein Thema wählen.

Bei einer Teamgröße von sechs bis acht Mitgliedern musste ich pro Kurs drei Themen betreuen. Zur Gruppeneinteilung habe ich abhängig von der jeweiligen Lerngruppe folgende Verfahren erprobt, die jeweils unterschiedliche Vor- und Nachteile haben:

•Gruppeneinteilung nach Themenwunsch, mit dem Vorteil, dass damit stark auf die Schülerwünsche eingegangen wird.

•Leistungshomogene Gruppeneinteilung, bei der sich jeder in der Gruppe fachlich gleichermaßen einbringen kann und die Gefahr der Überforderung Einzelner durch technisch anspruchsvolle Lösungsansätze anderer gering ist; nach der Einteilung wählt die Gruppe ein Thema für sich aus.

•Leistungsinhomogene Gruppeneinteilung, sodass pro Gruppe in etwa ein gleiches Verhältnis von Leistungsstarken und -schwachen vorhanden ist. Diese Variante hat den Vorteil des Wissenstransfers innerhalb der Gruppe, sowie eine höhere Erfolgsquote für ein lauffähiges Endprodukt bei allen Gruppen.

Nachdem nun die Teams und Themen stehen, kann das Projekt beginnen. Da Ziele und Umsetzung einzelner Methoden in den Kapiteln 4 und 5 ausführlich beschrieben werden, gehe ich im Folgenden nur auf Besonderheiten ein.

User-Story und die Varianten Modeling-Story und Student-Story

Der Beginn mit der (Grob-)Planung auf Ebene von User-Storys funktioniert sehr gut, weil sich alle unabhängig von ihrer Programmiererfahrung gut einbringen und die ersten Implementierungsschritte spätestens nach drei Schulstunden beginnen können. Jedoch ist bei zunehmender Prototyp-Größe die Zahl der Klassen nicht mehr so einfach zu überblicken bzw. kann es notwendig sein, dass eine sehr zentrale Klasse zeitgleich von mehreren Paaren verändert werden muss. Hieraus entsteht im Entwicklungsverlauf der Bedarf, einen Überblick über die Klassen, deren Schnittstellen und ihre Beziehungen zu bekommen. An diesem Punkt ist es sinnvoll, ein Klassendiagramm zu erstellen, welches die Grundlage für weitere Überlegungen und Besprechungen ist. In der Regel muss ich den Anstoß dazu geben. Passend zum agilen Projektablauf schlage ich dazu in einem Planungsmeeting vor, eine von mir als Modeling-Story bezeichnete besondere User-Story aufzunehmen. Im Nachgang zur Modellierung ist häufig ein Refactoring nötig. Modellieren und Refactoring brauchen zwar Zeit, sodass in dieser Iteration weniger Funktionalitäten umgesetzt werden. Da das verteilte Arbeiten danach aber wieder leichter geht, weil die Aufgaben und Schnittstellen klarer sind, sehen die Schülerinnen und Schüler auch den Mehrwert.

Ebenso ermuntere ich dazu, Student-Storys – spezielle User-Storys, in denen Wissen aufgebaut wird – über das Project-Board einzupriorisieren. Deren Inhalte können Einarbeitung in neue Themen wie eine Datenbankanbindung sein oder aber auch der Wissenstransfer von Leistungsstärkeren zu -schwächeren. Da diese Lernprozesse Zeit benötigen, ist es wichtig, sie über das Project-Board transparent zu machen und dann auch nach Beendigung mit einem Setzen auf «Done» zu feiern.