Wie passt Agilität in HERMES?
HERMES 2022 entkoppelt Projektmanagement und Entwicklungsmanagement. Das Projektmanagement bettet das Vorhaben in die Governance der Stammorganisation ein — Schnittstellen zur Aufbau- und Ablauforganisation, minimale Lieferergebnisse, Freigaben. Das Entwicklungsmanagement bestimmt, wie die Lösung entsteht.[1] Diese Trennung ist der Kern der Ausgabe 2022 und der Grund, warum HERMES heute klassische und agile Projekte im selben Rahmen führt.[2]
Der Agile Leitfaden, eine offizielle Erweiterung zum Referenzhandbuch, leitet daraus drei Kombinationen ab: Klassische Entwicklung führt zu klassischem HERMES-Projektmanagement, agile Entwicklung zu hybridem Projektmanagement, und eine hybride Entwicklung zu einer Kombination aus beidem.[1] «Hybrid» heisst hier: Die Phasen Initialisierung und Abschluss sowie alle Steuerungsentscheide bleiben klassisch, dazwischen arbeitet das Team iterativ.
| Entwicklung | Projektmanagement | Phasen |
|---|---|---|
| Klassisch | HERMES klassisch | Initialisierung, Konzept, Realisierung, Einführung, Abschluss |
| Agil | HERMES hybrid | Initialisierung, Umsetzung, Abschluss |
| Hybrid | Kombination klassisch und hybrid | Klassische Phasen wie Konzept oder Einführung kombiniert mit einer agilen Umsetzung |
Als agile Methoden nennt HERMES einfache Methoden wie Scrum oder Kanban und skaliert agile Methoden wie SAFe bis zur Stufe «Essential» beziehungsweise «ART Flow».[3] Die Begriffe innerhalb der Entwicklung schreibt HERMES nicht vor; verbindlich sind nur die Schnittstellen und die Ergebnisse des Projektmanagements. Die Grundlagen der Phase Umsetzung beschreibt das Kapitel HERMES-Phasen.
Wann ist agil die richtige Wahl?
Der Entscheid fällt in der Initialisierung mit dem Entscheid Weiteres Vorgehen. Er klärt Lösungsvariante, Szenario, Vorgehensweise und Projektwertigkeit. Die Wahl ist pro Projekt zwingend, kann nicht im Programm oder Portfolio vorgeschrieben werden und muss nachvollziehbar sein; die Studie wird entsprechend ergänzt.[1] Der Leitfaden liefert dafür eine Entscheidungshilfe mit Kriterien, von denen einige laut Leitfaden stark gegen eine agile Umsetzung sprechen:
| Kriterium | Spricht für klassisch | Spricht für agil |
|---|---|---|
| Typ des Vorhabens | Life-Cycle-Vorhaben, Standard-Beschaffung, stark reglementierte Vorhaben wie Rechtsetzung | Innovationsvorhaben: individuelle Lösung oder Organisationsveränderung |
| Umfang | Umfang und Anforderungen weitgehend klar, Änderungen teuer | Funktionsumfang noch offen, Änderungen gehören zur Methode |
| Time-to-Market | Produktiv gehen mit der vollständigen Lösung | Schnell mit einer Basislösung produktiv, dann iterativ ausbauen |
| Technologie | Bekannt, Risiken gut abschätzbar | Neu, höhere Risiken |
| Agile Kompetenz | Wille, Kompetenz oder Erfahrung fehlen | Organisation will und kann agil arbeiten |
| Einbezug des Fachs | Fach nur bei Anforderungen und Tests, kein Product Owner verfügbar | Fach wirkt stark mit und stellt einen Product Owner |
| Kapazität | Mitarbeitende nur sporadisch verfügbar | Fixe Zuteilung zu den Teams möglich |
| Lieferant | Arbeitet klassisch | Arbeitet agil |
| Projektstand | Realisierung bereits klassisch begonnen | Realisierung noch nicht begonnen |
| Variabilität | Fokus auf Umfang; Änderungen wirken auf Zeit und Ressourcen | Fokus auf Zeit und Ressourcen; Änderungen wirken auf den Umfang |
Die verbreitete Stacey-Matrix, die Klarheit der Anforderungen und der Technologie gegenüberstellt, hält der Leitfaden für einen nützlichen ersten Eindruck, aber nicht für schlüssig. Die Kriterien sollen einzeln geprüft und mit dem Bild der Matrix verglichen werden.[1] Die Wahl gehört in den Durchführungsauftrag, zusammen mit dem Szenario aus dem Kapitel HERMES-Szenarien.
Wer macht was in einem agilen HERMES-Projekt?
Der wichtigste Grundsatz: Weder Projektleiter noch Auftraggeber nehmen direkt Einfluss auf Abläufe und Zeremonien der agilen Umsetzung. Fachlich interagieren sie nur über den Anwendervertreter, der gleichzeitig die Rolle des Product Owners oder eine vergleichbare Rolle im Entwicklungsteam haben kann.[1]
| Rolle | Aufgabe bei agiler Umsetzung |
|---|---|
| Auftraggeber und Projektleiter | Steuern und führen das Projekt, nehmen aber keinen Einfluss auf die operative, fachliche Umsetzung |
| Anwendervertreter | Schnittstelle zum Entwicklungsteam; idealerweise in Personalunion Product Owner |
| Entwicklungsteam | Rollengruppe aller Ausführungsrollen während der Phase Umsetzung; das Referenzhandbuch nennt sie Umsetzungsorganisation |
| Qualitäts- und Risikomanager | Bleibt unabhängig; der Blackbox-Ansatz gilt für diese Rolle nicht, sie darf Informationen direkt im Team einholen |
Bei kleinen Vorhaben können Anwendervertreter und Product Owner in Personalunion besetzt werden. Bei komplexeren Vorhaben mit mehreren Entwicklungsteams empfiehlt der Leitfaden eine getrennte Besetzung.[1] Alle Standardrollen und Besetzungsregeln stehen im Kapitel HERMES-Rollen.
Planung: vom Projektmanagementplan zum Releaseplan
Bis zum Vorgehensentscheid in der Initialisierung wird klassisch geplant. Grobanforderungen dürfen trotzdem schon als User Stories, Epics oder Features beschrieben werden. Die minimalen Ergebnisse der Initialisierung — einschliesslich des Projektmanagementplans mit der Durchführungsplanung — entstehen in jedem Fall.[1]
Fällt der Entscheid auf agil, entsteht der Releaseplan mit Releases, Abhängigkeiten, Voraussetzungen, Organisation und Terminen. Er ist Teil des Projektmanagementplans oder wird separat geführt. Weil sich Release-Termine im Lauf der Umsetzung verschieben, muss der Projektmanagementplan laufend synchronisiert werden — in beide Richtungen: Änderungen aus dem Team fliessen in den Plan, äussere Einflüsse werden über den Anwendervertreter dem Team kommuniziert.[1]
Welche HERMES-Ergebnisse entstehen agil?
Die minimalen HERMES-Ergebnisse müssen in jedem Fall erstellt werden. Der Projektleiter legt mit dem Anwendervertreter fest, welche Lieferergebnisse entstehen; der Anwendervertreter führt sie als Anforderungen im Backlog und priorisiert sie. Anders als klassisch werden sie iterativ entwickelt — ein ISDS-Konzept etwa wird initial erarbeitet und vor jeder Vorabnahme eines Releases überprüft und angepasst.[1]
| HERMES | Scrum | Hinweis |
|---|---|---|
| Lösungsanforderungen | Product Backlog (initial) | Änderungen über die Änderungsstatusliste, Änderungsantrag nur bei Folgen für Ziele, Budget oder Zeit |
| Detailspezifikation | Sprint Backlog | Dient nur der Dokumentation; ein Verweis auf das Entwicklungswerkzeug genügt |
| Anwendervertreter | Product Owner | Idealerweise dieselbe Person |
| Entwicklungsteam/Umsetzungsorganisation | Developers, Scrum Master | Organisiert sich selbst |
| Release mit Vorabnahme und Abnahme | Release eines oder mehrerer Inkremente | HERMES verlangt die Betriebsaktivierung pro Release |
| Releasefreigabe (optional) | keine direkte Entsprechung | Governance-Element der Steuerung |
Die Zuordnung von Lösungsanforderungen und Detailspezifikation stammt aus den Ergebnisbeschreibungen des Referenzhandbuchs.[2] Welche Ergebnisse ein Projekt insgesamt verlangt, beschreibt das Kapitel HERMES-Ergebnisse.
Reporting und Steuerung bei agiler Umsetzung
Die Stammorganisation muss nach HERMES regelmässig über den Stand informiert werden. Das Entwicklungsmanagement bereitet die Informationen auf und übermittelt sie über den Anwendervertreter; der Projektleiter bereitet sie so auf, dass die Projektsteuerung sie versteht. Innerhalb des Teams gilt das Reporting der gewählten agilen Methode.[1]
In der Praxis heisst das: Burn-down- oder Burn-up-Charts, Velocity und Release-Prognosen bleiben im Team; im Projektstatusbericht erscheinen Releasefortschritt, Budgetverbrauch, Risiken und Entscheidungsbedarf. Die optionale Releasefreigabe gibt dem Auftraggeber zusätzlich einen Steuerungspunkt pro Release, ohne in die Sprints einzugreifen.
Welche agilen Werkzeuge empfiehlt der Leitfaden?
Der Leitfaden nennt methodenunabhängige Werkzeuge, die sich bewährt haben, ausdrücklich als nicht abschliessende Liste:[1]
- Visualisieren: Kanban- oder Task-Board, auch mit Swimlanes je Modul; Burn-down-Chart; Design Sprint; Whiteboard.
- Anforderungen und Planung: User Stories, Epics, Personas, Story Points, Planning Poker, Timeboxing, Definition of Done.
- Zusammenarbeit: Daily-Stand-up, Kollaborationsplattform, Retrospektive.
Für die Umsetzung in einem Werkzeug bietet sich eine Trennung an, die der HERMES-Logik folgt: Das Team arbeitet auf dem Kanban-Board, die Projektführung sieht Releases, Gates und Abhängigkeiten in einer Timeline. In Flenio laufen beide Ansichten auf denselben Aufgaben, sodass keine Doppelpflege zwischen Team- und Steuerungssicht entsteht.
Beispiel: ein agiles Projekt mit drei Releases
Ein kantonales Amt will ein Online-Gesuchsportal entwickeln. In der Initialisierung zeigt die Studie, dass der Funktionsumfang erst mit den Nutzenden präzisiert werden kann; ein Fachbereich stellt eine Person als Anwendervertreterin mit Entscheidungsbefugnis. Nach der Entscheidungshilfe spricht damit vieles für agil. Der Auftraggeber trifft den Entscheid Weiteres Vorgehen, der Durchführungsauftrag hält das Szenario und die agile Umsetzung fest.
Der Projektmanagementplan enthält einen Releaseplan mit drei Releases: ein Basisportal für ein Gesuchsformular, danach weitere Gesuchsarten, schliesslich Schnittstellen zu Fachanwendungen. Pro Release folgen Vorabnahme, Betriebsaufnahme und Abnahme; vor dem ersten Release gibt die Führung die Lösungsarchitektur und das ISDS-Konzept frei. Der Auftraggeber verlangt eine Releasefreigabe vor Release zwei, weil dann zusätzliche Mittel nötig werden. Im Team arbeiten Entwicklerinnen, Testende und die Anwendervertreterin als Product Owner in Sprints; die Projektleitung berichtet monatlich über Releasefortschritt, Budget und Risiken an den Projektausschuss.
Typische Fehler in agilen HERMES-Projekten
- Agil wählen, weil es modern ist — das Referenzhandbuch verlangt einen fachlich und vorgehenstechnisch begründeten Entscheid.
- Der Projektleiter verteilt Aufgaben im Team und hebelt damit die Selbstorganisation aus.
- Der Anwendervertreter hat keine Entscheidungsbefugnisse; das Team wartet auf Antworten, die niemand geben darf.
- Minimal geforderte Ergebnisse werden als «nicht agil» weggelassen statt als Backlog-Einträge iterativ erarbeitet.
- Der Releaseplan wird nicht mit dem Projektmanagementplan synchronisiert; Steuerung und Team planen gegen verschiedene Termine.
Den Rahmen für alle diese Punkte setzt der HERMES-Leitfaden; wie agile Teams grundsätzlich arbeiten, beschreibt die Methode Scrum.