1. Agile Softwareenwticklung mit SCRUM

2. AGENDA

3. 1 2 3

4. Über Rollen, Artefakte und Zeremonien – Eine Einführung in die Begriffswelt von SCRUM 1 2 3

5. SCRUM ist mehr als Projektmanagement und Softwareentwicklung - Agile Prinzipien, Werte und der Faktor Mensch. 1 2 3

6. SCRUM im Feldversuch – 3 Jahre SCRUMologie bei Regis24. 1 2 3

7. Einführung in die Begriffswelt von Agile und SCRUM 1

8. Das Ziel agiler Softwareentwicklung ist es, schneller und effektiver Software zu entwickeln als in den klassischen, schwergewichtigen Entwicklungsmodellen. = 1 2 3

9. Im schwergewichtigen Wasserfallmodell wird die Gesamtprojektzeit in feste Phasen eingeteilt. Projektfortschritt Zeit 1 Monat 3 Monat 12 Monate 16 Monate Initialplanung Anforderungs- analyse Systemdesign Implementierung Release Nutzung 1 2 3

10. Agile Prozesse nähern sich dem Projektziel in kurzen, absehbaren und planbaren Iterationen und schaffen dadurch kontinuierlich Nutzen. ITERATION 1-5 Wochen Initialplanung Anforderungs- analyse Systemdesign Implementierung Test Planung aktualisieren Release Nutzung 1 2 3

11. SCRUM gibt eine Antwort auf viele typische Probleme der Softwareentwicklung. Zu lange Releasephasen Zu wenig Stabilität Änderungen nur schwer umsetzbar Unzureichende Qualität Demoralisierung durch Projektstopp Kurze Releasephasen Stabilität durch TDD und Refactoring Änderungen dankbar annehmen Hohe Qualität der Software Spaß und Freude bei der Arbeit 1 2 3

13. Eine Person schreibt Code, die Andere prüft, modelliert, hinterfragt

14. Vorteile: bessere Qualität, weniger Ablenkung, Wissenstransfer, Spaß

16. 100% Abdeckung erforderlich

17. Tests als elementarer Bestandteil der Entwicklung

19. Alles wird in besserem Zustand verlassen als es vorgefunden wurde

20. Dringende Grundbedingung: 100% TDD, Collective Code Ownership

22. Unstimmigkeiten werden sofort beseitigt

23. Alle Ansätze werden untereinander gechallenged

25. Mit jeder Integration werden an einem Testserver sämtliche Unit-Tests sowie ein automatischer Build durchgeführt

26. Code Fragmente laufen so nicht auseinander, jederzeit Release möglich 1 2 3

27. SCRUM bringt ein sehr übersichtliches Set an Grundsätzen mit. Product Owner Scrum Master TEAM Sprint Planning Sprint Sprint Review Retrospektive Daily Scrum Product Backlog Sprint Backlog Sprint Burndown Chart Product Increment Impediment List Estimation Meeting Product Burndown Definition of Done Rollen Zeremonien Artefakte 1 2 3

29. bestimmt Auslieferungsdatum und Inhalt

30. ist verantwortlich für den Gewinn des Projekts (ROI)

31. priorisiert Features abhängig vom Marktwert

32. passt Features und Prioritäten nach Bedarf für jede Iteration an

34. Mitglieder sollten Vollzeitmitglieder sein

35. Interdisziplinär

36. Teams organisieren sich selbst

38. Entfernt Hindernisse

39. Stellt sicher, dass das Team vollständig funktional und produktiv ist

40. Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen

41. Schützt das Team vor äußeren Störungen

42. Vermittelt der Organisation die Welt der agilen Werte

43. SCRUM lebt vor allem durch die Interaktionen zwischen den einzelnen Akteuren. Das Team Nebenrollen Scrum Master Product Owner Anwender Vertrieb Kunde Marketing Geschäftsleitung Rechtsabteilung Gesetz Entwickler Tester DBA's / SysAdmins Designer Beschützt, befähigt und hilft unterstützt Klärt Anforderungs- details Erteilt Aufträge als User Stories Sammelt Anforderungen und Wünsche klärt Anforderungsdetails 1 2 3

44. Vor dem ersten Sprint – und immer dann, wenn neue Produkte entwickelt werden – sollte eine Vorplanungs- phase stattfinden (Vom Konzept zum Produktbacklog) Das Produkt ist immer mehr als die Software – und sollte aus diesem Grund auch eine andere Behandlung erfahren. Alles was sich nicht oder nur sehr schwer ändern lässt (z.B. Basisarchitektur), sollte ausserhalb von Scrum in einer Vorphase aufgesetzt werden. Agilität ist nicht der komplette Verzicht auf Vorabplanung. Vision Product Planning Product Envisioning Major Features Product Design Product Architecture Risks / Benifits Budgetierung 1 2 3

