https://admin.intention.de/wp-content/uploads/2020/11/iStock-1199291049_20202213_Blog-1500x680.jpg

AndreyPopov / iStock

Im Dialog

Aufbruch in die Agilität – Teil 4: 1 Jahr Kanban

Swimlanes, WIP-Limits, Pull-Prinzip, Impediments, Flight Level, Parkplatz, Backlog und Done. Wie passt das alles zusammen und welche Funktion hat das alles? Mit dieser und ganz vielen weiteren Fragen sind wir im Sommer 2019 in das Seminar „Kanban“ von Klaus Leopold gestartet. Nun ist ein gutes Jahr rum – die Boards haben sich mittlerweile immer wieder verändert und es ist Zeit für ein erstes Fazit. Was kann Kanban oder was kann Kanban nicht?

Warum Kanban?

Auf unserem Weg in die Agilität stand nicht nur das Bilden interdisziplinärer Teams auf dem Plan, auch die Einführung von Dailys und weiteren agilen Elementen haben die Agentur innerhalb eines Jahres ganz schön auf den Kopf gestellt.

Davon hast du noch nichts gehört? Dann lies dir auch unsere anderen Beiträge zum Thema „Aufbruch in die Agilität“ durch:

Ebenfalls mit zu den neuen Tools gehören unsere Kanbanboards. Das Ziel: Arbeit sichtbar machen. Das klingt erstmal sehr banal, ist jedoch sehr interessant und hilfreich, wenn man die Maxime „stop starting, start finishing“ dazu nimmt: Aufgaben im System werden erst zum Abschluss gebracht, bevor neue Aufgaben begonnen werden. So wollen wir Task-Switching vermeiden und uns auf das konzentrieren, was aktuell im System ist.

Arbeit sichtbar machen

Jeder hat da so seine Methoden: Manche schreiben sich eine To-Do-Liste, andere Kalendereinträge und wieder andere Post-Its. Aber alle haben eins gemeinsam – es gibt keine zentrale Übersicht und die To-Dos beziehen sich in aller Regel nur auf das eigene Aufgabengebiet.

Die Kanbanboards sind also nicht nur der zentrale Ort, an dem die Teams sehen, welche Projekte aktuell bearbeitet werden, sondern auch, wo sie sich im Prozess gerade befinden. Darüber kann jedes einzelne Teammitglied abschätzen, wann er oder sie das Projekt wohl bearbeiten kann bzw. wie viel für ihn/sie in der nächsten Zeit zu erwarten ist.

Neben dem Prozess, den ein jedes Projekt durchläuft, gibt das Board auch Aufschluss darüber, welche Projekte sich gerade in der Planung befinden oder welche proaktiven Initiativen es gibt, die potenziell zu Aufgaben im System führen könnten. Somit ist für das Dev-Team transparent, welche Optionen und welche Themen den PO beschäftigen. Und das bietet die Möglichkeit, sich einzubringen, auch wenn das Projekt noch nicht spruchreif ist.

WIP-Limits

Mit „Arbeit sichtbar machen“ ist es aber nicht getan. Nur wenn die Anzahl der Aufgaben limitiert wird, können die einzelnen Aufgaben schneller fertiggestellt werden. Warum? Weil wir uns so genau auf die Menge an Aufgaben konzentrieren, die das Team auch maximal bearbeiten kann. Das kann dazu führen, dass Aufgaben manchmal etwas länger im Backlog warten müssen, um dann mit voller Kraft zügig durchgezogen werden zu können. Und weil die Arbeit daran fokussierter und konzentrierter erfolgt, sind die Ergebnisse ausgereift und doch schneller fertig, als wenn man Task-Switching zwischen den Projekten betrieben hätte.

So ist zumindest der theoretische Plan. Aber wie bei jedem theoretischen Konstrukt, kommt die Wirklichkeit dazu – und wir stehen Herausforderungen gegenüber, zu denen ein Buch keine Lösung parat hat.

WIP-Limits einzusetzen und vor allem einzuhalten erfordert eine große Disziplin. Zu groß ist die Versuchung, einfach noch ein Ticket zu ziehen und die Limits damit zu reißen. Ein Lösungsansatz: eine Fast Lane für „Feuerwehr“-Projekte. Wenn erforderlich, wird das Ticket dort platziert und alles andere muss warten, bis das Ticket erledigt ist. Das ganze Team hat dann die Aufgabe, mit vereinten Mitteln die Aufgabe zu erledigen.

Ebenfalls sehr hilfreich ist es, sich wirklich bewusst zu machen, an welchen Tickets tagesaktuell aktiv gearbeitet wird. Dann stellt man häufig fest, dass am Tag nicht zehn Tickets aktiv bearbeitet werden, sondern vielleicht drei bis fünf – wenn es hochkommt.

Ein weiterer Aspekt: die WIP-Limits betrachten nur das „Was“ im Prozess, nicht jedoch das „Wer“. Ist das WIP-Limit also schon voll, mit z. B. drei Text-Aufgaben, sagt das nichts darüber aus, ob nicht die Grafik noch die Möglichkeit hätte, Tickets zu bearbeiten. Daher arbeiten wir an Lösungen, die Limits pro Chapter oder pro Kopf festlegen. Das ersetzt aber nicht die eigene Einschätzung, ob man noch ein Ticket übernehmen kann oder nicht.

Bei allen Regeln in der Agilität ist es doch enorm wichtig, auch genau das zu sein: agil.

Externe Faktoren

