Koordinierung durch Kanban

Koordinierung durch Kanban

Kapitel 7

7.1 Koordinierung durch Kanban


• Aufgabentyp

• Serviceklasse

• Statusinformationen (z.B. zu spät)

• Teammitglied


• 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?


• 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


• 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

Software

Koordinierung durch Kanban