Zunächst definierte jeder in „drei Worten“, was Leadership für ihn bedeutet. Dabei wurde nicht nur die Bandbreite sondern auch die Unschärfe im Verständnis von Leadership deutlich.

von Steffen Bleul

David J. Anderson der Gründer der Kanban Lean University hat es sich nicht nehmen lassen, neben seinem Advanced Kanban-Training in München noch einen öffentlichen Vortrag zu halten. Das Thema des Vortrages war „Fitness for Purpose - matching capability to customer expectations“. It-agile hat den passenden Konferenzraum organisiert und für passende Verpflegung gesorgt. Besten Dank! Der Andrang war groß, der Raum war voll. Sogleich hat David Anderson angekündigt die neuesten und heißesten Themen des letzten „Kanban Leadership Retreats“ in Portugal vorzustellen: „Sense & Respond“. 

David hat es geschafft perfekt von einem Thema zum Anderen zu leiten und dabei weder langweilig zu werden oder den Hörer abzuhängen. Der Vortrag war spannend, die Ideen sehr inspirierend. So konnte die späteren sehr fortgeschrittenen Ideen über „Sense & Respond“ verstehen. Der Vortrag war dazu in zwei Teile aufgeteilt; Eine einleitende Success Story von der Firma Blizzard Skis in Österreich und ein fiktives Beispiel aus der Pizza Branche. Danach der zweite Teil auf dem Flipchart mit Topics wie „Sense and Respond“, „Discovery Kanban“ und „Delivery Kanban“.

So und was hat es nun mit „Fitness for Purpose“ auf sich? Die Firma Blizzard Ski ist ein Skihersteller aus Österreich. Ein Premium Hersteller, der seit 1945 nur handgefertigte High End Skis produziert. Die produzierten Innovationen der Firma werden seit Jahren auf Veranstaltungen mit Preisen ausgezeichnet. Hauptabnehmer, der Skis, sind die Alpenanliegenden Länder. Im Jahre 2008 war die Firma mit dem Umstand konfrontiert, dass die Händler wegen den milden Wintern von 2006 und 2007 noch übermäßige Bestände der Vorjahresmodelle hatten und entsprechend 2008 verminderte Bestellungen aufzugeben. Da auch schon in 2007 der Auftragsbestand milde ausfiel war die Firma in einer schweren finanziellen Lage.

Auch der Markt von Skiproduzenten und Skihändlern hat besondere Merkmale. Skis werden auf Bestellung und nicht auf Prognose produziert. Ein Skimodell für 2007 wird bereits in der Wintersaison 2006 bestellt. Dementsprechend ist auch die Produktion ausgelegt. Ein 2007er Skimodell wird bereits im Frühjahr produziert. Eine Lead Time für ein Skimodell von fast einem Jahr! Die Lage wird dadurch noch dramatischer, dass die Händler anfingen ihre Bestellungen bis Mitte des Jahres hinaus zu zögern. Blizzard Ski musste deswegen anfangen Skis auf Prognose anstatt auf konkrete Bestellungen zu produzieren. Einige Modelle blieben liegen und andere konnten nicht schnell genug nachgeliefert werden. Die Kosten blieben, während die Erträge schwanden.

Die Antwort aus dem Management des italienischen Mutterkonzern kam sofort: Kosteneinsparungen und Zentralisierung. Die Niederlassungen in Österreich wurden in reine Fabriken umgewandelt, die Bestellungen wurden ausschließlich in Italien bearbeitet. Die Masse an individuellen Bestellungen wurden mit einem SAP System verwaltet. Nicht nur dass das System mehr gekostet hat als die Einsparungen, der Umweg über den italienischen Mutterkonzern hat einen Monat in Anspruch genommen und die Lead Time verkürzt und damit den Skibau noch unvorhersehbarer gemacht. Die Kosten sind weiter gestiegen. Die Lösung war keine Lösung, sie machte Blizzard Ski nicht „Fit for Purpose“.

Was ist nun „Fit for Purpose“ im Kontext Blizzard Ski? In einer Zeit extremer Klimaveränderungen musste die Produktion solange verzögert werden, bis konkrete Bestellungen eintrafen. Blizzard Ski musste ganz einfach doppelt so schnell produzieren. Dann konnte man die Händlerreaktionen abwarten und gezielt für die nächste Wintersaison produzieren. Blizzard Ski wurde der erste Lean Ski Hersteller der Welt. Die Produktion wurde radikal auf ein Fließbandverfahren umgestellt, mit dem trotzdem handgefertigte Skis produziert werden konnten. Noch besser, da die Produktion der Skis bereits in seachs Monaten abgeschlossen waren konnten die restlichen sechs Monate des Jahre für die Verbesserung des Produktionsprozeses genutzt werden. Blizzard Ski ist daher in der Lage jedes Jahr noch besser zu werden.

