Nach Scrum kommt nun Kanban

Wenn erwachsene Menschen Kärtchen mit Strichmännchen oder Smilies verzieren und an Wandtafeln befestigen, ist häufig Kanban im Spiel. Das aus der japanischen Automobilindustrie stammende Vorgehensmodell zieht längst auch in IT-Operations und Softwareentwicklung ein. [...]

SCRUM ALS EINSTIEGSDROGE
Wie Kaak setzt auch Michael Maretzke, CTO des Online-Dating-Portals „FriendScout24“, neuerdings Teil des europäischen Marktführers Meetic Group, auf Kanban. Allerdings nur in der Softwareentwicklung. „Im Operations-Bereich ist das extrem schwierig“, sagt Maretzke. Die Entwickler hätten mittlerweile ein anderes Verständnis von ihrer Rolle: „Das Berufsbild hat sich um 180 Grad gedreht; als Entwickler muss man heute ein kommunikatives Wesen sein, weil man sonst nicht mit den Fachbereichen reden kann.“ In Operations sei das Berufsbild noch traditioneller. Dort treffe man oft Menschen an, die eher introvertiert agierten und weniger kommunikativ seien

Außerdem gibt es in der Softwareentwicklung einen eklatanten Bedarf für neue Methoden. „Die Wasserfall-Entwicklung kommt oft zu spät mit Ergebnissen“, hat der FriendScout24-CTO festgestellt. Eine schnelllebige Web-Plattform müsse sich innerhalb von Tagen ändern oder weiterentwickeln lassen. Die „Scrum“Methode ist aus Maretzkes Sicht die ideale „Einstiegsdroge“ in das Thema Agilität. Hier gebe es immer noch ein Gerüst von Regeln, und seien es nur die „Planning“-, „Estimation“- oder die täglichen „Standup“- Meetings. Das Entwicklerteam übernehme zwar Eigenverantwortung, wie in der agilen Softwareentwicklung ja gewünscht, aber es praktiziere sie innerhalb eines Rahmenwerks.

PRAKTIKABLER KOMPROMISS: SCRUMBAN
Maretzke und sein 20-köpfiges Team sind schon einen Schritt weiter. Sie machen, wie der CTO sagt, „Scrumban“: Sie nutzen die Kanban-Tafeln und „Task-Zettel“, haben aber einen eigenen Satz Regeln vereinbart, an die sich alle halten. Dazu gehören unter anderem die regelmäßigen Meetings. Wie die Teams ihre Boards aufbauen, ist hingegen unterschiedlich. Selbstverständlich folgen alle dem Muster: To do – Doing – Done, aber „Doing“ kann durchaus mehrere Phasen haben. Der „Agile Coach“, den FriendScout24 als Position etabliert hat, konsolidiert die Boards wöchentlich in einem „Company Board“, das öffentlich einsehbar ist.

Bei FriendScout24 sollen alle Entwicklungsaufgaben möglichst in einem Tag von „To do“ bis „Done“ vordringen. Größere Themen („Stories“) müssen auf kleine Tasks heruntergebrochen werden. Die Teams unterteilen die Stories in Aufgaben, die jeweils von einer Person abgedeckt werden können. Mehr als drei Zettel gleichzeitig sollte niemand auf dem Board haben. So bleiben Abhängigkeiten erkennbar, Ineffizienzen werden offenbar, Hindernisse lassen sich leichter identifizieren und beseitigen, so dass der erwünschte „Flow“ entsteht.

MIT 60 STUNDENKILOMETERN SCHNELLER ANS ZIEL
Um dieses kontinuierliche Fließen zu gewährleisten, nimmt Blizzard-CIO Kaak bisweilen sogar Leerlauf an einer Arbeitsstation in Kauf. „Manchmal kann ein Mitarbeiter kein neues Ticket öffnen, weil die nachfolgenden Stationen ihre Tickets noch nicht abgearbeitet haben“, erläutert er. Warum hundertprozentige Auslastung keineswegs optimal ist, verdeutlich der IT-Chef am Beispiel der Tauern-Autobahn: Sie führte früher zweispurig auf den Tauerntunnel zu, in dem der Verkehr aber nur einspurig floss. Wenn nun die Autos mit 120 Stundenkilometern auf den Tunneleingang zurasten, bildete sich am Eingang oft ein kilometerlanger Rückstau. Hätten sich alle von Anfang an auf eine optimal berechnete Geschwindigkeit geeinigt, vielleicht 60 Stundenkilometer, wären alle eher angekommen.

Was auf der Autobahn meistens nicht funktioniert, lässt sich im Arbeitsumfeld durchsetzen. „Das erfordert selbstverständlich ein Umdenken“, räumt Kaak ein, „weil es ja immer hieß, wir müssen die Leute auslasten.“ Doch um Rückstaus zu vermeiden, müsse sich ab und an ein Mitarbeiter mit anderem beschäftigen, so die Überzeugung des IT-Verantwortlichen:

