Kanban und Metriken bei Versant/Actian

„Wer viel misst, misst viel Mist.“ Das dies nicht sein muss, zeigten uns Arne Roock (it-agile) und Per Jochumsen (Actian/Versant) an diesem Abend. Arne begann mit einer kurzen Einführung in Kanban und Metriken. Per zeigte uns Daten aus der Praxis bei Actian/Versant. Er berichtete, was das Team daraus gelernt hat und wie die Kunden und das Unternehmen von den Messungen profitieren.

 

Das Treffen fand bei Bigpoint statt. Ich kam kurz nach 19:00 Uhr dort an und betrat einen belebten Raum mit bemerkenswert hohem Energielevel. Es waren bereits (gefühlt, nicht gemessen!) 25 Personen anwesend. Diese hatten sich in kleine dynamische, angeregt redende Gruppen unterteilt. Ich liebe diese Atmosphäre und hatte das Glück eine Person kennen zu lernen, mit der ich zuvor nur Emails ausgetauscht hatte.

 

Um 19:30 Uhr ging es los, Arne berichtete Wissenswertes zu Metriken im allgemeinen und in Kanban und deren typische Visualisierungen. Um 20:00 Uhr übernahm Per mit seinem Erfahrungsbericht. Er zeigte uns die Visualisierungen der Messwerte zweier Teams und teilte die Erkenntnisse daraus. Von den Metriken profitiert nicht nur das Team, sondern auch der Product Owner und die Stakeholder. Für den, der mehr zu den Inhalten erfahren will, gibt es auch die Folien und weiter unten folgt eine inhaltlich Zusammenfassung der Präsentationen.

 

Nach einer Frage-Antwort-Diskussionsrunde bei der es unter anderem um die Teamgröße, das Tooling und den Verwaltungsoverhead ging, war der offizielle Teil gegen 21:00 Uhr beendet. Die Veranstaltung klang aus, wie sie begonnen hatte: In kleinen lebendigen Diskussionsgruppen.

 

Mir hat der Abend gut gefallen. Die Mischung aus Fachkenntnis, Offenheit und aufrichtigem Interesse der Teilnehmer katalysiert neue Erkenntnisse. Ich persönlich nehme diesmal zwei Dinge mit: Die Bestätigung, dass das Schätzen von Storypoints nicht notwendig ist. Und den Wunsch, in Zukunft Systemmetriken so schnell wie möglich einzuführen.

 

Vielen Dank an Arne, Per, alle Teilnehmer und natürlich Bigpoint für den Raum, Getränke und Knabbersachen!

Die Slides findet man hier

 

Arne eröffnete den Vortrag mit einem kurzen Hinweis auf die Kanban Praktik 'Measure and manage flow'. Messungen können für gutes Management sehr hilfreich sein. Das sei wie beim Abnehmen, ohne Waage ist es zwar möglich, aber deutlich schwieriger.

 

Metriken mit Boni zu verknüpfen ist kontraproduktiv, denn Mitarbeiter beginnen, die Metriken zu optimieren und nicht das System bzw. die Zielerreichung.

 

Messe das System und nicht die Leistung einzelner Mitarbeiter, da die Leistung einer Organisation systemabhängig und nicht abhängig von einzelnen Mitarbeitern sei. Das stellte schon W. Edwards Deming (Toyota Production System) fest.

 

Metriken sollen uns helfen, das System zu verbessern, indem wir die richtigen Fragen stellen und datenbasiert entscheiden.

 

Arne präsentierte drei typische Visualisierungen.

 

1. Das Cumulative Flow Diagram

 

Ein etwas sperriges, aber sehr mächtiges Werkzeug. Es braucht eine Weile, es richtig zu bedienen und lesen zu können. Es visualisert sehr gut die Entwicklung der Arbeitslast und die Durchlaufzeit über einen Zeitraum.

 

2. Das Control Chart

 

Gerne von Deming benutzt, visualisiert es die Durchlaufzeit über einen Zeitraum. Es zeigt, ob Maßnahmen den Median und die Varianz in der beabsichtigten Weise beeinflussen. Außerdem laden Ausreisser zu Diskussionen ein.

 

3. Das Histogramm

 

Visualisiert die Verteilung der Durchlaufzeit. Es ist hilfreich, um Vorhersagen zu machen -> Median und Perzentile. Nebenbemerkung: Diese Diagramme spielen auch eine Rolle im aktuellen Trend "Lean Forecasting": Troy Magennis spielt mit einer Monte Carlo Simulaton Projekte durch und stellt die Ergebnis ebenfalls in Histogrammen dar.

 

Arne geht auf den PDCA (Plan-Do-Check-Act) Kreis von Deming ein und klärte uns auf: Dies sei eine 'Scientific Method' - wenn man sie datenbasiert durchführt. Man kann anhand der Daten gut ablesen, welchen Einfluss beispielsweise die Einführung von Pair Programming auf Durchlaufzeit, Qualität und Mitarbeiterzufriedenheit hat.

 

Er weist auf ein Dilemma hin: Man muss früh anfangen, Daten zu sammeln. Denn nur mit einer soliden Datenbasis kann man datenbasiert Entscheidungen treffen. Aber Vorsicht: „If you measure it, you start to manage it“. Doch am Anfang bedeutet das Management ohne Kontext.

 

Fazit Metriken dienen in Kanban der Verbesserung, es muss jedoch einiges bei der Erhebung und Auswertung beachtet werden.

Die Slides finden man hier

 

Rahmenbedingungen

 