„Fit for Purpose“ ist kein goldener Hammer für jeden Branchenzweig. Es zeigt, dass Verbesserungen immer im Kontext gesehen werden müssen. Dazu brachte David J Anderson noch ein Beispiel eines Pizzalieferanten. Eine Pizza verkauft sich nicht allein über den Geschmack, der Erfolg kommt erst, wenn er die Erwartungen des Kunden trifft. Ein Softwareteam, das im Rahmen einer Deadline Überstunden macht, kann vielleicht mit einer Lieferzeit von einer Stunde leben. Eine Mutter, die drei pizzabegeisterte Kinder hat, ist selbst schon eine Lieferzeit von 30 Minuten nicht akzeptabel. Das Team kann mit einer falschen Pizza in der Lieferung leben, für ein Kind geht die Welt unter, wenn es die falsche Pizza bekommt. Wenn ein Pizzalieferant erfolgreich sein will muss er lernen, die Erwartungen der Kunden zu heraus zu finden „Sense“.

Eine Aufgabe, für die Kanban wie gemacht ist. Man fängt damit an, die Arbeitsabläufe zu „Kanbanisieren“ indem man die gesamte Wertschöpfungskette auf einem Kanban Board darstellt. Jede Lieferung muss mit geeigneten Metriken gemessen werden. Den Fitness Kriterien. Nach jeder Verbesserungsmaßnahme muss überprüft werden, ob eine Maßnahme die Fitness Kriterien verbessert. Geeignete Maßnahmen werden beibehalten, nicht geeignete Maßnahmen werden rückgängig gemacht. Erfolg stellt sich wenn, wenn die Fitness Kriterien dem Purpose einer Firma entspricht. Die Agilität eines Unternehmens wird darin bestimmt, wie schnell sich eine Firma auf den Kunden, bzw. Fitness Kriterien einstellen kann.

Damit waren wir dann bei den aktuellen Themen aus Portugal zu denen David J Anderson noch zwei Skizzen auf einem Flipchart machte. „Fitness for Purpose“ kann danach in zwei Kategorien geteilt werden, dem eigentlichen Produkt oder Service (Discovery), den eine Firma anbietet, und dem Lieferprozess an sich (Delivery). Ziel ist es beides in einen D&D Kanban unterzubringen. Kanban bietet von Haus aus Unterstützung für „Delivery Kanban“, in dem es darauf hinaus zielt die Lead Time zu verkürzen. Dagegen muss ein „Discovery Kanban“ sich darauf konzentrieren Fitness Kriterien für ein Produkt oder Service aufstellen, die es zu verbessern gilt. 

Lean Startup ist bereits ein konkretes Beispiel für den Aspekt der Produktförderung wie „Discovery Kanban“. David findet den Begriff „Lean Startup“ zumindest in der Finanzbranche nicht sehr förderlich. In der Finanzbranche wird erstens Lean ganz anders gehandhabt, als in der Softwarebranche, und außerdem sind Startups etwas, dem die Finanzbranche nur Geld gibt, wenn Sie bereit sind, hohes Risiko einzugehen. Auch für D&D Kanban wird noch ein geeigneterer markttauglicher Name gesucht. Das noch zu etikettierende Verfahren soll, laut seiner Aussage, bereits nächstes Jahr Marktfähig sein.

Das führt uns final zum Thema „Sense & Respond“. Mit „Sense“ wird die Außenwelt bezeichnet, die mit geeigneten Fitness Kriterien abgebildet werden. Die aktuelle Fragestellung hier: Wie können wir dies effektiv tun? Diese Fragestellung ist noch sehr offen und wer ganz vorne mit dabei sein will, kann sich sehr gerne mit diesem Thema beschäftigen. Dagegen gibt es für „Respond“ bereits viele Antworten, wie geeignet mit Kapazitäten, Lieferzeiten und geeigneten Produkten und Diensten reagiert werden kann.

von Ingo Goldbeck, Alexander Stein und Alexander Fedtke

Nach einer viel zu langen Winterpause fand endlich wieder ein Treffen der Limited WiP Society Hamburg statt. Und zwar diesmal in den Räumlichkeiten des Deutschen Klima Rechenzentrums (DKRZ) und des Max-Planck-Institutes für Meteorologie (MPI) in der Bundesstraße. Um 19 Uhr waren bereits einige bekannte Gesichter zu sehen und man tauschte sich bei Bier und Softdrinks aus, welche freundlicherweise vom MPI zur Verfügung gestellt wurden. Es gab viel zu erzählen, viele hatten sich ja einige Monate nicht gesehen. Sehr beeindruckend war der hochmoderne, teilbare Konferenzraum, der locker Platz für 60 Besucher bietet und dabei mit modernstem Equipment wie mehreren Beamern, Lichttechnik, einer 3D Projektor Anlage sowie einem riesigen Smart Board ausgestaltet ist. Der Traum eines jeden Coaches.

Gegen 19:30 führte uns Gunnar Gorges (stellvertretender Leiter der IT-Abteilung und Projektmanager) zunächst in den „Kanban-Raum“. Hier präsentierte er uns zwei große, sehr ordentlich gestaltete Kanban Boards mit einer Vielzahl bunter Karten, WIP Limits, Avataren und Magneten, sowie einem in fetter Schrift ausgedruckten knappen Regelwerk zur Benutzung des Boards. Genau genommen handelt es sich um zwei Boards, eines zur Sammlung und Priorisierung von Projekten und eines zur Durchführung von maximal 6 parallelen Projekten sowie größer Aufgaben. Das tägliche Stand-up findet mit 15 festen Personen sowie freiwilligen Zuhörern statt. Diverse Fragen zum Board wurden gestellt und von Gunnar offen und fachkundig beantwortet.

