Please enable JavaScript.
Coggle requires JavaScript to display documents.
Fortgeschrittene Agile Vorgehensmodelle (Themenfelder zur LV WS_25/26) -…
Fortgeschrittene Agile Vorgehensmodelle
(Themenfelder zur LV WS_25/26)
Kanban
Praktiken
(1) Visualize your Work
Kanban Board
Swim-Lanes
Für Service Klassen
Mit WIP Limits
Expedite Lane: WIP Limit 1!
(Für wirklich dringende Arbeiten)
"Kannst Du mal"-Lane ...
(Sichtbar Machung von nicht abgesprochenen Tätigkeiten)
Service Klassen:
Unterschiedliche Tätigkeitsarten
Allgemeines Layout
Karten / Spalten
Karten-Inhalt:
Titel, Kurze Beschreibung,
Bearbeiter, Fertigstellungsdatum
Art der Tätigkeit (Service Klasse), Checkboxes, Progress, etc.
Es gehört alles drauf, was für das Team passt
Übliche Prozess-Spalten:
Todo; In-Arbeit; Review; Done
Umgang mit "Unteraufgaben" und "Epics"
Visualisierung von Blockern
Sichtbarkeit von Engpässen
(Ergebnis von Blockern ... Staus in Spalten)
Regeln für Board-Bearbeitung sollten sichtbar sein
Metriken
Cumulative Flow Diagramm (CFD)
Beinhaltet WIP, avg. Cycle-Time und Throughput
Cycle Time / Lead Time
Anzahl
geblockte
Tasks vs. erledigte Tasks, "Blocked Time Ratio" (Blocked Time / Total Lead-Time) < 10%
Lead-Time Distribution Chart
Visualisierung schafft Transparenz
(2) Limit Work in Progress
Stop Starting, Start Finishing
Fokussierung
Vermeidung von Überproduktion/Waste
Veringerung der Cycle Time
Man schafft mehr, wenn man weniger gleichzeitig macht ...
Zeit, in der wir keine Arbeit verrichten (Slack time) ermöglicht uns, Schwächen im System zu identifizieren, zu messen, die Qualität zu erhöhen und Verbesserungen vorzunehmen.
Einführung und Anpassung von Limits:
Kleine Schritte / Experimente
Ziel: eher kleine Werte!
Psychologische Aspekte:
Wenn ich nichts tue (weil das WIP Limit erreicht ist), dann wirkt das so, als ob ich faul wäre ...
(3) Manage Flow
Gleichmäßiger Fluß wird angestrebt
Vorhersagbarkeit von Fertigstellungszeiten
Hohe Qualität bei ruhigem Arbeitsfluss
Engstellen/Blocker erkennen und Verbesserungen durchführen
Nur ein stabiles System erlaubt es, verlässliche Vorhersagen zu treffen und Versprechen einzuhalten.
Je später wir beginnen, desto besser für den Kunden
(6) Kontinuierliche Verbesserung
(Kollaborativ)
Kleine experimentelle Schritte führen langfristig zu Verbesserungen
Regelmäßige Retros zur Identifikation von Verbesserungsmöglichkeiten
Viel Kommunikation im Team
Alle sind für das Gesamtergebnis verantwortlich
Lokale Optimierungen bringen nichts.
Man muss das Gesamtsystem im Blick haben!
(4) Make Policies Explicit
Regeln und Prozesse sind für alle sichtbar und bekannt
Die implizten und expliziten Regeln sind dem Projekt-Team bekannt (man muss nicht gegen die Realität ankämpfen)
(5) Implement
Feedback Loops
"Cadences":
Daily Standup,
Replenishment Meeting,
Delivery Planning Meeting,
(in der Vorlesung nur gestreift): Service Delivery Review, Operations Review, Risk Review und Strategy Review
Daily Standup: "Walk the board"
Ziel: Items "fertig" bekommen
Replenishment-Meeting, 1 bis 2 mal die Woche:
Entscheiden, welche Items als nächstes umgesetzt werden
Delivery Planning: Welche Items werden wie zu Releases zusammengefasst
Retrospektiven
Ablauf einer Retro:
Setting the Stage
Collecting Data
Generating Insights
Decide what to do
Closing the Retro
Verschiedene Techniken (siehe Simulation / Games)
Psychologische Sicherheit .... Las Vegas Rule ...
(0) Start with what is
Die Kraft der
kleinen Schritte
Ursprung/Bedeutung
Signal-Karten
Lean-Management / Lean-Production
Fokus: Kontinuierliche Prozess-Verbesserung
Push vs. Pull
Push:
Arbeit wird zugewiesen.
Zentrale Kontrolle & Überblick
Skalierungsprobleme und evtl. Engässe
Pull:
Arbeit wird eigenständig "geholt", d.h. es gilt Eigenverantwortung
Nachteil: Es kann sein, dass Arbeit "liegen bleibt"
Überblick muss durch Visualisierung/Metriken hergestellt sein.
Theory of Constraints
Der Engpass definiert den Throughput:
Egal, ob wir mit Push oder Pull (bzw. WIP-limitierter) Methodik arbeiten, bestimmt der Engpass immer den
Durchsatz
des Systems. Warum? Weil sich spätestens hier die Arbeit aufstaut. Es macht keinen Unterschied, wieviel Arbeit wir in das System geben oder wie schnell wir vorherige Schritte abarbeiten: Am Ende ist die fertiggestellte Arbeit die gleiche.
Fokussierungsschritte der TOC:
Identifizieren
Ausnutzen
Unterordnen
Erweitern
Wiederholen
Um keinen Überlauf zu erzeugen, werden WIP-Limits gesetzt (in den davor liegenden Prozess-Schritten)
Little's Law
L = λ * W
L: durchschnittle Zahl von Elementen (Work in Progress)
λ : Durchschnittle Ankunftsrate (Throughput)
W : Durchschnittliche Verweildauer (Lead-Time)
Lead-Time = WIP / Throughput
Wichtig: Durchschnittswerte!
Wenn die Work in Progress bei gleichem Throughput steigt, dann erhöht sich die Lead-Time.
Simulationen/ Games
Kanban-Klinik
Lernziele:
Limit WIP,
Pull anstele von Push,
Kontinuierliche Verbesserung
Personal Kanban
Boss-Worker Game
Prinzip: Push vs. Pull
Schiffe falten
Erkenntnisse zu Push/Pull
Throughput
Cycle Time
Später Arbeitsbeginn
Vermeidung von Waste
Pizza Game
Komplexerer Entwicklungsprozess
Blocker-Management (Ofen)
Umgang mit unterschiedlichen Aufgabentypen
Metrik: Fertigstellung vs.
verschwendetem Material
Board-Design anpassen
Übertragbarkeit auf Software-Entwicklung!
Ticket Race
Vorstufe zu "Getkanban"
Verschiedene Service-Klassen
Multitasking Name Game
Little's Law:
Mehr Arbeit im System erhöht die durchschnittliche Wartezeit (Lead-Time)
Ball Point Game
Limit Work in Progress
Push / Pull
Auwertung von Lead-Time mit Metrik (CFD)
TOC Simulation
https://nixos-clean-big.krpg.users.h-da.cloud/toc/toc-game.html
Der Engpass bestimmt den Durchsatz
Die Cycle-Time steigt, weil durch den Engpass das WIP steigt (Little's Law)
WIP Limits sind nur sinnvoll, wenn die Menge an Arbeit tatsächlich limitiert wird.
https://nixos-clean-big.krpg.users.h-da.cloud/toc/toc-game-with-throughput.html
Einstellen von Bearbeitungszeiten: Little's Law verstehen, Cycle-Time, Throughput, etc.
https://nixos-clean-big.krpg.users.h-da.cloud/toc/toc-game-with-blockers.html
Simulation mit Blocker -> Auswirkung auf WIP
Wichtig
: Erhöhung des WIP "heilt" Blocker ... aber Cycle-Time erhöht sich (z.T. auch sprunghaft!)
Get Kanban
Komplexe Simulation
Service Klassen / "Intanbibles" ohne klar erkennbare "Belohnung"
Zielgerichtete Abarbeitung
Kommunikation im Team
Teilweise abhängig vom Würfelglück ...
Metriken: CFD und
Controlchart
:
Cycle Time von fertiggestellten Items
Einfluss des Managements auf den WIP
"Aushelfen" bei Engpässen: möglich aber nicht super effizient
Retro-Games
One Word Status (Wie geht es mir gerade)
5 Whys
Fishbone
Mad / Sad / Glad
Sailboat
SMART Actions
Circles and Soup
Appreciation / Kudos
Fishbowl
Technik zur Gruppen-Diskussion
Überwindung von Widerständen bei der Einführung von agilen Methoden
Andere Agile Vorgehensmodelle
Scrum
Fokus: Inkrementelle Produktentwicklung
Kernelemente: Rollen / Artefakte / Mettings / Vorgehensweisen ...
eXtreme Programming (XP)
Fokus
: Technische Exzellenz
💬 CommunicationStändiger Austausch im Team und mit Kunden
✨ SimplicityDie einfachste Lösung, die funktioniert
🔄 FeedbackSchnelle Rückmeldung auf allen Ebenen
💪 CourageMut, schwierige Entscheidungen zu treffen
🤝 RespectGegenseitige Wertschätzung im Team
ScrumBan
Verbindung von Scrum und Kanban
Häufig: Scrum ohne Sprints
Kanban Board mit Flow Metriken
Das Agile Manifest
Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
Lauffähige Software ist wichtiger als umfassende Dokumentation
Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans
Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen