PM Forum 2017, Nürnberg: Vortrag von Michael Rohleder (@Rohleder10, Bereichsleiter bei QAware) Abstract: Agiles Vorgehen funktioniert weitgehend reibungslos für kleine IT-Projekte. Eine Herausforderung stellen agile Großprojekte dar, vor allem dann, wenn der Auftragnehmer ein agiles Festpreisgewerk verantwortet. Der Vortrag beschreibt sieben Erfolgsfaktoren für solche Projekte: 1. Mehrere Ebenen der Planung und Steuerung 2. Sicherstellung der Baubarkeit von User Stories 3. Eliminierung von Zeitfresser und Produktivitätskiller 4. Softwarequalität als Gegenpol zu Feature-Gier 5. Rekordgeschwindigkeit durch den Software-OEM-Ansatz 6. Absicherung der Qualität durch Testautomatisierung 7. One Team Approach

1. Michael Rohleder
michael.rohleder@qaware.de
@Rohleder10
Agil zum Ziel: Erfolgsfaktoren
für agile IT-Großprojekte
Nürnberg, 25. Oktober 2017

2. Unsere Erfahrungen stammen aus langlaufenden agilen
IT-Großprojekten bei unseren Kunden.
QAware 2
Teamgröße > 25 in Spitze
(Entwicklung + Konzeption)
Gesamt-Programm
> 150 Mitarbeiter
Umfeld / Schnittstellenpartner
noch nicht auf agil umgestellt
Agiles Festpreisgewerk
(pro Jahr / pro Quartal)
Entwicklung über
mehrere Jahre

3. Ein Fallstrick in agilen Projekten: Fehlende Sichtweite
bei der Planung.
QAware 3
Sprint 1 Sprint 2 Sprint 3 Sprint …
…? …? …?
User Stories pro Sprint:

4. Planungsebenen oberhalb des Sprints sind essenziell für
den langfristigen Projekterfolg in Großprojekten.
QAware 4
Sprint Sprint SprintSprint Sprint
Release Release Release
Jahresumfang Jahresumfang
ProjektProduktvision
Jahres-Roadmap
Sprint-Plan
(Teamplan, Aufgaben)
Release-Plan
Jahre
12 Monate
3-4 Monate
2-5 Wochen
Konkretisierung
Sichtweite
Sprint

5. Der Weg vom fachlichen Problem zur technischen
Lösung ist für komplexe Systeme lang und steinig.
QAware 6
„Als Servicemitarbeiter möchte ich
die Servicehistorie für ein Fahrzeug
einsehen können um einen besseren
Kundenservice bei der
Kundenberatung bieten zu können“
Akzeptanzkriterien:
• …
User Story
Lösung /
Umsetzung?

6. Frontrunner-Teams machen auf zwei zeitlichen Ebenen
den Weg für das Entwickler-Team frei.
QAware 7
Exploration
Konzeption
Realisierung
Sprint 2 Sprint 3 …
Release
Definition of
Ready?
Klärung Fachlichkeit.
Erstellung grobes Lösungskonzept.
Prüfung technische Machbarkeit
über Proof of Concepts.
Abstimmung mit
Schnittstellenpartnern.
Release - 1
Konzeption
Realisierung
Sprint 1
Mini-
Spec

7. QAware 8

8. Erarbeiten von Lösungen in Kleingruppen
Daily timeboxed im gesamten Team Flexible Sprintdauer im Release
Zeitfresser und Produktivitätskiller im agilen Vorgehen
eliminieren.
QAware 9
S2 S6S4S3 S5 S7S12 wöchig
2-5 wöchig
vs.
Nur relevante Vertreter des Projekts für
Backlog-Grooming
Sprint-Planning
Sprint Review
Definition of Done
Release Retrospektive
S2 S4S3S1

9. Entwicklungskosten
+ Qualitätsschulden
= Arbeitszeit
x Arbeitszeit-Kosten