Zurück im Konferenzraum begann nun Gunnar’s Vortrag über die Arbeit mit Kanban innerhalb der letzten 18 Monate. Gunnar arbeitet in der 30-köpfigen IT-Gruppe, die vor einem Jahr in 2 Teams aufgeteilt wurde. Die tägliche Arbeit umfasst den Betrieb diverser Server und Clientsysteme im Forschungs- und Universitätsumfeld mit 800-1000 Nutzern. Trotz einer hohen Kundenzufriedenheit im Service blieben aber viele Projekte unvollendet und es mangelte an Fokus auf die Projekte. Gemeinsam mit Rainer Weigle, dem Leiter der IT Gruppe, entschloss sich Gunnar, im August 2012 Kanban einzuführen. Nach drei Monaten und drei Retrospektiven, in denen das Kanban Board immer wieder angepasst wurde, kam es dann erst im Februar 2013 wieder zu einer Retrospektive, gefolgt von einer Phase der internen Reorganisation. Während dieser Zeit wurde die Arbeit mit Kanban vernachlässigt, gewann im dritten Quartal 2013 jedoch wieder an Fahrt. Im Oktober wurde das Board noch einmal mit Fokus auf die Projektarbeit umgestellt. Parallel dazu gab es die erste Kanban-Implementation für eine andere Gruppe am MPI, gefolgt von weiteren Implementierungen und Info-Veranstaltungen Anfang 2014. Während das initiale Board überfüllt war mit Tickets, ist das aktuelle Board wesentlich aufgeräumter und übersichtlicher. Ein einsames Ticket hat es allerdings bis auf das neue Board geschafft. ;-) An den gezeigten Cumulative Flow Charts lassen sich viele Dinge, wie die Trennung der Gruppe, interne Restrukturierung, sowie erfolgreiche Umsetzungen aus Retrospektiven und dem letzten Redesign des Boards erkennen. Als Gunnar mit dem Fazit "Es braucht immer wieder jemanden, der Input gibt und den Prozess vorantreibt“ sowie "Selbstorganisation passiert nicht einfach und ist nicht mit selbständigem Arbeiten zu verwechseln“ schließt, gibt es zu Recht begeisterten Applaus.

Nach einer abschließenden regen Fragerunde gab es einen weiteren kurzen Vortrag von Rainer Weigle, Leiter der IT-Abteilung des MPI. Das MPI für Meteorologie ist eines von 80 Instituten der Max-Planck-Gesellschaft und ist in die drei Abteilungen Atmosphäre, Ozean und Land unterteilt. Insgesamt arbeiten hier etwa 250 Menschen an Modellen zur Klimaberechnung. Diese Berechnungen stellen extrem hohe Anforderungen an Rechenleistung, Parallelisierung, Netzwerk und Speicherplatz. Für die Klimamodellierung steht den Forschern am MPI der Hochleistungsrechner “Blizzard” zur Verfügung. Er wird betrieben vom DKRZ und ist weltweit einer der leistungsstärksten Rechner, der ausschließlich für Klimaberechnungen eingesetzt wird. Er besteht aus 264 Nodes mit jeweils 16 Dual Core CPUs @ 4,7 Ghz, 20 Terrabyte RAM, 4,8 Petabyte Filesystem und einer 7,6 TB/s Datentransferrate zum Filesystem.

Das Datenarchiv besteht aus 7 Sun StorageTek Tape Libraries, die jeweils von 8 Robotern versorgt werden. Die Einspeisung erfolgt über insgesamt 88 Laufwerke mit einer Rate von 3GB pro Sekunde. Die Gesamtkapazität beläuft sich auf 100 Petabyte gespeichert auf 67000 Bändern. Pro Jahr werden etwa 10 Petabyte an Archivdaten produziert.

Nachdem wir nun die unglaublichen Parameter dieses Großrechners gehört hatten, war es an der Zeit, diesen zu besichtigen. Im vierten Stock konnten wir eine komplette Etage mit langen Korridoren zwischen laut rauschenden dunkelgrauen Schränken bestaunen. Einige davon öffnete Rainer und präsentierte uns fein säuberlich verkabelte Systeme. Ein beeindruckender Großrechner, der bereits ab 2015 durch ein 18 mal schnelleres System mit 3 PFLOPs und einem 45 Petabyte Filesystem ersetzt werden soll. Mit diesem lassen sich dann die Berechnungen und Simulationen mit einem noch engeren Raster durchführen.

Am 17.02.14 fand bei it-agile ein Treffen der Limited WiP Society München statt. Der Fokus der Limited WiP Society liegt auf Lean und Kanban. Mit ungefähr 20 Teilnehmern wurde auf diesem Treffem eine Simulation, die die Skalierung mit Kanban erlebbar machen sollte in einer Art Workshop mit 4 Teams durchgeführt (siehe Ankündigung auf XING).

