Wiki-unterstütztes Prozessmanagement von agilen Workflows an der Technischen Informationsbibliothek

Agile Methoden sind im Bereich der Softwareentwicklung in Agenturen und Industrie längst etabliert. Ganz anders sieht es im Bibliotheksbereich aus. Dort wird in vielen Fällen noch nach dem traditionellen Projektmanagement gearbeitet. Das heißt: Die Projektphasen Initiierung, Planung, Durchführung und Abschluss sind durch Meilensteine getrennt, und Abweichungen vom anfänglich erstellten Plan sollten minimal sein.

Im Kompetenzzentrum für nicht-textuelle Materialien (KNM) an der Technischen Informationsbibliothek (TIB) haben wir vor zwei Jahren begonnen, agile Methoden aus Scrum in unser Projektmanagement zu integrieren. Da Scrum nicht vollständig in unsere Arbeitsabläufe integriert werden konnte, haben wir uns lediglich einiger nützlicher Komponenten von Scrum bedient. Das betrifft v.a. die Sprints.

Wir haben einen eigenen, auf das KNM zugeschnittenen Sprint-Workflow entwickelt und diesen in unserem Unternehmenswiki (Confluence) abgebildet. Wikis werden in Bibliotheken und öffentlicher Verwaltung in vielen Bereichen eingesetzt. Meist werden sie allerdings nur zum kollektiven Sammeln und Bereitstellen von Link- oder File-Listen verwendet. Im KNM nutzen wir das Wiki hingegen als Management-Tool zur Steuerung unserer Workflows. Unser Ansatz kombiniert demnach zwei Dinge, die in der Bibliothekswelt noch nicht sehr verbreitet sind: agile Methoden plus Wiki-Management. Genau genommen, handelt es sich bei unserem Ansatz um ein Wiki-unterstütztes Prozessmanagement eines agilen Workflows.

Ich möchte zuerst beschreiben, was uns am KNM dazu bewogen hat, ein solches Prozessmanagement einzuführen. Danach werde ich unsere Methode zumindest grob skizzieren. Wer sich im Detail damit beschäftigen möchte, sei auf die Publikationen am Ende dieses Blog-Beitrags verwiesen.

Ich arbeite seit 2013 im KNM und bin für die konzeptionelle Weiterentwicklung des TIB AV-Portals (av.tib.eu) verantwortlich. Ich habe in meinem ersten Jahr ausschließlich mit Word-, Powerpoint- und Visio-Dokumenten gearbeitet, die in verschiedenen Ordnern auf meinem persönlichen Laufwerk gespeichert waren. Das Wiki habe ich lediglich als Archiv genutzt, d.h. abgeschlossene Projekte habe ich am Ende im Wiki „abgelegt“. Erste Entwürfe für Spezifikationen habe ich allein geschrieben und dann entweder per Mail an diverse Empfänger verschickt oder in die nächste Teamsitzung als Ausdruck mitgenommen.

Das Verschicken der Dokumente per Mail erwies sich schnell als impraktikabel, da dadurch viele Versionen in den verschiedenen Outlook-Postfächern herumgeisterten und oft nicht klar war, welche Version nun die aktuelle war. In der Teamsitzung lief es aber auch nicht viel besser. Die Konzeption wurde Punkt für Punkt mühevoll „durchgekaut“. Es wurden kaum To-dos festgehalten, und oft fehlten wichtige Personen aufgrund von Krankheit, Urlaub oder Dienstreisen. Das hatte zur Folge, dass Entscheidungen häufig wieder zurückgenommen und die Spezifikation immer wieder umgeschrieben werden musste.

Wir haben in der Zeit nicht nach einer strukturierten Management-Methode gearbeitet; auch wurde das Konzept nicht wirklich kollaborativ entwickelt. Der ganze Prozess ging nur schleppend voran und war für mich oft frustrierend. Anfang 2015 haben wir ein großes Projekt in Angriff genommen: den Relaunch des TIB AV-Portals. Ziel des Projekts war es, das Bedienkonzept nach Usability-Gesichtspunkten komplett zu überarbeiten sowie ein neues und responsives Screendesign zu entwerfen und zu implementieren. Das Projekt musste spätestens zur Stiftungswerdung der TIB am 01.01.2016 abgeschlossen sein.

