Wann Kanban eine Alternative zu Scrum ist

Seit vielen Jahren bin ich in Scrum-Projekten unterwegs,  dem aktuellen Standard in der Software-Entwicklung.

Dabei muss ich sagen, dass die „Reine Scrum Lehre“ in keinem Kundenunternehmen wirklich gelebt wird. Es gibt überall Anpassungen an das eigene Vorgehensmodell und an die Unternehmenskultur.

Kanban kenne ich schon seit vielen Jahren, als es für die Produktionsplanung bei einem Kunden eingeführt wurde. Damals wurde extra ein Trainer aus Japan eingeladen, damit das Know-how möglichst aus erster Hand stammte.
In einem Kundenprojekt habe ich jetzt die Kanban-Methode live erlebt.
Kanban wurde 1947 in Japan entwickelt.
Im Wesentlichen geht es um eine optimale Produktionssteuerung.
Die einzelnen Aufgaben / Tätigkeiten werden auf einer Karte notiert und dann auf den jeweiligen Produktionsschritt verschoben.

Die Anzahl der Karten pro Produktionsschritt ist begrenzt. Wenn die maximale Anzahl erreicht wird, darf keine weitere Karte in diesem Schritt platziert werden.
Dadurch entsteht natürlich ein Stau in den vorgeschalteten Produktionsschritten. Diese Mitarbeiter sind nun aufgerufen den Produktionsstau mit abzubauen, bis sie wieder neue Karten im geblockten Produktionsschritt platzieren dürfen.

Kanban in der Software-Entwicklung

Kanban in der Software-Entwicklung ist relativ leicht umsetzbar. Die einzelnen Prozessschritte sind oft bekannt, z. B.

  • Anforderungen
  • Anforderungsanalyse
  • Bereit zur Entwicklung
  • Entwicklung
  • QS
  • Fertig

Im Schritt Anforderungen werden die Kundenwünsche gesammelt. Sobald ein Businessanalyst oder Requirements-Engineer frei ist, nimmt er sich eine Karte aus dem Pool „Anforderungen“ und verschiebt sie nach „Anforderungsanalyse“. Dem WiP = Work in Progress wurde eine Karte hinzugefügt.

Bereits hier sollte man die Anzahl der in der Analysephase befindlichen Karten pro Analysten begrenzen, um einer Überlastung vorzubeugen und die Qualität zu gewährleisten.

Ist die Anforderungsphase beendet, wandert die Karte in den Prozessschritt „Bereit zur Entwicklung“.
Die einzelnen Anforderungen sind unterschiedlich priorisiert, was sich in ihrer vertikalen Position innerhalb der Spalte ausdrückt. Wichtige Features sind oben angeordnet.

Ist ein Entwickler mit seiner Arbeit fertig, nimmt er sich die nächste zu entwickelnde Funktion von oben aus dem Prozessschritt „Bereit zu Entwicklung“.
Nachdem die Entwicklung abgeschlossen ist, wandert die Karte mit der Anforderung in die Qualitätssicherung, usw.

In regelmäßigen Abständen – z. B. einmal pro Woche oder auch kontinuierlich – werden die fertigen Artefakte nach Produktion deployed.

Vorteile gegenüber Scrum

Das Vorgehen bei Scrum ist sehr ähnlich, unterscheidet sich aber an einem wichtigen Punkt: Bei Scrum gibt es zeitlich definierte Sprints, meistens von 2-3 Wochen.

Product-Owner versuchen oft so viele Features wie möglich in den nächsten Sprint zu platzieren. Projektleiter ohne das richtige Standing knicken dann ein und damit ist ein Sprint überladen.

Das Ergebnis ist, dass das Team mehr oder weniger unter Druck gesetzt wird, bzw. die einzelnen Entwickler sich selber unter Druck setzen, um die geplanten Funktionen im Sprint unterzubringen. Erfahrungsgemäß gibt es in jedem Sprint solche „dringenden“ Features, was zu einer dauerhaften Überlastung des Teams führen kann.

Mit Kanban umschifft man diese Klippe. Wenn die einzelnen Prozessschritte im Kanban-Board gut gefüllt sind, entsteht fast automatisch ein ruhiger, kontinuierlicher Wertschöpfungsprozess.

Neue Funktionen können problemlos jederzeit priorisiert werden, was bei Scrum nur vor dem Sprint-Start möglich ist, will man das Scrum-System nicht destabilisieren.

Damit die Projektleitung einen besseren Überblick über den Aufwand machen kann, der für jedes Feature entsteht, ist es sinnvoll eine ungefähre Aufwandsschätzung pro Funktion zusammen mit den Entwicklern durchzuführen.

Hier können schon vorab Fragen gestellt, und Meinungen der unterschiedlichen Fachleute eingeholt werden.

Dies ist besonders sinnvoll, wenn man mit verteilen Systemen, z. B. mit Microservices arbeitet und die geplante Funktion mehrere dieser Services betreffen.

Fazit

Das ganze Vorgehen klingt zunächst nicht wirklich spektakulär – und genau das ist der Vorteil dieser Arbeitsweise: Es ist ein unspektakulärer, kontinuierlicher Prozess, der eine Überlastung der Mitarbeiter verhindert.

Durch die gleichmäßige Fertigstellung von Programm-Features eignet sich die Methode auch sehr gut für das Continous-Delivery.

Gerne beraten wir Sie über die Möglichkeiten von Kanban in Software-Entwicklungsprozessen. info@rockingbit.com

Hier noch eine Buchempfehlung für alle, die gerne tiefer in die Thematik einsteigen möchten:

http://www.hanser-fachbuch.de/buch/Kanban+in+der+IT/9783446438262

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s