Sehr wahr, lieber Alexander. Wer viel misst, misst viel Mist, heißt es ja auch.

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/

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.

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.

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

Ja, genau das hatte ich ein wenig blauäugig unterschätzt und würde ich künftig anders machen.

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.