Ein wirklich tolles Treffen!

Der Workshopablauf

Es gab 4 Teams und 2 weitere Rollen:

• Team "Analyse"
• Team "Rumpf"
• Team "Aufbauten"
• Team Montag
• der Kunde
• der Boss

Letztendlich ging es darum Schiffe zu bauen, und zwar zwei verschiedene Arten:

• Faltschiffe
• Schiffe mit Rumpf und Aufbauten

Gestartet wurde aber sofort, nachdem die Teams aufgeteilt waren. Jedes Team bekam dann sukzessive ein Briefing über seine Aufgaben und Beschränkungen (ala "Ihr dürft nicht mit denen reden") und hatte ein Kanban Board (ohne WiP Limitierung) für seine Arbeit.

Gearbeitet wurde jeweils in 10 Minuten Iterationen (insgesamt 3), dazwischen gab es 5 Minuten für Team Retrospektiven und danach gab es auch gemeinsame Retrospektiven, moderiert vom Boss, in denen der Gesamt-Prozess angepasst wurde.

Der Start

Das Analyse Team ging direkt zum Kunden und bekam dort Aufträge für neue Schiffe, während die zwei "Teile"-Teams (Rumpf und Aufbauten) nur durch den Input des Analyse Teams bzw. das Montage Team durch Lieferung von Teilen getriggered wurden. D.h es hielt gerade am Anfang auch alle Fäden in der Hand.

Waste Waste Waste

Von Anfang an konnte man diverse Arten von Verschwendung beobachten (bobachtet aus der "Montage-Brille"):

• Das Montage Team stand 8 Minuten von den ersten 10 Minuten nur herum, da noch keine Lieferung kam
• In jedem Team hatten mehrere Leute nichts zu tun, der Input war zu dünn für die Teamstärke
• Das zweite Schiff wurde nicht vom Kunden akzeptiert ("ich wollte einen anderen Schornstein"), da es 
• keine Spezifikation für die zu liefernden Schiffe in der Montage gab, sondern nur eine Kiste, dadurch
• unvollständige Teile-Lieferungen in der Montage
• dadurch auch wachsende Lagerhaltung
• doppelte Lieferung von Schiffen (die der Kunde dann nicht doppelt haben wollte)
• Demontage von abnahmebereiten Schiffen
• Eingeschränkte Verfügbarkeit des Kunden für die Abnahme
• Übergaben
• Lagerhaltung vor den Übergaben
• Keine oder nur rudimentäre Kommunikation führte zu Irritationen und teilwiese Stillstand

Der erste Kontakt

In der ersten Teamübergreifenden Retrospektive nahm der Boss Problemstellungen auf und fragte nach Lösungsvorschlägen, die auch meistens von ihm angenommen wurden. U.A. wurden dann

• das Planungsboard vom Analyse Team wurde zentral für alle einsehbar aufgestellt
• das Rumpfteam durfte mit anderen Teams kommunizieren

Chaos

Dennoch wurde es dann auf einmal sogar richtig chaotisch. Dies fing damit an, dass der Boss dem Montage Team ein WiP Limit von 4 Teilen auf den Eingang legte, worauf das Montage Team alle folgenden Lieferungen ablehnte (was auch ein Aufbauten Teammitglieder )

Denn es brauchte zur Fertigstellung bereits teilmontierter Schiffe unbedingt einen orange-gestreiften Schornstein. Diese Info gab es auch an das Aufbauten Team weiter, dennoch dauerte es 2 Iterationen, bis endlich ankam:

Ein Kiste mit fertigen Schornsteinen gab es schon seit geraumer Zeit, diese wurde nur irgendwo vergessen und nur durch Zufall (oder Recherche?) wiederentdeckt.

Stattdessen wurden in dieser Zeit weiter neue Rümpfe gebaut in neuen Designs gebaut. Montageanleitungen gabs immer noch nicht (welcher Aufbau auf welchen Rumpf?), die auch nicht auf dem Kanban Board des Analyse Teams zu finden waren.

 Ist der Auftrag verschwunden oder wurde hier kreativ gebaut?!?

Die Schornsteine waren da da, fix mit dem Kunden abgestimmt, was wir bauen sollen und zwei Schiffe für die es keinen Auftrag auf dem Kanban Board gab, wurden dann vom Kunden nachträglich beauftragt und abgenommen. :)

Feature Teams

In der zweiten Retrospektive wurde dann der Vorschlag von Gerhard, Feature Teams einzusetzen, angenommen.

• In der Folge löste sich die Montage Abteilung komplett auf und in den beiden Teilefertigungen wurde auch die Endmontage durchgeführt.
• Z.B. das Rumpf Team bekam zwei Endmonteure und später wurde das ganze Team sogar noch nach teaminternen Beschluss geteilt, da es zu große war.
• Die Kommunikation mit dem Analyse Team wurde viel besser und innerhalb des nun crossfunktionalen Teams gab es keine Kommunikationsbarrieren und keine Silos mehr (jeder montierte mit)

Das Debriefing

Hier wurden die Kanban Flight Levels (vn Klaus Leopold) vorgestellt.

