2
7

Kanban als agile Methode in einer Agentur.

5.1.2015

Agile Methoden sind heute in aller Munde. „Agil“ wird oft auch als Synonym zu „gut“ verwendet. Agile Methoden sind zwar kein Allerheilmittel sie können aber – richtig eingesetzt – gute Dienste leisten. Vor 2 Jahren haben wir angefangen Kanban als agile Methode in allen Fachteams innerhalb der MySign einzuführen. Inzwischen haben wir sehr viel Erfahrung gesammelt und setzen Kanban, auf eine interdisziplinäre E-Commerce-Agentur adaptiert, erfolgreich ein.

Gerade bei komplexen Webprojekten wie E-Commerce-Plattformen stossen klassische Methoden wie die Wasserfallmethode (zuerst spezifizieren dann umsetzen, testen und in Betrieb nehmen) sehr rasch an ihre Grenzen. Der Grund dafür ist relativ einfach: Es lässt sich bei solchen Projekten vor Projektstart nie eine 100%-ige Spezifikation schreiben. Die Anforderungen ändern sich häufig während der Umsetzung des Projektes und neue bisher nicht beachtete Aspekte kommen hinzu – das Projekt ist einem kontinuierlichen Wandel unterworfen und ein gutes Projektmanagement ist hier unabdingbar für ein erfolgreiches Projekt das pünktlich fertiggestellt wird.

Ein weiterer Aspekt der die Komplexität erhöht ist der Bedarf an ganz unterschiedlichen Kompetenzen. Das Beispiel eines Onlineshops demonstriert dies sehr gut: Hier sind neben Software- und Frontend-Entwicklern, auch Designer, Usability-Spezialisten, Marketing-Fachleute, Suchmaschinen-Experten und nicht zuletzt auch Personen mit Logistik- und Prozess-Know-How gefragt. Eine bunte Palette von unterschiedlichsten Spezialisten die zusammen ein Projekt umsetzen welches zu Beginn nicht ganz genau definiert werden kann.

Veränderungen im laufenden Projekt miteinbeziehen

Hier setzen agile Methoden an und versuchen die laufende Veränderung der Anforderungen mit in den Prozess aufzunehmen. Einer der 4 wichtigsten Punkte des agilen Manifest, welches die Grundlage aller agilen Methoden ist, lautet dann auch „Das Eingehen auf Veränderungen ist wichtiger als das Festhalten an einem Plan“. Es gibt unterdessen einige agile Methoden die eine gewisse Verbreitung gefunden haben. Dazu gehören unter anderem Scrum, Extreme Programming, Kanban, Behavour Driven Development, Crystal und andere. Kanban nimmt hier eine besondere Stellung ein, da es nicht wie Scrum einen kompletten Projektmanagement-Prozess mit allen Details definiert, sondern nur ein paar einfache Regeln vorgibt wie die Arbeit in einem Projekt abgearbeitet werden soll.

Wie funktioniert Kanban

Kanban ist in seiner Grundstruktur tatsächlich so einfach, dass es in ein paar Sätzen erklärt ist: Es gibt pro (Fach-)Team eine Pipeline (in Kanban oft auch Swimlane genannt). In diese Pipeline werden die Arbeitspakete eines Projektes nach Priorität geordnet gefüllt. Jedes Team-Mitglied nimmt nun aus dieser Pipeline jeweils dasjenige Arbeitspaket, das zuoberst ist und hat nun die Aufgabe dieses Arbeitspaket komplett zu erledigen bevor eine neue Arbeit begonnen wird. Die Arbeit wird je nach Fachteam in verschiedene Arbeitsschritte eingeteilt. Bei Softwareentwicklung können diese Schritte bspw. aus Analyse, Konzept, Review, Implementation und Testing bestehen. Die Pipeline mit den Arbeitspaketen die warten und denjenigen die in Arbeit sind, werden auf einem Board visualisiert.

Kanban Board

Kann jemand eine angefangene Arbeit nicht zu Ende bringen, weil z.B. Angaben fehlen, so wird das Arbeitspaket als „blockiert“ markiert und ein neues Arbeitspaket wird aus der Pipeline genommen.

Kaizen – die stetige Verbesserung