Grundsätzlich möchten wir Arbeit sichtbar machen: Die, die gegenwärtig ist und die, die auf uns zukommt. Aber wie verhält sich das mit Arbeiten, die nicht bei uns stattfinden? Das typische Beispiel: Gestaltung und Text gehen an den Kunden zur Abstimmung. Den Zeitraum, den der Kunde dafür braucht, können wir in einem Timing zwar definieren, doch wie in jedem Unternehmen läuft sicherlich auch dort nicht immer alles so, wie man es geplant hat. Dann befindet sich ein Ticket länger als geplant in „aktiv“ aber eben nicht bei uns, sondern „extern“. Auch dieser Aspekt beeinflusst in der Theorie das WIP-Limit und würde somit weitere Tickets blockieren. Unser Ansatz: Wir limitieren nur, was wir steuern und beeinflussen können – und das ist die Arbeit, die bei uns liegt.

Aber auch „verspätete“ Tickets haben einen positiven Effekt. Wenn etwas nicht wie geplant zurückkommt, sind bei uns kurzfristig Kapazitäten frei, die dann z. B. für Eil-Projekte genutzt werden können oder, um andere Dinge schon weiter voranzutreiben.

Arbeit fertig machen

Arbeit sichtbar machen ist das eine Ziel, das andere: Arbeit, die begonnen wird, muss auch zu Ende gebracht werden: „Start finishing!“

Eine Aufgabe sollte daher immer nach dem gleichen Prinzip begonnen und weitergeführt werden: Man zieht sich eigentständig die Aufgabe, anstatt von anderen den Tisch vollgelegt zu bekommen. Schnell mussten wir feststellen, dass das Pull-Prinzip bei uns in dieser Weise nur schwer umsetzbar ist.

Oft wird bei Kanban das eigene mit einem IT-Unternehmen verglichen. Dort kann man davon ausgehen, dass jeder Mitarbeiter des Dev-Teams quasi jede Aufgabe übernehmen kann, weil die Fähigkeiten ähnlich sind. Unsere Gewerke sind aber so unterschiedlich, dass sich das nur eingeschränkt verwirklichen lässt.

Unsere Interpretation ist daher: Man hilft, wo man kann. Man versucht sich in neuen Dingen, versucht zuzuarbeiten oder vorzubereiten, damit der Teamkollege dann schneller und leichter vorankommt. Allerdings ohne Anspruch darauf, die Aufgabe so perfekt lösen zu können, wie ein Experte in dem jeweiligen Gebiet. Und das bietet gleichzeitig die Möglichkeit, sich auch mit eher fachfremden Themen auseinanderzusetzen.

Natürlich spielt auch hier wieder das Thema Eil-Projekte eine wichtige Rolle. Kurzfristige Änderungen gehören zum Daily Business. Da ist dann wenig Platz für „Wer möchte sich den Job ziehen?“ Was aber vielleicht sehr hart rüberkommt, fühlt sich in der Praxis anders an. Kommt ein solcher Job rein, wird gemeinsam das Team mobilisiert: Wer braucht was, wer kann wen entlasten, indem er andere Dinge übernimmt? Die dabei entstehende Dynamik stärkt das Team und man hat nicht das Gefühl, alleine vor dem Problem zu stehen. Für mich als Product Owner ist das ein großer Pluspunkt.

Trotzdem versuchen wir das Pull-Prinzip anzuwenden, wenn auch nicht auf dem Team-Board, sondern auf einem agenturweiten Board. Kommen Neukunden-Anfragen rein, dann kann sich jedes Team melden, das daran arbeiten möchte. So hat man die Möglichkeit, sich die Themen und Aufgaben zu ziehen, die einem besonders liegen oder einen besonders interessieren. Diese Version des Pull-Prinzips ist dabei viel weitreichender und langfristiger angelegt: Jemand, der an etwas arbeitet, das ihm Spaß macht, dem geht die Arbeit viel leichter und besser von der Hand. Kurzum – es motiviert. Und ist ein neuer Kunde einem Team zugeordnet, so hat er dort auch zukünftig seine Heimat.

Kanban – ja oder nein?

Zum Schluss will ich ein erstes Fazit wagen, eine abschließende Beurteilung ist aber noch zu viel erwartet. Einfach weil Kanban auch etwas ist, das sich immer weiterentwickelt und in drei Monaten oder Wochen vielleicht schon wieder neue Erkenntnisse bringt.

Natürlich lässt sich nicht alles wie im Lehrbuch anwenden, ständig stehen wir neuen Herausforderungen gegenüber, die wir für uns analysieren und meistern müssen. Aber hier Wege zu finden die Regeln für uns zu biegen, ist eine spannende Aufgabe. Vor allem, wenn man sieht, was das für Auswirkungen auf Team-Dynamik und Arbeitsabläufe hat.

Ich bin der Meinung, dass es uns schon jetzt enorm viel gebracht hat: Das Team und auch der PO hat jederzeit einen Überblick, wie viel Arbeit da ist und wer woran arbeitet – man funktioniert zusammen und nicht jeder für sich. Es wird auch schneller deutlich (und zwar jedem), wenn Engpässe entstehen und das Team oder auch ein Team-Mitglied Hilfe braucht. Außerdem kann das Team sich auch selbst organisieren, sollten alle POs, aus welchen Gründen auch immer, nicht da sein. Und die Öffnung der Aufgaben bedeutet genauso, dass die Kollegen z. B. auch in den direkten Kundenkontakt gehen, um Probleme zu lösen oder Tickets voran zu bringen.

Kurz gesagt: Kanban? Ja!

intention Werbeagentur Bonn

Anna Müller
0228 97734-285
anna_mueller(at)intention.de

Consultant