• Flight Level 1: In der ersten Runde des Workshop.
• Flight Level 2: In der zweiten Iteration wurde der Input limitiert und nur vollständige Lieferungen akzeptiert
• Flight Level 3: Ein Board für die gesamte Wertschöpfungskette wurde installiert.
• Flight Level 4, Portfolio Kanban, wurde am Board kurz erklärt

Danach wurde der Ansatz der Kanban Kata angesprochen, mit 3 verschiedenen Leveln des Prozess Reviews.

Feedback

Das Feedback, dass ich wahrnahm wahr folgendes:

• Ein Super Abend!
• Der Bezug zur Skalierung kam nicht so heraus
• Wenn man mal "am Arbeiten" ist (->Flow?!?), dann tritt das Thema Kanban Skalierung gefühlt in den Hintergrund
• Die "neuen Gesichter" wollen wiederkommen.
• Eine Aussage zum nachdenken für alle: "Wenn man Feature Teams hat, braucht man kein Kanban mehr!"

Mein Fazit

Mein persönlicher Eindruck war:

• Ein große Energie und ein lustiger Abend
• IMHO: Die Teilnehmer ohne (große) Erwartungen gaben eine deutlich bessere Bewertung in ihrem Feedback ab, als diejenenigen, die speziell am Thema Kanban Skalierung interessiert waren.
• Die Moderatoren waren als Kunde (Sebastian) und Boss (Wolfgang) ziemlich im Stress, das ist den Teammitgliedern aber nicht aufgefallen. Wichtig ist: Man muss einfach die Teams "am Arbeiten halten", in dem man dafür sorgt einen Rahmen vorzugeben, in dem sich die Teams selbst organisieren können.
• Um den Workshop zu verbessern könnte man die Flight Levels zwischendurch anmoderieren, anstatt nur im debriefing darauf einzugehen.

Nils Bernert

@nilsbernert

www.disruptivelearning.de

Stille herrschte in unserem Schulungsraum, als sich die Teilnehmer der ersten LWS Muc 2014 für sich die Frage beantworteten: ”Was ist das Beste was 2014 passieren kann?”

Sebastian und ich hatten für das Communitiy Treffen ein Thema vorbereitet, das etwas von Kanban entfernt war. Wir hatten die Idee, dass wir die Teilnehmer anleiten sich selbst zu helfen und ihnen gleichzeitig eine einfache Struktur an die Hand geben, die sie auch in ihrem Alltag anwenden können. Und diese Idee ging auf.

Doch der Reihe nach. Zu Beginn des Abends haben wir unsere Agenda vorgesellt, die

sich weitestgehend an die Struktur eine Retrospektive hielt.

Um allen Anwesenden eine Vorstellung zu geben, was ein Wunsch für 2014 sein kann, hat Sebastian mich nach meinem Wunsch gefragt. “Ich wünsche mir einen Kunden der mir vertraut und mit dem ich gemeinsam seine bestehende Welt in eine bessere entwickle”.

Schweigend schrieb jeder für sich seinen wichtigsten Wunsch (“Daten sammeln”) und formulierte ihn in im User Story Format. Die Ideen der Teilnehmer gingen von “ich möchte TDD in meinem Team einführen” bis hin zu “ich würde gerne Kanban in die Filmindustrie ausprobieren”.

Über Dot-Voting haben wir die interessantesten Themen gefunden. Ein Beispiel ist:

* Ich als Bühnenmalerin möchte Kanban in einem Filmprojekt einführen, um zu beweisen, dass es auch dort hilft.

Wir haben Kleingruppen gebildet, um 15 Minuten um “Einsichten zu generieren”. Dafür haben wir kurz `Powerful Questions` vorgestellt, die die Wünschenden dazu animieren sollen, die eigene Idee tiefer zu erforschen und besser zu verstehen. Es handelte sich um Fragen dieser Art “Was ist so wichtig, dass du dafür die Komfortzone verlassen möchtest?

“Wen betrifft es?” “Wie bekommst du deine Energie” uvm.

Hinterher haben wir uns wieder im großen Kreis getroffen und ein kurzes Debriefing gemacht. Heraus kam, dass der Redeanteil hauptsächlich beim “Wünschenden” lag. Durch die Fragen haben die Session-Hosts gesagt, dass sie ihren Wunsch und ihre Bedürfnisse dahinter besser verstanden haben.

Um zu “entscheiden was zu tun ist” haben sich die Kleingruppen wieder zurückgezogen. Im 1. Teil dieser Session haben wir lösungsorientiertere Fragen mitgegeben. (“Was wäre der richtige Zeitpunkt?”, “Wer fehlt?”, “Was funktioniert bereits, auf dem du aufbauen kannst?” uvm.)

Das Ziel dieser Fragen war, die Gedanken des Ideengebers in Richtung einer Lösung zu lenken.

Im 2. Teil dieser Kurzsession war die Aufgabe viele kreative Lösungsideen zu entwickeln und sich am Ende für einen ersten kleinen Schritt zu überlegen. Dafür haben wir das “safe to fail experiment” erklärt.

Folgende Eigenschaften hat dieses Experiment

