Kann man Agilität messen? Und wenn ja, wie und womit? Organisationen, die über viele Jahre sehr erfolgreich plangetrieben agierten und es deshalb gewohnt sind, in Kennzahlen zu denken, stellen sich diese Fragen eher früher als später auf ihrer Reise hin zu mehr Agilität. Unerschütterlich ist der Glaube an das Dogma, dass man nur managen kann, was man messen kann. Aber stimmt dieses Dogma überhaupt? Und ist es für die agile Transformation irgendwie nützlich und anwendbar?
It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.
W. Edwards Deming, The New Economics, S. 35
Als Urheber dieses Dogmas werden wahlweise W. Edwards Deming oder Peter F. Drucker genannt. Nur haben weder Deming noch Drucker das je so gesagt. Beide waren sich im Gegenteil der Grenzen der Messbarkeit durchaus bewusst, insbesondere dort wo es um Menschen und Führung geht.
Natürlich wäre es wünschenswert, eine Organisation oder ein Veränderungsvorhaben mit GPS-Genauigkeit steuern zu können: Position bestimmen, handeln, veränderte Position und damit Richtung und Fortschritt bestimmen. Wo das möglich ist, sollte man genau das natürlich tun. In den weitaus meisten Fällen wird das aber nicht oder wenigstens nicht einfach und direkt möglich sein. Dennoch muss irgendwie entschieden und gehandelt werden.
Nicht alles, was zählt, kann gezählt werden, und nicht alles, was gezählt werden kann, zählt.
Albert Einstein
Lange Zeit war ich fest davon überzeugt, dass die Vermessung der Agilität und das Management der agilen Transformation mit Kennzahlen direkt in die Cargo-Kult-Hölle führt. Das was wirklich zählt, die Effektivität, die Wertorientierung, die Anpassungsfähigkeit, die Resilienz, die Zufriedenheit der Kunden oder die Zufriedenheit der Mitarbeiter, ist recht aufwändig zu bestimmen.
Andererseits gibt es natürlich Dinge, die sich leicht beobachten und messen lassen, die bunten Haftzettel, die Backlogs, die Story Points und die Velocity der Teams, besetzte agile Rollen und absolvierte Trainings und vieles mehr. Nur ist all das nicht die Essenz der Agilität, sondern Phänomene, die man in agilen Organisationen beobachten kann. Diese Formen entspringen der Essenz, aber die Essenz lässt sich nicht mittels der Imitation der Form erzwingen.
Wenn nun in Unternehmenskulturen ohne ausreichende psychologische Sicherheit, dafür mit allerlei an Kennzahlen geknüpften individuellen Leistungsanreizen, begonnen wird diese Phänomene zu messen und zu belohnen, wird das Ergebnis notwendigerweise oberflächlicher Cargo-Kult bleiben. So weit meine bisherige Argumentation.
Rückblickend halte ich es mittlerweile aber für einen meiner größten Fehler, die Vermessung der Agilität und Kennzahlen für die agile Transformation bisher immer mehr oder weniger kategorisch abgelehnt zu haben. Die Gefahr einer Inflation des Cargo-Kults sehe ich zwar immer noch, aber ich würde das Risiko heute bewusst eingehen bzw. durch eine sehr sorgfältige Auswahl der Kennzahlen begrenzen.
Früher oder später kommt in jeder Transformation der Zeitpunkt, wo sehr nachdrücklich die Frage gestellt wird, was das alles soll und bringt. Und die einzige Sprache, in der eine Antwort darauf verstanden und akzeptiert werden wird, ist die Sprache der Kennzahlen. Insbesondere dann, wenn sich seit dem Beginn der Transformation die wirtschaftliche Situation des Unternehmens verschlechtert hat, die Grundstimmung gegenüber der Transformation vielleicht zu kippen droht oder wesentliche Protagonisten das Unternehmen mittlerweile verlassen haben.
Man muss das System, das man eigentlich überkommen will, mit seinen eigenen Waffen schlagen, sonst schlägt das System irgendwann unerbittlich zurück.
14 Kommentare
Marcus, danke für diesen Artikel. Ich habe mich auf dem Blog von Daniel Dubbel, inspectandadapt.de in der ergänzenden Betrachtung zum Thema Messbarkeitsdilemma auch für das Messen ausgesprochen.
Die Frage, woher das Zitat mit dem Messen und Steuern kommt, kann ich nicht beantworten. Wie auf Twitter jemand schrieb, könnte es sogar vom Naturwissenschaftler Lord Kelvin stammen, der bezogen auf die Physik sagte, dass erst eine Messung zu einem wahren Verständnis der Gegebenheiten führt.
Ich glaube, da ist auch im Kontext von Arbeit etwas daran. Agilität war und ist die Anwendung von empirischem Vorgehensweisen auf die Arbeit. Zu einem Inspect&Adapt gehört aus meiner Sicht immer auch die Validierung durch Messung.
Einen weitergehenden Beitrag gibt es von Jutta Eckstein, die sich mit dem Thema Data Driven Approach for company-wide agility beschäftigt.
Dazu gibt es auf meiner Webseite Links und einen spannenden Podcast mit der Jutta.
Ich arbeite seit Jahren in einem internationalen Konzern im Prozess- und Performancemanagement. Ich kenne eigentlich nur die Zeit der Veränderung mit Carve-Out und Carve-In mit der ständigen Notwendigkeit Org.- Prozess- und IT Umstrukturierungen durchzuführen. Dabei sind Mitarbeiter- oder Organisations Kennzahlen essentiell und wichtige diese über Treiberbäume auch an die Firmen Score Card KPI zu verknüfen.
Ja, genau das hatte ich ein wenig blauäugig unterschätzt und würde ich künftig anders machen.
Lieber Marcus, ich meine, das unser Unwohlsein beim Messen mehr aus dem Gefühl heraus kommt und im Prinzip schon richtig ist. Ich würde das zusätzliche Messen aber trotzdem sein lassen. Wenn man damit anfängt, bekommt man auch „Messer“. Die werden leicht zur Abteilung, die wie alle Abteilungen sich entsprechend „Murphy’s laws“ entwickelt. Also: „Wehret den Anfängen!“
Im übrigen bin ich absolut für eine konsequente „Kaufmännische Kontrolle“. Die erfordert auch Messen. Und Werte wie Umsatz, Kosten, Deckungsbeiträge müssen selbstredend gemessen werden, egal ob agil oder nicht. Das machen ja auch alle, man nennt die. Ergebnisse BWA und Bilanz. Dabei würde ich’s aber sein lassen.
Ich selbst hatte immer Interesse an Zahlen wie Durchschnittsalter, Gehaltsstrukturen, Krankheitstage. Auf so etwas würde ich heute verzichten. Qualitätsmessungen wie Fehler pro lines of Code (Software-Entwicklung) würde ich immer noch machen.
Roland, ein sehr treffender Kommentar! Danke dafür! Ich füge noch einen allgemeinen Gedanken hinzu. Immer, wenn von messen gesprochen wird, hat man zuerst sehr kleinteilige, Ganauigkeit vorgaukelnde Messungen im Sinn. Wir messen aber schon, wenn wir nur 3 Anteile einer Aufgabe definieren oder, wenn man Projetschritte zu Zeitspannen zuordnet. Die Genauigkeit der Messung hängt davon ab, was ich WARUM(!) messen will. Die „Fehler pro lines of Code “ sind unerlässlich, weil man sich fragen muss „Was ist der Grund? für die Zahl? Ist der Programmierer nicht leistungsfähig, weil er z.B. aus Kostengründen in drei Projekten gleichzeitig arbeiten muss? Oder ist ihm der übergeordnete Funktionale Zusammenhang nicht deutlich? Oder sollte man ihn auffordern, eine ausreichende Anzahl von Kommentarzeilen einzufügen, damit er und seine Vertreter bei jeweils erneutem Einsteigen in die Aufgabe sofort Aufsetzpunkte haben? Gerade Agilität verlangt aufgrund horizontaler und damit vertikaler Differeierung – auch bis hin zur Kleinteiligkeit – ein Verständnis an den Anschlsspunkten, die inhaltlich, zeitlich, persönlich und besonders kommunikativ sind. Und Kommunikation bedeutet nicht, man versteht sich, nein, man verständigt sich. Und dazu helfen die cuts, die Maßgaben. Messen so weit verstanden, wird zur Findung der angemessenen (Achtung Wortspiel) Skalierung der Messung führen. Das Thema des Messens sollte immer Teil von Entscheidungsvorgängen sein.
Gute Ergänzung, lieber Frank. Das Warum ist entscheidend. Und auch die Kultur in der diese Zahlen erhoben werden. Oder mit den Worten von W. Edwards Deming: „Whenever there is fear you will get wrong numbers.“
Lieber Roland, damit hast du meinem Unwohlsein wieder Auftrieb gegeben. Ich bin da immer hin- und hergerissen. Aber vermutlich würde ich mir künftig sehr genau überlegen, woran wir den Erfolg der Transformation erkennen (und messen).
Lieber Marcus,
vielen Dank für diesen (wie alle anderen) Artikel!
Ich möchte mich Rolands Kommentar anschließen. Messung zur Wirtschaftlichkeit müssen sein. Aber auch dies in Maßen. Ich sehe eines der wichtigsten Aspekte im agilen Kontext ist und bleibt die Qualität. Nur daran können sich Teams messen. Schon seit Jahren praktiziert Google die sogenannte „WTF“ Messung (=Anzahl Fehler im Code ). Egal ob SW Entwicklung oder Produkte/Dienstleistungen sollte an der Qualität gemessen werden. Zusätzlich erachte ich den Happiness Index als angemessen zu messen. Die Ergebnisse beider Messungen können Führungskräfte unterstützen hilfreich einzuschreiten wenn dies von Teams erwünscht ist. M E wissen aber die Teams selber woran es liegt wenn es mal nicht funktioniert und wie man dies beheben kann *zwinker*
Die passenden KPIs muss man allerdings selbst finden und da liegt wohl eher der Hund begraben. Es gibt keine Blaupause die zu allem paßt (wie so oft im agilen Umfeld) und daß wird vom Management nicht immer verstanden.
Liebe Melania, danke für die Erinnerung an die WTF / Minute als die einzige Maßzahl für Code-Qualität ;-) Qualität ist aber schon ein sehr guter Ansatzpunkt. Darum schrieb ich Kundenzufriedenheit und eben auch Mitarbeiterzufriedenheit, weil es sonst nicht nachhaltig ist.
Danke Dir, Marcus und allen anderen, die durch diesen Artikel angeregt wurden, über das Thema nachzudenken. Einige sind sogar so weit gegagnen, einen Kommentar zu verfassen.
Und wenn Du die Anzahl der Kommentare zur Grundlage nimmst, dann ist das hier ein durchaus wirksamer Beitrag zur Diskussion um „Kennzahlen der Agilität“. ;-)
Ich verorte das „Problem“ mit dem Messen weniger an den Zahlen als an dem, was sie bedeuten. Es ist verführerisch, eine Veränderung der Zahl als Verbesserung oder Verschlechterung anzusehen. Tatsächlich ist es erheblich, ob jemand das versteht, was die Zahl abbildet.
Oder wie es @LukasDonSchmidt auf dem letzten agiLEipzig Barcamp ausdrückte:
„Das Problem an Deiner Kennzahl ist, dass Du Subjektivität auf Irrelevanz abbildest.“
https://commodus.org/agile-leipzig-barcamp‑4/
Im selben Kontext nannte Volker Schramm das „Popometrie“.
Zahlen sind sehr gut geeignet, den Blick auf das Wesentliche, die Effektivität des Handelns zu verschleiern.
Und dann fiel mir noch ein:
„20% in to do and 80% in progress is nothing to ship!“
Ein Teilgeber aus dem agiLEipzig-Umfeld testete seinen Beitrag „Overcommitment“.
Ich selbst habe immer wieder die Burndown-Muster „Ritterburg“ und „Abgrund“ beobachten können.
https://commodus.org/agile13-barcamp-warmup/
Sehr wahr, lieber Alexander. Wer viel misst, misst viel Mist, heißt es ja auch.
Ob Messen oder nicht, die Kennzahlen gehen am Problem vorbei. Sie sind Indizien für Führungskräfte, die von dem was sie führen wenig bis gar keine Ahnung haben. Schauen Sie sich mal die Geschichte der Bell Labs an. Die waren so erfolgreich, weil es eben diese Kennzahlen nicht gab, die Führungskräfte aber ein Ahnung davon hatten, was die Mitarbeiter gemacht haben. Das Kennzahlensystem proklamiert, daß jeder der zwei Zahlen vergleichen kann, sinnvolle Entscheiden treffen kann. Das wage ich zu bezweifeln. Zur Wirtschaftlichkeit: das halte ich m. E. für eine Theorie der Erbsenzähler. Wirklich gute Führungskräfte und Unternehmer spüren, ob sich eine Investition in die Zukunft lohnen wird. Denn eine sog. Wirtschaftlichkeitsberechnung ist zu dem Zeitpunkt, wo sie fertiggestellt wird, schon nicht mehr gültig in einer Welt mit einem so rasanten Wechsel, wie wir ihn haben. Da hilft eben nur Beweglichkeit (oder Agilität?). Prognosen sind eben schwierig, besonders wenn sie die Zukunft betreffen (Karl Valentin).
Das ist genau der Fall, wenn die Diskussion genauso interessant ist wie der Beitrag selbst ;)