Agile Zukunft, zukünftige Agilität Henning Wolf

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)

Meine agile Erfahrung

Ist es agil, in die Zukunft zu schauen?

• Dogma-Frage?• menschlich verständlich• Umgang mit Unsicherheit• Agiles Zukunftsverständnis:

Fortschreibung der Vergangenheit plus Unvorhergesehenes

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 Wolfis awarded the designation Certified Scrum Trainer® onthis day, October 20, 2011, for completing the prescribedrequirements for this certification and is hereby entitled

to all privileges and benefits offered bySCRUM ALLIANCE®.

Certificant ID: 000013290 Certification Expires: 01 January 2017

Chairman of the Board

Henning Wolfis awarded the designation Certified ScrumMaster® onthis day, March 21, 2006, for completing the prescribedrequirements for this certification and is hereby entitled

to all privileges and benefits offered bySCRUM ALLIANCE®.

Certificant ID: 000013290 Certification Expires: 01 January 2017

Joseph PelrineCertified Scrum Trainer® Chairman of the Board

Meine bisherige Agile-Methoden-Reise

eXtreme Programming Scrum Kanban

ship happens

Worauf kommt es (mir) bei Agilität an?

LIEFERNinspect & adapt

Mindset

Agiles Manifest (2001)

• Liefern

• Inspect & Adapt

• Mindset

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.

7 Working 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.

LIEFERNLIEFERN

LIEFERN

inspect

& adapt inspect

& adapt

inspect

& adapt

MindsetMindset

Mindset

MindsetMindset

Mindset

Mindset 1/2

Mindset 2/2

Einfachheit

Warum brauchen wir agil? Darstellung von Niels Pfläging

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 Erfolg führen. Dazu einige Beispiele:

QQ Die Standish Group empfiehlt in ihrem Chaos Report von 2005 explizit agile Methoden, um Softwareprojekte erfolgreich(er) durchzuführen.

QQ Im eBusiness-Bereich gibt es kaum noch ein Unternehmen, das nicht agil vorgeht.

QQ Die ganz Großen der Branche nutzen die Vorteile agiler Methoden für sich: Google, SAP und Microsoft gehen agil vor.

QQ Es gibt kaum noch ein softwareentwickelndes Großunternehmen, das nicht mindestens in Teilbereichen agile Verfahren einsetzt.

QQ Agile Verfahren werden auch in sicherheitskritischen Bereichen wie der Medizintechnik verwendet.

QQ Immer häufiger wird auch Hardware mit agilen Verfahren entwi-ckelt. Besonders auffällig ist die Entwicklung eines spritsparenden Pkw durch die Wikispeed-Gruppe.

QQ Seit 2001 haben weltweit mehr als 300.000 Menschen an Kursen zum Certified Scrum Master teilgenommen.

QQ Es haben sich eigene große nationale und internationale Kon-ferenzen etabliert, die sich nur um agile Entwicklung kümmern (z.B. Agile Conference, Scrum Gathering, Lean Kanban Confe-rence, XP Days, XP Conference).

QQ Alle großen IT-Konferenzen haben sich inzwischen des Themas angenommen – die meisten bieten sogar eigene Tracks zu agilen Methoden.

Wo steht agil? Einordnung auf dem Technology Adoption Cycle von Geoffrey A. Moore

aber auch: „Scrum but“ und „Durchwursteln 2.0“heute

Ist „Agile“ ein Hype? 2005 vs. 2016

2005: Wieso „agile?“

2016: Wieso nur „IT?“

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

ab hier wird es spekulativ

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 2014Zukunftsszenario 1

• die „Big Player“ übernehmen

• agil wird Mechanik und kann durchexerziert werden

• ohne Tooling geht es nicht

• 14 Zertifizierungsstufen

• fake-change

Zukunftsszenario 2

• die „Dogmatiker“ gewinnen

• „so ist es nicht agil“ wird zum Totschlagargument

• Hauptsache den Teams geht es gut

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

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

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

😞

6 Tipps für die weitere (agile) Reise

Welches Problem bleibt?

Demand

Capability

Die einfach schwere Lösung

persönlicher Fokus

Fokus für agile Reise

Fokus der Stakeholder: Was ist am wichtigsten?

Immer liefern schafft Vertrauen

Sei pragmatisch

• aber nicht beliebig!

Als Leader (nicht nur Chef/Manager)

• Mach deine Erwartungen sehr klar

• Zusammenschweißen statt Zusammenscheißen

• Zusammen etwas Reißen statt Zusammenreißen

Arbeite mit Experimenten

• das ist inspect&adapt in Aktion

• so findet man leichter Mitstreiter

• Experimente schaffen Daten(empirisches Management)

Stell dich auf eine lange Reise ein

Organisation

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

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

Traumszenario

Was ist agil?

Was ist es nicht?