Verfrühte Konvergenz durch elektronische Tools

Elektronische Tools sind in IT-Unternehmen äußerst beliebt, kaum ein Weg führt an ihnen vorbei. Beim Einsatz in Umgebungen mit nicht konsolidierten Prozessen können sie aber Schwierigkeiten erzeugen: Sie festigen den Status quo zu schnell.

Beginnen wir damit, die Kanban Methode in einer Organisation einzuführen, designen wir gemeinsam mit dem Kunden das Kanban-System, welches die Veränderung treiben soll. Um das System zu designen, setzen wir uns mit den Mitarbeitern, Kunden, Stakeholdern und Managern zusammen und finden gemeinsam Anforderungen, Workflows und Synchronisationspunkte heraus. Dabei sind alle Beteiligten wichtig und müssen ihren Input geben. Denn Kanban-System-Design ist eine komplexe Sache. Damit meine ich nicht, dass es so unglaublich herausfordernd ist. Es ist vielmehr so, dass es nicht die eine Lösung gibt, sondern unterschiedliche Bedürfnisse, Wahrnehmungen und Vorgehensweisen. Wir sprechen also über Komplexität im Sinne wie Dave Snowden es in Cynefin beschreibt.

Cynefin und Komplexität
Dave Snowden beschreibt mit Cynefin Vorgehensweisen, wie man mit Komplexität umgehen kann. Beispielsweise ist es bei komplexen Problemen nicht angemessen, einen Experten eine Lösung finden zu lassen und sich dann darauf zu verlassen. Das empfohlene Vorgehen ist, ein Netzwerk menschlicher Sensoren aufzubauen und gemeinsam über Mikro-Narrative zu einem gemeinsamen Verständnis der Situation zu kommen.

Cynefin beschreibt auch, dass man irgendwann in die komplizierte Domäne wechseln sollte. Das bedeutet, dass man eine Domäne hoher Variabilität verlässt und Good Practices für die Behandlung von Problem etabliert. Das Problem ist, dass diese Good Practices wirklich erst etabliert werden müssen. Das funktioniert im Allgemeinen darüber, dass sie aus Mustern entstehen, die in der komplexen Domäne gefunden werden. Diese Muster werden in Cynefin „Emergent Practices“ genannt. Sie entstehen (oder werden sichtbar), wenn das System mit verschiedenen sogenannten safe-to-fail-Experimenten stimuliert wird. Diese Experimente sollten safe-to-fail (aber nicht fail-safe!) sein, um sie in großer Anzahl und ggf. zueinander widersprüchlich durchzuführen.
Wird das System durch verschiedene Experimente stimuliert, findet man über die Zeit hinweg für das Ziel positive Muster und negative Muster. Die positiven Muster sollten verstärkt und unterstützt werden, die negativen sollten unterdrückt werden. Mit der Zeit gelangen wir in einen Zustand, in dem die Vorhersagbarkeit des Systemverhaltens durch das Sensoren-Netzwerk gut ist. Das bedeutet, dass die theoretische Wahrnehmung eine gemeinsame ist und sie mit dem praktischen Systemverhalten übereinstimmt. Wir legen die Muster als Good Practices fest und verlassen damit die komplexe Domäne. Wir hören auf, safe-to-fail Experimente durchzuführen.

Kanban-System-Design und elektronischen Tools
Was hat das mit Kanban-System-Design und elektronischen Tools zu tun?
Ein zu frühes Übertreten der Grenze komplex/kompliziert nennt man „Premature Convergence“, also verfrühte Konvergenz. Das System ist noch nicht so weit verstanden, dass Standards festgelegt und befolgt werden können. Die Prozesse und Interaktionen sind noch nicht so weit ausgebildet, dass man sich darauf verlassen kann, dass diese auch funktionieren.
Elektronische Tools neigen leider dazu, genau diese verfrühte Konvergenz zu erzeugen. Das ist anfänglich bequem, weil das Herausbilden von Mustern eine anstrengende Sache ist. Und häufig geht die Akzeptanz einer Methode mit ihrer Verwendbarkeit in einem Tool einher.

Viele Tools sind sehr flexibel in der anfänglichen Gestaltung eines Boards bzw. Kanban-Systems. Spalten, Zeilen, WIP-Limits und Policies lassen sich recht einfach anlegen und konfigurieren. Das heisst, das initiale Setup ist kein Problem. Problematisch wird es erst, wenn man versucht, schnell parallele safe-to-fail Experimente durchzuführen und das System entsprechend der Stimulation und Reaktion zu verändern. Hier tritt die Hürde auf: Die wenigsten Tools, die mir bekannt sind, unterstützen eine schnelle Rekonfiguration.
Je weiter sich das gelebte Kanban-System vom dargestellten entfernt, desto ausgeprägter treten aber die folgenden Verhaltensweisen auf.

• Im Tool werden sehr generische Prozess („To Do“, „Doing“, „Done“) verwendet.
  
• Die Prozesse im Tool folgen nicht der Veränderung der Realität und sind falsch
  
• Es wird das Falsche gemessen oder falsch gemessen.
  
• Aus dem Kanban-System werden keine Informationen gewonnen, die weitere Experimente oder eine Konvergenz stimulieren könnten.
  

Das Resultat der verfrühten Konvergenz ist also, dass das Kanban-System seinen Status von einem Change-Agent (der Veränderung erzeugen soll) zu einer Taskverwaltung verändert.

Lösungsmöglichkeiten
Für dieses Problem gibt es zwei Lösungen, sollte man tatsächlich auf ein elektronisches Tool angewiesen sein.

• Durch den Schmerz gehen und das Tool so verwenden, als wäre es einfach zu ändern.
  
• In der ersten Zeit ein physikalisches Board verwenden und nach der Konvergenz in ein elektronisches Board überführen.
  

Die beiden Lösungen haben gemeinsam, dass sie nicht in Frage stellen, dass eine Phase des Experimentierens notwendig ist.
Setzt man von Anfang an auf ein elektronisches Tool, muss das Tool kontinuierlich an das aktuelle Verständnis des Systems angepasst werden. Experimente müssen sich hier widerspiegeln, die Ergebnisse ebenfalls. Das bedeutet, dass die Administration des Tools in den Händen der Systemgestalter liegen muss. Gerade in großen Unternehmen ist das häufig nicht der Fall.
Entscheidet man sich für das elektronische System von Anfang an, kann man sowohl dem Informationsbedürfnis der Firma, als auch der Aufgabe des Kanban-Systems gerecht werden. Es bedeutet einen größeren Aufwand, die Tools zu ändern, aber der kann durchaus angemessen sein. Und gerade für verteilte Teams stellt diese Variante eine Möglichkeit dar, von einem gemeinsamen Board zu profitieren.
Die zweite Lösungsmöglichkeit, nach der Konvergenz zu einem elektronischen Board zu wechseln, wird teilweise sogar von Toolherstellern empfohlen. Physikalische Boards sind relativ leicht zu ändern und können mit sehr wenig Aufwand den aktuellen Stand des Systems wiedergeben. Die Kreativität (bezüglich Experimenten mit dem Prozess) wird nicht durch das Tool beschränkt. Und es ist im Allgemeinen leichter, eine gemeinsame Sicht (hier kommt wieder das Stichwort Netzwerk menschlicher Sensoren hervor) zu erarbeiten, wenn man davor steht.
Verteilte Teams müssen damit umgehen lernen, ein Board an mehr als einem Standort zu pflegen. Typische Verhaltensmuster sind hier Board Buddies oder Webcam-Übertragungen an andere Standorte.