Agilophil-Daily Podcast Episode 22: Metriken in Kanban – was sollen wir messen, sieben Tage lang… was sollen wir messen, so ein Frust…

Kennst Du das noch? Von den Bots…Was sollen wir trinken, sieben Tage lang, was sollen wir trinken so ein Durst…witzig oder?  Kam mir gerade so in den Sinn…liegt wahrscheinlich daran, dass ich älter bin – ich glaube, die kennt keiner mehr…

Aber das ist natürlich keine Geschichte für heute, nein Ich beginne anders:

Ich starte heute etwas weniger fröhlich – ein bisschen nachdenklich…ich habe heute einen Artikel im Spiegel gelesen – also online, da ging es um einen taub-blinden Jungen und wie er gefördert werden kann…ich nehme Dich mal mit in diese Thematik, wir gehen da mal gedanklich rein…

Stell Dir mal vor, Dein Name ist Jan (ich habe den Name geändert)…Du kommst auf die Welt und kannst weder sehen noch hören…Dein Gehirn ist aber vollkommen ok – ich habe ja in agilophilosophischen Folge schon mal über die Leistungsfähigkeit des Gehirns gesprochen…was für ein Supercomputer das eigentlich ist. Dein Supercomputer ist aber  – um es mal so auszudrücken – weder an die Kamera, noch an das Mikrofon angeschlossen. Sehen und hören sind – für mich jedenfalls klar die wichtigsten Sinne – 

Was passiert, wenn Du diese nicht nutzen kannst?

Ohne Hören, keine Sprache, keine Musik, kein sich ausdrücken können…, keine Zukunft? Keine Vergangenheit? Nichts in Worte fassen können – nicht mit Dir selbst reden können…Keine Wünsche äussern? Wie teilst Du mit, dass Du dir etwas wünschst? Einen Wunschzettel zu Weihnachten? Nicht vorstellbar – gibt es überhaupt Wünsche? Keine Bedürfnisse mitteilen – wie teilst Du mit, dass Du Hunger oder Durst hast? Freude, kannst Du über deinen Gesichtsausdruck mitteilen..das geht. Aber es wird nie konkret – Du kommst ja nie ins Detail…wie kannst Du etwas genau erklären, was Du haben oder erreichen willst? wie soll das gehen?

Ohne Sehen, keine Farben, Keine Bilder, Keine Filme – wir denken nicht in Bildern…wir denken in Filmen…wir träumen in Filmen…wie träumst Du? Wie denkst Du? Wie stellst Du dir etwas vor? Alles, was wir realisieren, was wir tun oder erreichen startet mit einem Bild im Kopf, mit einer Vorstellung, einer Vision, einem Tagtraum….wie soll das gehen? Wie soll das gehen, wenn Du diese Bilder nicht hast – keine Vorstellung davon, was das überhaupt ist…es gibt keinen Eingangskanal dafür…Dein Supercomputer kann keine Nervenbahnen dafür ausbilden und trainieren…es ist schwarz und still….

Dein Input kommt über das Fühlen, riechen und schmecken, das funktioniert ja – Wärme, Oberflächen – Räume – Gerüche, und Geschmäcker, da entwickelt sich auch ein Vorstellungsvermögen für Deine Umwelt…ja…und da Du es nicht anders kennst, wirst Du auch nichts vermissen…es gibt keine Information in deinem Gehirn, dass da jemals entwas anderes draussen existiert, als das, was Du über Deine Haut und Deine Nase und deine Zunge wahrnimmst.

Es entsteht eine völlig andere Wahrheit in Dir…und vor allem…alles entsteht sehr langsam…Ohne Stimulation von aussen, kann nicht viel passieren – das Gehirn verknüpft Nervenbahnen auf Grund von äusseren Reizen…diese werden dann zu Kompetenzen und Erfahrungen. Und je mehr Reize es gibt, desto schneller arbeitet auch das Gehirn – Du kannst Das Gehirn nicht überfordern…jedenfalls nicht als Kind. Das siehst Du auch an den Kindern, die zweisprachig aufwachsen. Wenn Vater und Mutter eine unterschiedliche Sprache mit dem Kind sprechen, lernt es einfach beide…wenn dann die Kinder im Kindergarten vielleicht noch eine andere Sprache sprechen, lernt es diese auch noch dazu…kein Problem. Das Hirn kann das…

