Schreiben als agiles Kollektiv – das Grundrechte Projekt

Im Grundrechte-Projekt wird es sowohl für das Lehrbuch als auch für das Fallbuch ein kleines Projektteam geben, das die Inhalte gemeinsam erstellt. Anstatt über mehrere Monate in die digitale Isolation zu verschwinden, soll möglichst schnell eine Diskussion gefördert werden. Vordergründiges Ziel ist es, gemeinsam durch die Perspektive der anderen zu lernen.

Es wird auch im Grundrechte-Projekt Herausgeber:innen und Autor:innen geben. Beide Rollen haben jedoch eine leicht veränderte Funktion. Es gibt keine klaren Hierarchien, nur unterschiedliche Aufgaben. Die Verantwortung für das Endprodukt trägt das Projektteam gemeinsam. Aus diesem Grund sollten die jeweiligen Teams auch nicht größer als zehn Personen sein, um immer noch eine direkte Kommunikation zu ermöglichen.

Das Zusammenwirken innerhalb des Grundrechte-Projektes ist stark inspiriert von agilen Arbeitsweisen und besonders der Methode SCRUM. Welche Bezüge und Quellen hier für mich wichtig waren, erkläre ich am Ende.

Autor:innen

Alle im Projektteam sind gleichzeitig Autor:innen. Sie diskutieren mit den Herausgeber:innen die Inhalte der Publikation. Danach wählen sie eigenständig diejenigen Inhalte auf, die sie bearbeiten möchten. Sobald Inhalte fertig geschrieben sind, wählen sie eigenständig diejenigen Inhalte anderer Autor:innen aus, die sie einem Peer-Review-Prozess unterziehen möchten. Bei den regelmäßig erfolgenden Meetings des Teams wird der eigenen Fortschritt kurz vorgestellt.

Die Autor:innen tragen die erstellten Inhalte auch aktiv in ihre Arbeitsgemeinschaften, sofern sie welche in diesem Bereich anbieten. Idealerweise wird hier das Feedback der Studierenden gesammelt und kann gleich in die nächste Überarbeitung der Materialien einfließen.

Sobald Inhalte auf Wikibooks veröffentlicht worden sind, ist die Autor:in für das von ihr veröffentlichte Material gleichzeitig die Kontaktperson. Auf Kommentare und Änderungsvorschläge sollte zeitnah reagiert werden.

Wenn die Materialien bei Wikibooks einen gewissen Reifegrad erreicht haben, werden sie als Open Access Publikationen in einem Verlag veröffentlicht. Die Autor:innen übernehmen hier die Überarbeitung ihrer Beiträge in dem jeweiligen Buch.

Herausgeber:innen

Jedes Buchprojekt wird mindestens zwei Herausgeber:innen haben. Sie umreißen in knappen Worten, was das Ziel des Projektes ist. Danach füllen sie anhand dieses Ziels die Aufgabenliste für das Projekt. Die Aufgabenliste wird priorisiert. Für jede Aufgabe wird geschätzt, wie aufwändig sie ist, und welche Kriterien erfüllt sein müssen, damit sie fertig ist. Die wichtigeren Aufgaben werden ausführlicher beschrieben als die weniger wichtigen.

Die Herausgeber:innen sorgen dafür, dass regelmäßige Zeitabstände zur gemeinsamen Arbeit (Sprints) festgelegt werden, die maximal einen Monat lang sind und sich regelmäßig wiederholen.

Am Beginn eines jeden Sprints organisieren sie ein Treffen mit dem ganzen Team, um die Arbeit für diesen Zeitraum zu planen (Sprint Planning). Die priorisierten und definierten Aufgaben werden vorgestellt und mit dem Team diskutiert (Fehlt etwas? Ist der Aufwand falsch eingeschätzt? Ist die Priorisierung verbesserungswürdig?). Danach wählen die Autor:innen diejenigen Aufgaben aus, die sie in dem Sprint fertig stellen wollen.

In der Mitte des Sprints organisieren die Herausgeber:innen ein kurzes (15-30 Minuten) Treffen (Daily), in dem alle Teammitglieder eine kurze Rückmeldung geben, woran sie gerade arbeiten und ob es Probleme gibt. Bevor der Sprint beendet wird, sollte jede bearbeitete Aufgabe eine Phase des Peer-Review durch mindestens eine andere Autor:in durchlaufen.

