Was der FINAS Quick-Check ÖD ist? Eine responsive Web-App, die schnell und unkompliziert das Ruhegehalt von Beamten im Öffentlichen Dienst (ÖD) berechnet. Die Anwendung läuft in der Cloud und lässt sich einfach in eine Webseite integrieren. Fünf Kollegen und Kolleginnen haben an der Entstehung mitgearbeitet – drei davon sind Martin, Philipp und Peter. In diesem und den folgenden Artikeln geben die Drei nähere Einblicke, wie sie dabei vorgegangen sind, welche Tools sie genutzt haben und was sonst noch wichtig war.
Wir arbeiten agil. In unserer Digital Factory entwickeln die Teams selbstorganisiert funktionierende Software, die die Kundenanforderungen mit technischer Exzellenz und in gutem Design erfüllt. Dafür arbeiten Fachbereich und Technik täglich eng zusammen. Auch ein guter Start in ein agiles Projekt bringt zu Beginn alle Beteiligten zusammen und lässt sie gemeinsam die Grundlagen des Projektes festlegen. Diesen Start nennen wir Foundation Phase. Wie der Name schon andeutet, bildet sie das Fundament des Softwareentwicklungsprojektes. In einem Workshop erarbeiten Business, Fachbereich und Entwicklung hier miteinander einen Überblick über die Ziele des Auftraggebers, die fachlichen sowie weiteren Anforderungen, die Architektur und das Ökosystem der geplanten Applikation, um daraus ein grobes Backlog mit Meilensteinplan sowie eine Aufwandsindikation ableiten zu können. Inhaltlich orientiert sich die Foundation Phase an den sieben Produktdimensionen von Ellen Gottesdiener¹: Nutzer, Schnittstellen, Aktionen, Daten, Kontrolle, Umwelt und Qualität.
Dauert die Foundation Phase länger als einen Tag, wird sie durchgehend in ein und demselben Raum durchgeführt. Um die verschiedenen Ziele zu erreichen, stehen jeweils unterschiedliche Methoden zur Verfügung. Sämtliche Ergebnisse werden während der Durchführung durch die Teilnehmenden visualisiert und sind so für alle jederzeit ersichtlich. Im weiteren Projektverlauf sind die Visualisierungen aus der Foundation Phase zudem ein guter Erinnerungsanker für das Entwicklungsteam.
Bei unserem Projekt FINAS Quick-Check ÖD sind wir natürlich ebenfalls mit einer Foundation Phase gestartet, die ich als Agile Coach und Facilitator durchführen durfte. Dabei wurde ich aufgrund der Projektgröße jedoch vor eine besondere Herausforderung gestellt. Welche das war? Die Zeit.
Grundsätzlich gilt: Der Aufwand für eine Foundation Phase sollte in einem angemessenen Verhältnis zum erwarteten Projektaufwand stehen. Geht es um ein komplexes Projekt mit langer Umsetzungsdauer, wie z.B. die Entwicklung einer neuen Vertriebsplattform, kann die Foundation Phase durchaus mal bis zu zwei, drei Wochen dauern. Im Fall unseres FINAS Quick-Check ÖD standen uns zwei Stunden zur Verfügung. Das bedeutete, wir mussten den Workshop auf das wirklich Allernotwendigste reduzieren und eine extrem fokussierte Zusammenarbeit sicherstellen (da alle Beteiligten sich bereits gut kannten, war letzteres kein Problem).
Einige Eckpfeiler sind zwingend erforderlich, um das angestrebte Ziel der Foundation Phase zu erreichen – im Team passende technische Lösungen zu finden und, dezentral und schnell, gute Entscheidungen treffen zu können:
Am Ende sah die finale Agenda für die Foundation Phase des FINAS Quick-Check ÖD so aus:
|
Schritt 1: Projektziele |
Schritt 2: Akteure Danach ging unser Product Owner näher darauf ein, wer das System nutzen wird und was die jeweiligen Aktivitäten sind. |
|
Schritt 3: Systemkontext |
Schritt 4: Nicht funktionale Anforderungen |
Schritt 5: Story Map
Den größten Teil des Workshops nahm die Erarbeitung einer Story Map ein. Der Begriff 'Story Map' bezieht sich auf die Darstellung und Technik von Jeff Patton². Als Grundgerüst für die Story Map haben Product Owner und Fachbereich im Vorfeld des Workshops ein initiales Backbone für den FINAS Quick-Check ÖD erarbeitet. Mit dem initialen Backbone sowie den bisher gewonnenen Erkenntnissen als Basis, haben alle Beteiligten Feature-Überschriften notiert und auf das vorbereitete Board gebracht. Im Dialog zwischen Business, Fachbereich und Entwicklungsteam wurde das initiale Backbone so sukzessive erweitert.
Darauf aufsetzend erfolgte dann die Planung des Minimum Viable Product (MVP) sowie von zwei Releases. Fachbereich, Business und Entwicklungsteam haben hier wieder eng zusammengearbeitet, da bereits Abhängigkeiten zwischen den Features erkannt und berücksichtigt wurden. Zum Schluss erstellte das Team aus den Feature-Überschriften der Story Map die ersten User Stories für das Backlog.
Zugegeben, das Ganze war schon eine sehr sportliche Angelegenheit aufgrund der knappen Zeit. Dennoch haben wir es gemeinsam geschafft, eine ordentliche Grundlage für unser Projekt zu erstellen. Und damit konnte es dann auch so richtig losgehen.
Aber mehr dazu demnächst im Artikel von Philipp.
¹ Weitere Informationen zu den 7 Produktdimensionen von Ellen Gottesdiener unter: https://www.ebgconsulting.com/agile-resources/agile-books/
² Weitere Informationen zum Thema Story Map von Jeff Patton unter: https://www.jpattonassociates.com/story-mapping/