So und wie kommen wir jetzt zu meinem eigentliche Thema? Warum fahren wir eigentlich unsere Projekte oft so, als ob wir uns unserer Sinne beraubt hätten? Warum nutzen wir nicht die Eingangskanäle und – ich nenne es mal – Sinnesorgane – die wir eigentlich zur Verfügung hätten? Wir fliegen blind und hören nicht auf die Signale….

Kein Wunder, dass sich manche Projekte seltsam und von allem sehr langsam entwickeln…

Kanban ist daher sehr datengetrieben – und dadurch auch durchaus  beliebt bei den Teckis… 

Und um Daten sichtbar zu machen, müssen wir sie messen. Und wir brauchen- ausser vielleicht einer Uhr und einem Kalender noch nicht einmal spezielle Messgeräte dazu. Die Sinne sind alle vorhanden…

Also: Wir sehen Veränderungen und Verbesserungen aber auch Verschlechterungen am besten dann, wenn wir die Kennwerte dafür durchgehend messen. Und zur Beurteilung des Zustandes unseres Projekts oder Kanban-Systems benutzen wir Kennzahlen – sogenannte KPIs oder Key Performance Indicators. Wichtig hierbei ist, dass nur das System gemessen wird, nicht aber die Leistung einzelner Mitarbeiter. Das ist etwas, was gerne mal falsch interpretiert wird. Wir beurteilen nicht die Leistungen der Mitarbeiter, sondern des gesamten Systems. Also des Teams und wie das Team sich organisiert. Denn – seien wir mal ehrlich – in den allermeisten Fällen liegt es  nicht an der Performance Einzelner, wenn etwas stockt, sondern daran, dass das System durch irgendwas ausgebremst wird. Doch dazu mehr in einer der nächsten Folgen.

Ich betrachte das jetzt mal sozusagen Low-Tech mässig – also ganz analog: Ich weiß, dass es für alles gute Tools gibt – sehr verbreitet ist ja bekanntlich Jira von Atlassian, aber es geht ja nicht um die elektronischen Tools, sondern um den Inhalt. Und der lässt sich hier – finde ich zumindest – im Podcast am einfachsten an analogen Beispielen erklären. 

Um richtig messen zu können, brauchen wir Informationen und die müssen gespeichert bzw. festgehalten werden. Viele davon können wir einfach auf unserer Signalkarte (also dem Ticket) notieren. Was gehört also auf das Ticket?

  • Da wäre zunächst mal der Aufgabentitel. Titel und eine Kurzbeschreibung der Aufgabe sollte für das Team verständlich sein – auch für die Leute, die nicht daran arbeiten. In Scrum nehmen wir hierfür ja auch gerne das Format der Userstory – ich empfehle das hier auch, es muss aber nicht sein, da wir ja auch in einem anderen Kontext arbeiten können. 
  • Wenn es einen festen Liefertermin für die Aufgabe gibt, dann gehört der auch gut lesbar auf die Karte
  • Wer macht es : hier kann der Bearbeiter bzw. Die Bearbeiterin wechseln, daher ist es gut, wenn Du dazu Magnete oder kleine Klebemarker/(oder Post-IT’s) nimmst, die sich austauschen lassen. 
  • Status-Veränderungen: und das ist jetzt besonders wichtig – Notiere das Datum bzw. Die Uhrzeit, wann die Karte von einem Status (also Prozessschritt) in den nächsten übergeht. (elektronische Systeme machen das natürlich automatisch…). 
  • Größe (oder Komplexität) der Aufgabe: In Scrum verwenden wir gerne Storypoints – es geht aber auch anders z. B. Mit T-Shirt-Größen – also S, M, L, XL – das wäre eine sehr einfache Variante dafür. 

