Februar 27, 2019

KANBAN, SCRUM & CO

KANBAN

ist eine Methode der Produktionsablaufsteuerung. Taiichi Ohno ist der Vater des Lean Production Systems bei Toyota. Kanban ist in 1953 in Verbindung mit der JIT (Just -In-Time) Produktion von ihm eingeführt worden. Das auch Hol- oder Zurufprinzip genannte Pull-Prinzip hat das Ziel die Wertschöpfungskette kostenoptimal zu steuern. In der Software-Entwicklung ist Software-Kanban eine einfache Methode den bestehenden Arbeitsprozess für das Team transparent darzustellen und so Engpässe aufzuspüren und Verbesserungsansätze zu definieren und auszuprobieren. Kanban in der IT reduziert die Anzahl paralleler Arbeiten, den Work in Progress (WiP), und erreicht somit schnellere Durchlaufzeiten (Cycle Time). Die Probleme – insbesondere Engpässe (Theory of Constraints-TOC) - werden schnell sichtbar und deren Beseitigung erhält die volle Aufmerksamkeit des Teams.
SCRUM

Scrum ist inzwischen wohl das bekannteste Methoden-Framework im agilen Kontext wenn es um das Thema agiles Projektmanagement geht. Der Grund dafür ist, dass die Scrum Prinzipien relativ einfach zu verstehen und umsetzbar sind und dass Scrum dadurch einfach gut funktioniert! Wenige aber klar definierte Rollen, Meetings, und Projektartifakte sowie "time-boxing" Verfahren ermöglichen einen gut strukturierten und dennoch flexible Prozesse.
Das Scrum Framework basiert auf den drei Hauptpunkten der Transparenz, der Überprüfung und der Anpassung. Das Ziel ist es möglichst schnell, kostengünstig und qualitativ hochwertige Entwicklung von Produkten zu gewährleisten.
Der iterative und inkrementelle Ansatz von Scrum sorgt für ständige Transparenz und fördert schnelles Feedback während eines Zyklusses.
SCRUMBUT

ScrumButs sind Gründe, warum Teams nicht den vollen Nutzen von Scrum nutzen können, um ihre Probleme zu lösen und den vollen Nutzen der Produktentwicklung mit Scrum zu realisieren. Jede Scrum-Rolle, Regel und Timebox ist so konzipiert, dass sie die gewünschten Vorteile bietet und vorhersehbare, wiederkehrende Probleme löst. ScrumButs bedeuten, dass Scrum eine Dysfunktion aufgedeckt hat, die zu dem Problem beiträgt, aber zu schwer zu beheben ist. Ein ScrumBut behält das Problem bei, während er Scrum so modifiziert, dass es unsichtbar wird, so dass die Dysfunktion nicht mehr ein Dorn im Auge des Teams ist.
Ein ScrumBut hat eine bestimmte Syntax: (ScrumBut)(Grund)(Abhilfe)
Beispiele:
"(Wir verwenden Scrum, aber) (ein tägliches Scrum jeden Tag ist zu viel Aufwand,) (also haben wir nur eines pro Woche.)"
"(Wir benutzen Scrum, aber) (Retrospektiven sind Zeitverschwendung,) (also machen wir sie nicht.)"
"(Wir verwenden Scrum, aber) (wir können nicht ein Stück Funktionalität in einem Monat bauen,) (also sind unsere Sprints 6 Wochen lang.)"
"(Wir verwenden Scrum, aber) (manchmal geben uns unsere Manager spezielle Aufgaben,) (so haben wir nicht immer Zeit, unsere Definition of Done zu erfüllen.)"