Eine weitere Regel besagt nun aber, dass immer nur eine ganz bestimmte Anzahl von Arbeitspaketen in Arbeit sein darf. Ist dieses sogenannte WIP-Limit (Work-In-Progress-Limit) erreicht, so hat das Teammitglied, welches nun keine weitere Arbeit aus der Pipeline mehr nehmen darf, eine ganz besondere Aufgabe: Es gilt herauszufinden, warum Arbeitspakete die in Arbeit gegangen sind blockiert wurden und wie diese Blockaden in Zukunft verhindert werden können. Das erscheint im ersten Augenblick nicht sehr verständlich, ist doch genau in diesem Zeitpunkt, in welchem viele Arbeiten blockiert sind, der Druck im Projekt sehr hoch und man sollte auf jeden Fall weiterarbeiten. Wie oft hat man während eines Projektes in einer solchen heissen Phase schon den Ausspruch gehört „Das müssen wir dann nach Projektabschluss analysieren und nächstes Mal besser machen“? Meist kommt es nicht dazu oder man kann die genauen Gründe im Nachhinein nicht mehr genau eruieren. Genau hier setzt Kanban an, indem es das Projektteam zwingt die Probleme sofort anzugehen und nicht aufzuschieben. Erstens ist es einfacher die genauen Gründe für einen Missstand im Moment des Auftauchens zu finden und zweitens kann die gefundene Verbesserung schon im laufenden Projekt helfen oder zumindest getestet werden. Dieser Teil in Kanban wird Kaizen genannt. Diese stetige Verbesserung kann im Team weiter gefördert werden, indem immer wieder Review-Meetings abgehalten werden, die einzig zum Ziel haben sich weiter zu verbessern.

Stolperstein „Gut gemeint“

Hier sind wir aber bereits auch bei einem heiklen Punkt in der Umsetzung. Die Gründe, warum ein Teammitglied in einer Situation zu vieler blockierter Aufgaben sich die Zeit nehmen soll, den Ursprung des Problems zu finden und nicht wie üblich am Projekt weiter zu arbeiten, müssen dem gesamten Team genau erklärt werden. Das Gefühl, dass es für das Unternehmen und das Projekt besser ist, in diesem Moment weiterzuarbeiten, ist zwar natürlich entspringt aber einer sehr sehr kurzfristigen Sicht. Allzu oft wählt hier das Teammitglied den falschen Weg, vielfach auch auf Anweisung des Managements – notabene desselben Managements das Kanban eingeführt hat.

Arbeit im Fluss

Warum aber definiert Kanban, dass eine angefangene Arbeit zu Ende gebracht werden soll und wie soll das die Projektarbeit verbessern? Der absolute grösste Effizienz-Hemmer unserer Zeit ist die Unterbrechung. Wir haben heute kaum mehr unterbrechungsfreie Zeit beim Arbeiten: Das Telefon klingelt, es kommt gerade ein E-Mail herein, eine WhatsUp-Nachricht, ein Skype-Call, wir erhalten eine Nachricht aus irgendeinem Social-Media-Kanal oder jemand kommt ins Büro und hat eine Frage zu irgendeinem Projekt. In jeder dieser Situationen werden wir bei dem was wir gerade tun unterbrochen und es kostet uns, je nachdem wie komplex die Aufgabe ist an der wir gerade arbeiten, einige Zeit bis wir nur wieder an dem Punkt sind, an dem wir vor der Unterbrechung waren. Angenommen es kostet uns nur 5 Minuten bis wir wieder in der Aufgabe „drin“ sind. Angenommen wir erhalten 25 E-Mails am Tag, 5 Telefonanrufe und noch 5 andere Nachrichten aus Social-Media-Kanälen und werden 10 Mal am Tag etwas gefragt. Die Rechnung ist relativ einfach: Wir verlieren so am Tag 45 Mal 5 Minuten, was fast 4 Stunden Arbeitszeit entspricht. Kanban versucht dieses sogenannte „Kontext-Switching“ zumindest bei den eigentlichen Aufgaben zu verhindern indem nicht parallel an verschiedenen Dingen gearbeitet werden darf. Durch das WIP-Limit wird auf dem Kanban-Board sehr rasch visualisiert, wenn dieses trotzdem stattfindet (zu viele blockierte Tasks) und Kanban schreibt auch gleich vor, dass Lösungen gefunden werden müssen um dies zu verhindern. Natürlich ist es sinnvoll dieses Kontext-Switching auch im kleinen zu verhindern, indem z.B. das Mailprogramm nicht stetig geöffnet ist während dem Arbeiten und E-Mails zu bestimmten Zeiten bewusst abgerufen werden.

Besser Ressourcen-Planung

Eine statische Ressourcen-Planung zu Beginn eines Projektes bildet zwangsläufig nicht die ganze Wahrheit ab, wenn sich das Projekt während des Verlaufs ändert. Kanban bietet hier eine sehr einfach aber umso effektivere Möglichkeit an, die Ressourcenplanung trotz ständigem Wechsel zu visualisieren und immer den jetzigen Zeitpunkt der Planung anzuzeigen. Die Aufgaben die in eine Pipeline gestellt werden, werden alle mit einer ungefähren Grösse versehen. Dies muss keine genaue Zeitangabe sein, T-Shirt-Grössen wie XS, S, M, L und XL sind besser geeignet. Aus den anstehenden Aufgaben in der Pipeline und in dem jeweiligen Team verfügbaren Ressourcen kann dann das System ungefähr berechnen, wann welche Arbeiten erledigt sein werden. Ändern die Prioritäten oder kommen Aufgaben hinzu, so zeigt dieses System sehr rasch die Auswirkungen auf den globalen Terminplan. Hilfreich ist dies vor allem wenn viele Projekte parallel durch verschiedene Teams laufen, hier scheitert eine konventionelle Terminplanung kläglich. Kanban im Gegensatz dazu zeigt stetig die aktuelle Voraussage an.