Eben schon kurz angedeutet – eine der wesentlichen Kenngrößen eines Kanban-Systems ist die Durchlaufzeit – auch (Lead-Time genannt): Das ist die Zeit, die es braucht von dem Zeitpunkt, an dem eine Aufgabe geplant wird – also in den Arbeitsvorrat oder die Input-Queue aufgenommen wird – bis zu dem Zeitpunkt, an dem die Aufgabe erledigt ist. Also streng genommen die Zeit die es braucht, bis eine Aufgabe durch das Kanban-System geflossen ist.

Bei den Begriffen müssen wir jetzt ein bisschen aufpassen, die gehen gerne mal durcheinander. 

Die Durchlaufzeit wird auch als System-Durchlaufzeit oder System lead time bezeichnet, dann gibt es aber noch eine Kunden-Durchlaufzeit oder customer lead time: die beschreibt wie lange der Kunde auf sein Ding wartet – also von seiner Anforderung oder seinem Auftrag bis zur Erledigung. Es kann ja sein, dass ein Auftrag sehr lange in einem Auftragsstapel liegt, bis er überhaupt in Arbeitesvorrat unseren Kanban Systems aufgenommen wird. Das ist nämlich der Zeitpunkt der Zusage (Commitment). Ich habs in der letzten Folge ja schon mal erwähnt. Im Replenishment Meeting wird der Arbeitsvorrat besprochen – alles was hier beschlossen wird, wird ja dann auch umgesetzt und in die Input-Queue getan – daher gibt es erst ab diesem Zeitpunkt überhaupt das Commitment. Was davor passiert – kümmert uns jetzt erstmal nicht – aber das kann natürlich eine Quelle von großem Kundenfrust sein, wenn die Aufträge ewig auf diesem undefinierten Stapel herumliegen. 

Dann gibt es noch den Begriff Cycle Time, der leider nicht eindeutig belegt ist und einfach beides bedeuten kann – also entweder die Durchlaufzeit oder die Kundendurchlaufzeit. Also – bitte immer vorher die Begriffe genau klären, damit ihr nicht aneinander vorbei sprecht…

Mit der Durchlaufzeit können wir schon eine ganze Menge anfangen: Es gibt eine sehr schöne Darstellung mit der wir mehrere Informationen im Blick haben: Das kumulatives Flussdiagramm…wenn man sich mal ein bisschen dran gewöhnt hat, ist es eigentlich ganz einfach:

Auf der y-Achse – also die senkrechte, die Ordinate, die nach oben geht….tragen wir an jedem Tag ein, wieviele Karten jeweils in den Prozessschritten stecken…und das summieren wir von Tag zu Tag auf – daher heißt das ja auch kumulativ…Die Zeitachse ist dann auf der x-Achse, also auf der Waagerechten, die dann nach rechts weggeht…

Fangen wir mal an: Nehmen wir an, am ersten Tag unserer Betrachtung haben wir insgesamt 75 Karten auf unserem Kanban-Board System. Davon sind dann also 15 im Arbeitsvorrat (bzw. In der Input-Queue), dann 7 in der Analyse, 8 in der Entwicklung, 17 im Test und 28 sind bereits fertig. Diese bekommen jeweils unterschiedliche Farben (oder Muster), so dass man die auf eine Blick leicht unterscheiden kann. 

Am nächsten Tag haben wir 11 im Arbeitvorrat, 6 in der Analyse, 9 in der Entwicklung, 14 im Test und demnach 35 fertig…so läuft das  jetzt jeden Tag und jede Woche… Die Linien gehen immer nach oben, da das ja immer aufaddiert wird. Aber die Bereiche zwischen den Linien werden unterschiedlich breit sein. Und so bekommen wir dann ein genaues Bild, wie lange sich die Karten im Prozess befinden und wieviele Karten pro Tag in Arbeit waren. Dazu müssen wir nur die Karten auf der Y-Achse zusammenzählen, die in den Schritten „Analyse“, „Entwicklung“ und „Test“ waren. Am Tag 1 waren das 32 und am Tag 2 waren das 29.