Am Ende des Sprints gibt es ein Treffen, das den aktuellen Stand der Aufgaben bespricht (Sprint Review), um in das nächste Sprint Planning überzugehen und die weiteren Aufgaben zu planen.

Die Herausgeber:innen haben während des Sprints ein Auge darauf, dass sich alle Autor:innen eigenständig Aufgaben zuweisen, ohne den Autor:innen aktiv die Aufgaben zuzuweisen.

Sie erstellen die Buchprojekte auf Wikibooks und organisieren die Veröffentlichung im Verlag, sobald das Buch vom Team als fertig angesehen wird.

Was bringt uns „agil“ und „Kanban“?

Agile Arbeitsweisen sind vor mehreren Jahrzehnten im Bereich der Softwareentwicklung entstanden. Viele dieser Projekte waren und sind sehr komplex. Es wurde lange im Voraus geplant und die Entwicklungszeiträume waren sehr lang. Am Ende war das Budget überschritten und der Liefertermin wurde nicht eingehalten. Einen Gegenpol hierzu versuchte das agile Manifest und die damit eng verwandte Prozessmanagement-Methode Scrum aufzubauen.

Anstatt einen großen Masterplan aufzustellen und die Arbeit zwischen unabhängigen Abteilungen aufzuteilen, werden cross-funktionale Teams geschaffen, die in kleinen Zeitabschnitten arbeiten, um flexibel auf neue Probleme zu reagieren und sich kontinuierlich zu verbessern. Nach mehreren solcher Zyklen (Sprints) entsteht irgendwann das fertige Produkt. Jedes Team vereint alle Fähigkeiten, die für die Entwicklung des Produktes notwendig sind. Im Fokus der Arbeiten steht immer die Zielgruppe des Produktes. Die einzelnen Bestandteile von Scrum sind im Scrum-Guide festgehalten.

Eine andere Quelle der Inspiration für OpenRewi (und eng verwandt mit Scrum) ist die Prozessmanagement-Methode Kanban. Auf einem sogenannten Kanban-Board werden die zu erledigenden Aufgaben in Spalten angeordnet und durchlaufen mehrere Stadien (To Do, Doing, Done). Die Teammitglieder ziehen die Aufgaben eigenständig in die nächste Spalte (Pull-System). Probleme und Engpässe werden schnell sichtbar. Der Arbeitsprozess wird für alle auf einen Blick einsehbar.

Können solche Management-Methoden aus dem IT-Bereich, die primär kommerzielle Produkte herstellen möchte, sinnvoll in eine kooperative Umgebung zur Erstellung von Open Educational Ressources übertragen werden?

Auch wir stellen Materialien her, die in Konkurrenz zu bereits am Markt befindlichen Lehrbüchern stehen. Auch wir sollten bei unserer Arbeit die Zielgruppe (Studierende) im Blick haben und möglichst früh von ihnen eine Rückmeldung einholen, ob unsere Materialien gut nutzbar sind. Gute Wissenschaft im Sinne der Open Science lebt von offenen, ehrlichen Diskussionen, die für alle transparent und nachvollziehbar sind. Agile Methoden fördern das Hinterfragen der eigenen Tätigkeiten.

Eine wirklich strenge Anwendung von Scrum würde verlangen, dass unsere Projektteams täglich zusammen kommen, um sich kurz zu besprechen. Das ist bei einem Projekt, das für uns alle nur eine Nebentätigkeit zu sonstigen wissenschaftlichen Arbeit ist, nicht durchführbar. Gleichzeitig sind die Rollen in agilen Projekten sehr viel starrer verteilt. Bei OpenRewi können ruhig mehrere Personen zusammen dieselbe Rolle ausfüllen, auch wenn das die Diskussion und Abstimmung in die Länge zieht. Letztendlich ist die Diskussion in der Wissenschaft ein Wert für sich. Im Moment bin ich noch unschlüssig, ob bei uns auch „Retrospektiven“ eingeführt werden könnten. Hier trifft das ganze Team nach jedem Sprint zusammen und überlegt (unabhängig vom zu entwickelnden Produkt), wie sie die Arbeitsweise allgemein verbessern können.

Die Anwendung agiler Methoden in der OER-Entwicklung ist, dazu noch in der (konservativen) Rechtswissenschaft, ein recht gewagtes Experiment. Zum Glück neigen agile Methoden dazu, die eigenen Ergebnisse und Arbeitsweisen konstant zu reflektieren. Dadurch neue Diskursräume zu schaffen, die durch Corona weggefallen sind, ist für mich eine ausreichend große Motivation.