• möglichst klein, möglichst kurz
• definierter Anfang, definiertes Ende
• Verantwortlicher
• Folgeaktionen
• Ziel des Experiments
• Festlegen, wann das Experiment erfolgreich / nicht erfolgreich ist

Nach ca. 25 Minuten sind wir wieder zusammen gekommen und haben gesammelt, was die Erfahrungen in dem Teil waren. Diesmal lag der Hauptredeanteil bei den Gruppenmitgliedern und je nach Gruppe sind unterschiedliche Ergebnisse herausgekommen. Für alle war auch dieser Teil wertvoll, um gemeinsam auf neue Ideen zu kommen, neue Perspektiven zu entwickeln und dann konkret an einem ersten Schritt zu arbeiten.

Mit der Vorstellung der Experimente haben wir den offiziellen Teil beendet.

Die Gruppe der Bühnenmalerin hat zum Beispiel die Idee erarbeitet, dass sie ein Projekt an der Filmhochschule unterstützen wird.

Das Bild des “return on time invested” zeigt, dass unsere Idee ankam, was wir auch als persönliches Feedback bekommen haben. Wir haben in den Kleingruppen viele tolle Diskussionen beobachten können, die unterschiedlich tief und persönlich waren.

Wir hatten viel Spaß bei der Moderation und gingen am Ende kaputt und glücklich nach Hause.

Es gibt viele Ansätze, Menschen, die noch keine Berührungspunkte mit der Kanban-Methode hatten, das Thema näher zu bringen. Ein effektiver Ansatz ist, die Grundprinzipien mit Spielen und kleinen Experimenten praktisch zu erläutern.

Das Treffen fand wie meistens in den Räumlichkeiten von it-Agile in der Rosenheimer Straße statt. Der Andrang war bereits im Vorfeld hoch, die Höchstzahl an Anmeldungen ist schnell erreicht; so ist es keine Überraschung, dass sich gegen 19:00 knapp dreißig Personen eingefunden haben. Der Abend beginnt mit einem launigen Austausch zwischen den regelmäßigen Teilnehmern und denen, die zum ersten Mal bei der Limited WIP Society dabei sind. Dazu gibt es kalte Getränke und eine Auswahl unterschiedlicher Pizze.

 Etwa eine halbe Stunde später eröffnet Wolfgang Wiedenroth den Abend mit ein paar Begrüßungsworten und einer Einführung über den Ablauf des Abends. In einem Marktplatz können alle Teilnehmer thematisch passende Spiele, die sie kennen oder dabei haben, einbringen und dann der Runde kurz vorstellen. Nachdem eine grobe Agenda zustande gekommen ist, geht es auch schon los mit dem ersten Spiel.

Beim ersten Spiel nehmen alle Anwesenden gemeinsam teil. Dabei bildet eine Person jeweils mit seinem Nachbarn ein Team. Pro Team gibt es jeweils einen Manager und einen Entwickler. Die Aufgabe des Entwicklers ist, eine Tabelle zu erstellen, in der es drei Spalten gibt. In der ersten Spalte sollten die Zahlen von 1 bis 26 stehen, in der zweiten Spalte die Buchstaben von A bis Z und in der dritten Spalte die römischen Zahlen von I bis XXVI. Der Manager ist dabei dafür verantwortlich, auf die Korrektheit des Ergebnisses zu achten, den Entwickler anzutreiben und zu motivieren und mittels einer Stoppuhr zu bestimmen, zu welchen Zeiten eine Spalte begonnen und abgeschlossen wurde.

 Der Clou daran ist, dass diese Arbeit zweimal durchgeführt wird. Beim ersten Durchgang müssen die Entwickler die Tabelle Zeile für Zeile erstellen. Dadurch sind die Anfangszeiten und die Fertigstellungszeiten für alle drei Spalten nahezu identisch. Beim zweiten Durchgang müssen die Entwickler die Tabelle Spalte für Spalte fertigstellen, die zweite Spalte wird also erst begonnen, nachdem die erste Spalte fertig ist.

 Nach den beiden Durchgängen werden die Zeiten miteinander verglichen und festgestellt, dass die Arbeit im zweiten Durchgang generell schneller beendet wurde. Die Manager erklären auf Nachfrage, dass beim ersten Durchgang mehr Fehler gemacht wurden. Nach einer Diskussion darüber, was denn für den Unterschied zwischen den Zeiten verantwortlich ist (Stichwort „Context Switching“) und welche Bedeutung das im Arbeitsalltag hat, wird damit der Kreis zum Thema Kanban und das Prinzip der Reduzierung des WIP geschlossen.

