2. S. 2
HERMES 5 heute
Traditionelles PM mit „Agiler Ergänzung“
Entscheidung Variante
Entscheidung Agil
3. S. 3
Leitfaden Agiles HERMES 5
Mitarbeit:
Andreas Hamberger (Mitglied
Themengruppe)
Boris Bäsler (QS Scrum)
Daniel Kobi (Autor)
Frank H. Ritz (Autor)
Hans Dijkgraaf (QS HERMES 5)
Hans-Jürg Kleine (Autor)
Matthias Roth (Autor / Leiter
Themengruppe)
Peter Lang (Autor / Lektor)
4. S. 4
Einbettung der User Group eco-HERMES
eco-HERMES
ISB / USIC / OSIC
produziert
TÜV Süd
(SAQ)
beauftragt
eCH
Zusammenarbeit
Personen
zertifiziert
Anwender
sind
Mitglied
sindrepresentiertdurch
standardisiert
Markt
Added Value
„Praxis-Sicht“
sind Mitglied
6. S. 6
Traditionelles PM
vs. Agiles PM
TPM: was
Manuals
APM: wie
Best Practices
Best Practices
Orientierung am Geschäftswert
Adaption an Veränderung
Rollierende Planung
Timebox
Feature Breakdown
Selbstorganisation
Trandsparenz und Rückkopplung
Leitfaden
12. S. 12
Variante: Neue Technologie / Architektur
Klare Vision,
Einigkeit über Ziele, Anforderungen sind bekannt
Infrastruktur: unbekannt / ist neu
Risiken: Technologie, Skalierbarkeit
2. Freigabe: in Sprints Erfahrung sammeln (PoC) mit
Nichtfunktionalen Anforderungen
Systemarchitektur
Leitfaden
2. Freigabe: PoC, Architektur
13. S. 13
Streams
1 Product Backlog
n parallele Sprints mit S-BL
Start Konzept mit einem initialen Stream
BL - Zerlegung nach technologischer /
fachlicher Diversifizierung
Leitfaden
14. S. 14
Variante: N Entwickler-Teams
Mehrere Anwendergruppen, typisch f. grosse Projekte
Verschiedene / Unklare Vision / Zielvorstellungen = Risiken
2. Freigabe: Erstellung gemeinsamer Infrastruktur und Vision
Analog: Variante N Entwickler Teams und Zerlegung in Streams
2. Freigabe: gemeinsame Anforderungen, Parallelität
15. S. 15
Releases
Sprints ≠ Releases → Wird jedes Sprintergebnis ausgerollt?
Durchläuft das Sprint-Ergebnis eine Staging-Umgebung (nicht-Agil)
Für wen wird ausgerollt? PO, Stakeholder, Schulung oder Produktiv
Releases: Produktiv setzen, für PO, Stakeholder, Schulung: Testumgebung
16. S. 16
Ergebnisse und Rollen am Beispiel der Variante “Simpel”
je Scenario / Variante
aus Hermes 5 entnommen
Ergebnisse
Rollen
Nicht-Agile Ergebnisse sind
grün hinterlegt
Legende
V – Verantwortlich
PL – Projektleiter
ISDSV -
Arch – Architekt
PO – Product Owner
SM – Scrum Master
ET - Entwicklungsteam
17. S. 17
Konflikt: Agilität durch Flexibilisierung des Inhalts nach Business Value
bei Festpreisprojekten
Prinzip: Business Value statt
Funktionalität
Business Value statt Zeit, Kosten, Inhalt →
warum:
Anforderungen, Integration,
Interaktionsfähigkeit ist erst durch Nutzung
vollständig bekannt und verstanden
Unsicherheiten sind immer enthalten und
zwangsläufig
Konsequenz
Magisches Sechseck erfahren einschätzen
Ausschreibung für Business Value
(Backlog: Vision, Epics, Stories) gestalten
kein Time & Material
indikativer Festpreisrahmen (Optinenmodell)
Rahmenwerk: Inkrementell / Iterativ Teile des
Werks vergeben (Optionen)
Organisation auf Agitität ausrichten
Magisches Sechseck: Anpassung von Anforderungen und Lösungen →
inkrementelle Lieferung von Ergebnissen in Iterationen // Ergebnis:
Höhere Zufriedenheit → aktuellere Lösungen (beste Software fürs Budget)
Besseren Geschäftswert → intensive Interaktion mit dem Geschäft
Bessere Qualität → frühere Qualitätssicherung mit dem Nutzer
Vermeidung (Reduktion Umfang) unnötiger / aufwendiger Implementierungen
→ stetige Priorisierung des Nutzers
18. S. 18
Magisches Sechseck
Kombination von
Management Dreieck (Traditionell,
Planungsgetrieben)
4 HERMES Dimensionen
Agilem Dreieck(Werte- /
Geschäftsgetrieben auds Prozess)
durch Erweiterung von 2, 3
weiteren Dimensionen
Business Value
Zufriedenheit
Qualität (hat Agilität intrinsisch
zusammen mit Risiko)
Erfassen, Messen, Zeigen !
intrinsic:
Q/R
19. S. 19
Worst case: WTO - Ausschreibung
Worst case: Projektnatur: WTO-Ausschreibung
Evaluation erforderlich: Risiken - unzureichende Funktionale Anforderungen
Evaluation erforderlich: Nichtfunktionale Anforderungen unzureichend sicher
Erfordernis: Ausschreibung flexibel halten, auf „Business Value“ orientieren
Inkrementell Iterativ freigeben: Evaluation, dann Umsetzung
Ausschreibung sucht einen Lösungspartner
Ausschreibung enthält Business Value und dessen inkrementelle / iterative
Verfeinerungswünsche
Neuen Change Freigeben
20. S. 20
Beispiel einer alternativen Story- / Sprint-
Planungsmethodik MoSCoW
Agile Sprint Planungs Methodik, kommt aus
den agiles Ansätzen des DSDM Konsortiums
(Brit.); unterstützt KANO-Modell. Prio./Sprint
Planung aus DSDM Ansatz entnehmen:
Must Storys (essentiell)
Should Storys (erfreulich)
Could Storys (nebensächlich)
Won‘t Storys (später oder gar nicht)
Bereits in den Phasen vor der Phase
KRE an
Prinzip der Abarbeitung des Backlog
Sprint- und Taskplanung
Priorisierung
Team-Performance
je Sprint denken
Effizienz und Effektivität
der agilen Methodik
einbringen.
Scrum, aber nicht nur
Scrum
Emotionale Intelligenz
hinzunehmen
Sevant Leadership
Must or
Should, Could
or Won‘t
23. S. 23
Verschiedene Anwendergruppen
Anforderungen verschiedener (neuer) Anwendergruppen sind nicht harmoniesiert
Konsolidierte Sicht muss erarbeitet werden
Architektur und Technologie sind jedoch bekannt und gesetzt
Inkrementell Iterativ in wenigen kurzen Sprints diese Ziele erarbeiten bis ein Initiales
Backlog existiert (nicht Velocity relevant)
PO gibt den Start für Initiales Backlog als gültig an.
Reguläres Projektvorgehen beginnt
(Beginn der Messung von Velocity und anderen Kennzahlen)