45. Iterationen bestehen aus den gleichen, immer wieder kehrenden Stufen, die den Rhythmus der Entwicklung vorgeben. Planning Estimation Sprint Retrospektive Review Daily Scrum 1 2 3

47. Team schätzt den Aufwand (die Größe) der User Stories in Story Points

48. Kann als Teil des Planning oder (besser) spontan zwischendrin abgehalten werden.

49. Methodik des „Planning Poker“ hat sich bewährt. 1 2 3

51. Product Owner stellt seinen „Selected Backlog“ bzw. eine priorisierte Short List vor und prüft gemeinsam mit Team und anwesenden Stakeholdern jede der User Story und deren Akzeotanzkriterien auf Vollständigkeit, Richtigkeit, Testbarkeit und Durchführbarkeit

52. Team diskutiert untereinander die erreichbare Punktzahl und gibt ein bindendes Commitment ab.

53. Commitete User Stories werden in Tasks heruntergebrochen (Entwicklung- und Testtasks)

54. Team hat das unabhängige letzte Wort in Sachen Schätzung und Commitment – es sind keine Manipulationen oder Vorgaben möglich

55. Ergebnis: Sprint Ziel und Sprint Backlog 1 2 3

57. Eine User Story ist dann abgeschlossen, wenn alle Tasks implementiert und funktional getestet sind sowie die Definition of Done erreicht wurde

58. Der Product Owner steht dem Team stets für Rückfragen und Entscheidungshilfen zur Verfügung 1 2 3

61. Was will ich heute erreichen?

63. Meeting wird direkt am Sprint Task Board durchgeführt. 1 2 3

65. KEINE technische Präsentation, sondern lediglich Abnahme der Akzeptanzkriterien

66. Optional können KPIs der vergangenen Iteration vorgestellt werden sowie die nächsten Termine durch den Scrum Master vorgestellt werden. 1 2 3

68. Dient dem Ziel der stetigen Verbesserung

69. Aufdecken und Verstehen von Problemen und Hindernissen, die sich negativ auf die Arbeit und die Gesundheit des Teams auswirken

70. Im Fokus steht der Prozess und die Zusammenarbeit – nicht einzelne Personen

71. Kann durch ein regelmäßiges Team Barometer unterstützt werden 1 2 3

72. Das Backlog ist die zentrale Instanz für das Management von Anforderungen. Product Backlog Sprint Backlog Sprint Tasks Das Backlog ist die neue unternehmensweite Wissensdatenbank als Antwort auf Komplexität und Themenfluktuation. 1 2 3

73. User Stories unterliegen einer Evolution und enthalten immer eine klaren Nutzen für eine konkret genannte Person. 1:n 1:n 1:n Epic Theme User Story Tasks Einführung eines geschützten Bereichs für User. Sicheres einloggen, ausloggen Als User möchte ich mir mein Passwort zuchicken lassen können, um auch noch Zugriff zum Userbereich zu haben, wenn ich mein Passwort vergessen habe. Link auf Website im Loginpanel einblenden, 1 2 3

75. Als Tourist möchte ich eine 5-wöchige Reise nach Kathmandu unternehmen.

76. Als Kunde benötige ich täglich statistische Informationen zu allen getätigten Transaktionen. Entwickeln Sie User Stories für folgendes EPICs: 1 2 3

77. Durch die Verwendung von Story Points lassen sich Diskussionen über vermeindlich absehbare Größen vermeiden. 1 2 3 5 8 10 13 21 Letztendlich sind Softwareprojekte wie Fahrten in unbekannte Gegenden: Man weiß welches Auto man hat, man kennt die Distanz in Kilometern – aber weiß nichts über die Straßenverhältnisse, ungeplantes wie Stau, Verkehrskontrollen, Pannen etc. Abstrakt Story Points beschreiben die „Größe“ einer Aufgabe – mit all ihrer Komlexität, Randparameter etc.. Relativ Punkte sind miteinander Vergleichbar und erzeugen keine unnötige Genauigkeit. Unabhängig Punkte sind unabhängig von Zeit und sind damit nicht als Druckmittel oder vertragliche Grundlage verwendbar. Lernbar Punkte verändern über die Zeit ihre Bedeutung: Teams lernen dazu, werden größer etc. 1 2 3

79. Story wird vom PO vorgestellt, erfahrene Entwickler gibt techn. Überblick

80. Fragen werden gestellt und Akzeptanzkriterien vervollständigt

81. Jeder legt eine Karte (verdeckt) mit seiner geschätzten Punktzahl

82. Sobald alle gelegt haben wird aufgedeckt

83. Bei größeren Differenzen scheint es Klärungsbedarf zu geben – die Diskussion findet sofort vom SM gesteuert statt.

