Kanban und Scrum

Kindernothilfe e. V.
Referat Organisation und Datenmanagement
Die nächste große Entscheidung war, ob geteilte Verantwortung für die verschiedenen Arbeitstypen
eingeführt werden sollte oder nicht. „Sollten wir einen festen Teil des Teams sich mit den direkten Fragen
(reaktive Arbeit) befassen lasen und den Rest des Teams sich auf die Projekte (Arbeit in Eigeninitiative)
konzentrieren lassen?“ Wir entschieden uns, zuerst die geteilte Verantwortung auszuprobieren. Ein
Hauptgrund war, dass wir erkannt hatten, dass Selbstorganisation und stetiges Lernen und Wissenstransfer
seitens der Teammitglieder entscheidend waren, um ständiges Wachstum zu ermöglichen. Der Nachteil
dieser Entscheidung waren mögliche Unterbrechungen für Jeden, aber das war die beste Lösung, die wir
uns für den Anfang vorstellen konnten. Eine kurze Randnotiz: als wir den Workshop durchführten,
organisierten sich die Teams rund um dieses Problem tatsächlich selbst. Sie ließen eine Person die
dringenden Anfragen bearbeiten und den Rest mit den größeren Dingen.
25.1 Das erste Kanbanmodell
Unten ist das Grundmodell, das wir für Kanban genutzt haben. Beachten Sie, dass das Team entschieden
hat, die Arbeitspakete hochsteigen zu lassen (wie Wasserblasen), entgegen dem typischeren Modell,
fließend von links nach rechts.
Abbildung 2. Dies ist das erste Modell eines Kanbanboards.
Prioritäten laufen von links nach rechts, der Arbeitsablauf
läuft aufwärts. WIP wird als Gesamtanzahl von Aufgaben bei
den Arbeitspaketen, die gerade in der Spalte „In Arbeit“
(Work in progress) sind, gezählt (eingekringelt). Das Modell
ist beeinflusst durch die Erfahrungen, die Linda Cook
berichtet hat.
- 44 -