S. 1

HERMES AgilWege agiler Projektführung

S. 2

HERMES 5 heute

Traditionelles PM mit „Agiler Ergänzung“

Entscheidung Variante

Entscheidung Agil

S. 3

Leitfaden Agiles HERMES 5

Mitarbeit:

Andreas Hamberger (MitgliedThemengruppe)

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 / LeiterThemengruppe)

Peter Lang (Autor / Lektor)

S. 4

Einbettung der User Group eco-HERMES

eco-HERMES

ISB / USIC / OSICproduziert

TÜV Süd(SAQ)

beau

ftra

gt

eCH

Zusammenarbeit

Personen

zertifiziert

AnwendersindMitglied

sind re

presen

tiert du

rch

standardisiert

Markt

Added Value

„Praxis-Sicht“

sind Mitglied

S. 5

Grundlage für Leitfaden Agiles HERMES 5

+SAFe®

Leitfaden

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

S. 7

Agilität Blueprint

PMI-ACP®

Tools and techniques

Value driven, Storys …

Estimation, Planning ...

Knowledge and Skills

Performance, Enabler, ...

Self (Orga., Motivation) ...

Verschiedene methodische Ansätze:

• Scrum

• DSDM

• Crystal

• XP

• Lean

• Agile Modeling

• Scrum & Kanban = Scrumban

• SAFe ...

S. 8

Ansatz der TG Agiles HERMES

Entscheidung Agil, mglw. nach Variante Neue Technologie / Architektur

Leitfaden

S. 9

Variante: Projekt Simpel

Alle durch die Storys im BL betroffenen Dokumentations-Aspekte in KRE realisieren Backlogs pflegen: anpassen, priorisieren, ... Sprint – Organisation: Statistik: Burndown, Velocity, …; Demo, Review; Retrospective Impediment Backlog Konkretes Ergebnis (Shippable) zum Sprintende Betriebshandbuch Migrationsverfahren

Letzter Sprint: alle offenen Aspekte realisierter Storys finalisieren Projektschlussbeurteilung

Leitfaden

S. 10

Leitfaden

Demo

Demo, Plan. 1

wie

Was geschieht zusätzlich in jedem Sprint

S. 11

Leitfaden

Sprint Planung 1 und 2

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

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

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

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

S. 16

Ergebnisse und Rollen am Beispiel der Variante “Simpel”

je Scenario / Variante aus Hermes 5 entnommen Ergebnisse Rollen

Nicht-Agile Ergebnisse sindgrün hinterlegt

Legende V – Verantwortlich

PL – Projektleiter ISDSV - Arch – Architekt PO – Product Owner SM – Scrum Master ET - Entwicklungsteam

S. 17

Konflikt: Agilität durch Flexibilisierung des Inhalts nach Business Valuebei Festpreisprojekten

Prinzip: Business Value stattFunktionalität

Business Value statt Zeit, Kosten, Inhalt →warum: Anforderungen, Integration,

Interaktionsfähigkeit ist erst durch Nutzungvollständig bekannt und verstanden

Unsicherheiten sind immer enthalten undzwangslä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

S. 18

Magisches Sechseck

Kombination von Management Dreieck (Traditionell,

Planungsgetrieben) 4 HERMES Dimensionen Agilem Dreieck(Werte- /

Geschäftsgetrieben auds Prozess)

durch Erweiterung von 2, 3weiteren Dimensionen Business Value Zufriedenheit Qualität (hat Agilität intrinsisch

zusammen mit Risiko)

Erfassen, Messen, Zeigen !

intrinsic:

Q/R

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

S. 20

Beispiel einer alternativen Story- / Sprint-Planungsmethodik MoSCoW

Agile Sprint Planungs Methodik, kommt ausden agiles Ansätzen des DSDM Konsortiums(Brit.); unterstützt KANO-Modell. Prio./SprintPlanung 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 PhaseKRE an Prinzip der Abarbeitung des Backlog Sprint- und Taskplanung Priorisierung Team-Performance

je Sprint denken

Effizienz und Effektivitätder agilen Methodikeinbringen. Scrum, aber nicht nur

Scrum Emotionale Intelligenz

hinzunehmen Sevant Leadership

Must or

Should, Could

or Won‘t

S. 21

Fragen Links

Links

User Group eco-HERMEShttp://www.eco-hermes.ch

Agiles Manifesthttp://www.agilemanifesto.org

Scrumhttp://scrum.orghttp://www.scrumguides.org/doc

s/scrumguide/v1/scrum-guide-us.pdf

Agilität, PMI-ACP®

http://www.pmi.org/certification/agile-management-acp.aspx

Unsere eMail: ritz@ritzeng.com

S. 22

Backup

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)

S. 24

Entscheid Agile Entwicklung mit Scrum

S. 25

Product Backlog, Increment

S. 26

Sprint durchführen

S. 27

Product backlog führen

S. 28

Ergebnisse (Auschnitt Agil)

S. 29

Projekt führen

S. 30

Projekt steuern