Kanban als Fieber-Thermometer

Kanban ist wie schon oben erwähnt im Gegensatz z.B. zu Scrum kein Projektmanagement-Prozess. Dieser Umstand ist sehr wichtig. Kanban gibt keinerlei Regeln vor, wie ein Projekt organisiert werden soll. Es macht keine Vorgaben darüber ob und wie ein Projekt spezifiziert werden soll, wie die Iterationen aussehen oder wie das Projektteam zusammengesetzt werden soll. Wozu dann Kanban? Kanban lässt sich gut mit einem Fieber-Thermometer vergleichen: Kanban misst, ob es dem Patienten gut geht oder ob er bereits Fieber hat. Sind zu viele Arbeiten blockiert (meist mit roten Zetteln auf dem Board markiert) oder gehen die Arbeiten nur langsam voran, so zeigt Kanban „Fieber“ an. Interessant daran ist, dass dieses Fieber-Thermometer sehr rasch anschlägt, meist schon bevor das Projektteam das Gefühl hat, dass etwas nicht optimal läuft. Und genau hier liegt die grosse Stärke von Kanban: Es führt dazu, dass Prozesse die Schwächen haben, sich laufend verbessern – immer vorausgesetzt Kanban wird intern richtig verstanden.

Kanban richtig verstehen

Eine Reaktion auf ein erreichtes WIP-Limit und blockierte Prozesse kann auch sein, dass das Projektteam fälschlicherweise Kanban als Grund des Übels ansieht und die wenigen Regeln die Kanban vorgibt mit kreativen neuen Regeln ab absurdum führt. Im übertragenen Sinn würde man anstatt den eigentlichen Grund zu beseitigen einfach die Skala des Fieber-Thermometers verschieben und 39 Grad Fieber werden dann als 36.5 Grad angezeigt. Ein Beispiel hierfür ist die Abschaffung des WIP-Limits. Dies verhindert dann tatsächlich Blockaden, weil es keine Regel mehr gibt, die verhindert, dass weitergearbeitet werden darf. Dies ist aber reine Symptombekämpfung und führt nicht zu einer Verbesserung im Projekt-Prozess. Es ist etwa so, wie wenn man bei Fieber einen Fiebersenker geschluckt hat – gesünder ist man deshalb noch nicht.

Das kann passieren, wenn Kanban als Projektmanagement-Prozess und eben nicht als Messinstrument des eigentlichen Prozesses angesehen wird. Jeder im Projektteam muss genau verstehen, dass Kanban hier nur das Messinstrument – eben das Fieber-Thermometer – und nicht der Prozess selbst ist.

Fazit

Bei einer erfolgreichen Einführung von Kanban darf man folgende Verbesserungen erwarten:

  • Verhinderung von unnötigem Kontext-Switching
  • Missstände werden rasch aufgezeigt (Fieber-Thermometer)
  • Aktuelle Ressourcenplanung bei parallel laufenden Projekten immer ersichtlich

Obwohl die Grundregeln von Kanban rasch erklärt sind und meist auch einfach in bestehende Strukturen und Prozesse eingeführt werden können, ist es enorm wichtig, dass alle Beteiligten nicht nur die Regeln kennen, sondern die genauen Hintergründe dazu. Weiter ist es wichtig, dass neben Kanban bereits ein Projektmanagement-Prozess besteht oder ein solcher zusammen mit Kanban eingeführt wird.

Insbesondere wenn viele unterschiedliche Projekte mit interdisziplinären Projektteams parallel durchgeführt werden, kann Kanban gute Dienste leisten.

Auch erschienen im M&K.

Google+ 5 Facebook 0 Twitter 0 Pinterest 0

Kategorisiert in:

2
7
  • Pingback: Weekend Reader Woche 2 - Philip Büchler()

  • Aktuell befasse ich mich mit Scrum und kenne Kanban ja noch von früher. Scrum ist „nur“ ein Framework, allerdings mit, meiner Meinung nach, sehr nützlichen Elementen. Wirklich spannend finde ich, wenn sich Kanban und Scrum gegenseitig unterstützen. Vieles was bei Kanban optional ist, wird mit Scrum besser definiert, ein Kanban-Board wiederum kann besser visualisieren. Kanban hat eine WIP-Limite, bei Scrum wird diese mit dem Backlog quasi vom Team bereits definiert. Die Iterationen bei Scrum helfen auch die Stakeholder regelmässig abzuholen und so auch eine nähe zum Team zu schaffen.

    Lange Rede kurzer Sinn, Scrum ist nicht wirklich ein „kompletter Projektmanagement-Prozess mit allen Details“. Am Ende des Tages ist es „nur“ ein Tool und wir keine Sklaven. Für mich ist die Kombination aus Scrum und Kanban die wohl perfekte Lösung.