Dieses Spiel ist in fast jedem Kanban-Workshop anzutreffen und so durfte es auch an diesem Abend nicht fehlen. Dabei setzt sich eine Gruppe von sieben Personen an die Längsseite von zwei Tischen, so dass die Personen eine Kette bilden. Die ersten fünf Personen in der Kette haben dabei die Aufgabe, Schiffchen aus DIN A4 Blättern zu falten, wobei jede Person einen fest definierten Arbeitsschritt befolgen soll. Die vorletzte Person nummeriert das fertige Schiffchen mit einem Filzstift, die letzte Person notiert Nummer und Zeitpunkt der Fertigstellung auf einem Blatt Papier. Nach einer kurzen Weile markiert der Spielleiter ein Blatt Papier mit einem roten Filzstift; sobald das Schiffchen aus diesem Blatt das Ziel erreicht hat, endet der Durchgang.

 Durch die unterschiedlich komplizierten Arbeitsschritte der ersten fünf Personen kommt es schnell zu einer großen Menge an begonnenen Blättern und es bildet sich ein Rückstau. Es braucht entsprechend lange, bis all diese Blätter abgearbeitet wurden und das rot markierte Schiffchen das Ziel erreicht.

Im zweiten Durchgang wird das Pull-Prinzip bzw. ein WIP-Limit eingeführt: eine Person darf nun also nicht mehr unendlich viele Zwischenprodukte herstellen, sondern erst dann fortfahren, wenn die nachfolgende Person ein Zwischenprodukt abgeholt hat; erst dann ist wieder Kapazität frei. Auch hier markiert der Spielleiter nach der selben Zeit ein Blatt Papier mit einem roten Filzstift und das Spiel endet, wenn dieses Schiffchen das Ziel erreicht hat. Durch die Limitierung des WIP entstehen keine Rückstaus. Mit diesem Spiel lässt sich verdeutlichen, was in Kanban mit dem Begriff Durchlaufzeit gemeint ist und wie sich die Limitierung des WIP auf den Durchsatz auswirkt.

Auf dieses Spiel habe ich mich besonders gefreut. Dabei handelt es sich um eine Eigenentwicklung von Peter Rössler, die das Ziel hat, spielerisch den Teilnehmern beizubringen, wie man Durchlaufzeiten misst und wie man ein Spektral-Analyse Diagramm erstellt. Der Name des Spiels ist dabei eine Hommage an David Anderson – es ist also wichtig, auf korrekte schottische Aussprache („daahtaa“) zu achten. ;-)

 Das Spiel wird in einer Gruppe von sechs Personen gespielt und besteht aus mehreren Runden. Jede Runde besteht aus verschiedenen Aufgaben wie zum Beispiel das Aufblasen von Ballonen, das Sortieren von Karten oder das Erwürfeln einer bestimmten Zahlenkombination. Die Teilnehmer können selber planen und bestimmen, wie sie sich die Aufgaben untereinander aufteilen wollen und welche Strategien sie dafür anwenden. Für jede Einzelaufgabe wird die Durchlaufzeit erfasst; die Zeiten werden dann auf einem Flipchart oder einer Pinnwand erfasst, woraus sich im Laufe des Spiels ein Spektral-Analyse-Diagramm ergibt. Die gestellten Aufgaben sind abwechslungsreich, werden pro Runde anspruchsvoller und führten zu einigen lustigen Momenten.

Mehr dazu kann man in englischer Sprache auf Peter Rösslers Blog lesen:

http://proessler.wordpress.com/2012/10/04/learning-playfully-kanban-lead-time-spectral-analysis-chart-service-level-agreement/

Parallel zu den anderen Spielen gab es für eine Gruppe die Möglichkeit, die deutsche Übersetzung der vierten Auflage von getKanban auszuprobieren. Als Spielleiter fungierte dabei Florian Eisenberg. Bei getKanban handelt es sich um ein Brettspiel, bei dem der Alltag in einer Software-Entwicklungs-Firma simuliert wird. Es gibt eine Reihe von Projekten, die die Projektphasen Konzeption, Umsetzung und Test durchlaufen müssen, bis sie released werden können. Für jedes fertige Projekt werden pro Runde Einnahmen generiert. Ziel des Spiel ist, durch eine Optimierung des Prozesses einen hohen Umsatz zu erreichen. So einfach ist das aber nicht: zu Beginn jeder Runde (entspricht einem Tag im Spiel) wird eine Ereigniskarte gezogen, die das Spielerlebnis stark beeinflusst und die Pläne der Gruppe durcheinanderbringt. Auch die Auswahl der Projekte erfordert, nachhaltige Entscheidungen zu treffen: manche Projekte bringen keinen direkten Gewinn, wirken sich aber auf das Spielgeschehen aus.

 Während des Spiels wird nicht nur fleißig diskutiert und geplant, sondern auch noch am praktischen Beispiel gelernt, wie man Control-Charts und Cumulative-Flow-Diagramme erstellt, und was man aus ihnen herauslesen kann. Leider ist der Ausmaß des Spiels zu groß, um es an einem Abend fertigspielen zu können; es machte den Spielern trotzdem eine Menge Spaß.

Bei der reichhaltigen Fülle an Spielen war für jeden Anwesenden etwas dabei. Manche der Spiele waren so nachgefragt, dass sie mehrmals gespielt werden mussten. Für manche der Spiele, die beim Marktplatz vorgestellt wurden, blieb leider keine Zeit, da der Abend schon um 22:30 endete. Mir bereitete der Abend sehr viel Spaß und der Termin bildete damit einen gelungenen Jahresabschluss für die Limited WIP Society München.

