Ja, Pots-Its mit Smilies auf Wandtafeln haben etwas mit Kanban zu tun. ;) Das aus der japanischen Automobilindustrie stammende Vorgehensmodell ist schon längst in der IT und Softwareentwicklung eingezogen. Warum Kanban das Potential hat Scrum abzulösen, versuchen wir im folgenden Beitrag zu klären.
Zwei grundsätzliche Gedanken: Viele Fertigungsprozesse in Produktionsbetrieben funktionieren heute nahezu perfekt. Und egal welche Branche, ein jedes Unternehmen ist schon irgendwie von einer IT abhängig. Und genau dort sieht die Welt noch anders aus. Bloß wieso? Am System selbst kann es kaum liegen, da laut aktueller Umfrage der Statistik Austria (u.a. IKT-Einsatz in Unternehmen 2014) diese am aktuellen Stand der Technik sind. Ergo muss es in den Prozessen und Abläufen haken.
Eine typische IT-Truppe ist fünf- bis siebenköpfig (3-5 Entwickler und 2 Operations-Spezialisten) und wird täglich mit mehr Change Requests bombardiert, als diese bearbeiten können. Vor allem weil alles sofort passieren muss und am besten schon gestern fertig hätte sein sollen, um die internen Kunden zufriedenzustellen. Aus diesen und anderen Gründen lässt sich halt vieles von dem, was einst begonnen wurde, nie beenden. Fazit: Die Flut der Anforderungen, die ständig über die IT hereinbricht, ist mit vertrauten, althergebrachten Verfahren nicht mehr zu bewältigen.
Ein Blick in die Fertigungsprozesse kann dabei helfen. Denn dort findet man schon fast überall die “Prinzipien der möglichst verschwendungsfreien und aus sich selbst lernenden Produktion” oder kurz Lean Production. Und genau das ist Kanban: die Übertragung dieser agilen Prinzipien auf die Arbeiten im IT-Bereich.
Lean Production in der IT
Befasst man sich mit der Lean Production und der IT stößt man frühzeitig auf das Standardwerk von David J. Anderson “Evolutionäres Change Management für IT-Organisationen”. Dabei gelangt man rasch an eine erste Lösung: Nicht mehr alles gleichzeitig beginnen, sondern selektieren und priorisieren um danach unterbrechungsfrei abzuarbeiten (man spricht dabei vom One Piece Flow).
Man muss sich also (endlich) mit den richtigen Fragen beschäftigen. Also jenen, die das “Endprodukt” betreffen und nicht “nur” innerhalb einer Abteilung die höchste Priorität genießen. Wichtige Fragen müssen beantwortet werden, wie zB
- Hat das überhaupt einen Wert für das Gesamtunternehmen?
- Welche Tasks sollen in welcher Reihenfolge bearbeitet werden?
- Welche Tasks sind so wichtig, dass sie schon vorher behandelt werden müssen?
- Ist das überhaupt ein IT-Job oder doch eher eine Business-Aufgabe?
Eine Bestandsaufnahme zeigt meist ein fatales Bild: Um alle offenen Punkte zu bearbeiten, bräuchte man mehrere Dutzend Manntage, um diese ohne Unterbrechung abarbeiten zu können. Doch fehlen oft die benötigten kurzfristigen Kapazitäten, noch seltener aber hat man eine störungsfreie Zeit, womit also nur ein neuer Stau entsteht. Und paralleles Arbeiten kostet Zeit: Wer häufig den Arbeitskontext wechselt, brauch immer wieder “geistige Rüstzeiten”, während derer man nicht produktiv ist. Wer aber eine Aufgabe abschließt, bevor er andere beginnt, spart Nerven und Zeit – zwischen 20 und 50 %!
Pull statt Push!
Whiteboard, Marker und Karteikärtchen oder Post-Its genügen, um es “einfach mal mit Kanban zu versuchen”. Visualisieren mithilfe einer tabellarischen Ansicht ist das Gebot der Stunde. Dann wird auf der linken Seite (To-do) regelmäßig geprüft, was denn wirklich wichtig ist und was nicht (nach 2 Monaten “herumhängen” scheint der Task für das Unternehmen nicht wichtig zu sein und kann gestrichen werden).
Zum Kanban-Prinzip gehört auch, dass die Mitarbeiter die Aufgaben eingenständig und sukzessive auf ihren Schreibtisch holen, statt sie mit Arbeit von allen Seiten zuzuschütten. Und diese Arbeit wird limitiert – dh, dass insgesamt nicht mehr Aufgaben auf der To-Do-Liste stehen dürfen, als das Team gleichzeitig bewältigen kann. Nur so bilden sich keine Engpässe und die Arbeit kann gleichmäßig fließen.
Weiters wären gleichgroße Tasks wünschenswert bzw. sollen große Tasks in überschaubare Portionen unterteilt werden. Ein Task der länger als 2 Wochen Aufwand bedeutet, wird in der Regel gar nicht akzeptiert. Vor allem im Wartungsbereich (Helpdesk, Trouble Tickets etc.) gelten aber andere Beschränkungen als für normale Software Changes.
Ausgehend vom Toyota Production System (TPS) ist es keine Seltenheit, dass Whiteboards mit horizontalen “Swimlanes” kreiert werden, auf denen sich die einzelnen Aufgaben bewegen und vertikal von links nach rechts (von To-Do über WiP bis hin zu done – und nur in diese Richtung!) durch die einzelnen Phasen/Stadien des Arbeitsablaufs fließen.
Signalkarte als Taktgeber
Die Aufgaben sind auf Kärtchen symbolisiert, werden von links nach rechts abgearbeitet und sind zusätzlich mit dem Namen oder Avatar gekennzeichnet. Arbeitsfortschritte und Engpässe lassen sich so auf einem Blick erfassen. Bei konkurrierenden Themen kann von allen Beteiligten direkt an der Tafel geklärt werden – im Idealfall mit Coach oder Moderator, um so der Entwicklung bzw. Operations den Rücken freizuhalten.
Verschieden Farben helfen dabei, Aufgaben zu kanalisieren – zB grün für Helpdesk-Tasks. Eine Regel könnte lauten, dass genau 5 pro Tag von Operations-Mitarbeiter genommen werden dürfen. Interne Change Request sind zB blau und dürfen direkt in die Schlange eingereiht werden, welche nach dem FiFo-Prinzip abgearbeitet werden. Störungen in der Produktion (Blocker) sind rot und werden direkt bearbeitet – werden also in der “Fast Lane” oder “Fire Lane” an den anderen Ticket vorbeigeführt.
Normale Customer Requirements (“Projekt-Kanal”) untergliedern sich oft in zwei Kategorien: Entwicklung und Test, wobei jeweils 2 oder mehrere Aufgaben gleichzeitig bewältigbar sind. Nicht selten erfordern Tests Feedback vom Anwender außerhalb der IT, weshalb der Flow hier oft stockt. Werden Aufträge an externe Dienstleister vergeben, können diese normal im Board eingepflegt werden, werden jedoch mit einem “E” gekennzeichnet und sollten unter besonderer Beobachtung stehen, da sich hier oft ein Flaschenhals herausstellt.
Ein weiteres Board könnte die Tickets der vergangenen Monate repräsentieren – geordnet nach Durchlaufzeit, um Transparenz in den Arbeitsfluss zu bringen. Tickets, die zu lange hängen (zB mehr als 5 Tage), gelten als kritisch. Nach einer Analyse können ggf. Gegenmaßnahmen eingeleitet werden.
Das Berufsbild des Entwickler ändert sich gerade: Ein kommunikatives Wesen, um sich mit anderen (Fach-)Bereichen auszutauschen, ist nicht nur gewünscht, sondern wird in manchen Branchen auch vorausgesetzt. Introvertierte Entwickler müssen sich jetzt aber nicht (noch mehr) verstecken: Vielerorts sind sie noch anzutreffen und werden auch bevorzugt, zB im Operations-Bereich.
Lesen Sie weiter in unserem Beitrag “Wasserfall vs. Scrumban“
