HERMES 2022 – Agile als Blackbox?

Warum soll Hermes agil werden?

Der Trend zu agilen Arbeitsformen in der IT und in immer weiteren Bereichen der Organisation ist ungebrochen, getrieben durch eine innovative IT und die Digitalisierung von Prozessen. Lösungsoptionen, die gestern noch strategisch waren, sind heute bereits Makulatur und Anforderungen ändern sich häufig fast täglich. Und zwar nicht, weil die Benutzer dies wollen, sondern weil das Umfeld sich rasch verändert. Kurz: Wir leben in einer VUCA-Welt. 

Veränderungen an Produkten und Services verlangen deshalb ein adaptives Vorgehen mit raschen Feedbackzyklen. Diese Veränderungen sind zunehmend im Fokus von Projektmethoden wie HERMES, die traditionell dem klassischen Phasenmodell folgen (mit agiler Entwicklung als Modul) und Änderungen eher als eine Ausnahme behandeln. Gespannt war ich deshalb, wie die neue Version HERMES 2022 die beiden Welten für die Steuerung von Veränderungen im Produktlebenszyklus noch besser verbinden würde. 

Was sagt die HERMES (Beta Version) 2022 zur Agilität?

HERMES 2022 beginnt mit einer Seite «Prolog», als wohlformulierte Grundsätze der Eidgenössischen Finanzkommission (EFK). Ganz offensichtlich konsolidiert aus unzähligen nicht immer ganz erfolgreichen Projekten. Wie wurden diese Empfehlungen in HERMES 2022 umgesetzt? Kurz: leider ist die neue Version eher eine Verschlimmbesserung. Sie hat signifikante Lücken, genau dort, wo sie das Beste aus beiden Welten in der Praxis verbinden möchte, und wird den cleveren Thesen im Prolog nicht gerecht:

1. Aus dem Prolog zur Steuerung: 

«Steuern Sie als Auftraggeber das Vorhaben … den Geschäftsnutzen ins Zentrum stellen und die Berichterstattung konsequent danach ausrichten» und weiter: «Definieren Sie z.B. über Meilensteine, wann Sie welchen Projektnutzen realisiert haben wollen und überlassen Sie die Projektdurchführung primär dem Projektteam». Zudem schlägt HERMES 2022 vor, zur Steuerung der Blackbox der Phase Umsetzung Release-Meilensteine zur Kontrolle durch die Auftraggeber zu nutzen. 

Meine Erfahrungen: In einer VUCA-Welt ist eine häufige adaptive Steuerung essenziell. Release-Meilensteine erlauben dem Auftraggeber zwar mehrere End-to-End-Feedbackloops statt nur einem am Projektende, aber genügt das? Unsere Erfahrung sagt «Nein». Agile Produktentwicklungsteams sind Feedbackloops (mit Stakeholdern inkl. Auftraggebern) im Wochen-, Monats und Quartalstakt gewohnt, geführt als Dialog, nicht zur Kontrolle. Eine agil geführte Umsetzung ist eine «Whitebox», keine Blackbox. Ausserdem sollte die Zusammenarbeit zwischen Endanwendern, Betreibern und Auftraggeber intensiv und auf gleicher Höhe stattfinden.

2. Aus dem Prolog:

«Schicken Sie Architektur-, IKS- und Sicherheitsverantwortliche früh ins Rennen…». 
Dazu fehlt leider jeder Hinweis in HERMES 2022. Es suggeriert, dass Dokumente als Lieferobjekte hier genügen. Aspekte wie: sich laufend entwickelnde Dokumente, enge Zusammenarbeit, Prüfungen im laufenden Betrieb werden nicht erwähnt.

Meine Erfahrungen: Frühe gezielte Einbeziehung ist u.E. aus Sicht Produktlebenszyklus essenziell und wird durch agiles Vorgehen – sofern clever umgesetzt – explizit unterstützt. Ich mache exzellente Erfahrungen mit frühem und kontinuierlichem Dialog sowie laufender Begleitung in diesen (und weiteren) Themen. Dazu gehören kontinuierliche Tests, z.B. durch Einbinden der OWASP-Top-10-Vulnerability-Kriterien (Security) in den täglichen, automatisierten Build-Prozess. Damit werden Schwächen laufend entdeckt und nicht erst kurz vor dem Release. Es ist immer wieder erfrischend zu sehen, wie der Fokus auf die wirklich relevanten Fragen fällt, wenn Themen wie Security oder Compliance in einem agilen Umfeld gelöst werden sollen. 

3. Aus dem Prolog:

«…der Anwendervertreter (Product Owner) sowohl über das Fachwissen als auch die nötigen Entscheidungsbefugnisse verfügt» und weiter «… überlassen Sie die Projektdurchführung primär dem Projektteam». Die von HERMES 2022 vorgeschlagene Lösung stellt die Governance auf den Kopf. Dem Anwendervertreter wird die Product Owner Rolle zugeteilt, quasi als Schnittstelle zum Entwicklungsteam. Zusätzliche Kompetenzen erhalten er und das Team nicht.

