Kanban – Ein Erfolgsrezept für das Rezept des Erfolges

Nachdem ich auf der diesjährigen Spring-Edition am "Agile Day" einen richtig guten Talk von Arne Roock (it-agile GmbH) und Fridtjof Detzner (Jimdo) über "Kanban bei Jimdo" gehört hatte, und das dort empfohlene Buch "Kanban – Evolutionäres Change Management für IT-Organisationen" von David J. Anderson ohnehin schon zuhause liegen hatte, war ich infiziert!

Das Beispiel des praktischen Einsatzes bei Jimdo, die guten Erfahrungen die sie dort damit gemacht haben und machen und schließlich die abolut überzeugende Art und Weise des mit viel Enthusiasmus und innerer Überzeugung vorgetragenen Talks der Beiden hat gewirkt. Ich wollte mehr wissen über diese sich wie ein Virus verbreitende Methode.
Mir gefällt das Buch und der Schreibstil Andersons sehr gut! Die praktischen Beispiele machen es einem leicht, ihm zu folgen, und es liest sich schon fast mit Spannung, wie er nach und nach zur Methode Kanban kam, wie sich auf seinem Weg zum großen Ganzen ein Puzzleteil an Erkenntnis scheinbar an das nächste gereiht hat.
Was für mich bei aller Agilität aber immer sehr wichtig bleibt, ist die Beantwortung der Frage, wie es möglich ist in Organisationen und Strukturen agile Methoden einzuführen, ohne dabei an den überdimensionalen, starren Gefügen zu scheitern, die zum Beispiel große Konzerne mit sich führen und an denen sie mit aller Macht versuchen festzhuhalten. Es gibt leider nicht überall Firmen wie Jimdo, bei denen eine agile Methode in der kompletten Firmenstruktur eingesetzt wird, und vor allem bei denen eine solche Offenheit da ist, alte und überkommene Strukturen aufzubrechen und neuen Methoden eine Chance zu geben. Auf manchen Managementebenen scheint agil gleichbedeutend zu sein mit chaotisch, neue Ideen werden schnell argwöhnisch abgewiegelt und überhaupt kann man einen solchen Umbruch in manch einem Konzern auf mittleren bis unteren Ebenen doch ganz sicher nicht einfach so einführen!?
Oder vielleicht doch?

An dieser Stelle trifft Anderson mit seinem Beispiel von Dragos Dumitriu als Programm-Manager bei Microsoft voll ins Schwarze! Wahnsinnig spannend liest sich diese Erfolgsstory des einst so schlecht angesehenen Offshore-Teams eines Dienstleisters in Indien! Ich empfehle es zu lesen! ;-) Hier wird sehr schön verdeutlicht und sogar mit ganz konkreten Grafiken und Zahlen unterstrichen, wie ein Team eine agile Methode wie das Kanban-System nach und nach "im Kleinen" durchzusetzen vermag und damit eine ungeheuerliche Leistungssteigerung erreichen kann. Und das völlig ohne tiefgreifende Veränderungen im System des Konzerns machen zu müssen!
Faszienierend!

Aber was macht nun das Rezept Andersons aus? Das Rezept dem Kanban es ermöglicht umgesetzt zu werden? Mit dessen Hilfe sich Kanban als so wertvoll erklären lässt?

Man nehme:
– zwei große Hand voll Qualität,
– eine Prise Work in Progress,
– eine große Schüssel voll Lieferungen,
– eine sorgfältig abgewogene Menge Nachfrage-Durchsatz,
– eine Messerspitze Prioritäten und
– einen Schuss Variabilitätsquellen.

Wird das Rezept in der angegebenen Reihenfolge und mit dem nötigen handwerklichen Geschick umgesetzt, resultiert daraus ein für alle Beteiligten "gut schmeckender Prozesskuchen"!

Durch den Fokus auf Qualität erfolgt – gerade zu Beginn einer solchen Prozesskette – die Chance Vertrauen aufzubauen, Vertrauen vor allem mit vorgelagerten Teams. Denn durch Solches lässt sich am ehesten auf Rahmenfaktoren zur Durchführung weiterer Prozessschritte Einfluss nehmen. Je fehlerhafter Sourcecode ist, umso mehr Aufwand und Schmerzen folgen anschließend aus den Konsequenzen der Fehler und aus den Fehlerbehebungen. Je hochwertiger der Code ist, umso besser sind Produktivität und Durchsatz! Und damit auch die Kundenzufriedenheit. Um die Qualität zu steigern sollte auf Maßnahmen wie automatisierte Tests, Codeinspektionen (wie etwa Pair Programming), Einsatz von Entwurfsmustern und andere bekannte Techniken zurückgegriffen werden. Je weniger Code man währendessen gleichzeitig bearbeitet, umso hochwertiger ist er.

