Wie entwickelt man neue Studiengänge, wenn die Zielvorgaben stehen, wenn klar ist, wie der Studiengang heißen soll, was die Studierenden am Ende können sollen und welche Erwartungen die sonstigen Anspruchsgruppen (z.B. eine gute Planbarkeit aus Verwaltungssicht, regionale PartnerInnen etc.) haben?
Eine leider oft anzutreffende Form ist: Man beauftragt eine nicht präzise genug definierte Arbeitsgruppe, die sich erst einmal finden muss, dann tagt sie, und sie tagt, und tagt, und tagt, hin und wieder müssen andere Instanzen (Fachbereiche, Dekanate, die Hochschulleitung und das FBI) einbezogen werden, bevor es mit dem Tagen weiter geht. Dann kommt irgendwoher ein diffuser Endtermin des überhaupt nicht beschriebenen Prozesses – z.B. die Einreichungsfrist bei der Akkreditierungsagentur – und dann wird im Rekordtempo vor sich hingewerkelt, mit oft nicht völlig befriedigendem Endprodukt, reichlichen Kollateralschäden und der Einsicht, dass ein so wichtiges Projekt wie Studiengangsentwicklung nicht einfach so im Hochschulalltag platziert werden kann.
Das muss nicht sein, wenn die Entwicklungsarbeit von vornherein sinnvoll geplant wird. Für WissenschaftlerInnen, die gerne eigenständig und in flexiblen Teams mit eher flachen Hierarchien arbeiten, bietet sich eine agile Studiengangsentwicklung an. Mit agilen Planungsprinzipien ist dabei ein aus der Softwareentwicklung bekanntes Vorgehen gemeint, das sehr flexibel, proaktiv und dezentral ein Projekt umsetzt und mittlerweile auch in vielen Verwaltungen zum Standard geworden ist. Agiles Planen und Organisieren liegt dabei quer zum bekannten Projektemanagement mit klassischer Prozessoptimierung, das häufig einen großen Wasserkopf mit vielen inhaltlich nicht Beteiligten produziert, als kostenintensive Infrastruktur vorgehalten werden muss und oft zu langsam für dynamische Planungsaufgaben ist. Agile Prinzipien sind durch die transparente Beauftragung einer ExpertInnengruppe, deren Arbeit von vielen oder allen jederzeit nachvollzogen werden kann, auch ein guter Beteiligungsmix aus Basisdemokratie und ExpertInnenkultur.
Für kleine Teams – 2 bis 10 Personen – sind zwei Vorgehensweisen agiler Planung und Organisation von Bedeutung: Scrum und Kanban. Mit beiden Modellen lassen sich prima Studiengänge entwickeln. Scrum funktioniert dabei dann besonders gut, wenn es nicht nur um eine einzige Neuentwicklung geht, sondern auch insgesamt darum, agile Prinzipien einzuführen um z.B. Hochschulen mit langem Entwicklungsrückstand fitter für die aktuell sehr dynamische Hochschullandschaft zu machen (ein Lieblings-Klassiker zum organisationalen Umgang mit Wissen: Nonaka und Takeuchi 1997?). Scrum ist also auch ein Medium, das über den Einzelfall hinaus die Organisation lernen lassen kann, wozu eine gewisse Masse an interessierten KollegInnen gehört. Kanban hingegen ist nahezu voraussetzungslos, hat aber weniger Interventionscharakter für die Gesamtorganisation.
Und wie funktionierts? Bei Scrum wird das Gesamtprojekt Studiengangsentwicklung in einzelne, vorher festgelegte Phasen zerlegt, die ein bis sechs Wochen dauern können. Eine solche Phase heißt Sprint – das ganze Modell ist entlang von Begriffen aus dem Sport benannt: Scrum (Gedränge) meint das produktive Knäuel aus Spielern beim Rugby, Sprint das schnelle und zielsichere zurücklegen einer Strecke. Jeder Sprint hat einen definierten Startpunkt aus Anforderungen und Eingangsvariablen. Im Sprint werden diese Anforderungen nicht mehr geändert (was das zentrale Prinzip der Sache ist) und ein bestmögliches Ergebnis unter diesen Vorgaben entwickelt, das dann evaluiert wird. Die Ergebnisse dieser Evaluation sind dann automatisch der Startpunkt für den nächsten Sprint, und so weiter. So entsteht eine recht einfache Kette von Iterationen, die aber zwei zentrale Vorteile hat: Es wird nicht ständig an den Vorgaben herumgedoktert (das nicht nur an Hochschulen beliebteste Mittel, um Projekte ins Endlose laufen zu lassen), und es wird nicht mit undefinierter Zeit herumgewerkelt. Geht ein Sprint völlig schief, dann wird auch dieses Ergebnis ebenso wie alle anderen evaluiert und der nächste Sprint beginnt planmäßig. Für Scrum sind drei Rollen zentral, die KollegInnen dabei haben: ProduktbesitzerIn (etwas holprig übersetzt, hat sich aber eingebürgert) ist eine Person, die alle Spezifikationen kennt, bei der Studiengangsentwicklung ist das in der Regel der Dekan oder die Hochschulleitung, in größeren Hochschulen kann dies auch eine nur mit Studiengangsentwicklung betraute Person aus einer Stabstelle (meist ein zentraler Dienst wie Planung und Evaluation oder Hochschuldikdaktik) sein. Mitglieder des eigentlichen Entwicklungsteams haben in Scrum die inhaltliche Expertise – oft, aber nicht immer sind das die in einem zukünftigen Studiengang lehrenden Profs. Dieses Team ist in der Regel für die Studiengangsentwicklung interdisziplinär zusammengesetzt, idealerweise sowohl mit VertreterInnen der (Haupt)fachdisziplinen sowie einer/einem Kollegin, die hochschuldikdaktisch spezialisiert ist. Und schließlich gibt es den/die ScrummasterIn, die über den Prozess wacht und eventuelle Konflikte im Entwicklungsteam antizipiert und klärt. In der Studiengangsentwicklung kann dies auch jemand aus der Verwaltung sein, der sich mit allfälligen Konfliktmustern im Wissenschaftsbetrieb auskennt. Für das Scrum-Vorgehen ist es dabei sogar ein Vorteil, wenn dies kein/e FachwissenschaftlerIn ist. Ein typischer Scrum-Prozess für einen Studiengang entwickelt dabei zunächst in den ersten Sprints die Struktur (Anzahl und Benennung der Module, ETCS-Bepunktung) und in den folgenden Sprints dann jeweils die konkreten Inhalte (meist die Module) und in eventuell notwendigen Abschlussrunden noch einmal kleine Korrekturen an der Gesamtstruktur. Hat man sich auf die Struktur geeinigt, lassen sich in den Modul-Sprints auch Module parallel entwickeln, die Evaluation dieser Sprints muss aber dann vor allem bekannte und eventuell neu auftretende Abgängigkeiten parallel durchgeführter Sprints evaluieren.
Kanban ist zunächst einfacher, entfaltet aber auch eine stark strukturierende Wirkung. Das Wort kommt aus dem japanischen und meint wörtlich „Signalkarte“, gemeint ist im engeren Sinne dabei aber eine Karte mit einer Aufgabe, die auf der typischen Kanban-Tafel (die früher eine Kreidetafel o.ä. in der Werkstatt war) drei Stadien durchläuft: „Offen“ (Aufgabe ist definiert), „in Bearbeitung“ und „fertig“. Während des Durchlaufs werden dabei zuständige Personen und eventuell notwendige Unterschritte und Ressourcen definiert (=auf der Karte notiert), so dass alle am Projekt beteiligten sehen können, welche Aufgabe gerade wo steht. Auch hier wird die Studiengangsentwicklung also zunächst aufgeteilt, allerdings in Aufgaben und nicht in Zeitabschnitte. Das Durchlaufen der Prozesskette ist also nicht wie bei Scrum zeitlich definiert, sondern richtet sich nach den Anforderungen der Aufgabe – unterschiedliche Aufgaben können unterschiedlich lange dauern. Kanban verhindert aber ebenso wie Scrum, dass Aufgaben stecken bleiben, gar nicht angegangen oder verdrängt/vergessen werden.
Beide Prinzipien erleichtern die Entwicklungsarbeit enorm. Wenn die Grundlagen eines Studienganges vorgeklärt sind (z.B. entsprechen der ständig aktualisierten Nexus-Seite der KMK) kann man die Entwicklung in einigen Monaten bis zu max. einem Jahr absolvieren – und sich dabei noch über eine neue Art der Zusammenarbeit freuen. Und natürlich (wie könnte es auf diesem Blog auch anders sein…) macht agile Entwicklung besonders Spass, wenn man die Kreidetafel durch eine App ersetzt. Hier gibt es derzeit nur eine, die wirklich alles kann und auch noch schön aussieht (das Auge arbeitet ja mit) – nämlich MeisterTask (in der kostenlosen Version schon völlig ausreichend).