Meine Erfahrungen: Die Aussage der EFK ist ein Steilpass für echt agiles Vorgehen. Die Erfahrung zeigt, dass zwei Schlüsselkompetenzen einen guten Product Owner auszeichnen: «entscheidungs­fähig» (= können, Sachkompetenz) und «entscheidungs­willig» (= wollen, Mut). Dies nicht im Sinne von «Alle überstimmen» sondern «Im Interesse des Ganzen». Agile lässt sich nicht kapseln, wenn man den vollen Wert haben will, funktioniert sie nicht als Blackbox. Die Steuerungsmöglichkeiten sind bei agilem Vorgehen - richtig gelebt(!) - erfahrungsgemäss signifikant besser als in den meisten klassischen Projekten. Dies weil Auftraggeber, Endbenutzer, Betrieb, Security und weitere Stakeholder regelmässig gemeinsam Einblick in das lauffähige Produkt/den Service nehmen und nicht nur schöngefärbtes Papier begutachten. Dies umzusetzen ist nicht immer trivial, aber meist sehr heilsam für das Risikoprofil von Veränderungen. Ein Produkt in kleinen Stücken zu denken, welche stufenweise Nutzen bringen, ist anspruchsvoll, ungewohnt und braucht etwas Mut zu Neuem.

4. Aus 3. folgt:

Die Stellung des «Projektleiters» in der Governance ist kritisch zu hinterfragen. Grosse, komplexe Veränderungen brauchen klar mehr Management-Kapazität als der Normalbetrieb einer Organisation. Und letztlich zählt nur der stabile, nutzenstiftende (spätere) Betrieb, nicht der Projekterfolg. Die Rolle des Product Owners (PO, verantwortlich u.a. für den kommerziellen Erfolg des Produkts) ist die weitaus anspruchsvollste in einem typischen agilen Set-up und braucht für grosse Veränderungen dringend Unterstützung. Wieso nicht durch «ein Art Projektleiter» mit noch näher zu definierenden Aufgaben? In HERMES 2022 rapportiert der PO dem Projektleiter, welcher sich – etwas verkürzt gesagt - auf die Fortschrittskontrolle beschränken solle und den Inhalt dem PO überlässt. Wie sich diese Beziehung sinnhaft gestalten lässt, bleibt leider im Dunkeln.

Was uns sonst noch auffällt:

1. Was ich mir von der EFK noch gewünscht hätte, wäre eine Aussage zur «Betriebsphase» gewesen, welche typischerweise mehr als 75% der Gesamtkosten ausmacht. Dies ist wohl dem Projektfokus der EFK im «Prolog» zuzuschreiben, d.h. der Tatsache, dass hier die Betriebsphase durch die EFK nicht überprüft wird. Schade. Sowohl der Produkt- wie auch der Projektlebenszyklus haben ihre Berechtigung, HERMES 2022 deckt weiterhin strikt den letztgenannten ab. Angesichts der Kostenverteilung mehr Hinweise wünschte ich mir im Sinne des grossen Ganzen und weniger Abgrenzung. Der Übergang von projektartiger (allenfalls agiler) Beschaffung in eine kontinuierliche Maintenance fehlt. Es wird weiter die Vorstellung gepflegt, dass man Software beschaffen und sie dann ohne grössere Anpassungen für Jahre betreiben kann.
2. Trotz vielen Hinweisen zu Agile in HERMES 2022 fehlt an wesentlichen Stellen eine konkrete, praktische Hilfestellung, wie bei einem agilen Vorhaben vorzugehen ist - es wird nur der klassische Fall beschrieben.

Einige Beispiele:

Bei einem Projekt für den Einkauf von Standardsoftware (z.B. SAP, Zeiterfassung,...) mit anschliessender Anpassung mit dem Lieferanten fehlen Hinweise in Richtung agiler Ausschreibung und Beschaffung der Verträge, der Zusammenarbeit und Governance.

HERMES 2022 beschreibt einige Lieferobjekte, welche für den Betrieb ihre Berechtigung haben, z.B. die Betriebsorganisation und welche typischerweise in agilen Frameworks fehlen. Auch hier fehlen Hinweise für ein geschicktes Vorgehen in agilen Umfeldern, wie schlanke, clevere, laufend nachgeführte Dokumentationen (Wiki statt Dokumente), frühe Erfahrungen und eine intensive Zusammenarbeit. Die EFK-Empfehlungen lassen grüssen. 

Fazit

HERMES 2022 ist weiterhin eine traditionelle Projektmethodik und bleibt, auch mit ein paar Streuseln «Agile» drauf, ein Wasserfallvorgehen. Dies finde ich nicht ungefährlich, da es dem unbedarften Leser suggeriert, dass damit die von Agilität versprochenen Nutzen erreicht werden. Schade, gerade auch, weil an zentralen Stellen, wie der Einbindung der PO Rolle, zu viele Kompromisse eingegangen wurden.

Weitere Blogs, in welchen wir die Änderungen in Hermes 2022 bezüglich der agilen Vorgehensweise in der IT-Entwicklung oder IT-Adoption aus Sicht der «ART of SwissQ» - Agile, Requirements und Testing - näher betrachtet werden, findest du hier.