Downloaden Sie, um offline zu lesen
Hochgeladen vonSebastian Bauer
Verlernte Agilität
Das Dokument ist eine Präsentation von Sebastian Bauer, Scrum Master bei Lotum GmbH, die sich mit dem Thema 'verlernte Agilität' beschäftigt. Es werden verschiedene Aspekte des Scrum-Frameworks behandelt, darunter die Rolle des Product Owners, der Scrum Master sowie tägliche Scrum-Meetings, Sprint-Planung und Retrospektiven. Zudem wird auf externe Einflussfaktoren und den empirischen Charakter von Scrum als sensibles Ökosystem eingegangen.
Verlernte Agilität
- 1.
- 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.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13. „You cannot control what you cannot measure“ ‐ Tom DeMarco 12
- 14. Die Sache mit den... Timeboxes 13
- 15.
- 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
Hinweis der Redaktion
- #2 \n
- #3 1.200.000.000 Page Impressions / Monat (viel;)\nZweitgrößtes Social Network für Schüler\n\n\n
- #4 1.200.000.000 Page Impressions / Monat (viel;)\nZweitgrößtes Social Network für Schüler\n\n\n
- #5 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
- #6 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
- #7 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
- #8 Ü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
- #9 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
- #10 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
- #11 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
- #12 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
- #13 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
- #14 \n
- #15 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
- #16 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
- #17 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
- #18 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
- #19 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
- #20 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
- #21 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
- #22 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
- #23 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
- #24 \n