HERMES 2022 ist da und darin soll, nach eigenen Angaben, darauf geachtet worden sein, "das agile Entwicklungsvorgehen im HERMES-Projektmanagement an die aktuellen Bedürfnisse der Organisationen angepasst werden" (HERMES, 2022, p. 3). Was hat sich also getan in Bezug auf agil? Es wurde die Möglichkeit geschaffen, mehrere Releasefreigaben während der agilen Entwicklung durchführen zu können. Auch wurde explizit die agile Entwicklungsmethode als Blackbox in das Phasenvorgehen von HERMES integriert und somit den Entwicklungsteams eine agile Arbeitsweise ermöglicht. Dazu gibt es eine neue (nur in der agilen Umsetzung vorhandene) Phase "Umsetzung" – und dafür die Phasen "Konzept", "Realisierung" und "Einführung" bei agiler Umsetzung nicht mehr.
Aber reicht das, um agil zu sein? Die Frage stellt sich und man muss dabei auch im Hinterkopf haben, was "agil" denn wirklich heisst. Wikipedia definiert dies so:
"Agile Softwareentwicklung (von lateinisch agilis „flink, beweglich“) bezeichnet Ansätze im Softwareentwicklungsprozess, die die Transparenz und Veränderungsgeschwindigkeit erhöhen und zu einem schnelleren Einsatz des entwickelten Systems führen sollen, um so Risiken und Fehlentwicklungen im Entwicklungsprozess zu minimieren. Dazu wird versucht, die Entwurfsphase auf ein Mindestmaß zu reduzieren und im Entwicklungsprozess so früh wie möglich zu ausführbarer Software zu gelangen. Diese wird in regelmäßigen, kurzen Abständen mit dem Kunden abgestimmt. So soll es möglich sein, flexibel auf Kundenwünsche einzugehen, um so die Kundenzufriedenheit insgesamt zu erhöhen.
Agile Softwareentwicklung zeichnet sich durch selbstorganisierende Teams sowie eine iterative und inkrementelle Vorgehensweise aus." (Wikipedia, 2022)
Diese Definition entspricht auch in etwa dem Agilen Manifest (Beck et al., 2001).
HERMES 2022 als agile Methode
Nach diesen Kriterien könnte HERMES 2022 tatsächlich als agil angesehen werden. Es sind definitiv Ansätze vorhanden um möglichst schnell ein Inkrement erstellen und verifizieren zu können und die Entwicklungsteams sollen soweit möglich selbstorganisiert sein.
Weiterhin weisst HERMES bereits im Prolog darauf hin, dass "Kulturwandel in Veränderungen zentral ist"(HERMES, 2022, p. 3).
HERMES 2022 zeigt sich besonders im Prolog (geschrieben von der Eidgenössischen Finanzkontrolle – EFK, (HERMES, 2022, p. 3)) in den folgenden Bereichen als "kompatibel" mit dem klassischen Verständnis von Agilität:
- Der Product Owner sollte von der Fachseite kommen und ist der Anwendervertreter (HERMES, 2022, p. 151)
- Die Verantwortung der Fachseite (Auftraggeber) das Vorhaben zu steuern und den Geschäftsnutzen ins Zentrum zu stellen (HERMES, 2022, p. 3)
- Ein Reporting anhand dem Geschäftsnutzen aufzusetzen (HERMES, 2022, p. 3)
- Grundlegend steuernd zu definieren, welche Projektnutzen erwartet werden und dem Projektteam die Durchführung zu überlassen (HERMES, 2022, p. 3)
- Selbstorganisierte Entwicklungsteams (HERMES, 2022, p. 155)
- Die Entwicklungsteams können die Lösung iterativ-inkrementell erarbeiten und - falls gewünscht - auch mehrere Releases durchführen (HERMES, 2022, p. 14)
- Falls gewünscht kann der Auftraggeber bei jedem Release entscheiden, wie es weitergehen soll (das heisst in HERMES "Release Freigabe" und gemeint ist, ob der darauffolgende Release – im Sinne einer Phase freigegeben wird) (HERMES, 2022, p. 84)
- (HERMES, 2022, p. 20)[DP1] (inwiefern die Milestones dann in einer bestimmten Reihenfolge erfüllt werden müssen oder einfach am Ende eines Releases erfüllt sein müssen ist dann vermutlich eine Frage der Durchführung, siehe [DP2] Abbildung 3 unten)
- In der Phase "Initialisierung" werden grobe Anforderungen definiert und (bei Wahl der agilen "Umsetzung") in einen initialen Backlog überführt (HERMES, 2022, pp. 53, 107)
- Das Entwicklungsteam ist interdisziplinär aufgestellt und der Projektleiter darf nicht in die Selbstorganisation des Entwicklungsteams eingreifen (HERMES, 2022, p. 155)
HERMES 2022 vielleicht doch nicht so agil
Allerdings gibt es noch ein Problem: in HERMES 2022 werden agilen Methoden (die Büchse der Pandora mit der Diskussion "agile Methoden" oder "agile Frameworks" mache ich jetzt bewusst nicht auf) in ein Phasenvorgehen eingebettet. Dies führt zu ein paar grundlegenden Problemen aus einer rein agilen Sichtweise:
- Da es sich um eine Projektmanagementmethode handelt wird ein Projekt abgewickelt und als solches muss recht früh (in der Phase "Initialisierung") auch bereits grob die Lösung beschrieben werden (HERMES, 2022, p. 23)
- In der Phase "Umsetzung" wird dann die Lösung soweit nötig detailliert und umgesetzt - aber die Lösung selbst wurde in der Phase "Initialisierung" bereits definiert.
- Es kommen dem klassischen Projektcontrolling angelehnte Kontrollmechanismen zum Zug, z.B. Burndown-Charts. Diese tracken aber nur die Einhaltung eines Plans und nicht, ob ein Problem wirklich zufriedenstellend gelöst wird, also prinzipiell schon ein Widerspruch zum «Reporting von Geschäftsnutzen», siehe oben.
- Die Phase "Initialisierung" wird immer klassisch (nicht agil) abgewickelt (HERMES, 2022, p. 21)
- Die Führungsrolle des Projektleiters kann mit der Rolle eines Product Owners (Anwendungsvertreter, inhaltliche Verantwortung) kollidieren (HERMES, 2022, pp. 142, 147, 151)
- Bei der agilen Variante geht HERMES von einem Fixpreis oder Kostendach aus (HERMES, 2022, p. 170). Dies mag bei einer echt agilen Arbeitsweise für einen (mehr oder weniger kurzen) Zeithorizont gelten (da zum Beispiel das Team fix ist), aber nicht für die gesamte Entwicklungsdauer.
- Der Auftraggeber kontrolliert den Projektfortschritt anhand der von der Projektleitung erstellten Berichte (HERMES, 2022, p. 119). In einer agilen Welt sollte der echte Fortschritt begutachtet werden (in Form von: was haben wir erreicht, was ist fertig, was liefert einen Wert), nicht Fortschrittsmetriken, die auf Plan-Ist Vergleichen beruhen.
- Es wird auf einen optionalen Qualitäts- und Risikomanager verwiesen, wenn es um die Überprüfung der Qualität der Lösung geht; und dieser soll auch Empfehlungen und Massnahmen zur Erreichung der Ziele geben (HERMES, 2022, p. 146). Hierin könnte definitiv ein Konflikt mit der Rolle des Product Owners und auch der Umsetzungsteams entstehen.
- Der Projektleiter verantwortet "wirtschaftlicher und nachhaltiger Einsatz der Ressourcen" (HERMES, 2022, p. 147). Wie die Ressourcen eingesetzt werden, liegt in einem agilen Vorhaben beim selbstorganisierten Team - und das aus gutem Grund. Die Verantwortung, nachhaltig und wirtschaftlich vorzugehen, liegt typischerweise beim Product Owner (Schwaber and Sutherland, 2020, p. 5).
- Der Product Owner (Anwendervertreter) ist "während der Lösungsentstehung in fach- und lösungsspezifischen Fragen und Entscheidungen im Rahmen des Budgets eigenständig", wird jedoch "vom Projektleiter geführt" (HERMES, 2022, p. 151). Das ist, zumindest auf den ersten Blick, ein Widerspruch. In eine ähnliche Richtung geht die Verantwortung "Einbindung der Stakeholder gemäss Stakeholderliste"; die Stakeholderliste ist ein Ergebnis der Phase "Initialisierung". Auch hier wird die typische Kompetenz des Product Owners und auch des Entwicklungsteams beschnitten.
- Der Product Owner "fungiert auch als Schnittstelle zum Entwicklungsteam" und hat die "Verantwortung für die Kommunikation mit dem Entwicklungsteam". Beides entspricht nicht der Idee des Product Owners, wie beispielsweise in Scrum (Schwaber and Sutherland, 2020) definiert.
- Die Rolle des Business Analysten erhält die Verantwortung über die Organisationsanforderungen und den Einbezug von Spezialisten (HERMES, 2022, pp. 142, 153). Dies kann mit der typischen Idee eines Product Owners und eines selbstorganisierten Teams kollidieren.
- Das Entwicklungsteam (im Fall von Scrum als verwendete Methode, das Scrum Team oder die Entwickler und der Scrum Master) haben nach HERMES 2022 keine spezifische Verantwortung. Die Verantwortung des Entwicklungsteams ist lediglich durch die Verantwortung der beteiligten Rollen definiert. Das kann problematisch sein, wenn es darum geht ein echtes, high-performing Team mit sozialer Sicherheit zu schaffen (Prohammer, 2022 oder Scaledagile, 2022).
- Die Governance hat - es ist eine Projektmethode - den Fokus auf eine "Effektive und funktionsfähige Projektplanung, -steuerung und -führung". (HERMES, 2022, p. 159).
- "HERMES-Projektmanagement ist darauf ausgerichtet, eine gute Projekt-Governance zu gewährleisten" (HERMES, 2022, p. 160). Die Governance ist definiert wie im vorherigen Punkt und richtet sich somit nicht am Ergebnis aus, sondern an der Art der Durchführung; oder aus agiler Sicht an sogenannten "Vanity-Metriken". Es geht darum etwas "richtig" zu machen und nicht darum sicherzustellen, dass man das "Richtige richtig" tut. Agile Methoden versuchen möglichst schnell und kontinuierlich zu prüfen, ob das "Richtige richtig" gemacht wird. Das ist der Kern der agilen Vorgehensweise mit den möglichst kurzen Lernzyklen, dem Feedback und darauf reagieren.
- In dieselbe Richtung geht auch "Auftraggeber samt Projektausschuss und Qualitäts- und Risikomanager auf der Hierarchieebene Führung arbeiten entsprechend dem klassischen Projektmanagement; das Entwicklungsteam auf der Hierarchieebene Ausführung mit den agilen Techniken" (HERMES, 2022, p. 169). Dies zeigt aber auch deutlich das grundlegende Problem auf: eigentlich ist nur die Umsetzung agil, der Rest nicht.
Fazit
Ja, HERMES 2022 kann zu einem gewissen Grad als agil bezeichnet werden und unter den Umständen in denen es normalerweise eingesetzt wird (mittlere bis sehr grosse Vorhaben (HERMES, 2022, p. 4) und dem Bundesumfeld mit seinen Prozessen, Budgetierungen und Ausschreibungen) ist die erarbeitete Lösung sicher ein Schritt in die richtige Richtung. Es werden jedoch einige der wesentlichen Elemente aus der agilen (Produkt-) Entwicklung grundlegend ignoriert. Dies ist wohl dem Fokus auf das beschriebene Umfeld und der angestrebten Governance geschuldet. Als echt agil würde ich dieses Vorgehen somit nicht bezeichnen.
Es bleibt aber abzuwarten, wie sich HERMES 2022 in der Praxis bewährt – bei HERMES 5 war auch schon ein grosser kreativer Spielraum bei der Auslegung in den einzelnen Bereichen erkennbar. Den Fokus auf das Wesentliche zu lenken, den grössten Mehrwert aus einem Vorhaben und der verwendeten Umsetzungsmethode zu ziehen, das ist eine der Kompetenzen unserer Agile Coaches.
Auf der anderen Seite verwenden viele Firmen, die mit agiler (Produkt-) Entwicklung auch (noch) nicht ganz warm geworden sind, einen ähnlichen Ansatz. Und sie sind damit nicht allein: dieser Spagat zwischen phasenorientiertem Vorgehen und iterativ-inkrementellem Vorgehen ist nicht neu und war schon unter den Begriffen RUP (Rational Unified Process (IBM Rational Software, 2022)), AUP (Agile Unified Process, (Ambler, 2006)) oder auch dem Nachfolger DAD (Disciplined Agile Delivery, heute Teil von PMI – Project Management Institute (PMI Disciplined Agile, 2022)) bekannt. Warum also nicht auch bei HERMES? Den vollen Nutzen aus einem agilen Ansatz für die (Produkt-) Entwicklung werden weder DAD noch Hermes 2022 so nicht erreichen.
Es steht jedoch immer die Option offen, sich mehr auf die agile Welt einzulassen, einzelne Bereiche oder (besser) die gesamte Produkt- oder Serviceentwicklung agil zu gestalten, oder sich sogar in Richtung der Business Agilität zu bewegen. Darin unterstützen wir unsere Kunden und ermöglichen den Austausch all derer, die sich auf diesem Weg befinden.
Referenzen
Ambler, S. W. (2006) ‘The Agile Unified Process (AUP) Home Page’ [Online] Ambysoft. Available at http://www.ambysoft.com/unifiedprocess/agileUP.html (Accessed 11 November 2022).
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J. and Thomas, D. (2001) ‘Agiles Manifest’ [Online] Manifest für Agile Softwareentwicklung. Available at https://agilemanifesto.org/iso/de/manifesto.html (Accessed 7 November 2022).
HERMES (2022) Hermes Referenzhandbuch - Projektmanagement, Bern Available at https://www.hermes.admin.ch/ (Accessed 7 November 2022).
IBM Rational Software (2022) ‘Rational Unified Process’, Wikipedia Available at https://de.wikipedia.org/wiki/Rational_Unified_Process (Accessed 11 November 2022).
PMI Disciplined Agile (2022) ‘Disciplined Agile Delivery (DAD)’ Available at https://www.pmi.org/disciplined-agile/process/introduction-to-dad (Accessed 11 November 2022).
Prohammer, D. (2022) ‘Agile Team Facilitation – der Effektivitäts-Booster für dein agiles Team’, SwissQ Consulting AG - Agile Available at https://swissq.it/agile/agile-team-facilitation-der-effektivitats-booster/ (Accessed 11 November 2022).
Scaledagile (2022) ‘Agile Teams’ [Online] Scaled Agile Framework. Available at https://www.scaledagileframework.com/agile-teams/ (Accessed 11 November 2022).
Schwaber, K. and Sutherland, J. (2020) ‘The 2020 Scrum Guide’ [Online] Scrum Guides. Available at https://scrumguides.org/scrum-guide.html (Accessed 22 October 2021).
Wikipedia (2022) ‘Agile Softwareentwicklung’, Wikipedia Available at https://de.wikipedia.org/wiki/Agile_Softwareentwicklung (Accessed 7 November 2022).