Verlernte Agilität
•Télécharger en tant que KEY, PDF•
0 j'aime•520 vues
SCRUM als eine der meist verbreiteten agilen Methodiken bezeichnet sich selbst als Framework. Es bietet also eine Sammlung nützlicher Herangehensweisen und ein eher loses Regelwerk. SCRUM lässt gewollt Spielraum für Anpassungen an eigene Gegebenheiten offen. Bei der Einführung von SCRUM werden aber gerade hierdurch oft elementare Konzepte übersehen und das Konzept damit ad absurdum geführt. Aber auch in einem etablierten SCRUM Team schleichen sich im Laufe der Zeit oft unbemerkt Fehler und Probleme ein, welche den Prozess nach und nach gefährden, werden sie nicht frühzeitig wahrgenommen. Dieser Vortrag soll daher erklären, welche Fehler sich bereits bei der Einführung von SCRUM vermeiden lassen. Vor allem aber soll gezeigt werden, wie man sich davor schützen kann, Agilität nicht zu verlernen und sich mit der Zeit immer weiter von seinem Ziel zu entfernen. Er soll Vorschläge und Anregungen bieten, wie man das tägliche Stand-Up Meeting nicht zur wertlosen Pflicht werden lässt und wie man Retrospektiven effektiv nutzt, um sich langsam einschleichende Fehler und Probleme zu identifizieren und zu beseitigen.
Recommandé
Contenu connexe
En vedette
En vedette (20)
Plus de Sebastian Bauer
Plus de Sebastian Bauer (12)
Verlernte Agilität
- 2. Vorstellung o Sebastian Bauer o SCRUM Master o LOTUM GmbH o Bad Nauheim bei Frankfurt/Main o @litervollmilch o http://blog.gjl‐network.net 2
- 3. Vorstellung o Sebastian Bauer o SCRUM Master o LOTUM GmbH o Bad Nauheim bei Frankfurt/Main o @litervollmilch o http://blog.gjl‐network.net 2
- 4. Verlernte Agilität? 3
- 5. Anforderungen 4
- 6. Product Owner 5
- 7. Der Scrum Master 6
- 10. Sprint Planung 9
- 11. Sprint Review 10
- 12. Retrospektiven 11
- 13. „You cannot control what you cannot measure“ ‐ Tom DeMarco 12
- 14. Die Sache mit den... Timeboxes 13
- 15. Einflussfaktoren von Außen 14
- 16. Einflussfaktoren von Außen o Definierte Deadlines mit definiertem Umfang 14
- 17. Einflussfaktoren von Außen o Definierte Deadlines mit definiertem Umfang o „Ihr müsst doch schneller werden!“ 14
- 18. Einflussfaktoren von Außen o Definierte Deadlines mit definiertem Umfang o „Ihr müsst doch schneller werden!“ o Misstrauen 14
- 19. Scrum ist... 15
- 20. Scrum ist... o ... ein sensibles Ökosystem 15
- 21. Scrum ist... o ... ein sensibles Ökosystem o ... REVOLUTION! 15
- 22. Scrum ist... o ... ein sensibles Ökosystem o ... REVOLUTION! o ... kein Sklavischer Gehorsam! 15
- 23. Scrum ist... o ... ein sensibles Ökosystem o ... REVOLUTION! o ... kein Sklavischer Gehorsam! o ... empirisch, ABER! 15
- 24. Scrum ist... o ... ein sensibles Ökosystem o ... REVOLUTION! o ... kein Sklavischer Gehorsam! o ... empirisch, ABER! o ... ein Framework! 15
- 25. DAS WAR‘S! Fragen? Sebastian Bauer http://blog.gjl‐network.net @litervollmilch Rocke mit uns das Web! www.lotum.de/jobs 16
Notes de l'éditeur
- \n
- 1.200.000.000 Page Impressions / Monat (viel;)\nZweitgrößtes Social Network für Schüler\n\n\n
- 1.200.000.000 Page Impressions / Monat (viel;)\nZweitgrößtes Social Network für Schüler\n\n\n
- Probleme werden analysiert - (klassische Probleme auflisten) - Scrum wird eingeführt - Ersten wochen voller motivation und alles bestens\n irgendwie der wurm drin - oder - niemand merkt, dass der wurm drin ist\n ODER: Scrum wird eingeführt und man denkt sich „das und das ok, aber das, nö“\n \n\n
- Backlog wird viel zu groß -> gleiches, klassisches Wasserfallproblem\n keine Berücksichtigung nicht-funktionaler Anforderungen\n „Wir wollen doch keine Verschwendung“ -> agil heißt, keine Dokumentation, kein Konzept\n Über-spezifizierung von stories\n Stories „kommunikativ“ halten\n Team damit Verantwortung und Identifikation übertragen\n Denn: Gefahren von Überspezifizierung! Beamtentun, „Commit and Forget“\n
- nicht erreichbar\n nicht Erreichbarkeit sorgt für unausgesprochene Impediments!\n einfach „nur“ Projektmanager -> nicht Scrum-geschult\n wichtigste Brücke zwischen Kunden/Stakeholdern und Team!\n Funktioniert nicht, wenn er nicht „Scrum“ ist!\n
- Übernimmt Teamaufgaben, weil Zeit knapp\n Übernimmt noch andere Aufgaben\n Verliert Fokus\n Macht PO Tätigkeit\n ist disziplinarischer Vorgesetzer -> kann funktionieren, wird es aber zu 99% nicht\n Muss immer beobachten und voll fokussiert sein\n Wenn auf andere Aufgaben konzentriert, fehlt die Sensibilität und das Gespür „Gefahrenherde“ zu erkennen\n
- Reporting an PO, SM, Stakeholder oder sonst wen\n Vorlesen der gestrigen To-Do Liste\n Rechtfertigung, wie 8 Stunden zusammen gekommen sind\n Erwähnung von „Meta“ Aufgaben\n kein Fokus auf Meeting (Leute bleiben vor PC sitzen)\n „gestern irgendwas, heute gehts damit weiter“\n Aufstehen!\n Timebox!\n Tempo machen!\n Team soll nur „wertvolle“ Inhalte vermitteln\n als SM oder PO: wegschauen!\n Stakeholder absichtlich eine Zeit lang „ausladen“\n Taskboard! Taskboard! Taskboard!\n ANGST - KOMFORTZONEN VERLASSEN\n
- Werden nicht wahrgenommen\n „Da kann man ja jetzt eh nichts dran machen, also sag ich es nicht“\n Impediments werden nicht angegangen\n Scrum Master rechtfertigt Ursachen von Impediments statt sie anzugehen -> RIESEN Gefahr fürs Team\n
- Planungspoker geht zack zack zack, aber Schätzungen sind nie einheitlich\n zu lange planungsmeetings\n zuviel Übergabe-Overhead\n Team will zu früh schneller werden\n Immer auf das Maximum planen\n Team „einbremsen“, gleichmäßige Pace finden\n Team schulen, Schätzungen zu hinterfragen\n\n
- Es wird nicht festgehalten, wenn DoD nicht eingehalten wurde\n noch schlimmer: es gibt keine DoD\n Vorstellung unfertiger Stories\n PO überlegt sich noch dieses und jenes und nimmt Stories nicht ab\n
- retrospektiven laufen falsch, daher oft abgeschafft\n kein empirisches vorgehen\n immer gleiche aktivitäten - keine wissensgewinnung\n schlechte moderation\n immer nur das gleiche erzählen - jemand schweigt „im grunde hat‘s der andere ja schon gesagt“\n Retrospektiven immer schließen!\n Ganz sensibel auf jede Stimme achten!\n Die richtigen Aktivitäten für die richtigen Zwecke!\n Fortschritte inspizieren!\n Empirisches Vorgehen nicht vergessen -> Änderungen „gegenkontrollieren“\n
- \n
- Scrum ist doch kein blinder gehorsam!\n Wenn die Planung länger dauert, können wir nicht einfach abbrechen.\n Doch!\n Timeboxes strikt einhalten, fördert Selbstorganisation des Teams!\n Daily Scrum ging zu lange? Am nächsten Tag wird das Team dem „Schwätzer“ schon auf die Füße treten!\n
- Definierte Deadlines mit definiertem Umfang töten jede Form von Commitment\n Ihr müsst schneller werden -> over committing -> Beeinflussung des Teams -> tötet Selbstorganisation\n ganz wichtiger Negativfaktor: misstrauen\n
- Definierte Deadlines mit definiertem Umfang töten jede Form von Commitment\n Ihr müsst schneller werden -> over committing -> Beeinflussung des Teams -> tötet Selbstorganisation\n ganz wichtiger Negativfaktor: misstrauen\n
- Definierte Deadlines mit definiertem Umfang töten jede Form von Commitment\n Ihr müsst schneller werden -> over committing -> Beeinflussung des Teams -> tötet Selbstorganisation\n ganz wichtiger Negativfaktor: misstrauen\n
- Alles ein extrem sensibles Ökosystem -> fällt ein Steinchen, kann das gesamt Konstrukt aus den Fugen geraten\n Scrum ist REVOLUTION!\n kein Sklavischer Gehorsam, aber Regeln sind wichtig!\n Empirisch ja, aber nicht an den Grundregeln schrauben und bei der Einführung von Scrum schon alles abändern, weil man sonst zuviele Schwierigkeiten hätte\n Denn, was ist ein Framework? Es gibt grundlegendes vor, das man verwenden kann. Schraubt man daran herum, ändert man das Framework\n
- Alles ein extrem sensibles Ökosystem -> fällt ein Steinchen, kann das gesamt Konstrukt aus den Fugen geraten\n Scrum ist REVOLUTION!\n kein Sklavischer Gehorsam, aber Regeln sind wichtig!\n Empirisch ja, aber nicht an den Grundregeln schrauben und bei der Einführung von Scrum schon alles abändern, weil man sonst zuviele Schwierigkeiten hätte\n Denn, was ist ein Framework? Es gibt grundlegendes vor, das man verwenden kann. Schraubt man daran herum, ändert man das Framework\n
- Alles ein extrem sensibles Ökosystem -> fällt ein Steinchen, kann das gesamt Konstrukt aus den Fugen geraten\n Scrum ist REVOLUTION!\n kein Sklavischer Gehorsam, aber Regeln sind wichtig!\n Empirisch ja, aber nicht an den Grundregeln schrauben und bei der Einführung von Scrum schon alles abändern, weil man sonst zuviele Schwierigkeiten hätte\n Denn, was ist ein Framework? Es gibt grundlegendes vor, das man verwenden kann. Schraubt man daran herum, ändert man das Framework\n
- Alles ein extrem sensibles Ökosystem -> fällt ein Steinchen, kann das gesamt Konstrukt aus den Fugen geraten\n Scrum ist REVOLUTION!\n kein Sklavischer Gehorsam, aber Regeln sind wichtig!\n Empirisch ja, aber nicht an den Grundregeln schrauben und bei der Einführung von Scrum schon alles abändern, weil man sonst zuviele Schwierigkeiten hätte\n Denn, was ist ein Framework? Es gibt grundlegendes vor, das man verwenden kann. Schraubt man daran herum, ändert man das Framework\n
- Alles ein extrem sensibles Ökosystem -> fällt ein Steinchen, kann das gesamt Konstrukt aus den Fugen geraten\n Scrum ist REVOLUTION!\n kein Sklavischer Gehorsam, aber Regeln sind wichtig!\n Empirisch ja, aber nicht an den Grundregeln schrauben und bei der Einführung von Scrum schon alles abändern, weil man sonst zuviele Schwierigkeiten hätte\n Denn, was ist ein Framework? Es gibt grundlegendes vor, das man verwenden kann. Schraubt man daran herum, ändert man das Framework\n
- \n