Bei Actian/Versant arbeiten zwei Teams mit Kanban. Das eine Team entwickelt ein neues Produkt auf der grünen Wiese. Das andere Team wartet und entwickelt eine bereits volljährig gewordene Anwendung, den Datenbankserver.

 

Zu Beginn wurde ein physikalisches Bord für die Visualisierung des Prozesses und der Aufgaben eingesetzt. Die Messwerte wurden manuell in einer Tabelle  erfasst. Dabei wurde nicht nur jeden Tag die Anzahl 'tickets-per-column' festgehalten, sondern für jeden Spaltenübergang eines Ticketsdas Datum gespeichert. 

 

Heute erfolgt die Verwaltung der Tickets ausschließlich in Jira mit dem Greenhopper Plugin. Ein Board wird nicht mehr geführt. Die Daten ermittelt Jira automatisch. Die Informationen spuckt Jira aber nicht ohne weiteres wieder aus. Hier ist ein manuelles Vorgehen notwendig. Bei Interesse bitte an per.jochumsen@actian.com wenden.

 

Team 'Neues Produkt'

 

Per zeigte uns einen Control Chart der 'Cycle Time' (dt.?) der ersten drei Monate nach Einführung von Kanban. Man konnte gut erkennen, dass die Bearbeitungszeiten der Tickets im wesentlichen zwischen 1 und 10 Tagen liegen und um den Mittelwert von 5 Tagen verteilt waren. Es gab drei deutliche Ausreisser zu sehen. Der Chart vermittelt eine hohe Stabilität.

 

Warum ist das so? Das Delivery Team und der PO hatten zuvor mit Scrum gearbeitet und waren erfahren in der Entwicklung, mit der Fachlichkeit und im Erstellen von Stories. Die Größenschätzung einer Story erfolgte durch Planning Poker mit T-Shirt Größen. Eine Story ab Größe XL wurde nicht umgesetzt, sondern musste in kleinere Stories zerteilt werden. So sichert das Team Verständnis und Kleinteiligkeit der Anforderungen.

 

Zwei Ausreisser waren schnell erklärt: Zum einen wurde eine Anforderung unterschätzt. Aus "ein paar Ergänzungen" in der Anwenderdokumentation wurde ein völlig überarbeites Benutzerhandbuch. Zum anderen musste das Team auf einen Patch in einer benötigten 'third-party' Bibliothek warten. Das Ticket hing also aufgrund einer durch das Team nicht auflösbaren Abhängigkeit.

 

Aufgrund der stabilen Durchlaufzeiten kann man die Daten für die Planung nutzen: Das Team schafft regelmäßig 0,67 Tickets am Tag bzw. 3,38 Tickets pro Woche.

 

Fazit: Schätzen von Storypoints ist nicht notwendig. Wenn man denn wollte, so sollte man die Abhängigkeiten nach außen weiter minimieren.

 

Team 'Server'

 

Per zeigte uns einen Control Chart mit drei verschiedenen Ticketklassen: Expedite, Normal und Intangible. Expedite sind vorrangig zu behebende Produktionsstörungen, Normal ist alles von der Konfigurationsänderung bis zur großen Weiterentwicklung, Intangible sind selbstgewählte Aufgaben des Teams, wie Refactorings, Automatisierungen, etc.

 

In diesem Chart sind viele Langläufer und kein Trend erkennbar. Warum ist das so? Das Produkt hat im Verlauf seiner Evolution eine hohe Komplexität angenommen. Die heutigen Entwickler sind bereits die dritte Generation, die an diesem Produkt arbeitet. Sie müssen sich viel Wissen aneignen. Nutzen kann man die Daten auch für das Erwartungsmanagement des Vertriebs und damit des Kunden.

 

Es wurden konkrete Maßnahmen ergriffen. Eine davon war, Tickets herunterzubrechen, wenn sie zu groß erscheinen.

 

Als nächstes Diagram zeigte uns Per ein Cumulative Flow Diagram des gleichen Teams. Hier konnte man ablesen, dass die expliziten Prozessregeln nicht zu einer Reduktion der Lead Time geführt haben. Aber in einem anderen Diagramm wurden die Verbesserungen sichtbar: In der Abnahme gemeldeter Fehler durch Kunden, also einer Qualitätsverbesserung.

 

Die Prozessverbesserungen haben zu einer Reduktion der Cycle Time geführt. Wer jetzt verwirrt ist, warum nicht die Lead Time, aber die Cycle Time reduziert wurde, kann hier mehr über die Begriffe erfahren: http://stefanroock.wordpress.com/2010/03/02/kanban-definition-of-lead-time-and-cycle-time/

 

Fazit: Explizite Prozessregeln führen zu einer Verbesserung. Man muss auch über den Tellerrand herausschauen, wenn man die Daten interpretiert: Eine Verbesserung kann auch in Metriken erkennbar werden, die sich nicht auf den Ticketdurchlauf beziehen.

 

Wer profitiert von den Metriken

 

Der Product Owner, weil die Metriken eine Planung ermöglichen.

Der Vertrieb und der Support, weil sie die Erwartungen der Kunden besser leiten können.

Das Team, weil es Potenziale erkennt, den Erfolg von Prozessänderungen verifizieren kann und die Diskussionen sachlicher geführt werden können.

 

Fragen/Diskussion

 

Bemerkenswert fand ich die Bemerkung von Volker John, General Manager Engineering Actian, dass sich der 'Overhead' der Messungen auch für das Management lohnt, wenn Entscheidungsvorlagen verlangt werden. Mithilfe der Zahlen kann man die Positionen belegen, gewinnt Vertrauen und spart wertvolle Zeit in der Entscheidungsfindung.