Die Reduzierung des Work in Progress ist von elementarer Wichtigkeit! Der Work in Progress bildet sich aus der Differenz der insgesamt begonnenen Features und der Anzahl der entwickelten, aber noch nicht durch die QA abgesegneten, Features, zu einem festen Zeitpunkt. Also die Menge an Features an denen das Team im Gesamten jeweils aktuell arbeitet. Diese Menge ist optimal gering zu halten, um die Durchlaufzeit möglichst kurz zu halten. Diese wird im Durchschnitt ermittelt, begrenzt jeweils durch den Tag des Entwicklungsstarts bis zu dem Tag des Entwicklungsendes eines Features.
Anderson sieht den Zusammenhang folgendermaßen: Je geringer der Work in Progress (durch den Einsatz eines Kanban-Systems) gehalten wird, umso geringer ist auch die durchschnittliche Durchlaufzeit. Ebenso führt eine verlängerte Durchlaufzeit zu schlechterer Qualtität.

Durch häufige Lieferungen von Releases wird ebenfalls Vertrauen aufgebaut, vor allem auch mit nachgelagerten Teams. Eine kürzere Durchlaufzeit führt dabei direkt zur Möglichkeit häufigeren Auszulieferns, mit zusätzlich besserer Qualität. Das führt nicht nur zur Zufriedenheit im Management und ähnlich gelagerten Teams, sondern ebenso bei Systemadminstratoren, Wartungsteams, bis hin zum Vertrieb. Höhere Qualität und häufigere Lieferungen führen insbesondere zu wartbareren Anwendungen.

Mit der Sorge für ein Gleichgewicht zwischen Nachfrage und Durchsatz wird gewährleistet dass regelmäßig ausführbarer Code geliefert wird. Dieses Gleichgewicht bestimmt die Größe des Work in Progress, die damit auf einen bestimmten Wert festgelegt werden soll. Nur wenn ein Feature seinen Platz im Work in Progress freigibt, weil es erledigt ist, kann ein neues Feature in den Work in Progress nachgezogen werden! Durch dieses Vorgehen werden nun Engpässe besser sichtbar. Zweierlei wird bewirkt: Durch die weitere Disziplin beim Einhalten der Prozessschritte kann nun die Engpassstelle ohne weiteren zusätzlichen Druck nachfolgender Stellen das Problem beheben. Außerdem werden an den anderen Stellen wichtige Freiräume geschaffen, die zu Verbesserungen genutzt werden sollen! Damit lässt sich wiederum sukzessive die Qualität verbessern. Deshalb soll auch NICHT eine Ressourcenumverteilung stattfinden um die Auslastung möglichst hochzuschrauben!

Priorisierungist nicht Sache des IT-Bereichs, sondern des Managementbereichs. (Wobei das IT-Management Einfluss nehmen kann.) Die entsprechenden Personen sollten sich abstimmen und eine vernünftige Prioritätenfolge erstellen. Erst wenn ein Feature aus dem Work in Progress verschwindet, kann wieder – gemäß Priorität – ein nächstes Feaure nachgeschoben werden. Wird die Priorisierung verbessert, verbessert sich auch der Geschäftswert.

Die Quellen von Variabilität sollten ins Visier genommen werden, um die Vorhersagbarkeit zu verbessern. Dies ist der schwierigste Schritt in der Prozesskette und sollte erfahrenen Leuten vorbehalten bleiben. Durch die Reduzierung von Quellen der Variabilität lässt sich der Durchsatz verkürzen und damit auch die Vorhersagbarkeit positiv beeinflussen.

Mit Hilfe dieses Erfolgsrezeptes kann letztlich bei bestehenden Teams eine schnelle Weiterentwicklung erfolgen ohne auf allzu großen Widerstand zu stoßen.

Wer mehr wissen will, dem kann ich das Buch Andersons nur empfehlen:
David J. Anderson: Kanban: Evolutionäres Change Management für IT-Organisationen, 1. Aufl., Dpunkt Verlag, 2011