Vortragsfolien zu meinem Talk von der OOP2016

1. Agile Zukunft,
zukünftige Agilität
Henning Wolf

2. Wer bin ich? Was
motiviert mich?
• Erster Computer 1983
• Programmierer
• Dipl. inform., Software
Engineering, SW-Architekt
• Begeisterung für das Schaffen
von Systemen (Software)
• heute: Begeisterung für das
Schaffen von Systemen, die
Systeme erschaffen
(Organisationen)

3. Meine agile Erfahrung

4. Ist es agil, in die
Zukunft zu schauen?
• Dogma-Frage?
• menschlich verständlich
• Umgang mit Unsicherheit
• Agiles Zukunftsverständnis:
Fortschreibung der
Vergangenheit plus
Unvorhergesehenes

5. Meine agile Reise
• ab 1998: Pair-Programming und
eXtreme Programming (XP)
• 1999: erstes professionelles
Projekt mit XP
• 2001: Agiles Manifest
• seit 2004: Scrum
• 2005: Gründung it-agile
• 2006: Certified ScrumMaster
• 2009: Kanban
• 2011: Certified Scrum Trainer
• 2015: 10 Jahre it-agile
Henning Wolf
is awarded the designation Certified Scrum Trainer® on
this day, October 20, 2011, for completing the prescribed
requirements for this certification and is hereby entitled
to all privileges and benefits offered by
SCRUM ALLIANCE®.
Certificant ID: 000013290 Certification Expires: 01 January 2017
Chairman of the Board
Henning Wolf
is awarded the designation Certified ScrumMaster® on
this day, March 21, 2006, for completing the prescribed
requirements for this certification and is hereby entitled
to all privileges and benefits offered by
SCRUM ALLIANCE®.
Certificant ID: 000013290 Certification Expires: 01 January 2017
Joseph Pelrine
Certified Scrum Trainer® Chairman of the Board

6. Meine bisherige Agile-Methoden-Reise
eXtreme Programming Scrum Kanban

7. ship happens
Worauf kommt es (mir) bei Agilität an?
LIEFERN
inspect
& adapt
Mindset

8. Agiles Manifest
(2001)
• Liefern
• Inspect & Adapt
• Mindset

9. Prinzipien des Agilen Manifests
1
Our highest priority is to
satisfy the customer
through early and
continuous delivery
of valuable software. 2
Welcome changing
requirements, even late
in
development. Agile
processes harness
change for
the customer's
competitive advantage.
3
Deliver working software
frequently, from a
couple of weeks to a
couple of months, with a
preference to the shorter
timescale. 4
Business people and
developers must work
together daily throughout
the project.
5
Build projects around
motivated individuals.
Give them the
environment and support
they need,
and trust them to get the
job done.
6
The most efficient and
effective method of
conveying information to
and within a
development
team is face-to-face
conversation.
7Working software is the
primary measure of
progress.
8
Agile processes promote
sustainable
development.
The sponsors,
developers, and users
should be able
to maintain a constant
pace indefinitely.
9
Continuous attention to
technical excellence
and good design
enhances agility.
10
Simplicity - the art of
maximizing the amount
of work not done--is
essential.
11
The best architectures,
requirements, and
designs
emerge from self-
organizing teams. 12
At regular intervals, the
team reflects on how
to become more
effective, then tunes and
adjusts
its behavior accordingly.
LIEFERN
LIEFERN
LIEFERN
inspect
& adapt inspect
& adapt
inspect
& adapt
Mindset
Mindset
Mindset
Mindset
Mindset
Mindset

10. Mindset 1/2

11. Mindset 2/2
Einfachheit

12. Warum brauchen wir
agil?
Darstellung von Niels Pfläging

13. Wie erwachsen sind agile Methoden?26
Abb.9 Agile Methoden haben die »Kluft« überwunden.
Ihre Nutzung stellt längst kein großes Risiko mehr dar, sie haben bereits
vielfach bewiesen, dass sie auch in großen industriellen Projekten zum
Wo steht agil? Einordnung auf dem Technology Adoption Cycle von
Geoffrey A. Moore
aber auch: „Scrum but“
und „Durchwursteln 2.0“
heute

14. Ist „Agile“ ein Hype? 2005 vs. 2016
2005:
Wieso „agile?“
2016:
Wieso nur „IT?“

15. Was alles schon
erreicht wurde
• mehr Testautomatisierung
• gemeinsamer Code
• continuous integration
• kleinere (Teil-)Projekte
• kürzere Releasezyklen
• mehr Denken in Features
• mehr Denken in Produkten
statt Projekten

16. ab hier wird es spekulativ

