NBA38: DORA Teil II: Missinterpretation und Kritik
Shownotes
Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile oder ihr hinterlasst mir eine Sprachnachricht: +4950329677123
—
NBA37: DORA
Agile Usergroup
DORA
Zusammenfassung
In dieser Episode betrachten wir die häufigsten Missinterpretationen und Kritikpunkte an den DORA-Metriken im agilen Kontext. Ein zentraler Punkt ist, dass Zahlen oft missverstanden oder manipuliert werden und nicht dazu dienen sollten, Teams miteinander zu vergleichen oder Zielvorgaben zu bestimmen. Die Metriken sind ein Werkzeug zur Analyse innerhalb des Teams, nicht fürs Management oder den externen Vergleich.
DORA-Metriken zeigen den Status eines Teams und helfen, Ansatzpunkte für Verbesserungen zu identifizieren. Sie sollen jedoch nicht als Proxy für Business Outcomes gesehen werden, da sie keine Aussagen über den Wert oder Erfolg der gelieferten Features machen. Letztlich sind die Zahlen Indikatoren und keine Zukunftsprognosen, und sollten niemals den Fokus auf schnelle, aber wertlose Auslieferungen fördern.
Transkript
Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Ich bin Teil eines Agilen Teams und bespreche hier jede Woche Themen aus der Agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Man fokussiert auf der Praxis, daher auch der Name No Bullshit Agile.
In der letzten Folge habe ich eine Einführung in Dora gegeben. Dora steht für DevOps Research and Assessment. Wenn dich das interessiert, hör da gerne rein. Den Link dazu findest du in den Shownotes. Das hier ist die Folge 38, und heute möchte ich ein bisschen über die Missinterpretation und auch die Kritik zu Dora sprechen.
Bevor wir da einsteigen, ein bisschen Housekeeping. Ich habe beim letzten Mal schon ein bisschen darüber erzählt. Ich habe ja vor, eine Agile User Group zu gründen – eine virtuelle Agile User Group – und wir haben tatsächlich einen ersten festen Termin. Das ist der 12.11. um 19 Uhr. Alle Informationen dazu findest du in den Shownotes. Da gibt es einen Link zu einer Webseite, wo ich ein bisschen den Hintergrund auch erkläre, wie das technisch abläuft und all die Dinge, die ihr wissen müsst. Also 12.11., 19 Uhr – wenn du Lust hast, komm gern vorbei.
Ja, dann würde ich sagen, steigen wir mal ein. Ich habe das ein bisschen unterteilt in einen Bereich Missinterpretation und einen Bereich Kritik, und ich würde mal sagen, wir fangen bei diesen Missinterpretationen an.
Und das erste Thema lautet „Zahlen sind Zahlen.“ Ja, das hatte ich beim letzten Mal schon kurz angedeutet. Zahlen haben immer einen negativen Touch, denn Zahlen dienen oft für den Vergleich. Und das Problem an Zahlen ist: Die lassen sich in der Regel auch manipulieren. Jetzt haben wir mit Dora im Prinzip vier Zahlen vor der Brust und machen mal ein Beispiel: Nehmen wir mal an, die Deploy Frequencies sind zu klein, also ihr deployt zu wenig. Das kann jetzt einfach super viele Gründe haben, und diese Gründe kennt eigentlich auch nur das Team, also ihr selber. Zum Beispiel, vielleicht sind eure Stories zu groß oder ihr habt zu viel Work in Progress oder Abhängigkeiten zu anderen Stories. So, und dann habt ihr einen geringen Wert bei der Deploy Frequency – bzw. einen hohen, je nachdem, wie man das sehen will.
Und natürlich ist es richtig gut, und deswegen ist Dora ja auch toll. Also, ich finde es halt auf jeden Fall toll, auch wenn die Folge heute so ein bisschen in den negativen Bereich geht. Denn ihr habt jetzt eine Möglichkeit, das zu interpretieren. Drei Interpretationen habe ich gerade schon genannt. Ihr habt jetzt eine ganz konkrete Zahl, anhand derer ihr gucken könnt: Okay, wo ist denn da wohl unser Problem?
Das Problem ist, wie so oft mit Zahlen – also, ich habe mal über Velocity ein bisschen „gerantet.“ Ja, das sind halt eure Zahlen, wenn ihr in einem Team arbeitet, und die sind nicht fürs Management. Wenn sie mal entfleuchen oder das Management sie nutzt oder vielleicht das Management sogar sagt: „Ey, lasst mal Dora einführen!“ – ja, dann können zumindest Probleme anfangen. Wie gesagt, Zahlen liefern eine Messbarkeit und eine Vergleichbarkeit, also zumindest fühlen sie sich immer so an. Und ja, dann kann viel Schlechtes passieren, zum Beispiel der Fokus auf Output statt Outcome. Ihr liefert Müll schneller aus, damit eure Deploy Frequency runtergeht, so müsste man es, glaube ich, sagen. Vielleicht ist es aber viel besser, ein bisschen langsamer zu liefern, dafür aber mehr Wert. Das hängt natürlich jetzt ganz stark von der individuellen Situation ab, und ihr innerhalb des Teams wisst das, glaube ich, auch. Es geht mir hier vor allem darum, dass euch klar ist, wenn ihr was mit Dora macht, für wen sind diese Zahlen? Die sind für euch als Team.
Der nächste Punkt: Metrics als Ziel, als Zielvereinbarung – habe ich in Klammern noch geschrieben, das hängt ein bisschen am ersten Punkt. Es kann halt passieren, dass auf einmal dann Dora benutzt wird, um, ja, ich sage mal Vereinbarungen und Ziele zu definieren – Quartalsvorgaben für Teams, die OKRs hängen vielleicht daran. Ja, dann ist auch Tür und Tor für schlimme Dinge geöffnet worden, denn ihr könnt es nicht vergleichen. Und man kann auch – garantiert, und das ist auch schon der nächste Punkt – Dora-Metrics nicht benutzen, um Teams untereinander zu vergleichen. Team A, Team B, Team C und dann zu sagen: „Dieses Team ist besser als jenes Team, weil der Dora-Wert besser ist.“ Das wird nicht funktionieren. No size fits all: Jedes Team ist anders, jedes Team hat eventuell andere Kunden, nutzt andere Techniken, hat eine andere Maturity (Erwachsenheit, weiß ich nicht, wie Maturity gut übersetzt ist), hat eine andere Struktur der Teammitglieder. Man kann Teams nicht vergleichen. Also, das hat auch, ehrlich gesagt, gar nichts mit Dora zu tun, sondern das gilt immer. Bloß bei Dora hätte man halt Zahlen und könnte auf die Idee kommen, Teams zu vergleichen.
Es gibt tatsächlich Fälle, wo Unternehmen Dora-Metrics der Teams auf so Status-Bords oder Dashboards veröffentlichen. Ja, das ist natürlich ein echtes Problem, denn ja, da steht dann auch so was wie: „Team B hat die Change Lead Time um 12 Prozent gesteigert.“ Das ist schön fürs Team B und wird wahrscheinlich total sinnvoll sein, aber das macht jetzt Team C nicht schlechter. Und deswegen halte ich von solchen Zahlen auf Dashboards auch überhaupt nichts. Auch hier, wie gesagt, man kann das eben nicht vergleichen.
Das ist auch noch so eine Missinterpretation: Dora-Metrics sind kein Business Outcome. Also natürlich gibt es durch Dora Core, also die Kriterien, wie hängt alles zusammen, auch die Aussage, und die halte ich auch für richtig. Dora ist ein wichtiger Teil, um auch etwas für das Business Outcome des Unternehmens zu tun. Es ist sogar ein ganz wichtiger Teil und trotzdem haben die Metrics direkt nichts mit Business Outcome zu tun. Man hat dahinter keine Aussage oder eine Berechenbarkeit, zum Beispiel auch nicht zu „Was ist wann fertig?“ Also, wir hatten die Diskussion – oder ich hatte das Thema schon im Bereich Velocity – das sind Vergangenheitswerte, und Dora-Werte sind auch Vergangenheitswerte. Das ist ein Ergebnis dessen, wie ihr in letzter Zeit gearbeitet habt. Und daraus kann ich die Zukunft nicht prognostizieren, so gerne wie ich das hätte. Es geht halt einfach nicht, weil wenn wir in einem agilen Umfeld arbeiten und unbekannte Dinge bearbeiten, dann kann alles Mögliche passieren. Deswegen ist es ja eben so schwierig, und deswegen machen wir unbekannte Dinge, und deswegen gehen wir iterativ vor. Und da wird auch Dora uns nicht helfen, die Zukunft vorherzusagen – soweit vielleicht zu Missinterpretationen, über die man so stolpern könnte.
Vielleicht der andere Punkt, die hängen schon irgendwie zusammen, aber ich habe sie halt einfach getrennt: Welche Kritik gibt es so ganz im Allgemeinen an Dora? Und die erste Kritik, die man anbringen kann, ist: Wert wird nicht berücksichtigt, „Value.“ Ihr findet in den Metrics jetzt keine direkte Zahl, die irgendwie den Wert des Gelieferten mit der Liefergeschwindigkeit korreliert, und das ist Absicht. Diese vier Werte in Dora – das ist jetzt nicht irgendwie vergessen worden, Wert zu berücksichtigen, sondern es geht eben darum, anzuzeigen, wo stehen wir. Und Value wird da eben ganz explizit rausgenommen. Das muss man wissen, man sieht das auch ziemlich offensichtlich. Aber wenn man mit anderen diskutiert, die vielleicht nicht so tief drinstecken, dann ist das eben einfach eine ganz bewusste Entscheidung, Value hier nicht zu berücksichtigen.
Dann der nächste Punkt, den man anbringen kann: Dora verhindert jetzt natürlich nicht, dass man etwas falsch macht. Der Punkt ist ein bisschen hart, aber ja, den muss man sehen, den muss man anerkennen. Man kann natürlich sehr gute Dora-Metrics haben, aber die komplett falschen Dinge liefern. Also, keine Ahnung, Mean Time to Recovery ist vielleicht schlecht, aber der Grund dafür momentan ist, dass ihr ein Experiment am Laufen habt, um zu gucken, ob da Potenziale drin sind. Dann habt ihr vielleicht einen schlechten Wert – also, wie gesagt, Mean Time to Recovery vielleicht als ein Beispiel – aber das ist ja eine bewusste Entscheidung von euch. Und die Konsequenz wäre ja, wenn man sagt, wir wollen aber unsere Dora-Werte jetzt hier nicht gefährden, wir machen keine Experimente mehr – und das wäre natürlich auch fatal.
Das nächste ist die Frage oder die Kritik: Was, wenn die Zahlen nicht gut sind? Was dann? Und ehrlich gesagt, ich finde die Kritik ein bisschen dünn, denn ich hatte ja gerade schon gesagt, Dora Core zeigt euch ja ziemlich gut, welche Abhängigkeiten es gibt. Sprich, wenn die Dora-Metrics nicht gut sind – also, nach eurer Interpretation nicht gut sind, nach der Interpretation von euch als Team – ja, dann habt ihr genug Ansatzpunkte, um zu gucken, was ist davor und danach, was sind die Gründe dafür, oder was könnten die Gründe dafür sein und an welcher Schraube wollen wir drehen. Und deswegen, na klar, Dora-Metrics ist ein Anzeiger für euch. Ihr müsst dann tiefer buddeln – wie gesagt, in der Kette davor gucken oder in der Kette danach gucken, wo können wir ansetzen.
Und der letzte Punkt der Kritik – klang vorhin schon mal ein bisschen an – es gibt kein Business-Kontext. Ja, ich teile die Kritik, ich kann das nachvollziehen, aber das heißt nicht, dass Dora schlecht ist. Also, es geht hier in diesem abgesteckten Raum auch nicht um Business und Company Metrics. Man kann aber – das ist ein bisschen mein Plädoyer – sagen: Wenn die Zahlen euch helfen, aufzuzeigen, an welcher Schraube ihr drehen könnt, und ihr damit dann potenziell auch irgendwann mal einen Business Outcome habt, dann finde ich das völlig ausreichend und dann hat Dora auch einen guten Zweck erfüllt.
