NBA37: DORA

Hallo und herzlich willkommen bei NoBullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Man Fokus liegt auf der Praxis, daher auch der Name NoBullshit Agile. In der letzten Folge habe ich über das Agilerer dargesprochen. Wenn dich das interessiert, hör da gerne rein, den Link dazu findest du in den Show Notes. Das ist die Folge 37 und heute möchte ich eine kleine Einführung in Dora geben. Dora steht für DevOps Research and Assessment. Bevor wir in das Thema einsteigen, erst mal ein bisschen Housekeeping. Ich habe schon länger die Idee eine virtuelle Agile User Group zu gründen und das nimmt jetzt Form an. Es gibt einen ganz konkreten Termin, nämlich den 12., 11. um 19 Uhr. Es gibt eine Infoseite dazu, den Link dazu findest du in den Show Notes. Wann, wie, wo? Ich will aber kurz erklären, worum es da geht. Ich bin ja großer Fan vom Austausch. Das ist der Hauptgrund, warum ich diesen Podcast gegründet habe. Ich glaube, durch den Austausch und um die Agilität kommt man einfach einen großen Schritt weiter und wie User Groups so gebaut sind. Ich suche halt Gleichgesinnte, die Lust haben, ein bisschen über das Thema zu quatschen. Wir haben momentan sechs Leute, die kommen wollen. Das finde ich total toll und die Idee ist tatsächlich zu sagen, wir treffen uns regelmäßig alle vier Wochen den zweiten Dienstag im Monat. Wie gesagt, all diese Details findest du auch nochmal auf der verlinkten Webseite hier in den Show Notes. Sprich, wenn du Lust hast, schau da gerne rein, kommen gerne am 12., 11. Das Ganze ist, ja, mit einem Videokonferenzsystem gemacht. Ich nutze da ein selbstgehostes Next Cloud. Das ist also nicht irgendwie Teams oder Google Mail oder Google Meet heißt es, oh je mini, sondern tatsächlich selbst gehostet für all die Leute, die sagen so Datenschutz und solche Systeme weiß ich nicht so genau. Und ich würde jetzt einfach erstmal ohne großes Format, Lien, Koffi oder so was in der Art starten wollen, dass wir uns einfach mal treffen, ein bisschen quatschen und vielleicht in dem ersten Treffen uns drüber unterhalten, wie wollen wir was machen oder wollen wir es einfach so ganz informell lassen, was mir tatsächlich auch ziemlich recht wäre. Ich glaube, es gibt genug zu besprechen. Ich glaube, da muss man nicht groß was vorbereiten und ich glaube, das muss man nicht groß strukturieren und organisieren. Ich glaube, unser Arbeitsalltag ist schon super strukturiert und deswegen würde ich es jetzt erstmal versuchen, ja, das Ganze ziemlich informell einfach zu halten. Ja und dann würde ich sagen, steigen wir mal ein. Was ist Dora? Wie gesagt, Dora steht für DevOps Research and Assessment und ist mal als eine wissenschaftliche Studie gestartet und das ist tatsächlich auch interessant. Es ist mehr oder weniger eine Sozialstudie tatsächlich gewesen, 2013 gestartet und die Idee ist halt zu sagen, was machen erfolgreiche Teams. Da kommt man dann gleich natürlich im Kern drauf, vielleicht noch ein bisschen so zum Einordnen. Die Firma hinter Dora, die wurde dann später, ich glaube, 2018 von Google tatsächlich gekauft. Ich denke, das ist gar nicht schlecht oder gar nicht schlecht gewesen für das Projekt, ist einfach mehr Geld da. Google hat sicherlich Interesse, gut Software zu entwickeln und deswegen denke ich, das ist gar nicht so schlecht. Diese Studie findet einmal im Jahr statt. Die Berichte dazu werden auch veröffentlicht. Die neuesten Berichte dazu muss man sich registrieren. Die älteren Berichte, die kann man sich tatsächlich so runterladen. In 2023 haben da 36.000 Menschen in dieser Studie mitgemacht, die da befragt wurden. Der Fokus liegt tatsächlich auf DevOps. Es geht also wirklich um Softwareentwicklung und eine der großen Fragen ist tatsächlich, wie kann man die Messbarkeit von Softwareentwicklung herstellen? Es geht aber tatsächlich um die Devs. Das werden wir auch in der heutigen Folge sehen später. Warum ist nicht um Management und nur Durchsatz oder so was geht, sondern es geht darum, eine Umgebung so zu bauen, dass Devs lange gut Software entwickeln können. Also Burnout ist zum Beispiel auch ein Thema in dieser Studie und es geht darum, den Devs, den Teams, Werte an die Hand zu geben, messbare Werte, damit sie kontrollieren können, welche Maßnahmen erfolgreich waren und welche nicht. Ziel davon ist eben nicht irgendeine tolle Zahl, sondern gute Software, die Menschen benutzen. Schluss endlich basiert die Werte auf Software Delivery als Maß und das macht tatsächlich auch Sinn. Ich hatte nach Folge 35 mal drüber gesprochen, dass es für mich total Sinn macht, Werte zu liefern und das als eine Orientierung für Entscheidungen zu nehmen und deswegen passt Dora mit der Idee einfach super gut rein. Welche Werte werden jetzt hierher rangenommen? Es gibt ja viele, viele Werte. Ihr kennt wahrscheinlich alle Velocity und ihr wisst auch, denke ich einfach mal, dass für mich Velocity einfach überhaupt keine gute Zahl ist. Warum ist es nicht so? Na ja, Velocity kann ich halt schießen. Ich kann halt sagen, dass was letzte Woche fünf Punkte waren, ist diese Woche 13 oder so und deswegen macht für mich Velocity einfach überhaupt keinen Sinn. Diese vier Werte, die hier herangenommen werden, die betrachten das Ganze aus einem ganz anderen Blickwinkel, aber sie sind total sinnvoll. Diese vier Werte sind folgende, die sind nochmal unterteilt in Durchsatz und Stabilität und innerhalb von Durchsatz gibt es zwei Werte und innerhalb von Stabilität zwei Werte. Innerhalb von Durchsatz ist der erste Wert Change Lead Time. Wie lange dauert es vom Code Commit bis dieses Feature in Produktion ist? Von Code Commit bis Deploy. Der zweite Wert innerhalb von Durchsatz ist Deployment Frequency. Wie oft deployt ihr zu Produktion und diese beiden Werte sind zusammengefasst zu Durchsatz. Die nächste Kategorie ist Stabilität. Auch darin gibt es zwei Werte. Der erste ist Change Fail Percentage. Wie groß ist die Prozentzahl der Deployments, die fehlt schlagen, also in Produktion. Und der zweite Wert ist Failed Deployment Recovery Time. Wie lange dauert es, sich von so einem Fail ja zu erholen. Und wenn man sich die Werte genauer anguckt, dann zielen die eben genau darauf ab zu sagen, okay, wir wollen gute Software schnell in die Hände der Menschen bringen. Und das ist so genial da dran. Es gibt auf der Webseite, den Link findest du in den Show Notes, Dora.dev, einen sogenannten Quick Check. Da werden genau diese vier Werte abgefragt und man kann so schieber schieben, um sich selber mal einzuordnen. Was glaube ich, wo stehe ich da und bekommt dann so eine Auswerte und sieht, wo man innerhalb von der Studie erfassten Daten stehen würde. Du bist im unteren Drittel, du bist in der Mitte oder du bist im oberen Drittel. Ergänzend dazu, aus der Studie gibt es jetzt noch kausale Zusammenhänge, sogenannte Dora Core. Welche Bedingungen müssen erfüllt sein, um diese vier Keymetrics zu steigern, sage ich mal. Und da sind wir dann eben bei dieser Menschenkomponente, von der ich gesprochen habe. Die haben in 2024 diese Übersicht überarbeitet. Das war früher so ein Netzmodell mit sehr vielen Pfeilen, um diese Abhängigkeit darzustellen. Und sie haben selber halt gesagt, über die Jahre ist es immer komplexer geworden, dieses Modell. Und sie versuchen das jetzt ein bisschen zu kondensieren. Und es gibt jetzt so eine Übersicht über das Core Modell. Und man kann auch so einen Haken setzen, zeigt mir Details, dann wird es ein bisschen detaillierter. Aber ich beschreibe mal die Übersicht. Das fängt halt an mit Capabilities. Und das sind drei Kriterien genannt. Nämlich Climate for Learning. Also wie gut ist das Umfeld im Unternehmen, damit wir Devs lernen können? Fast Flow. Was tun wir denn, um unseren Flow zu erhöhen? Und Fast Feedback. Wie gut sind unsere Feedback-Zyklen? Und ihr werdet feststellen, vieles davon habe ich in anderen Folgen tatsächlich auch schon behandelt, weil es eben Grundvoraussetzungen sind, um dieses Ziel zu erreichen, schnell gute Software zu liefern. Und das ist so der erste Teil. Und dann geht es in eine andere Übersicht. Die nennt sich dann Performance. Und die hängen zusammen Capabilities und Performance. Die bauen aufeinander auf. Dann finden wir innerhalb von Performance im Software Delivery. Da sind diese vier Keymetrics drin. Und Reliability, Service Level Objectives. Dann im nächsten Schritt hängt wieder von Performance auch ab. Kommt Outcomes. Und da geht es um Organizational Performance. Das sind eben wie gut performt unser Unternehmen. Und Well-Being. Da sind dann ganz viele, ja ich sage mal, humaner Aspekte drin. Ich habe ja vorhin gesagt Burnout zum Beispiel. Und dieses Modell kann man eben aufklappen. Man kann so eine Detail an sich machen und dann tauchen viel mehr Kriterien auf innerhalb dieser drei Hauptkategorien Capabilities, Performance, Outcome. Das lese ich jetzt nicht alles vor. Das ist sicherlich für Podcast auch nicht geeignet. Den Link zu dieser Übersicht findest du in den Show Notes. Man kann immer auf diese einzelnen Dinge klicken und kriegt auch so eine Erklärung dann noch dazu. Und es gibt natürlich dazu auch ausführlichere Texte. Ich kann jedem nur empfehlen, da mal rein zu gucken. Also zum Beispiel, ich pick jetzt immer nur was raus. Bei Capabilities hatte ich vorhin gesagt Climate for Learning. Und da steht dann sowas wie Documentation Quality als ein Detail dazu. Fast Flow, da steht sowas wie Version Control dazu. Oder Continuous Delivery. Fast Feedback, da steht sowas wie Test Automation. Bei Performance unterhalb von Software Delivery steht sowas wie Change Lead Time. Bei Reliability steht sowas wie Target Optimization. Bei Outcome finden wir sowas wie Commercial Performance. Bei Wellbeing finden wir sowas wie Reduce Burnout. Ja, wie gesagt, dieses Schaubild, das muss man glaube ich wirklich selber lesen. Das ist für ein Podcast und ehrlich gesagt auch für ein Video. Selbst wenn ich Video machen würde, nicht so gut geeignet. Mir geht es hier darum, dass ihr die Inspiration bekommt, da rein zu gucken. Ich selber kann ich auch sagen, wenn ich Studie höre, bin ich immer so ein bisschen skeptisch und denke mir viel zu lesen, viel Akademisches. Ich muss aber wirklich sagen, wenn man das runterkondensiert, zuallererst mal auf diese vier Keymetrics, Durchsatzstabilität mit jeweils zwei Kategorien darunter. Wenn man sich den Quick Check mal anguckt, das geht ziemlich schnell. Und wenn man sich diese Doracore Übersicht mal anguckt, kriegt man einen ziemlich guten Blick darauf, was wohl Dora ist und kann dann eigentlich ganz gut tiefer darin einsteigen. Das Schöne an Dora ist eben, es basiert auf Studien. Es hat einen sehr guten Ansatz in der Idee, wie kann man Messbarkeit herstellen? Es nutzt Messbarkeit nicht als Management Instrument, sondern um ein weiter Feedback Loop zu haben für das Dev Team. Ich finde, man kann sehr gut daran messen und sich sehr gut daran orientieren, welche Parameter wollen wir angehen, um gute Software schneller zu liefern. Und dieses gute Software schnell liefern, darum geht es halt wirklich. Daran hängt auch unter anderem der Unternehmenserfolg. Also Messbarkeit ist immer ein strittiges Thema. Das weiß ich. Ich selber sage das ja hier auch immer wieder. Aber Dora findet da wirklich einen sehr guten Ansatz. Ich plane eine weitere Folge. Es gibt auch für Dora natürlich eine Missinterpretation. Und das wäre mir heute für die Folge zu viel. Ich bin nicht sicher, ob die Folge wirklich nächste Woche schon erscheinen wird oder ob ich noch ein anderes Thema dazwischen mit reinnehme. Aber ich will gerne an dem Thema weiterarbeiten. Ja und das soll es für heute tatsächlich auch schon gewesen sein. Wie immer interessiert mich deine Meinung? Vielleicht kennst du Dora schon in und auswendig. Vielleicht nutzt ihr das schon in der Praxis. Dann würde mich natürlich interessieren, wie? Mich würde auch interessieren, habt ihr an bestimmten Stellen Probleme damit gehabt? Vielleicht hast du versucht das schon mal anzusprechen, ob man nicht an der Stelle was machen will und bis da dran gescheitert. Dann würde mich das natürlich auch interessieren. Wo waren vielleicht Blockaden bei dir im Unternehmen dazu? Wenn du Feedback hast, vielleicht auch ganz allgemein zu dieser Folge, dann hast du verschiedene Möglichkeiten, mich zu erreichen. Du kannst mir ganz klassisch eine Mail schreiben, nobs@gmail.com ist meine E-Mail-Adresse. Ich bin sehr aktiv auf Mastodon und parallel zu diesem Podcast gibt es auch immer einen Forum. Und zu jeder Folge lege ich da auch einen Forum Thread an. Das heißt auch da kannst du mir gerne Feedback geben. Relativ neu ist noch, dass du mir eine Sprachnachricht hinterlassen kannst. Die Telefonnummer findest du auch in den Shownutz. Da kannst du anrufen und mir im Prinzip auf dem Anruf beantworten, ein Feedback hinterlassen. Das hat tatsächlich auch schon mal jemand benutzt. Vielen Dank an dieser Stelle. Schöne Grüße. Nutzt das gerne. Regel nutzt alle Feedback-Kanäle gerne. Regel, wie immer in der Agilität Feedback ist eine ganz fundamentale Sache für meine oder die nächste Iteration dieses Podcasts. Dann habe ich noch eine Bitte. Wenn dir die Folge gefallen hat, wenn dir der Podcast gefallen hat, wenn dir das vielleicht sogar geholfen hat, dann teile das bitte gerne. Teile es mit deinen Kolleginnen und Kollegen. Sprich in deinem Team darüber. Teile es gerne auf deinen Social Media Kanälen. Je mehr Leute hier mitmachen, desto besser wird die Diskussion und desto mehr kann ich auch wieder im Podcast verarbeiten, um wieder mehr Leute zu erreichen. Ich hoffe mir so einen Effekt von angeregter Diskussion und damit für jeden von uns eine Verbesserung im agilen Bereich. Habt noch eine ganz tolle Woche und bis zum nächsten Mal. Bye. [Musik] [Ausschrei]