17. Erste Selbstorganisationsdurchführungsverordnung (SODVo)
Präambel
Aus gegebenen Anlass muss darauf hingewiesen werden, dass Selbstorganisation kein Freibrief für Kompe-
tenzüberschreitungen jeglicher Art einzelner Teammitglieder darstellt. Um entsprechende Fehlinterpretationen
abzustellen, ergeht diese Verordnung.
Diese Verordnung ersetzt mit sofortiger Gültigkeit die willkürliche Auslegung des Begriffs Selbstorganisation.
§1 Den Anordnungen des ScrumMasters ist unbedingt Folge zu leisten.
§2 Auch in agilen Teams muss Effizienz das höchste Ziel sein.
1) Ineffizienz durch Paar-Programmierung oder unautorisiertes Refaktorisieren ist unbedingt zu vermeiden.
2) Spezialisten sind ausschließlich innerhalb ihres Spezialgebietes einzusetzen, optimal auszulasten und
stets zu Beginn eines Sprints zu beplanen.
3) Sämtliche Teammitglieder sind dazu verpflichtet, sich dauerhaft in der Performing-Phase nach dem
Tuckman-Modell zu befinden. Insbesondere die Storming-Phase hat zu unterbleiben.
§3 Programmierfehler sind zu unterlassen. Bei Zuwiderhandlung müssen die Fehler in unbezahlter Freizeit
behoben werden.
§4 Die Trennung zwischen Produktion und Qualitätssicherung ist aufrecht zu erhalten.
§5 Die Definition of Done ist ausschließlich vom leitenden Qualitätsmanager vorzugeben. Dieser kontrolliert
auch ihre Einhaltung.
§6 Verbesserungsvorschläge von gewöhnlichen Teammitgliedern müssen in dreifacher Ausführung beim
Qualitätsmanager eingereicht und auf dem roten Formblatt vom Projektleiter genehmigt werden. Retro-
spektiven dienen dem Zweck, die genehmigten Verbesserungsvorschläge zu verkünden und somit in Kraft
zu setzen.
§7 Teamverträge müssen in Anwesenheit eines Notars erstellt und von diesem verlesen werden.
§8 Die unautorisierte Anbringung von Postern, Zeichnungen und sonstigen Notizen an den Wänden hat aus
datenschutzrechtlichen und feuerpolizeilichen Gründen zu unterbleiben.
§9 1) Das tägliche Status-Treffen dient ausschließlich dem Zweck, dem Produktverantwortlichen über den
Projektfortschritt zu berichten.
2) Mitarbeitern, die ein Dienstalter von 10 Jahren erreicht haben, das 49. Lebensjahr überschritten haben
oder ein entsprechendes ärztliches Attest besitzen, ist ein Sitzplatz zu gewähren. Die Nachweispflicht
obliegt den Bittstellern, Nachweise sind auf Verlangen vorzuzeigen.
§10 Das Committment ist zwingend einzuhalten.
a) Bei nicht erledigten Storys ist das Commitment des nachfolgenden Sprints entsprechend höher
anzusetzen, um die Gesamtplanerfüllung sicherzustellen.
b) Bei sinkender Velocity ist die Selbstorganisation mit sofortiger Wirkung einzustellen. Retrospektiven
sind so lange auszusetzen bis die Soll-Velocity wieder hergestellt ist.
Dieses Anschreiben wurde maschinell erstellt und ist ohne Stempel und Unterschrift gültig.
it-agile GmbH
Große Elbstraße 273
D-22767 Hamburg
Tel.: +49 40 41 358 48-0
Fax: +49 40 41 358 48-29
Hamburg d. 1. April 2014
Zukunftsszenario 1
• die „Big Player“ übernehmen
• agil wird Mechanik und kann
durchexerziert werden
• ohne Tooling geht es nicht
• 14 Zertifizierungsstufen
• fake-change

18. Zukunftsszenario 2
• die „Dogmatiker“ gewinnen
• „so ist es nicht agil“ wird zum
Totschlagargument
• Hauptsache den Teams geht
es gut

19. Zukunftsszenario 3
• in den Unternehmen wächst
das Verständnis, warum man
ernsthaft agil sein muss
• es etabliert sich eine echte
Verbesserungskultur
• auch in größeren Unternehmen
ändert sich das Mindset, ein
Miteinander von Business und
IT, von Management und
Teams schafft mehr Effektivität