„Entweder er hilft einem Kollegen, oder er dokumentiert den Engpass, damit andere daraus lernen können, oder – wenn die Ursache schon bekannt ist – er arbeitet an der Optimierung des Gesamtsystems. Und manchmal sage ich ihm sogar, er solle nach Hause gehen und ein Fachbuch lesen. Denn durch Lernen erhöhe ich die Kapazität ebenfalls.“

WAS TUN, WENN SICH DER FLUSS STAUT?
Bildet sich trotz ausreichend kleiner Skalierung und strikter Begrenzung des Work in Progress doch mal ein Rückstau, muss das Team entscheiden, was zu tun ist: Darf und soll die Aufgabe fallen gelassen werden, oder gibt es eine alternative Lösung? Muss man sie noch einmal unterteilen? Sind mehr Mitarbeiter für diese Aufgabe notwendig? Letzteres ist laut Kaak selten eine gute Idee. Schon Fred Brooks habe in „The Mythical Man-Month“ nachgewiesen, dass mehr Leute im Projekt auch mehr Reibungsverluste bedeuten.

Als praktikable Lösung sieht der Blizzard-CIO hingegen die Automatisierung bestimmter Prozesse und – einmal mehr – die bessere Qualifizierung der Mitarbeiter. „Lean bedeutet ja nicht, dass das Unternehmen Kosten um jeden Preis spart, sondern dass die Organisation in der Lage ist, sich kontinuierlich zu verbessern.“ Kanban sei quasi die organisatorische Umsetzung des japanischen „Kaizen“-Prinzips (das so viel wie „kontinuierliche Verbesserung“ bedeutet).

SOFTWARE-KANBAN NACH DAVID ANDERSON
Eines der Grundprinzipien von Kanban lautet: Der Arbeitsfluss wird sichtbar. Auf dem Kanban-Board lässt sich die gesamte Wertschöpfungskette mit ihren Prozessschritten für alle Beteiligten visualisieren. Die Menge der angefangenen Arbeit („Tickets“) ist begrenzt. In einem Kanban-System wird die Arbeit nach dem Pull-Prinzip verteilt: Anstatt fertige Aufgaben an die nächste Station zu übergeben, holt sich diese aktiv das nächste Ticket, sobald sie Kapazität frei hat. Und das ist nur der Fall, solange sie eine definierte Maximalzahl paralleler Aufgaben nicht überschritten hat. Der Durchfluss wird gemessen und gesteuert.

Typische Mess- größen sind die Länge von Warteschlangen, die Zykluszeit und der Durchsatz. Die Mitglieder des Prozesses messen und melden diese Werte. So wird ein etwaiger Verbesserungsbedarf erkennbar –und die Planung erleichtert. Alle Regeln für den Prozess sind für alle Beteiligten explizit; dazu gehört beispielsweise eine Definition von „fertig“. Jeder fühlt sich für den Erfolg verantwortlich: Nur wenn sich alle Ebenen der Organisation beteiligen, lassen sich tatsächlich Verbesserungen erzielen.

KANBAN DIGITAL – NUR IM NOTFALL?
Seit dem Buch von Anderson hat sich einiges getan. Mittlerweile gibt es eine ganze Reihe von Softwarewerkzeugen, die sich anheischig machen, die „Zettelwirtschaft“ abzulösen. Dazu zählen beispielsweise „Jira“, „LeanKit“, „Kanbanery“ oder „Projectplace“. Kaak sieht darin nicht unbedingt einen Fortschritt. Nur bei unternehmensübergreifenden und geografisch verteilten Projekten, beispielsweise der gruppenweiten ERP-Einführung, sei der Einsatz eines solchen Tools sinnvoll.

In den meisten Fällen bringe ein physisches Board jedoch mehr, beteuert der Blizzard-CIO: „In den ersten sechs Monaten habe ich meinen Mitarbeitern untersagt, nach einem Tool zu suchen. Wir wollten ja erst mal schauen, ob das überhaupt funktioniert. Und dann haben die Leute gesehen, wie gut es ist, tatsächlich vor einem Board zu stehen und zu diskutieren.“ Danach sei Softwareunterstützung kein Thema mehr gewesen. Einem digitalen Tool fehlten die Haptik und der kommunikative Faktor.

Auch bei FriendScout24 schätzen die Mitarbeiter die physischen Boards, die sie phantasievoll ausgestalten – teilweise mit Avataren und verdeutlichenden Graffiti. Aber die Methode lässt sich ja auch für externe Mitarbeiter nutzen, beispielsweise im Nearshore-Bereich. Für sie greift FriendScout24 auf eine Software zu, die Kanban-Abläufe abbilden kann: Jira mit dem Add-on „Agile“ (ehemals „Greenhopper“). Wie Maretzke einräumt, ist das Tool „nahe am Original, aber lange nicht so kommunikativ“.