Nach Scrum kommt nun Kanban

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."