20. Erste Selbstorganisationsdurchführungsverordnung (SODVo)
Präambel
Aus gegebenen Anlass muss darauf hingewiesen werden, dass Selbstorganisation kein Freibrief für Kompe-
tenzüberschreitungen jeglicher Art einzelner Teammitglieder darstellt. Um entsprechende Fehlinterpretationen
abzustellen, ergeht diese Verordnung.
Diese Verordnung ersetzt mit sofortiger Gültigkeit die willkürliche Auslegung des Begriffs Selbstorganisation.
§1 Den Anordnungen des ScrumMasters ist unbedingt Folge zu leisten.
§2 Auch in agilen Teams muss Effizienz das höchste Ziel sein.
1) Ineffizienz durch Paar-Programmierung oder unautorisiertes Refaktorisieren ist unbedingt zu vermeiden.
2) Spezialisten sind ausschließlich innerhalb ihres Spezialgebietes einzusetzen, optimal auszulasten und
stets zu Beginn eines Sprints zu beplanen.
3) Sämtliche Teammitglieder sind dazu verpflichtet, sich dauerhaft in der Performing-Phase nach dem
Tuckman-Modell zu befinden. Insbesondere die Storming-Phase hat zu unterbleiben.
§3 Programmierfehler sind zu unterlassen. Bei Zuwiderhandlung müssen die Fehler in unbezahlter Freizeit
behoben werden.
§4 Die Trennung zwischen Produktion und Qualitätssicherung ist aufrecht zu erhalten.
§5 Die Definition of Done ist ausschließlich vom leitenden Qualitätsmanager vorzugeben. Dieser kontrolliert
auch ihre Einhaltung.
§6 Verbesserungsvorschläge von gewöhnlichen Teammitgliedern müssen in dreifacher Ausführung beim
Qualitätsmanager eingereicht und auf dem roten Formblatt vom Projektleiter genehmigt werden. Retro-
spektiven dienen dem Zweck, die genehmigten Verbesserungsvorschläge zu verkünden und somit in Kraft
zu setzen.
§7 Teamverträge müssen in Anwesenheit eines Notars erstellt und von diesem verlesen werden.
§8 Die unautorisierte Anbringung von Postern, Zeichnungen und sonstigen Notizen an den Wänden hat aus
datenschutzrechtlichen und feuerpolizeilichen Gründen zu unterbleiben.
§9 1) Das tägliche Status-Treffen dient ausschließlich dem Zweck, dem Produktverantwortlichen über den
Projektfortschritt zu berichten.
2) Mitarbeitern, die ein Dienstalter von 10 Jahren erreicht haben, das 49. Lebensjahr überschritten haben
oder ein entsprechendes ärztliches Attest besitzen, ist ein Sitzplatz zu gewähren. Die Nachweispflicht
obliegt den Bittstellern, Nachweise sind auf Verlangen vorzuzeigen.
§10 Das Committment ist zwingend einzuhalten.
a) Bei nicht erledigten Storys ist das Commitment des nachfolgenden Sprints entsprechend höher
anzusetzen, um die Gesamtplanerfüllung sicherzustellen.
b) Bei sinkender Velocity ist die Selbstorganisation mit sofortiger Wirkung einzustellen. Retrospektiven
sind so lange auszusetzen bis die Soll-Velocity wieder hergestellt ist.
Dieses Anschreiben wurde maschinell erstellt und ist ohne Stempel und Unterschrift gültig.
it-agile GmbH
Große Elbstraße 273
D-22767 Hamburg
Tel.: +49 40 41 358 48-0
Fax: +49 40 41 358 48-29
Hamburg d. 1. April 2014
Vermutlich: Alles davon zum Teil

21. Was spielt Agilität
in die Karten?
• Digitalisierung
• Taylorwanne
• Automatisierung
• Schnelligkeit
• erwartete Flexibilität
• Generation Y (Purpose!)
😀
Was steht Agilität
im Weg?
• große Organisationen
• Kulturwandel ist langsam
• die Illusion von Sicherheit
(Plänen) ist so attraktiv
• Leadership fehlt
• Management fremdelt, fühlt
sich nicht willkommen
😞

22. 6 Tipps für die
weitere (agile) Reise

23. Welches Problem bleibt?
Demand
Capability

24. Die einfach schwere Lösung
persönlicher Fokus
Fokus für agile Reise
Fokus der Stakeholder:
Was ist am wichtigsten?

25. Immer liefern schafft Vertrauen

26. Sei pragmatisch
• aber nicht beliebig!

27. Als Leader (nicht nur
Chef/Manager)
• Mach deine Erwartungen sehr
klar
• Zusammenschweißen statt
Zusammenscheißen
• Zusammen etwas Reißen statt
Zusammenreißen

28. Arbeite mit
Experimenten
• das ist inspect&adapt in Aktion
• so findet man leichter
Mitstreiter
• Experimente schaffen Daten
(empirisches Management)

29. Stell dich auf eine lange Reise ein
Organisation

30. Ausblick: OOP 2031
• 30 Jahre Agiles Manifest
• Ich bin der Typ, der es euch
2016 schon gesagt hat, wie es
mit Agilität weitergeht
• Alle liefern!
• Alle machen konsequent
inspect&adapt!
• Das Mindset / die Kultur
haben sich gewandelt!
40
31

31. Danke für die Aufmerksamkeit
Fragen? henning.wolf@it-agile.de, @henningwolf

32. Traumszenario
Was ist
agil?
Was ist es
nicht?