Agile Zukunft, zukünftige Agilität
- 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)
- 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
- 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
- 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?