84. Schätzung wird so lange wiederholt bis eine Übereinkunft der Team Mitglieder gibt.

85. Wichtig: Aktives zuhören, Respekt, Disziplin Ablauf Planning Poker 1 2 3

86. Übung: Schätzung in ... Fahrt von Hamburg nach Stuttgart Fahrt von Berlin nach Wolfsburg Fahrt von Berlin nach Osterode im Harz Fahrt von Bremen nach Amsterdam Fahrt von Luckenwalde nach Rügen … Dauer … Kosten … Kilometer 1 2 3

87. Übung: Schätzung in Punkten an Urstory ausgerichtet 1 2 3 5 8 10 13 21 Fahrt von Hamburg nach Stuttgart Fahrt von Berlin nach Wolfsburg Fahrt von Berlin nach Osterode im Harz Fahrt von Bremen nach Amsterdam Fahrt von Luckenwalde nach Rügen 1 2 3

88. Die mögliche Leistung des Teams ergibt sich aus der gelernten „Velocity“ … und dem Bauchgefühl! Bisher ... Mit Punkten ... Sprint 1 Sprint 2 Sprint 3 Sprint 4 30 Tage x 6 Personen = 180MT v=16P/S v=15P/S v=13P/S v=14P/S A – 40 MT B – 20 MT C – 70 MT D – 25 MT G – 10 MT F – 10 MT E – 10 MT C – 8P B – 3P A – 5P I – 1P H – 5P G – 8P M – 2P L – 8P K – 2P Q – 3P P – 5P O –5P J – 3P F – 1P E – 2P D – 1P N - 1P 1 2 3

89. Scrum lebt durch Transparenz – am Task-Board kann man jeden Tag der Wahrheit ins Gesicht sehen und danach handeln. ToDo's Checked Out Implemented Done! (DoD) User Story 1: Als Kunde möchte ich drucken, um auch Offline eine Übersicht zu haben User Story 2: Als User möchte ich mich ausloggen, um Zugriff durch dritte zu vemeriden. User Story 3: Als Arzt möchte ich einen mobilen Zugriff auf meine Not,izen, um auch bei Hausbesuchen effektiv zu sein. 1 2 3

90. „Fertig“ ist eine höchst subjektive Bewertung eines Zustands, der Objektivierung erfordert: Definition of Done Developer A Developer B Developer C Developer D Definition of Done 1 2 3

91. SCRUM erfordert Transparenz zu jeder Zeit. Der Burndown zeigt wo wir stehen. Aufwand Zeit 1 2 3

92. Seeing the BIG PICTURE: Der Burn-Up Chart Die Planung in Releases oder Milestones erfordert Weitblick. Sprints Points 1 2 3 4 5 6 7 8 9 10 Total Planned for Release 1 2 3

93. Agile Prinzipien und Werte. Der Faktor Mensch in Scrum 2

94. Das agile Manifest rückt den Menschen in den Mittelpunkt. Individuen und Interaktionen Funktionierende Programme Zusammenarbeit mit Kunden Mut und Offenheit für Änderungen Prozesse und Tools Ausführliche Dokumentation Verträge Befolgen eines festgelegten Plans … gelten mehr als ... 1 2 3

96. Das Team organisiert seine Arbeit selbst

97. Das Team liefert stets die nützlichsten Features

98. Das Team empfängt Feedback von aussen

99. Das Team reflektiert die eigene Arbeitsweise mit dem Ziel sich zu verbessern

100. Die gesamte Organisation hat ein Bild vom aktuellen Team Status und Projektfortschritt

101. Das Team und das Management kommunizieren offen und respektvoll über Fortschritte und Risiken 1 2 3

