Die Ausgangsfrage: Wie bekomme ich die Anforderungen der vielen Stakeholder unter einen Hut?
Keine Frage, die von SEITENBAU und dem BVA vor mehr als 20 Jahren gestartete Entwicklung von OfficeNet (SON, früher ON2) ist eine Erfolgsgeschichte. Zunächst nur beim BVA selbst implementiert, setzen mittlerweile an die 40 Behörden die Portal-Software bei sich ein.
Die Krux dieses Erfolges: die stetig steigende Zahl an Stakeholdern bringt zum Teil sehr unterschiedliche Anforderungen an die Software und bei der Weiterentwicklung mit sich. Der auch für diesen Interessenausgleich gegründete Fachverbund konnte in seinen Anfangszeiten dieses Dilemma in der Regel gut auffangen. Ein wesentlicher Aspekt dabei war die Bereitschaft, für einzelne Behörden besonders wichtige Funktionen auf eigene Kosten entwickeln zu lassen und sie dann allen Behörden im Fachverbund zur Verfügung zu stellen.
Die Grenzen dieses Vorgehens wurden jedoch mit zunehmender Nutzerzahl ersichtlich. Eine gezielte Weiterentwicklung grundlegender Eigenschaften der Software in den Bereichen Barrierefreiheit, Sicherheit, Performance, usw. konnte mit einer solchen Form der dezentralen Finanzierung und Entscheidung immer schwerer umgesetzt werden.
Basis-Weiterentwicklung aus einem gemeinsamen Topf bedeutet auch: gemeinsame Priorisierung
Deshalb wurde neben Einzelbeauftragungen ein weiterer Finanzierungstopf als zweite Säule der Weiterentwicklung ins Leben gerufen. Per Rahmenvertrag festgeschriebene, jährliche Entwicklungsbeiträge aller Behörden sollen die kontinuierliche Weiterentwicklung der Basiseigenschaften der Software garantieren. Bei diesem Modell hat der Product Owner (PO) aus der Bundesverwaltung die Hoheit über die grundsätzliche Produktstrategie inklusive Auswahl der Features, die letztlich über den gemeinsamen Topf entwickelt werden.
Dies führte jedoch immer wieder zu Priorisierungs-Entscheidungen, die nicht unbedingt von allen Mitgliedern des Fachverbundes gleichermaßen unterstützt wurden. Und da alle Behörden sich über den zweiten Topf an der Finanzierung beteiligen, sollten auch alle die Möglichkeit bekommen, bei der Priorisierung mitzuentscheiden.
Dementsprechend wurde für die Entwicklung des SON-Release 7 eine neue Priorisierungsmethode gesucht, die allen interessierten Behörden die Möglichkeit zur aktiven Mitentscheidung gibt, welche Features im anstehenden Release berücksichtigt werden.
Welche Methoden gibt es denn da überhaupt? Und lösen die das Problem?
Erster logischer Schritt dieser Suche war es, sich bestehenden Methoden zur Priorisierung anzusehen und zu beurteilen, ob diese zur Lösung des vorliegenden Problems geeignet wären. Wichtig für die Auswahl oder Neuentwicklung einer geeigneten Methode waren dabei vor allem zwei wesentliche Anforderungen:
- Erstens sollen für mehrere Behörden geschäftskritische Features („Must-haves“) möglichst sicher durch den gemeinsamen Entscheidungsprozess gebracht werden können, wenn die Behörden dafür bereit sind, auf ihre „Nice-to-haves“ zu verzichten.
- Zweitens müssen aufgrund eines klar begrenzten Budgets für das neue Release die geschätzten Entwicklungsaufwände für die jeweiligen Features mit in die Abstimmung und Entscheidung zur Weiterentwicklung einfließen: je teurer ein Feature in der Entwicklung ist, desto mehr Unterstützung durch die Anwender ist bei der Auswahl erforderlich.
Dabei wurden neben „Klassikern“ wie dem KANO-Modell auch aus dem agilen Umfeld stammende Methoden wie beispielsweise die MoSCoW-Priorisierung angeschaut und mit in die Bewertung genommen.
Entwicklung einer speziellen Priorisierungs-Methode für den Fachverbund
Recht schnell kristallisierte sich eine Methode zur Priorisierung heraus, die – zumindest als Basis – für das angestrebte Verfahren sehr gut geeignet schien: die Business Value Methode, die zum Teil auch mit Karten als Business Value Poker „gespielt“ wird. Hierbei geben Stakeholder den im Backlog anstehenden Features Punkte, je nachdem wie hoch deren Wert (Business Value) aus ihrer Sicht ist.
Dieses Vorgehen schien für die Priorisierung im Fachverbund ziemlich passend. Allerdings waren aus unserer Sicht noch einige Modifizierungen und Erweiterungen notwendig, damit sich der von allen Beteiligten gewünschte Interessenausgleich bestmöglich einstellen würde. Diese waren im Wesentlichen:
- Inkrementelles Vorgehen: Da es für die Feature-Priorisierung mit so vielen Stakeholdern essentiell ist, dass alle beteiligten Behörden ausreichend Möglichkeiten bekommen, sich auszutauschen und abzustimmen, lag es auf der Hand, dass das Verfahren inkrementell aufgebaut sein muss. Also entschieden wir uns für die Erweiterung der Business-Value-Methode um zwei weitere Inkremente (Wahlgänge). Dadurch sollte gewährleistet werden, dass die Anwender sich untereinander so abstimmen und organisieren, dass für alle wirklich wichtigen Features in den zwei zusätzlichen Verhandlungsrunden sinnvolle Mehrheiten entstehen können.
- Berücksichtigung des Entwicklungsaufwandes: Eine weitere Modifizierung war die Einführung einer zweiten Dimension der Gewichtung als Ergänzung zur einfachen Vergabe von Punkten. Wie bei der Business Value Methode erhielten alle beteiligten Behörden Punkte für die Bewertung der möglichen Features. Darüber hinaus wurde allerdings vom Entwicklungsteam bei SEITENBAU der jeweilige Aufwand (grob) geschätzt und in Story-Points gewichtet. Die insgesamt zu vergebenden 180 Punkte/Story Points ergaben sich dann aus dem tatsächlich zur Verfügung stehenden Budget.
Features sollten demnach nur dann in die tatsächliche Umsetzung gehen, wenn die ihnen zugedachten Story Points (bzw. der Business Value) auch ihren Aufwand decken. So waren also auch Konstellationen möglich, bei denen Features, obwohl sie mehr Punkte auf sich vereint hatten als andere, nicht in die Roadmap priorisiert werden. Im Gegensatz zur klassischen Business Value-Methode floss demnach nicht nur der Value, sondern auch der Aufwand von Anfang an in die Priorisierung mit ein.
Los geht’s – Verteilung der Punkte, Erklärung der Aufwandschätzung und Rückfragen der Teilnehmer
Beim Anfang Juli 2022 durchgeführten Workshop zur Priorisierung nahmen letztlich 16 der insgesamt 40 Behörden des Fachverbunds aktiv teil. Weitere Behörden hatten ihre Punkte an SEITENBAU als Stellvertreter zur Stimmabgabe überlassen, wobei im Vorfeld die Ideen und Positionen der Behörden klar kommuniziert wurden. SEITENBAU sollte dann im Sinne der einzelnen Anwender die Punkte bestmöglich verteilen.
Andere Behörden verzichteten bei der Wahl ganz auf die Teilnahme, da sie insgesamt auf das Votum des Fachverbundes vertrauten und mit den bisher verfügbaren Funktionen bereits alle ihre wesentlichen Anforderungen an die Software abgedeckt sahen.
Zu Beginn des Workshops wurden allen Teilnehmern die zur Abstimmung stehenden Features vorgestellt und die jeweiligen Aufwand-Schätzungen erklärt. Im Anschluss daran wurde noch einmal auf die im Vorfeld bereits online verteilten Spielregeln der Priorisierungsmethode hingewiesen. Eine Fragerunde zu Features, geschätzten Aufwänden und Ablauf der Priorisierung beschloss die Einleitung des Workshops:
nun konnte es umgehend in media res gehen …
Gemeinsame Priorisierung am digitalen Whiteboard, Nervenkitzel und intensive Verhandlungen
… und der erste Wahlgang stand an. Als Tool diente hierbei ein digitales Whiteboard, auf dem alle zur Verfügung stehenden Features mit ihren jeweiligen Aufwänden aufgelistet waren. So konnten alle Teilnehmer jederzeit sehen, wie viele Punkte ein Feature mindestens zur Umsetzung benötigt.
Als dann die ersten 90 (von insgesamt 180) Story-Points von den Behörden auf die verschiedenen Features verteilt waren, wurde schnell offensichtlich, dass zwei der 19 zur Auswahl stehenden Features die zur Umsetzung nötigen Punkte bereits erreicht hatten. Die Verteilung bei den weiteren Features war weniger eindeutig.
Nach der ersten Diskussions- und „Werbe“-Runde erfolgte dann die Vergabe der restlichen 90 Punkte. Doch auch diese zweite Iteration brachte kein ganz klares Meinungsbild: nur wenige der verbliebenen 17 möglichen Features erhielten die notwendige Punktzahl zur Umsetzung. Der Rest jedoch war ziemlich breit über diverse Feature verstreut. Und nun?
Genau an diesem Punkt zeigten sich dann die erhofften Vorteile des neuen Verfahrens: Es gab schließlich noch eine weitere Runde zum Gedankenaustausch. Hier hatten die Behörden noch einmal Gelegenheit, die Vor- und Nachteile der Features zu erörtern und sich dann auf die Funktionen zu fokussieren, die für die Gemeinschaft den größten Nutzen bringen – intensive Diskussionen inklusive. Das abschließende Punkteverschieben begann.
Das Ergebnis: eine gemeinsame Roadmap mit hoher Akzeptanz und kleiner Nachjustierung
Dieses Verschieben in der Schlussrunde brachte nun doch eine klare Präferenz für bestimmte Features und der Fachverbund konnte sich im Ergebnis sehr einvernehmlich auf eine gemeinsame Roadmap mit sechs Features einigen, die nun für das kommende Release entwickelt werden.
Zwar fehlten dem Feature „Dynamisches Organigramm“ eigentlich noch 4 Story Points gegenüber der Schätzung, doch kam der Verbund schnell überein, dass man versuchen solle, diese Funktionalität mit geringfügig geringerem Aufwand zu entwickeln.
Einzig beim Modul zum „Seiten importieren und exportieren“ zeigte die Anzahl der vergebenen Punkte zwar den relativ hohen „Business Value“ für einige Anwender. Mit etwas mehr als der Hälfte der notwendigen Story-Points war man aber noch recht weit von einer Aufnahme in die Roadmap entfernt. Diese Differenz versucht der Fachverbund nun über Crowd Funding im Verbund zu überbrücken, so dass auch dieses Feature voraussichtlich im neuen Release 7 von SON entwickelt werden kann.
Fazit: die Methode funktioniert gut, könnte aber an einigen Stellen noch feinjustiert werden
Am Ende eines spannenden Workshops mit vielen Erkenntnissen war allgemeiner Konsens, dass die gemeinsam entwickelte Roadmap den wohl bestmöglichen Kompromiss darstellt. Während fast alle Behörden die für sie essentiellen Must-haves in die Roadmap einbringen konnten, gab es eine Ausnahme, bei der ein Teilnehmer für „sein“ Must-have leider keine Unterstützer gewinnen konnte. Alles in allem waren sich die beteiligten Behörden darin einig, dass die erarbeitete Roadmap für alle einen großen Nutzen mit sich bringt und man insgesamt mit dem gefundenen Kompromiss mehr als zufrieden sein kann.
Dementsprechend wurde vereinbart, dass die neue Methode auch in Zukunft im Fachverbund zur Priorisierung genutzt werden sollte. Passend zum agilen Mindset im Fachverbund soll zudem die Methode bei Bedarf, im Sinne eines „Inspect & Adapt“-Ansatzes, weiterentwickelt und noch stärker an die eigenen Bedürfnisse angepasst werden. So ist es denkbar bei der nächsten gemeinsamen Priorisierung folgende Anpassungen vorzunehmen:
- Den Zeitrahmen für die Diskussionsrunden zur Werbung für einzelne Features erhöhen und die Diskussion durch stärkere Moderation fördern und unterstützen. So könnte man noch eingehender das Für und Wider bezüglich der Entscheidung zur sofortigen Umsetzung einzelner Features erörtern.
- In der Moderation der Diskussionen die wesentlichen Merkmale der noch verbleibenden, zur Auswahl stehenden Features nochmals kurz und knapp zusammenfassen. Angesichts der vielen möglichen Features und deren Eigenschaften, könnte die so geschaffene Transparenz eine zusätzliche Hilfestellung für die Behörden sein, die für den Fachverbund letztendlich beste Entscheidung zu treffen.
Ein weiteres Learning war zudem, dass die Abstimmung mit dem digitalen Whiteboard vollkommen reibungslos vonstattenging. Niemand hatte bei der Abstimmung Probleme mit der Bedienung, so dass die volle Konzentration jederzeit auf der eigentlichen Aufgabe der Priorisierung lag. Etwaige kleinere Bedenken im Vorfeld erwiesen sich als gänzlich unbegründet.
Und wie geht es nun weiter?
Die Umsetzung der mit der neuen Methode abgestimmten Roadmap ist bereits in vollem Gange. Features, die bei der Entwicklung des neuen Release 7 nicht berücksichtigt wurden, können von den Behörden für die Abstimmung der nächsten Releases nochmals eingebracht werden. Priorisiert wird dann wieder spielerisch: mit der gemeinsam erprobten Priorisierungsmethode!