This month's meeting of Hamburg's Limited WIP Society took place on Nov 7 at it-agile's office. It was great to have Jim Benson (based in the US, in Seattle) a few days longer in the city, which gave us another opportunity to get in touch with him. The topic was "Post-Agile Development and Lean Coffee". (Although we didn't get to the Lean Coffee part:-)

There were appr. 25 people around who gathered in the presentation area after refreshments and networking in the kitchen. Luckily it was dark already, so we did not get too distracted by the wonderful view of the river Elbe and the harbor area. Jim first talked about his personal background, having almost graduated a study of psychology, followed by working in the transportation industry for many years. Understanding both people and flow of traffic to me sounds like the perfect qualification for a Kanban expert.

Jim used stickies to maneuver himself through his otherwise freestyle presentation in the following manner:

That worked out pretty well, as it both guided him through the session and provided flexibility to switch topics as well. Jim then talked about capacity planning. He stated that work doesn't fit, work flows. Therefore the widely used capacity model is wrong. Work flows like traffic: On a highway, when traffic flows best at up to 65% of its capacity, with more and more jams until the highway is fully utilized (100% capacity used – yay!) but traffic is stuck. In his view, a sprint is a capacity planning tool. He pointed out several flaws around Scrum's concepts of story points and velocity: The same amount of story points comprising a very different mix of stories (e.g. 20 small stories vs. one or 2 big ones) does not result in a comparable amount of work. In addition, story points are widely abused, as they are handy integer numbers (presenting what exactly?), making people and particularly managers wanting to make calculations with them (e.g. time/ money). A bit cheeky, this part resulted in the simple formula of Velocity = "an integer number" / arbitrary sprint length. He suggest standard daily question to focus on the exceptions, e.g. blockers instead of status or the three standard Scrum questions, as the status is already visual and up-to-date on the board. Most of us working with Scrum know the effect of the "sprint-end crunch time", where story completion is sped up in order to keep the commitment (which Jim doesn't seem to be a big fan of either ;). In his experience, the time before the sprint end is the one where most errors are made an quality is sacrificed (consciously or unconsciously) in order to make the promised scope. The easiest way to remember that is this kind-of-faked chart:

Jim then used the Cynefin model as a continuum of possible contexts for creating solutions to show where Scrum and Kanban fit.

• Simple - use of best practice – making toast is oretty much the same all over the world
• Complicated - use of good practices, Scrum and Kanban sit here, need a flexible working model
• Complex - emergent practices, often not apparent what is going on, need group and/ or experiment(s) to solve, then back to complicated.
• Chaotic - purely reactive mode. E.g. incidents in IT Operations are unplanned, often have a simple solution but are in the complex domain for long–term fixing.

We then had a brief discussion of longs (stickies that just sit there day over day on don't move) at the board. Jim stated that they tend to be in the complex domain, which means that they are really hard to resolve by one person alone. His tip was to spot them early, and then swarm on them! Spotting them is kind of a challenge as people tend to cover up their problems and going on and on and on on their own… He suggested watching people's expressions when putting them on the board, supported by questions like "Does any of these scare you / make you concerned?" or "Is your pulse going up?".

In order to improve your Kanban system, ask folks what the board is NOT telling you. He believes lean approaches like Kanban are easier to get across than Scrum as they bring a shared language between IT and the rest of the organization. Gradually increasing the horizontal scope of the board is a straightforward way to improve collaboration and alignment between teams or departments.

Running around his no less than 4 easels, he then demonstrated "Demand pull" - we'd better be producing what our customers want. He suggested putting more focus on demand pull rather than solely interior pull which is what most teams working with Kanban take care of.

Jim then gave us a brief glance at Personal Kanban, which he invented: You could start with a small board and 4 columns as simple like this: Ready – Planned for Today – Doing – Done. People systematically overestimate what they can get done, and he says this is a powerful tool to acknowledge this fact for one personally (often through repetition). The chance here is with minimal effort to constantly watch one's own work flow and learn from it.

As in his LKCE13 session, he stressed that people and processes are symbiotic. He introduced us to Deming' system of profound knowledge: "Deming advocated that all managers need to have what he called a System of Profound Knowledge, consisting of four parts:

1. Appreciation of a system: understanding the overall processes involving suppliers, producers, and customers (or recipients) of goods and services (explained below);
2. Knowledge of variation: the range and causes of variation in quality, and use of statistical sampling in measurements;
3. Theory of knowledge: the concepts explaining knowledge and the limits of what can be known.
4. Knowledge of psychology: concepts of human nature." (quoted from Wikipedia).

When forcing ourselves out of processes we separate processes from humanity, separating processes from culture.

He encouraged us to embrace what we can and cannot estimate. If you can't properly estimate something, don't force false numbers on it.

He then told us a closing story of a team with very capable but totally different individuals where Kanban finally got them to buy into "the same game" despite their opposing ways of working. One reason people seem to like working in a Kanban system might be that it can be seen as a game with the goal to move stuff to the other side of the board quickly and in a way that it never comes back. Kanban makes people see more than their single task.

After all these interesting insights, it was easy to follow up with a few more vivid discussions accompanied by a few more drinks. Thanks to Jim and it-agile for a really nice and valuable evening!

„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.