102. Der wichtigste Erfolgsfaktor für eine gelungene Adaption von SCRUM ist der Mensch und die Werte, die dieser lebt. Aktivität Initiative ergreifen, kein Minimalist sein, handeln statt abwarten, Verantwortung für die Projektziele übernehmen. Disziplin Ausgeprägte Selbstdisziplin, vereinbarte Grundregeln einhalten (z. B. Programmierrichtlinien, Tests und Code-Reviews durchführen, etc.). Gemeinnützigkeit Statt Egoismus zum Wohl des Teams beitragen, nicht nur den eigenen Code in Schuss halten, keine „Star-allüren“ an den Tag legen. Kommunikation Offen, klar und sachlich seine Meinung vertreten, Fehler konstruktiv ansprechen, Informationen breit streuen und Know-how austauschen. Dynamik Veränderungen und Verbesserungen mittragen und fördern. Bereit sein, den komfortablen Status quo aufzugeben, alte Gewohnheiten abzulegen und neue Wege auszuprobieren. Selbstkritik Eigene Fehler nicht unter den Tisch kehren und die Hilfe anderer Teammitglieder in Anspruch nehmen. Voraussetzung dafür ist eine vertrauens- und respektvolle Atmosphäre im Team. Courage Vertraue darauf, Probleme die morgen auftreten, auch morgen lösen zu können. Zwinge dich nicht, sie bereits heute lösen zu müssen. Offenheit Zeige dich immer offen für die Ideen und vorschläge anderer, für Anpassungen von Anforderungen, Meinungsänderungen des Kunden und neue Einblicke in komplexe Sachverhalte. Passion Bringe deine eigene Leidenschaft zum Ausdruck, stehe für deine Werte ein und lebe deine Passion für Technologie und Entwicklung mit deinen Teamkollegen. Pragmatismus KISS (Keep It Simple And Stupid) und YAGNI (You aren't gonna need it) sind zwei der wichtigsten Hedanken. Begrenzt euch auf das was wirklich gefordert ist – wofür wirklich gezahlt wird. Dienen Alles tun, um die anderen zu verstehen, und jedem anderen zu helfen: den Kollegen, dem Kunden und am Ende auch Dir selbst. Der Scrum Master ist kein Manager sondern im besten Falle ein Serving Leader... Passion Ohne Passion geht nichts. Vertraut euch mit neuen Technologien an, schaut euch an, wie andere Scrummer arbeiten. Versucht euch auzutauschen. Geld ist nicht de erste Priorität. 1 2 3

103. 3 Jahre SCRUM bei Regis24. 3

105. GF saß von Anfang an mit im Boot

106. Owner der Initiative war das Entwicklerteam

107. Anderen (befreundeten) Firmen und Interessierten von unseren Erfahrungen erzählen

109. Schätzung von Aufwand weiterhin in Manntagen

110. Umfang mehr oder weniger von GF / Vertrieb vorgegeben

111. Keine festen Sprintlängen (2-6 Wochen), lange „Pausen“ zwischen den Sprints

112. Keine Retrospectiven, technische Präsentationen in Reviews

113. Keine Time Boxes

114. Kein starker Scrum Master

115. Einführung neuer Rollen (TGP, TPO) und keine gute Ausführung der Rollen PO und SM

116. Kein selbstorganisiertes Team, kein TDD usw. 1 2 3 + -

117. Der große Re-Launch von Scrum 2010. … alles zurück auf LOS! Jetzt machen wir SCRUM, aber richtig! TOP Level Initiative Wiedereinführung von SCRUM als eine große strategische Initiative 2010 mit GF Support und großem Budget. 100%ige Einhaltung d. Theorie Rollen, Punkte, Commitments, Statische Time Boxes … Niemand kann das Vorgehen ändern. Die Theorie hat oberste Priorität. Coaching und Weiterbildung Kommunikationsseminare, Coaching der Scrum Master, Leadership und Problemlösungsseminare Team Barometer Regelmäßiges Team Feedback bzgl. SCRUM durch Team Barometer Aufbau und Integration QA Aufbau einer Testabteilung und schrittweise Integration in Prozess Externe Hilfe Zusammenarbeit mit Scrum Profis – Coaching, Seminare etc. Leadership Aufbau einer passenen Leadership-Philosophie: Lernen, persönliches Wachstum, Serving Leadership, Mentoring ... Ständiges Follow-Up Nutzen der gewonnenen Transparenz für ständige Verbesserungen. Jeder packt mit an! 1 2 3

119. Einführung einer Commitment-, Performance- und Feedback Kultur, die sich selbst trägt.

120. Besseres Verhältnis zum Kunden

121. Fokussierung in der Produktentwicklung

122. Angefangene Projekte werden fertiggestellt

123. Jeder Fehler, jede Unstimmigkeit fällt sofort auf und wird angegangen.

124. An der Qualität wird nicht geschraubt..

125. usw. 1 2 3 4

126. Kann Agile Softwareentwicklung wirklich Wunder wirken?

127. NEIN! Aber es gibt uns Softwerkern einfache Mittel an die Hand unsere Arbeit besser zu machen. Und es ändert das Mindset! Das ist wohl das wichtigste!

128. Lessons Learned: Do's and Dont's DO's Reifung der Unternehmenskultur DONT's Aufbau passender Entwicklungsumgeb. Scrum Master oder PO als Chef Störung des Prozess Start it NOW! An die Theorie halten. Seid diszipliniert Rollen mit den richtigen Leuten besetzen Mit anderen über die Erfolge sprechen Fehler und Probleme akzeptieren. Die harte Wahrheit muss auf den Tisch. Nichts beschönigen. Keine Retrospektiven und Reviews PO, der SCRUM nicht versteht Zu wenig Training der beteiligten Personen Zu wenig Fokussierung bei der Backlog-Planung Konkurrenz zwischen Team Mitgliedern Kein TDD und Refactoring 1 2 3 4

129. Fragen?