10. Gegenpol zur Feature-Gier des Product-Owners
aufbauen um Qualitätsschulden zu vermeiden.
QAware 11
Systeme benötigen Phasen, in denen vermindert neue Features entwickelt und das System gehärtet wird.
Lösungen:
Qualitäts-Backlog mit ca. 20% der Sprint-Kapazität.
Härtungs-Sprints.
Bug Hunting Days / Quality Days.
Vertraglich vereinbarter Qualitätskontrakt auf Basis
messbarer KPIs.
Umfassende Definition of Done, zu der auch der
Qualitätskontrakt gehört.
Foto: QAware Quality Day

11. Omnipräsenz von Kennzahlen zur Produktqualität trägt
maßgeblich zur Softwarequalität und Produktivität bei.
QAware 12

12. Wie groß ist die Fertigungstiefe
in Ihrem Projekt?
Fertigungstiefe := Anteil selbst geschriebener Code zu Code aus
verwendeten Open Source Komponenten

13. Maximale Geschwindigkeit in der Entwicklung durch den
Software-OEM Ansatz.
QAware 14
Software-OEM bedeutet: Software mit geringer Fertigungstiefe auf Basis von Open-Source-Komponenten
entwickeln.
Der Umgang mit Open Source muss professionell erfolgen, folgende Fragen muss man sich stellen:
… bei der Integration und Pflege:… bei der Recherche und Auswahl:
Enge Bindung oder lose Kopplung?
Ist der Nachweis der Compliance vollständig?
Sind die Lizenztexte lizenzgemäß hinterlegt?
Sollte auf eine aktuellere Version migriert werden?
…
Ist ein Open-Source-Baustein notwendig?
Ist eine Blueprint-Freigabe möglich?
Fordert die Lizenz Inakzeptables?
Gibt es bekannte Sicherheitsprobleme?
…

14. QAware 15
Erfolgsfaktor: Testautomatisierung

15. Große agile Projekte benötigen für eine hohe
Produktqualität automatisierte Tests auf allen Ebenen.
QAware 16
UI-
Tests
Typischerweise guteTestautomatisierung
auf den unteren Ebenen mit allenVorteilen.
PostulierteAusführungskosten
AnzahlTests
Akzeptanz-Tests
Exploratives manuelles Testen
Automatisches Testen
Testautomatisierung auf diesen Ebenen:
sehr gut geeignet für Regressionstests und
reduziert Aufwände für manuelles Testen.
entbindet nicht von der Pflicht für
manuelles explorativesTesten.
Integrations-Tests
Unit-Tests

16. QAware 17

17. Firmengrenzen sind in der Teamzusammenarbeit absolut
sekundär. Was zählt ist der gemeinsame Projekterfolg.
QAware 18
Retrospektive
„Inspect and adapt“
Konstruktive Lösungsfindung,
Mut zur offenen Reibung
Politics
Enge Zusammenarbeit,
Partnerschaft,
nah am Auftraggeber (Co-Location)
Erfolge gemeinsam feiern

18. Zusammenfassung
QAware 19
Mut zur Planung trotz Agilität, im Idealfall auf den Planungsebenen Sprint, Release, Roadmap und
Produktvision.
Frontrunning, MiniSpecs und Definition of Ready (DOR), um die Baubarkeit von User Stories im Sprint
sicherzustellen.
Effiziente Meeting-Strukturen und unterbrechungsarmes Arbeiten, um die Produktivität im Team
sicherzustellen.
Einen Gegenpol zur Feature-Gier etablieren, um Qualitätsschulden zu vermeiden.
Open Source Software professionell als Software-OEM einsetzen, um schnell in der Entwicklung zu sein.
Testautomatisierung zur Qualitätssicherung einsetzen, auch für Akzeptanztest, um Produktqualität
sicherzustellen.
Dem Projektteam das Mandat zu Lösung geben und Projekterfolge feiern.

19. Michael Rohleder
michael.rohleder@qaware.de
@Rohleder10 github.com/qaware
linkedin.com/qaware slideshare.net/qaware
twitter.com/qaware xing.com/qaware