Mit dem Relaunch-Projekt haben wir im KNM beschlossen, unser Projekt-Management strukturierter und „professioneller“ aufzuziehen. Da das Stichwort „Agilität“ schon länger im Team herumgeisterte und wir Software spezifizieren, lag es nahe, sich das Scrum-Framework näher anzuschauen. Ich habe dann aus Scrum diejenigen Komponenten ausgewählt, die in unsere Arbeitsprozesse integriert werden konnten. Das sind v.a. die folgenden Prinzipien:

• Das Team ist cross-funktional zusammengesetzt und arbeitet selbst-organisiert
• Anforderungen werden priorisiert
• Ein iterativer und inkrementeller Prozess liefert die Produktinkremente innerhalb einer festen Zeitspanne von 2 bis 4 Wochen (Sprints)
• Der Prozess ist hoch transparent
• Produktinkremente, Prozesse und Methoden werden regelmäßig inspiziert und ggf. an sich ändernde Bedingungen angepasst /1/

Der KNM-spezifische Sprint-Workflow definiert, wie Aufgaben strukturiert sind, wer welche Aufgaben ausführt und nach welcher Reihenfolge die Aufgaben ausgeführt werden. Nachdem der Sprint-Workflow konzipiert war, wurde er im Confluence-Wiki abgebildet. Das Wiki unterstützt das Team bei Planung, Steuerung und Monitoring des Sprint-Workflows. Wir haben im Relaunch-Projekt das Wiki nicht mehr nur als Archiv genutzt, sondern als Groupware, die die soziale Interaktion zwischen den involvierten Teammitgliedern unterstützt. Das betrifft die Kommunikation, Kooperation, Koordination und Konsensfindung innerhalb des Teams. Modernes Projekt- und Wissensmanagement basiert stets auf soziotechnischen Systemen, d.h. aus Mitarbeitern (soziales System) und Software (technisches System). Groupware wie Wikis oder Tracking-Systeme eignet sich hierbei besonders, da sie die Interaktion der Mitarbeiter bei der Erreichung gemeinsamer Ziele direkt unterstützt. Darüber hinaus ist das Confluence-Wiki ein einfach und intuitiv zu bedienendes und – bei richtigem Einsatz – gleichwohl sehr mächtiges Tool.

Die oben angeführten Scrum-Prinzipien werden allesamt in unserer Methode angewandt:

• Im KNM erzeugt ein cross-funktionales und selbst-organisiertes Team kollaborativ die Spezifikation. Das Team besteht aus: Produktmanagerin, Projektmanager, Usability-Expertin, Analysten, IT-Spezialist und Datenmanagerin.
• Anforderungen werden vom KNM-Team in einer IDEEN-Liste gesammelt, die von Zeit zu Zeit priorisiert wird. Die am höchsten priorisierten Ideen werden dann als Projekte in der NEXT-Liste im Wiki angelegt. Die NEXT-Liste enthält alle Projekte, die in einem gewissen Zeitraum – z.B. 2017 – umgesetzt werden sollen. Die NEXT-Liste wird erneut priorisiert. Das am höchsten priorisierte Projekt wandert in die ACTIVE-Liste, in der die aktiven Sprints des Teams verwaltet werden.
• Iterativ und inkrementell arbeitet das KNM-Team die Projekte der NEXT-Liste nach Priorität mit Hilfe von Sprints ab.
• Alle für das Projekt relevanten Informationen werden vom Team zentral im Projekt-Dashboard gesammelt und abgebildet: Sprint-Workflow, Projektphasen, Aufgaben, Roadmaps, Kontakte, Team-Kalender, Besprechungsnotizen, Workshops, Entscheidungen, Workflow-Beschreibungen etc. Wenn alles, was für das Projekt relevant ist, im Wiki abgebildet wird, ergibt sich die Dokumentation des Projekts als eine Art Nebenprodukt quasi von selbst. Die KNM-Methode ist also dank Wiki hoch transparent.
• Das KNM-Team testet nicht nur die Implementierungen, sondern überprüft auch kontinuierlich das Prozessmanagement und passt dieses an neue Bedingungen an.