Und wenn wir einen waagerechten Strich ziehen, können wir sehen, wie lange eine Karte gebraucht hat um von der Input-Queue bis zu Fertig zu kommen. Der Verlauf der Bereiche zwischen den Linien zeigt uns auch gleich wo es Problemstellen geben könnte – je dicker ein Bereich, desto langsamer scheint es da zu fließen. 

So ein CFD (wird meist so genannt aus der englischen Bezeichnung heraus – also cummulative flow diagram) kannst Du tatsächlich jeden Tag an der Wand vom Teamraum manuell aktualisieren und damit machst Du die Arbeit transparent. In Jira wird dir das auch angeboten, natürlich automatisch – die Problematik dabei ist nur – da guckt halt niemand ständig drauf…

Aus dem CFD kann man auch sehr einfach die Flusseffizienz ermitteln – das ist das Verhältnis der Bearbeitungszeit zur Gesamtdurchlaufzeit (also wie oft wurde an einer Karte wirklich gearbeitet und wie lange liegt sie z.B. in der Input-Spalte…Also – man kann es aus anders Ausdrücken: die Arbeitszeit und die Summe aller Wartezeiten ergibt letztlich die Gesamtdurchlaufzeit.

Ein anderes Diagram, was auch noch sehr einfach zu erstellen ist – und praktisch zugleich – ist ein Historigramm aus den fertigen Karten. Du musst einfach nur die Karten wenn sie fertig sind in ein Diagramm legen auf dem in der X Achse die Tage notiert sind. Also du zählst einfach hoch 1 Tag, 2 Tage, 3 Tage usw. (oder Wochen) und legst die Karten entsprechend der Bearbeitungsdauer ab. Die ast du ja auf der Karte notiert!

Was siehst Du darauf?: Du siehst wieviele Tag die Karten im Durchschnitt so brauchen – Du siehst Peak – also Gipfel – und kannst so sehr leicht und transparent machen, wie lange ihr im Durchschntt so braucht – Du siehst die Verteilung der Karten – gibt es Häufungen? gibt es breitere Verteilungen?

Die Frage – wann bekomme ich es geliefert lässt sich so gut beantworten…Nimm einfach die Gesamtzahl der erledigten Karten und schaue, bei welchem Tag Du 80% davon erledigt hast. Dann kannst du sehr einfach eine für den Kunden meistens hinreichend genaue Antwort geben: Mit 80% Wahrscheinlichkeit ist Ihr Auftrag in 3 Wochen erledigt (beispielsweise).

So – Du siehst – mit sehr einfachen Mitteln wirst Du und wird auch das gesamte Team aussagefähig. Du musst also nicht mehr blind und taub durch das Projekt irren und kannst sehr schnell und einfach deine Sinne einsetzen um einen klaren Blick über die Situation zu bekommen. Ich will das hier in dem Podcast nicht noch weiter vertiefen.  Ich wollte dir nur zeigen:  nimm die Metriken, die es gibt und benutze sie,  so dass du und dein Team sehen und hören könnt. Das ist weitaus weniger gefährlich als nur nach dem Prinzip Hoffnung – es wird schon gut gehen – zu fahren. 

So weit mit der heutigen Folge zu den Metriken in Kanban – ich weiß, dass das hier nicht vollständig ist und dass es noch eine ganze Reihe von Dingen gibt, die Du auswerten kannst. Du findest aber im Internet viele Beispiele dafür, wenn DU einfach mal nach „Kanban-Metriken“ googelst. 

Insofern wünsche ich Dir stets klare Sicht und guten Klang bei Deiner Projektarbeit.

Viel Erfolg beim Messen

Dein agilophiler Frank