Ein Projekt in 25 Sprints
Alle, die schon einmal ein Verbundprojekt geplant und beantrag haben, wissen, dass nach der Bewilligung, die auch gerne mal erst 12 bis 18 Monate nach Antragsabgabe erfolgt, die Welt sich mehrmals gedreht hat und das Projektkonzept neu mit Leben gefüllt werden muss. Auf Basis der ggf. modifizierten Ziele wird der Arbeitsplan für die in der Regel 24 bis 36 Monate Projektlaufzeit überarbeitet, verabschiedet und gestartet. Nicht selten wird sich für die Erhebung und Bewertung der ggf. vielen Veränderungen in den Rahmenbedingungen des Projektes und auch im Status quo der fachlichen Arbeitspakete nicht viel Zeit genommen. Man/Frau wollen und müssen starten, die Projektuhr tickt.
In unserem Projekt „KMU. Einfach Sicher.“ war das nicht anders. Erschwerend kam hinzu, dass ein Projektpartner nach Projektstart ausfiel und das Projekt noch einmal umstrukturiert werden musste. Die Entscheidung das Projekt nach der Umstrukturierung agil weiterzuführen, war im Nachgang betrachtet, genau die richtige. In einem halbtägigen Arbeitstreffen wurde auf Basis der Projektkonzeption ein Epic-Dokument erstellt, und zwar mit dem zentralen Epic: „Ich (KMU-Führung/ KMU-Beschäftigte:r/ Rolle/ Persona) will effizient die IT-Sicherheit meines Unternehmens eigenständig verbessern und weiterentwickeln, um besser geschützt zu sein.“ Alle Beteiligten formulierten daraufhin neun Unterepics, immer nach dem Stil „Ich als WER möchte WAS, um etwas zu bewirken/erreichen (WARUM).“ Wir ordneten diesen User Stories zu, die wir aus den unterschiedlichen Sichten IT-Sicherheit, KMU, Medienpädagogik und Didaktik formulierten. Im Ergebnis ergab sich ein umfangreiches Dokument, das in der Nachschau zwar nur selten wieder zum Einsatz kam, aber eine sehr gute Grundlage für ein frühes gemeinsames Projektverständnis der Projektpartner beitrug.
Dann ging es an die Rollenverteilung. Die Zusammensetzung des Projektteams war klar. Das Projektteam bestand aus fünf bis acht Vertreterinnen aus zwei Unternehmen und drei Lehrstühlen der beteiligten Universität. Was fehlte, war der oder die Product-Owner:in. Das monatliche Abstimmungsmeeting mit den beteiligten Professorinnen und dem Professor konnte diese Rolle mit Blick auf eine nachhaltige praktische Verwertung der Ergebnisse nicht vollständig ausfüllen. Obwohl im Projektkonzept nicht vorgesehen, wurde eine Projektbeirat eingerichtet, der unterschiedlichste Perspektiven vereinen sollte: Fachsichten Didaktik, Medienpädagogik und IT-Sicherheit sowie die Unternehmens- und Beschäftigtensicht, als die der Zielgruppe. Der Projektträger als Vertreter des Fördergebers war nicht Teil des Projektbeirates, was sicherlich sinnvoll gewesen wäre, aber aufwandstechnisch vom Projektträger nicht darstellbar war. So verteilte sich die Stakeholder-Perspektive auf drei Gruppen, die Professorinnen, den Beirat sowie den Projektträger mit jeweils eigenen Treffen. Der Beirat sollte sich über die Projektlaufzeit insgesamt sechs Mal treffen. Die Kommunikation erfolgte per Mail und über eine MS-TEAMS-Gruppe, die aber so gut wie nicht genutzt wurde. Der Projektträger wurde über monatliche Statusberichte auf dem Laufenden gehalten. Zusätzlich gab es ein Kick-Off-Treffen mit ihm sowie ein Zwischenberichts- und Abschlusstreffen. Zwischendurch gab es immer wieder fachliche Abstimmungen zu Ergebnissen mit wertvoller Kritik und guten Ergänzungen.
Wie sah die agile Projektarbeit aus? Als Werkzeuge kamen eine MS-TEAMS-Gruppe mit unterschiedlichen Kanälen, Trello sowie eine verkürzte Fassung des Epic-Dokuments mit Sprintplanungstabelle zum Einsatz. Die Dokumente wurden ausschließlich ins TEAMS gehalten und Trelloaufgaben enthielten einen Link zu diesen. Zu Projektbeginn dauerten die Sprintreviews/-planungen drei bis vier Stunden. Durch Vorausfüllen und Routine verkürzten sich diese Treffen auf eine bis eineinhalb Stunden. Die vereinbarten Sprintaufgaben wurden auf dem Trello-Board abgebildet und über farbliche Codierung den Arbeitspaketen zugeordnet. Im Vorfeld der wöchentlichen Jour Fixes (JF), die auf eineinhalb Stunden begrenzt waren, konnte jede:r Aufgaben für den JF markieren, so dass sich immer automatisch eine Agenda ergab. Zu Anfang dauerten die JF auch schon einmal länger als geplant, da auch inhaltliche Punkte besprochen wurden. An dieser Stelle war uns der Austausch aber wichtiger als die formale Einhaltung des Instruments. Die Monatsmeetings mit den zuständigen Professoren variierten zwischen einer und eineinhalb Stunden und dient vor allem dazu, den Professorinnen einen Überblick über die Arbeiten und Ergebnisse zu geben.
Welche Erfahrungen haben wir in den letzten 30 Monaten mit dem agilen Vorgehen gemacht? Das gesamte Team hat den agilen Ansatz als sehr zielführend und motivierend erlebt. Es hat einer gewissen Anlaufzeit bedurft, bis sich alle auf diese Arbeitsweise eingestellt haben und auch die Instrumente so eingestellt waren, dass alle damit zufrieden waren. Würde ein neues Projekt in der gleichen Teamzusammensetzung starten, wären die Voraussetzungen für eine hoch effiziente und effektive Umsetzung sehr gut. Aber da ein solches Projekt nicht ansteht, bleibt nur die Gewissheit, dass alle Mitglieder des Teams diese Erfahrungen mit in weitere, andere Projekte nehmen und nutzen werden. Würden wir mit dem heutigen Wissen etwas anders machen? Nein. Natürlich gibt es immer Verbesserungsmöglichkeiten, die wir aber auch immer im Sprintreview versucht haben, zu identifizieren und zu nutzen. Im Grundsatz würden wir das Projekt in der Form noch einmal genauso managen.
Michael Kemkes
Technologienetzwerk InnoZent OWL e.V.
weitere interessante Blog-Artikel:
Mittelstand-Digital Themenheft „Sicherer Datenaustausch“
„… In diesem Heft finden Sie Anregungen, Informationen und ermutigende […]mehr
Passwortmanager: alle Passwörter am selben Ort gespeichert – wie kann das sicher sein?
Wer hat’s nicht auch schon mal gehört „… und was […]mehr
