koordinierung durch kanban
DESCRIPTION
Kurzvortrag zum 7. Kapitel des Buches 'Kanban: Evolutionäres Change Management für IT-Organisationen' von David J. Anderson.TRANSCRIPT
Koordinierung durch Kanban
Kapitel 7
7.1 Koordinierung durch Kanban
7.1 Koordinierung durch Kanban
• Aufgabentyp
• Serviceklasse
• Statusinformationen (z.B. zu spät)
• Teammitglied
7.1 Koordinierung durch Kanban
• Ziel: Selbstorganisation
• Teammitglieder in Lage versetzen, Aufgaben selbständig zu ziehen
7.2 Elektronisches Tracking
• Erweiterte Möglichkeiten
• Limit überschritten, Ticket überfällig, …
• Daten sammeln, um Metriken und Berichte für Management und Nachbetrachtung zu erstellen
7.3 Tägliche Standup-Meetings
• in der Regel morgens
• Bisherige Fragen:
• Was hast du gestern geschafft?
• Was wirst du heute tun?
• Wirst du durch etwas blockiert, bzw. benötigst du Hilfe?
7.3 Tägliche Standup-Meetings
• Diese ‘3 Fragen’ sind hinfällig im Kanban-Standup
• Veränderungen seit letztem Meeting sieht man, wenn man regelmäßig teilnimmt
• Fokus liegt nun auf Fluss der Aufgaben
7.3 Tägliche Standup-Meetings
• Moderator (PM) geht von rechts nach links das Board durch
• Besondere Aufmerksamkeit auf Blocker oder Tickets, die (durch Fehler) im Verzug sind
• Festgesteckte Aufgaben => neuer Blocker?
• Reife Teams schauen nur noch auf Blocker oder Tickets die mit Fehlern zu tun haben => große Anzahl an Teilnehmer möglich
7.4 Anschlussmeetings• Spontan
• Kleine Gruppen von 2-3 Personen
• Generiert Verbesserungsvorschläge und führt zu Prozessanpassungen und Innovationen
• In größeren Projekten eventuell Form von Standup-Meeting
• Blockade, technisches Problem, Architekturfrage besprechen
7.5 Nachschubmeetings
• Priorisierung: Input Queue füllen
• PM, Dev, Fachbereich oder Product Owner
• möglichst regelmäßig (Vertrauen, Reduzierung Koordinierungskosten) => später bei Bedarf
7.6 Release-Planungsmeeting
• Auslieferung am Ende der Wertschöpfungskette
• Checklisten oder Frameworks, um Planung zu erleichtern (was bereit für Release, Risiken, Notfallpläne, …)
7.7 Triage• sinnvoll für Bugs, aber vor allem Backlog-Pflege
• Teilnehmer vom Nachschubmeeting (+ PM)
• was bleibt, was wird entfernt
• kleiner Backlog => Priorisierung einfacher
• Automatisierung möglich
7.8 Review der Problemliste und Eskalierung
• Blockaden werden entsprechend markiert
• regelmäßige Prüfung der offenen Blockaden
• Zunächst regelmäßige Reviews der Problemliste: PM + Team
• Wer Blockade zugeteilt, arbeitet dran?
• Wann Beseitigung?
7.8 Review der Problemliste und Eskalierung
• ‘Höherers Management’ nicht unbedingt notwendig
• Regeln definieren, wann nach oben eskaliert wird
• Umgang mit Blockaden und Eskalierung meist nicht zufriedenstellend in Praxis => Kernbereich, um Fluss und Produktivität zu verbessern
• Kapitel 20!
7.9 Sticky Buddies
• Home Office => Aktualisierung physikalisches Board?
• Sticky Buddy wird via IM, … kontaktiert und gebeten das Board zu aktualisieren
7.10 Synchronisierung über geographische Grenzen hinweg
• Schlüssel ist elektronisches System
• Physikalisches Board mindestens einmal am Tag aktualisieren
• Standup-Meetings über (Video-)Telko; Board zuvor aktualisieren
Zusammenfassung• Best Practice: physikalisches und elektronisches
Board
• Kanban bei verteilter Entwicklung möglich
• Meetings regelmäßig => Koordinierungskosten senken, Teilnahme erhöhen
• Priorisierung und Releaseplanung unabhängig voneinander
Zusammenfassung• Tägliche Standup-Meetings: Probleme, Blockaden, Fluss
der Aufgaben besprechen; wesentlicher Bestandteil der kontinuierlichen Verbesserung
• Standups: Ganzes Team dabei => Möglichkeit Verbesserungen vorzuschlagen; im Anschluss informelle Diskussionen zur Prozessverbesserung
• Pflege des Backlogs durch regelmäßige Triage => Einfachere Priorisierungsmeetings
• Kernkompetenz Leistung des Teams erhöhen: Probleme handhaben, eskalieren, lösen