Die neue Methode hat das Schreiben der Spezifikationen wesentlich vereinfacht und beschleunigt. Das Wiki-unterstützte Prozessmanagement des Sprint-Workflows sorgt dafür, dass die Prozesse strukturiert und standardisiert sind, die Kollaboration zwischen den Teammitgliedern intensiviert und gleichzeitig alles dokumentiert wird. Das Relaunch-Projekt konnte erfolgreich zur Stiftungswerdung der TIB abgeschlossen werden. Wir sind überzeugt, dass das neue Prozessmanagement hierzu wesentlich beigetragen hat. Im Folgenden möchte ich den Sprint-Workflow des KNM kurz skizzieren.

KNM-Sprints sind für kleine (2-5 Personen), cross-funktionale und selbst-organisierte Teams konzipiert. Einerseits muss das Team groß genug sein, um alle notwendigen Kompetenzen zu umfassen. Andererseits steigt der Kommunikations- und Koordinationsaufwand mit der wachsenden Zahl an Teammitgliedern. Letzteres schränkt tendenziell die Flexibilität und Anpassungsfähigkeit einer agilen Arbeitsweise ein. /2/ Es sollte also bei der Zusammenstellung von Teams das Ökonomieprinzip angewandt werden: So viel Teammitglieder wie nötig, so wenig wie möglich.

Im KNM definieren wir Sprints als kurze Arbeitszyklen (2-4 Wochen), in denen ein Konzept kollaborativ und hauptsächlich virtuell (per Wiki) erzeugt und abgenommen wird. Die Gesamtmenge der Konzepte wird inkrementell erzeugt durch die wiederholte Durchführung von Sprints. In unserem Fall handelt es sich bei den Konzepten um Anforderungsspezifikationen für Softwarefeatures des TIB AV-Portals. Der Sprint-Workflow ist wie folgt strukturiert:

1. Der Projektmanager legt für das ACTIVE-Projekt ein kollektives Sprint-Dokument im Wiki an. Er vergibt terminierte Aufgaben an die Sprint-Teilnehmer mit Hilfe einer Wiki-Funktion. Normalerweise besteht die erste Aufgabe für alle Sprint-Teilnehmer darin, die Anforderungen für eine bestimmte Softwarekomponente so exakt und ausführlich wie möglich im Sprint-Dokument festzuhalten.
2. Die Sprint-Teilnehmer schreiben kollaborativ an der Anforderungsspezifikation für die Softwarekomponente. Sie fügen Kommentare und Antworten, Ergänzungs- und Änderungsvorschläge sowie Visualisierungen hinzu. Darüber hinaus vervollständigen sie die ihnen zugewiesenen Aufgaben. Danach haken sie per Checkbox die dazugehörigen Action Items im Wiki ab, so dass das ganze Team den Projektfortschritt verfolgen und monitoren kann.
3. Der Projektmanager identifiziert im Sprint-Dokument anstehende Entscheidungen und organisiert ein Teamtreffen zu deren Klärung.
4. Beim Teamtreffen fällen die Teammitglieder finale Entscheidungen: Wie kann ein spezifisches Problem gelöst werden? Welche Alternative soll implementiert werden? Wie soll ein Feature visualisiert werden? etc. Außerdem identifizieren die Teammitglieder neue Aufgaben und besprechen diese. Der Projektmanager fragt die Sprint-Teilnehmer, wie lange sie für die Umsetzung der neuen Aufgaben benötigen, und terminiert diese entsprechend per Wiki-Funktion.
5. Die Teammitglieder schreiben die Spezifikation fort auf der Basis der in der Teamsitzung gefällten Entscheidungen.
6. (Die Komponenten 2. – 5. werden normalerweise mehrmals durchlaufen.)
7. Die Sprint-Teilnehmer nehmen die finale Version der Spezifikation ab. Auch dies erfolgt per Abhaken von Action Items im Wiki. Danach kann die Spezifikation zur Implementierung an die externen Softwareentwickler weitergegeben werden.

