Was Kanban alles kann

In unserer Betragsreihe zu den agilen Vorgehensmodellen haben wir Euch in unserem letzten Beitrag das Scrum Konzept vorgestellt und Euch erklärt was das Ganze mit Rugby zu tun hat. Ein weiteres gängiges Vorgehensmodell heißt Kanban. "Kan-was?" fragt Ihr euch jetzt sicher. Was das bedeutet, wo es herkommt und was es mit Softwareentwicklung zu tun hat erfahrt Ihr hier.

Was bedeutet "Kanban"?

Der Begriff "Kanban" kommt ursprünglich aus dem Japanischen und setzt sich aus den Wörtern Kan und Ban zusammen. Kan bedeutet so viel wie "visualisieren", Ban kann wiederum mit "Karte" oder "Schild" übersetzt werden. Der hiermit beschriebene Prozess geht auf Taiichi Onho zurück, der diesen erstmals bei dem Automobilkonzern Toyota umsetzte. Sein Ziel war es die Produktionsstraße zu optimieren und dazu orientierte er sich an dem Konzept amerikanischer Supermärkte, welche stets wenig Waren im Lager hatten und nur dann neue bestellten, wenn diese fast ausverkauft waren.

Kanban in der Softwareentwicklung

Jetzt fragt Ihr Euch sicher was das nun mit Softwareentwicklung zu tun hat. Da muss man ja keine Waren lagern, höchstens Daten. Bei der Anwendung des Kanban-Konzept geht es allerdings auch darum einen kontinuierlichen Arbeitsfortschritt zu erzielen. Diese Idee einer schrittweisen und regelmäßigen Produktion transferierte David J. Anderson 2007 auf die Softwareentwicklung. Hierzu postulierte er vier Prinzipien:

Fange mit dem an, was du gerade machst.
Strebe evolutionäre Verbesserungen an.
Nimm Rücksicht auf bestehende Prozesse, Rollen und Verantwortlichkeiten.
Versuche die Methode jedem zugänglich zu machen.

In der praktischen Umsetzung kommen hierbei sechs Methoden zum Einsatz:

1. Visualisierung der Arbeit:

Mithilfe eines Kanban Boards wie unten dargestellt werden einzelne Aufgaben in verschiedene Abschnitte unterteilt. Durch diese Darstellungsform werden Probleme sichtbar gemacht und das Team kann gemeinsam eine Lösung erarbeiten. Im Unterschied zu klassischen Arbeitsweisen, wird bei dieser Methode nach dem Pull-Prinzip gearbeitet. Das heißt, eine neue Aufgabe wird erst begonnen, wenn das jeweilige Teammitglied mit seiner vorherigen Aufgabe fertig ist. Ziel dieser Praktik ist es einen kontinuierlichen Arbeitsfluss zu gewährleisten und einen Mehrwert für den Kunden zu schaffen.

4. Prozessregeln explizit machen:

Regeln sollten in verständlicher Art und Weise festgehalten werden, um Probleme objektiv diskutieren zu können. Dies kann in Form von Definition of Done (DoD) erfolgen, welche gleichzeitig als visuelle Erinnerung an einer zentralen Stelle dienen können. Zudem weiß der Kunde so, welche Qualität er erwarten kann. Die Regeln sind allerdings nicht in Stein gemeißelt, sie können jederzeit auf Grundlage neuer Erkenntnisse durch das Team angepasst werden.