Sie sind auf Seite 1von 2

Kanban

• Vorteile:

• Visualisiert Arbeitsfluss (für alle, schneller Überblick) -> Transparenz

• Fehler werden schnell offensichtlich

• Begrenzt angefangene Arbeit/Projekte -> Pull system, man holt nur wenn man
wieder was frei hat, so liegt nicht viel gleichzeitig bzw. wenn ist etwas falsch

• Messbarkeit von Warteschlangen, Cycle time etc. -> ist alles richtig organisiert?
Verbesserungen und Planbarkeit wird immer besser

• Verbesserungen müssen/sollen von den Mitarbeitern/Verwendern kommen –> in


Meetings ansprechen (Operations Review)

• WiPs verändern, Teams verändern (bottlenecks), Puffer einführen

• Service Arten für die Karten

• High Prio (Expedite) -> extra Prio Lane dafür, zusätzlich zu normalem WIP

• Fixed Date

• Intangible (Wert bzw. Verzögerungskosten sind nicht 100% bekannt)

• Standard (fifo)

• Tracking

• Cumulative Flow diagram (Jede Kanban spalte hat ihre Linie, so sieht man wie lange
ein Task von reinkommen bis Ende dauert (cycle time) und es zeigt, wenn die Linien
weit auseinandergehen, das in diesem Bereich zu viele Tasks reingehen und zu wenig
raus)

• Schwierigkeiten:

• Bottleneck -> Tasks bleiben überall hängen (nicht immer kann das Team dann im
Bottleneck aushelfen)

• Möglichst wenig Varianz in den Tasks ist deshalb wichtig (keine Riesentasks und
Minitasks)

• Response time (wenn angefragt bis Team startet damit) & Lead time (Response time
+ cycle time) nicht zu hoch bzw. Backlog nicht zu voll

Embedded

• Hardware kann nicht agil gemacht werden, es muss im Wasserfallmodell gemacht werden,
aber man kann die Hardware in eine agile Methode einbinden:
• Softwarerequirements die Hardware zuerst brauchen bekommen einen eigenen
„Parkplatz“ (Puffer) und werden erst wenn HW fertig ist eingespeist (z.B. durch
Trigger/Milestones im Wasserfallmodell)

Rolle PO

• Backlog managen -> nicht zu groß, nichts altes, nichts zu lange, Zusammenhänge etc.

• Eigenes Kanban Board

• Meine To Do List Methode

• Epics runterbrechen

• In möglichst gleich „große“ Tasks

• Benötigt oft noch Zusatzinfos, genaueres etc. -> sollte aber nicht zu lange dauern da
für den Kunden die Lead time schon läuft

• Priorisierung notwendig (Backlog muss schön bleiben)-> gut so, man überwacht ständig und
wenn was ewig rumliegt wird es in Frage gestellt

• Verzögerungskosten: Was kostet es uns zusätzlich, wenn wir dieses Feature noch
nicht rausbringen? (z.B. Gesetze) Dann Durchlaufzeit + Puffer = Start

• Stakeholder

• Nein sagen können

• In ständigen Kontakt mit Stakeholdern

• Team abschirmen für Qualität

• Vision vermitteln