Abb. 1  Sprint-Workflow des KNM

 

Im Sprint erzeugt das Team eine Anforderungsspezifikation, die kollaborativ evaluiert, entwickelt und abgenommen wurde. Der Sprint-Workflow wird dabei im Wesentlichen im Wiki gesteuert und ausgeführt. Das Teamtreffen ist die einzige nicht-virtuelle Komponente des Sprint-Workflows. Die Effizienz des Workflows basiert auf dieser Kombination aus virtuellen und nicht-virtuellen Komponenten.

Abb. 2  Ausschnitt aus einem Sprint-Dokument im TIB-Wiki

Abb. 3  Ausschnitt der Reporting Page zu ACTIVE- und NEXT-Projekten im TIB-Wiki

 

Bisher habe ich v.a. Gemeinsamkeiten zwischen Scrum und der KNM-Methode betont. Es gibt aber auch ein paar wesentliche Unterschiede:

• Das KNM-Team erzeugt lediglich Anforderungsspezifikationen und keine potentiell lieferfähige Software. Die Implementierung wird von externen Softwareentwicklern geleistet, die nicht Teil des KNM-Teams sind.
• Scrum beinhaltet spezifische Rollen (Scrum Master, Product Owner…), Ereignisse (Daily Scrum…), Artefakte (Product Backlog…) und Regeln, die nicht Teil der KNM-Methode sind.

Die hier vorgestellte Methode zeigt, dass man Komponenten aus Scrum in eigene Modelle flexibel integrieren und mit anderen Komponenten wie dem Wiki-Management kombinieren kann. Das Wichtigste ist, dass es funktioniert. Was nicht zu unseren Prozessen passt, wird gar nicht erst aufgenommen bzw. wieder entfernt. Die KNM-Methode ist dabei nicht nur beschränkt auf den Bereich Softwareentwicklung. Man kann sie viel weiter fassen als eine Methode für die Groupware-unterstützte kollaborative Erzeugung von Konzepten. Diese Konzepte können alles Mögliche sein. Ich möchte daher anregen, diese Methode auf andere Konzepte anzuwenden, wie z.B. Forschungsanträge, wissenschaftliche Artikel, Handbücher, Guidelines, Bedienungsanleitungen, Change Logs, Software Code, Mockups, UI-Prototypen, Taxonomien oder Drehbücher – um nur einige zu nennen.

Referenzen

/1/ Vgl. Ken Schwaber & Jeff Sutherland (2013): The Scrum Guide^TM, the Definitive Guide to Scrum: The Rules of the Game (scrum.org); Joachim Goll & Daniel Hommel (2015): Mit Scrum zum gewünschten System. Wiesbaden: Springer, S. 84.

/2/ Vgl. Joachim Goll & Daniel Hommel (2015): Mit Scrum zum gewünschten System. Wiesbaden: Springer, S. 103.

Weitere Veröffentlichungen zum Thema:

• Sven Strobel (2015): “Einsatz von Sprints in der Produktentwicklung der Technischen Informationsbibliothek,“ Bub 67, 713-715.
• Sven Strobel (2016): “Workflow Management of Sprints and Software Tests: Coordination, Consensus, and Cooperation in the Enterprise Wiki of the German National Library of Science and Technology,” Information and Knowledge Management 6, 58-64.
• Sven Strobel (2016): „Developing the Web Portals of the German National Library of Science and Technology: Tools and Workflows Used,“ Qualitative and Quantitative Methods in Libraries (QQML) 5, 79-88.
• Sven Strobel (eingereichtes Manuskript): „Collaborative Working in the Enterprise Wiki: How Teams Develop Concepts Using Sprints“.