Scrum Workshop

2,400 views
2,178 views

Published on

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,400
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • PO: - gemeinsame Produktvision
  • Scrum Workshop

    1. 1. Agile Softwareenwticklung mit SCRUM
    2. 2. AGENDA
    3. 3. 1 2 3
    4. 4. Über Rollen, Artefakte und Zeremonien – Eine Einführung in die Begriffswelt von SCRUM 1 2 3
    5. 5. SCRUM ist mehr als Projektmanagement und Softwareentwicklung - Agile Prinzipien, Werte und der Faktor Mensch. 1 2 3
    6. 6. SCRUM im Feldversuch – 3 Jahre SCRUMologie bei Regis24. 1 2 3
    7. 7. Einführung in die Begriffswelt von Agile und SCRUM 1
    8. 8. Das Ziel agiler Softwareentwicklung ist es, schneller und effektiver Software zu entwickeln als in den klassischen, schwergewichtigen Entwicklungsmodellen. = 1 2 3
    9. 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. 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. 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
    12. 12. SCRUM ist ein agiler Prozess, der durch verschiedene agile Methoden gestützt werden sollte. Pair- Programming Test Driven Development (TDD) Ständiges Refactoring Code- und Architecture-Reviews Nightly Builds / Continous Integration <ul><li>Implementierungsaufgaben werden in Paaren gelöst
    13. 13. Eine Person schreibt Code, die Andere prüft, modelliert, hinterfragt
    14. 14. Vorteile: bessere Qualität, weniger Ablenkung, Wissenstransfer, Spaß
    15. 15. Nachteile: mehr direkter Zeitaufwand, ggf. negative Teamwirkung, </li></ul><ul><li>Nicht nur Unit- und Integrationstests, auch Anforderungen, Usability etc.
    16. 16. 100% Abdeckung erforderlich
    17. 17. Tests als elementarer Bestandteil der Entwicklung
    18. 18. Absicherung von Code gegen Änderung, Klare Zielrichtung </li></ul><ul><li>Code-Smells regelmäßig aufspüren und beseitigen
    19. 19. Alles wird in besserem Zustand verlassen als es vorgefunden wurde
    20. 20. Dringende Grundbedingung: 100% TDD, Collective Code Ownership
    21. 21. Vermeidung und Reduktion von Technical Dept als oberstes Ziel </li></ul><ul><li>Regelmäßige geplante und ständige spontane Code Reviews
    22. 22. Unstimmigkeiten werden sofort beseitigt
    23. 23. Alle Ansätze werden untereinander gechallenged
    24. 24. Wissenstransfer und Förderung des kollektiven Geistes </li></ul><ul><li>Jedes Teammitglied integriert seinen neuen Code täglich
    25. 25. Mit jeder Integration werden an einem Testserver sämtliche Unit-Tests sowie ein automatischer Build durchgeführt
    26. 26. Code Fragmente laufen so nicht auseinander, jederzeit Release möglich </li></ul>1 2 3
    27. 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
    28. 28. SCRUM beschreibt 3 relevante Rollen im Entwicklungsprozess. Product Owner Team Scrum Master 1 2 3 <ul><li>definiert Produkt-Features
    29. 29. bestimmt Auslieferungsdatum und Inhalt
    30. 30. ist verantwortlich für den Gewinn des Projekts (ROI)
    31. 31. priorisiert Features abhängig vom Marktwert
    32. 32. passt Features und Prioritäten nach Bedarf für jede Iteration an
    33. 33. akzeptiert oder weist Arbeitsergebnisse zurück </li></ul><ul><li>Typischerweise fünf bis zehn Leute
    34. 34. Mitglieder sollten Vollzeitmitglieder sein
    35. 35. Interdisziplinär
    36. 36. Teams organisieren sich selbst
    37. 37. Mitgliedschaft kann sich nur zwischen Sprints verändern </li></ul><ul><li>Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
    38. 38. Entfernt Hindernisse
    39. 39. Stellt sicher, dass das Team vollständig funktional und produktiv ist
    40. 40. Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
    41. 41. Schützt das Team vor äußeren Störungen
    42. 42. Vermittelt der Organisation die Welt der agilen Werte </li></ul>
    43. 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. 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. 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
    46. 46. Iterationen bestehen aus den gleichen, immer wieder kehrenden Stufen, die den Rhythmus der Entwicklung vorgeben. Planning Estimation Sprint Retrospektive Review Daily Scrum <ul><li>Aktuelle, priorisierte User Stories werden kurz vom Product Owner vorgestellt
    47. 47. Team schätzt den Aufwand (die Größe) der User Stories in Story Points
    48. 48. Kann als Teil des Planning oder (besser) spontan zwischendrin abgehalten werden.
    49. 49. Methodik des „Planning Poker“ hat sich bewährt. </li></ul>1 2 3
    50. 50. Iterationen bestehen aus den gleichen, immer wieder kehrenden Stufen, die den Rhythmus der Entwicklung vorgeben. Planning Estimation Sprint Retrospektive Review Daily Scrum <ul><li>Meeting bei dem sich Product Owner und Team auf das Arbeitspaket für den anstehenden Sprint einigen
    51. 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. 52. Team diskutiert untereinander die erreichbare Punktzahl und gibt ein bindendes Commitment ab.
    53. 53. Commitete User Stories werden in Tasks heruntergebrochen (Entwicklung- und Testtasks)
    54. 54. Team hat das unabhängige letzte Wort in Sachen Schätzung und Commitment – es sind keine Manipulationen oder Vorgaben möglich
    55. 55. Ergebnis: Sprint Ziel und Sprint Backlog </li></ul>1 2 3
    56. 56. Iterationen bestehen aus den gleichen, immer wieder kehrenden Stufen, die den Rhythmus der Entwicklung vorgeben. Planning Estimation Sprint Retrospektive Review Daily Scrum <ul><li>Im Sprint arbeitet das Team an der Erreichung des Commitments
    57. 57. Eine User Story ist dann abgeschlossen, wenn alle Tasks implementiert und funktional getestet sind sowie die Definition of Done erreicht wurde
    58. 58. Der Product Owner steht dem Team stets für Rückfragen und Entscheidungshilfen zur Verfügung </li></ul>1 2 3
    59. 59. Iterationen bestehen aus den gleichen, immer wieder kehrenden Stufen, die den Rhythmus der Entwicklung vorgeben. Planning Estimation Sprint Retrospektive Review Daily Scrum <ul><li>Tägliches Standup Meeting von max. 15 Minuten
    60. 60. Jedes Team Mitglied beantwortet folgende Fragen: </li><ul><li>Was habe ich gestern erreicht?
    61. 61. Was will ich heute erreichen?
    62. 62. Was hindert mich an der Erreichung meiner Ergebnisse? </li></ul><li>Product Owner nimmt idealerweise teil
    63. 63. Meeting wird direkt am Sprint Task Board durchgeführt. </li></ul>1 2 3
    64. 64. Iterationen bestehen aus den gleichen, immer wieder kehrenden Stufen, die den Rhythmus der Entwicklung vorgeben. Planning Estimation Sprint Retrospektive Review Daily Scrum <ul><li>Fertgigestellte Features werden dem Product Owner und anderen Stakeholdern als DEMO vorgestellt.
    65. 65. KEINE technische Präsentation, sondern lediglich Abnahme der Akzeptanzkriterien
    66. 66. Optional können KPIs der vergangenen Iteration vorgestellt werden sowie die nächsten Termine durch den Scrum Master vorgestellt werden. </li></ul>1 2 3
    67. 67. Iterationen bestehen aus den gleichen, immer wieder kehrenden Stufen, die den Rhythmus der Entwicklung vorgeben. Planning Estimation Sprint Retrospektive Review Daily Scrum <ul><li>Das Team nimmt sich die Zeit ihre Prozesse, Zusammenarbeit und zukünftigen Ziele bezüglich der vergangenen Iteration zu besprechen
    68. 68. Dient dem Ziel der stetigen Verbesserung
    69. 69. Aufdecken und Verstehen von Problemen und Hindernissen, die sich negativ auf die Arbeit und die Gesundheit des Teams auswirken
    70. 70. Im Fokus steht der Prozess und die Zusammenarbeit – nicht einzelne Personen
    71. 71. Kann durch ein regelmäßiges Team Barometer unterstützt werden </li></ul>1 2 3
    72. 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. 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
    74. 74. Übung: Aufstellen von User Stories <ul><li>Als Pilot möchte ich meinen Tagesablauf mit dem System organisieren können.
    75. 75. Als Tourist möchte ich eine 5-wöchige Reise nach Kathmandu unternehmen.
    76. 76. Als Kunde benötige ich täglich statistische Informationen zu allen getätigten Transaktionen. </li></ul>Entwickeln Sie User Stories für folgendes EPICs: 1 2 3
    77. 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
    78. 78. Am besten lässt sich die Schätzung als Planning Poker erspielen. <ul><li>Moderator (Scrum Master) führt in das Thema ein
    79. 79. Story wird vom PO vorgestellt, erfahrene Entwickler gibt techn. Überblick
    80. 80. Fragen werden gestellt und Akzeptanzkriterien vervollständigt
    81. 81. Jeder legt eine Karte (verdeckt) mit seiner geschätzten Punktzahl
    82. 82. Sobald alle gelegt haben wird aufgedeckt
    83. 83. Bei größeren Differenzen scheint es Klärungsbedarf zu geben – die Diskussion findet sofort vom SM gesteuert statt.
    84. 84. Schätzung wird so lange wiederholt bis eine Übereinkunft der Team Mitglieder gibt.
    85. 85. Wichtig: Aktives zuhören, Respekt, Disziplin </li></ul>Ablauf Planning Poker 1 2 3
    86. 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. 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. 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. 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. 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. 91. SCRUM erfordert Transparenz zu jeder Zeit. Der Burndown zeigt wo wir stehen. Aufwand Zeit 1 2 3
    92. 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. 93. Agile Prinzipien und Werte. Der Faktor Mensch in Scrum 2
    94. 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
    95. 95. „The Essence of SCRUM“ Die Art der Arbeit im Scrum Kontext erfordert Respekt für sich und andere, Vertrauen und Mut. <ul><li>Das Team verfolgt klare Ziele
    96. 96. Das Team organisiert seine Arbeit selbst
    97. 97. Das Team liefert stets die nützlichsten Features
    98. 98. Das Team empfängt Feedback von aussen
    99. 99. Das Team reflektiert die eigene Arbeitsweise mit dem Ziel sich zu verbessern
    100. 100. Die gesamte Organisation hat ein Bild vom aktuellen Team Status und Projektfortschritt
    101. 101. Das Team und das Management kommunizieren offen und respektvoll über Fortschritte und Risiken </li></ul>1 2 3
    102. 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. 103. 3 Jahre SCRUM bei Regis24. 3
    104. 104. Lehrjahre sind keine Herrenjahre. Von TPOs, TGP's und „der Moral von der Geschicht“. Nach der ersten Einführung von Scrum Ende 2006 haben wir einiges richtig, aber auch vieles falsch gemacht: <ul><li>Einfach beginnen – am besten lernt man indem man reale Erfahrungen sammelt
    105. 105. GF saß von Anfang an mit im Boot
    106. 106. Owner der Initiative war das Entwicklerteam
    107. 107. Anderen (befreundeten) Firmen und Interessierten von unseren Erfahrungen erzählen
    108. 108. Anforderungen allesamt in Backlog überführt </li></ul><ul><li>User Stories bestehen aus 1-3 Wörtern, Akzeptanzkriterien wenn überhaupt implizit
    109. 109. Schätzung von Aufwand weiterhin in Manntagen
    110. 110. Umfang mehr oder weniger von GF / Vertrieb vorgegeben
    111. 111. Keine festen Sprintlängen (2-6 Wochen), lange „Pausen“ zwischen den Sprints
    112. 112. Keine Retrospectiven, technische Präsentationen in Reviews
    113. 113. Keine Time Boxes
    114. 114. Kein starker Scrum Master
    115. 115. Einführung neuer Rollen (TGP, TPO) und keine gute Ausführung der Rollen PO und SM
    116. 116. Kein selbstorganisiertes Team, kein TDD usw. </li></ul>1 2 3 + -
    117. 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
    118. 118. Die Wiedereinführung von Scrum hat viele sehr positive Effekte auf die Entwicklungsarbeit bei R24. <ul><li>Verbesserung der Zusammenarbeit von Entwicklern und GF / Vertrieb
    119. 119. Einführung einer Commitment-, Performance- und Feedback Kultur, die sich selbst trägt.
    120. 120. Besseres Verhältnis zum Kunden
    121. 121. Fokussierung in der Produktentwicklung
    122. 122. Angefangene Projekte werden fertiggestellt
    123. 123. Jeder Fehler, jede Unstimmigkeit fällt sofort auf und wird angegangen.
    124. 124. An der Qualität wird nicht geschraubt..
    125. 125. usw. </li></ul>1 2 3 4
    126. 126. Kann Agile Softwareentwicklung wirklich Wunder wirken?
    127. 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. 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. 129. Fragen?

    ×