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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/57-nba38-dora-teil-ii-missinterpretation-und-kritik

NBA37: DORA

Agile Usergroup

DORA

Transkript anzeigen

Hallo und herzlich willkommen bei NoBullshit Agile. Mein Name ist Thomas. Ich bin Teil eines Agilenteams und bespreche hier jede Woche Themen aus der Agilentprojektwelt. 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 NoBullshit Agile. In der letzten Folge habe ich eine Einführung in Dora gegeben. Dora steht für DevOps Research and Assessment. Wenn ich 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 vorhin eine Agile User Group zugründende 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 da ein bisschen den Hintergrund auch erkläre, wie das technisch abläuft und all die Dinge, die ihr wissen müsst. Also 19.11.19 Uhr, wenn du Lust hast, komm gern vorbei. Ja, dann würde ich sagen, steigen wir mal ein und 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 mal 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 wir machen mal ein Beispiel, nehmen wir mal an die Deploy Frequencies zu klein. Also ihr deploys zu wenig. Das kann jetzt einfach super viele Gründe haben und diese Gründe kennt eigentlich auch nur das Team, also ihr selber. Also 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. also einen hohen, so 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 granted. Ja, die sind halt eure Zahlen, also eure Zahlen, wenn ihr in einem Team arbeitet und die sind nicht fürs Management. Wenn sie mal entfläuchen oder das Management sie nutzt oder vielleicht das Management sogar sagt, ey, lasst mal Dora einführen. Ja, dann können zumindest können die 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 den Focus 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, aber dafür 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 allen Dingen darum, dass euch klar ist, wenn ihr was mit Dora macht, für wen sind diese Zahlen und 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 an dem ersten Punkt. Es kann halt passieren, dass auf einmal dann Dora benutzt wird, die Zahlen 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 dieses Team, weil der Dora-Wert besser ist oder Teile des Dora-Werts. Das wird nicht funktionieren. No size fits all, jedes Team ist anders, jedes Team hat eventuell andere Kunden, nutzt andere Techniken, hat eine andere Majority Erwachsenheit, weiß ich nicht, wie Majority gut übersetzt ist, hat eine andere Struktur der Teammitglieder. Man kann Teams nicht vergleichen, also es 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 Teams oder Unternehmen, Dora-Metrics, der Teams auf so Status-Bords oder Dashboards veröffentlicht. 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 so 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, mit der Kette da vorne danach, wie gesagt, schaut euch gerne mal Dora Core an, um auch etwas für das Business Outcome des Unternehmens zu tun. Es ist sogar ein ganz wichtiger Teil und trotzdem hat 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 denn immer gilen 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 vorher zu sagen, soweit vielleicht zu Missinterpretationen über die man so stolpern könnte. Vielleicht der andere Punkt, die hängt 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 drin stecken, 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 was 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 eine 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, 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önnen 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, wenn nicht Dora schlecht ist, also es geht hier in diesem abgesteckten Raum auch nicht um Business und Business Value, sondern es geht darum, eine anfassbare pragmatische Matrix zu haben, mit der ihr als Dev-Team arbeiten könnt, mit der ihr als Dev-Team Verbesserung findet. Und die Studie zeigt eben ja auch ganz klar, dass diese Werte, Kernwerte sind im Entwicklungsprozess, nicht die einzigen, aber Kernwerte, die euch helfen, bessere Software schneller zu liefern. Dora zeigt ja unter anderem eben auch, dass es eben kein Widerspruch ist Qualität und Geschwindigkeit, sondern ganz im Gegenteil, ich brauche die Geschwindigkeit, um meine Qualität zu erhöhen, weil ich halt eben mehr Feedback schneller bekomme und das ist überhaupt kein Widerspruch. Insgesamt jetzt über zwei Folgen kann ich halt nur sagen, beschäftigt euch damit, ich sage nicht führts gleich ein, aber ich finde den Quick Check, den kann man auf jeden Fall machen, den gibt es auf der Webseite, hatte ich in der letzten Folge ein bisschen was drüber erzählt und schaut doch einfach mal, wo steht ihr da? Man sieht ja auch einen schönen Überblick zu den Damen, die die Studie erhoben hat, heißt das Wort. Nutzt es ruhig, schaut da mal nach und guckt mal, wo steht ihr denn? Und dann habt ihr eigentlich einen super schönen Ansatzpunkt im Team, um zu gucken, können wir was verbessern, warum stehen wir hier, wo wir stehen und was hindert uns da vielleicht einen Schritt weiterzukommen. Ja und das soll es für heute auch schon gewesen sein, wie ist eure Meinung dazu? Mich würde mal interessieren, nutzt ihr Dora? Kennt ihr das? Kanntet ihr das schon? Vielleicht habt ihr es genutzt und wieder abgebrochen? Das sind so all die Dinge, die mich natürlich aus der Praxis interessieren, gebt mir gerne dazu Feedback, steckt dazu gerne mit anderen in die Diskussion ein. Du erreist mich auf verschiedenen Kanälen, kannst du mir zum Beispiel ganz einfach eine Mail schreiben an nobs@gmail.com, du findest mich auf Mastodon, es gibt hier parallel zu dem Podcast ein Forum zum Austausch, für jede Folge lege ich dann einen einzelnen Thread an, auch da kannst du gerne diskutieren mit mir und du kannst mir auch eine Sprachnachricht hinterlassen, all die Links um mich zu erreichen, findest du in den Schonorts. Eine Bitte habe ich noch, wenn dir die Folge gefallen hat, hat sie dir sogar geholfen, dann teil die gerne, teil sie mit Kolleginnen und Kollegen im Team, vielleicht mit anderen Teams, mit Leuten, die du kennst, teil sie gerne auf deinen Social Media Kanälen, mir wäre es halt recht, wenn möglichst viele Leute dem Podcast hören, nicht weil ich Kohle damit verdienen will, sondern ich habe den Podcast halt mal gegründet, um ins Gespräch, um in Diskussion mit anderen zu kommen und genau da hilft natürlich, wenn es viele Leute diesem Podcast hören. Ganz vielen Dank dafür, habt eine ganz tolle Woche und bis zum nächsten Mal. Bye. [Musik]

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.