Bei meinem letzten Beitrag hatte ich es schon angesprochen: Agiles Projektmanagement gehört in die Schule. Worauf mir jemand über Twitter meinte, dass er das nun gar nicht so sehen würde. Und gestern Abend habe ich dann noch zufällig über den Hashtag #agileDidaktik gestolpert. Ich dachte mir also, dass es mal an der Zeit ist mein (Halb-)Wissen hier zum Besten zu geben. Geplant ist dabei eine Aufteilung in mehrere Beiträge. Der erste Beitrag, also dieser hier, wird in gaaaanz einfachen Zügen erstmal das Wasserfallmodell als klassisches Projektmanagementmodell darstellen. Danach gehe ich auf agiles Projektmanagement ein. Der nächste Beitrag wird dann auf agile Didaktik abzielen und am Ende kommen dann noch vielleicht konkrete Anwendungsbeispiele. Und abschließend versuche ich noch einen Realitätsabgleich bzw. diskutiere das Gesagte.
Doch bevor es richtig losgeht, noch kurz ein Wort zu mir und warum ich der Meinung bin, dass ich hier was dazu schreiben kann. Ich habe nach dem Referendariat zwei Jahre als Entwickler, Drehbuchautor und Projektleiter für Lernsoftware gearbeitet und dabei so einiges erlebt. Die meisten Projekte wurden damals noch nach dem Wasserfallmodell abgearbeitet. Inklusive aller Problemen, die dabei auftreten. Extreme Programming kam zwar zum Einsatz, aber an agiles Projektmanagement habe ich zumindest damals nicht gedacht und war auch gar nicht vorgesehen. Erst während meiner aktuellen Schulzeit kam ich mit diesem Konzept in Kontakt und habe mich selbst eingearbeitet. Daher präsentiere ich hier auch nur Halbwissen und alle voll ausgebildeten Projektmanager mögen mir verzeihen, wenn ich die Dinge hier stark vereinfache.
Agiles Projektmanagement
Bevor ich mit dem agilen Projektmanagement anfange, möchte ich einen Blick auf das klassische Wasserfallmodell werfen.
Das Wasserfallmodell
Das grundlegendste Projektmanagementmodell ist und bleibt immer noch das Wasserfallmodell, das ungefähr wie folgt abläuft:
Zunächst sagt der Kunde was er will – was er aber meist nicht wirklich in Worte ausdrücken kann. Dies wird in einem sogenannten Lastenheft zusammengefasst. Das Team, dass die Idee des Auftraggebers später umsetzen wird, geht dann in die Details und überlegt sich konkret und messbar wie was werden soll. Als Ergebnis entsteht das Pflichtenheft, das vom Auftraggeber abgenommen wird und später als Kriterium für die Abnahme dient.
Beide Stufen werden also mit einem sogenannten Meilenstein beendet. Meilensteine beschreiben Momente während eines Projekts, ab dem eine Phase nicht mehr bearbeitet wird. Ist das Pflichtenheft abgenommen, so wird es nicht mehr geändert – egal was passiert. Und das ist aber auch genau das Problem. Dazu aber später.
Ist das Pflichtenheft vorhanden, so kann man sich erstmal Gedanken darüber machen, wie die einzelnen Elemente, die im Pflichtenheft beschrieben wurden, nun umgesetzt werden können. Bei der Softwareentwicklung malt man die unterschiedlichsten Diagrammarten, entwirft Oberflächen und zeichnet Abläufe. Plant man eine Grillparty, kann man sich vielleicht Gedanken darüber machen welche Art von Grill denn nun genau zu organisieren ist.
Ist diese Phase beendet, einen richtigen Meilenstein gibt es hier nicht, so wird der Entwurf nun umgesetzt bzw. implementiert. Spätestens jetzt kommt es bei vielen Projekten zu Problemen. Und je nach Modell wird darauf nun anders reagiert. Beim Wasserfallmodell fängt die ganze Prozedur wieder von vorne an: Man sagt seinem Kunden, dass etwas so nicht geht. Dieser passt dann sein Lastenheft an und das Arbeitsteam schreibt ein neues Pflichtenheft. Dann wird wieder entworfen und dann wieder implementiert. Und wenn man Pech hat, hängt man fast in einer Endlosschleife fest. Gerade im Bereich der Informatik der letzten 20 Jahre hat sich soviel geändert, dass quasi ständig angepasst werden musste, weil sich die ganze Zeit die Rahmenbedingungen geändert haben: Das Internet war endlich so, dass man es benutzen konnte, also weg von irgendwelchen lokal installierten Programmen zu Web-Anwendungen. Diese wurden dann beispielsweise mit Java realisiert, nur um dann wieder mit anderen Technologien umgesetzt zu werden, da Java zu unsicher war. Und kaum war das geschafft, musste alles auf Smartphones angepasst werden. Hat man in dieser Zeit versucht eine komplexe Software zu entwickeln und hat sich wirklich strikt an das Wasserfallmodell gehalten, hat man immer wieder von vorne angefangen (das sind die schwarzen Pfeile).
Und nur damit das deutlich wird, nicht nur die Technologien sind daran schuld. Ich selbst habe den Wechsel vom G9 zu G8 und wieder zurück zum G9 erlebt und die Probleme der Softwarefirmen darauf zu reagieren.
Und nicht nur das. Auch die Lehrpläne, das sind in diesem Modell quasi die Lastenhefte, ändern sich die ganze Zeit. Wir Lehrer entwickeln dann alleine oder im Rahmen einer Fachschaftsbesprechung ein Pflichtenheft. Oder wir nehmen einfach das Schulbuch als Pflichtenheft. Denn an den Aufgaben im Buch wird doch eigentlich gemessen, ob ein Schüler den Unterrichtsstoff verstanden hat oder nicht – ich denke da vor allem an Mathebücher.
Und wenn dann die Schüler nicht die Leistung bringen, die erwartet wird, fängt man wieder von vorne an. Eventuell werden Lehrpläne angepasst – auch schulintern. So werden vielleicht die binomischen Formeln schon mal vorgezogen. Oder man überarbeitet sein “persönliches” Pflichtenheft. Und so geht es Jahr um Jahr weiter.
Das dieses Modell manchmal gut funktioniert, vor allem bei kurzen, kleinen und übersichtlichen Projekten, mag man sich noch vorstellen. Aber bei komplexen, lang andauernden Projekten und vor allem bei Projekten mit unklarem Ziel nicht so gut funktioniert, können sich vielleicht manche nun vorstellen. Und für diejenigen, die sich das nicht vorstellen können noch ein einfaches Beispiel, das meiner Ansicht nach nicht so gut mit dem Wasserfallmodell umgesetzt werden kann bzw. konnte: das Erstellen des Medienkonzepts der bayerischen Schulen.
Als der Auftrag an die bayerischen Schulen rausging, jede Schule soll ein Medienkonzept erstellen, gab es nur sehr geringe Vorgaben, die auch relativ unscharf waren (Lastenheft). Jede Schule hat daraufhin ein Medienkonzept entwickelt (Pflichtenheft). Darin wird unter anderem beschrieben, wie die Fortbildungen des Kollegiums absolviert werden sollen. Da sich die Anforderungen der Kolleginnen und Kollegen aber im Laufe der Jahre ändert wird, sie werden digital kompetenter, neue Hard- und Software kommt in die Schulen, muss das Fortbildungskonzept immer wieder angepasst werden. Ein zumindest zu detailliertes Pflichtenheft ist hier in meinen Augen fehl am Platz.
Wie nun agiles Projektmanagement eventuell helfen kann, stelle ich im kommenden Beitrag vor.