NBA37: DORA
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.
Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/56-nba37-dora
—
NBA36: Das Agile Radar
Agile Usergroup
NBA35: Liefert echte Werte!
DORA
- 4 Keys: https://dora.dev/guides/dora-metrics-four-keys/
- DORA QuickCheck: https://dora.dev/quickcheck/
- DORA Core: https://dora.dev/research/
Zusammenfassung
In der aktuellen Folge geht es um eine Einführung in DORA (DevOps Research and Assessment), eine wissenschaftliche Studie, die Teams dabei unterstützt, ihre Softwareentwicklungsleistung zu messen. DORA identifiziert vier Schlüsselmesswerte, die in "Durchsatz" (Change Lead Time, Deployment Frequency) und "Stabilität" (Change Fail Percentage, Failed Deployment Recovery Time) unterteilt sind. Diese Werte helfen Teams, die Geschwindigkeit und Qualität ihrer Softwarelieferungen zu verbessern.
Transkript
Hallo und herzlich willkommen bei No Bullshit 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. Mein Fokus liegt auf der Praxis, daher auch der Name No Bullshit Agile. In der letzten Folge habe ich über das Agilerer [wahrscheinlich: „Agilität“] gesprochen. 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 rund um die Agilität kommt man einfach einen großen Schritt weiter. Wie User Groups so gebaut sind: Ich suche 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, am zweiten Dienstag im Monat. Wie gesagt, all diese Details findest du auch noch mal auf der verlinkten Webseite hier in den Show Notes. Sprich, wenn du Lust hast, schau da gerne rein, komm gerne am 12.11. Das Ganze wird, ja, mit einem Videokonferenzsystem gemacht. Ich nutze da ein selbstgehostetes Nextcloud. Das ist also nicht irgendwie Teams oder Google Mail, oder Google Meet heißt es – oh je – sondern tatsächlich selbst gehostet, für all die Leute, die sagen: Datenschutz und solche Systeme, weiß ich nicht so genau.
Und ich würde jetzt einfach erst mal ohne großes Format – Lean Coffee oder so etwas in der Art – starten wollen, dass wir uns einfach mal treffen, ein bisschen quatschen und vielleicht in dem ersten Treffen uns darüber unterhalten, wie wollen wir was machen oder wollen wir es einfach 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 denke, unser Arbeitsalltag ist schon super strukturiert, und deswegen würde ich es jetzt erst mal versuchen, das Ganze ziemlich informell 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 gewesen, die 2013 gestartet wurde, 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 gewesen für das Projekt, es ist einfach mehr Geld da. Google hat sicherlich Interesse, gute 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 – da 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 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 später sehen. Es geht nicht um Management und nur Durchsatz oder sowas, 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.
Schlussendlich basieren die Werte auf Software Delivery als Maß, und das macht tatsächlich auch Sinn. Ich hatte nach Folge 35 mal darüber gesprochen, dass es für mich total Sinn macht, Werte zu liefern und das als eine Orientierung für Entscheidungen zu nehmen. Deswegen passt Dora mit der Idee einfach super gut rein. Welche Werte werden jetzt hierherangenommen? Es gibt ja viele, viele Werte. Ihr kennt wahrscheinlich alle Velocity und ihr wisst auch, denke ich einfach mal, dass für mich Velocity überhaupt keine gute Zahl ist. Warum ist das so? Naja, Velocity kann ich halt manipulieren. Ich kann halt sagen, das, was letzte Woche fünf Punkte waren, ist diese Woche 13 oder so, und deswegen macht Velocity für mich überhaupt keinen Sinn.
Diese vier Werte, die hier herangenommen werden, betrachten das Ganze aus einem ganz anderen Blickwinkel, aber sie sind total sinnvoll. Diese vier Werte sind folgende, die sind noch mal unterteilt in Durchsatz und Stabilität. 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 zur Produktion? 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 fehlschlagen, also in Produktion? Und der zweite Wert ist Failed Deployment Recovery Time. Wie lange dauert es, sich von so einem Fail 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 daran.
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 man bekommt dann so eine Auswertung und sieht, wo man innerhalb der 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. Sie haben 2024 diese Übersicht überarbeitet. Das war früher so ein Netzmodell mit sehr vielen Pfeilen, um diese Abhängigkeit darzustellen. Sie haben selber gesagt, über die Jahre ist es immer komplexer geworden, dieses Modell, und sie versuchen, das jetzt ein bisschen zu kondensieren.
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 an mit Capabilities, und da sind drei Kriterien genannt: Climate for Learning – also, wie gut ist das Umfeld im Unternehmen, damit die Devs lernen können? Fast Flow – was tun wir, um unseren Flow zu erhöhen? Und Fast Feedback – wie gut sind unsere Feedback-Zyklen? 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. Das ist so der erste Teil.
Und dann geht es in eine andere Übersicht, die nennt sich dann Performance. Capabilities und Performance hängen zusammen. Die bauen aufeinander auf. Dann finden wir innerhalb von Performance im Software Delivery diese vier Keymetrics und Reliability, Service Level Objectives. Dann, im nächsten Schritt, hängt wieder von Performance ab, es kommt Outcomes, und da geht es um Organizational Performance – also, wie gut performt unser Unternehmen? – und Well-Being. Da sind dann viele, ich sage mal, humanere Aspekte drin. Ich habe ja vorhin Burnout erwähnt, zum Beispiel. Dieses Modell kann man eben aufklappen, man kann sich die Details anzeigen lassen, 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 einen Podcast auch nicht geeignet. Den Link zu dieser Übersicht findest du in den Show Notes. Man kann auf die einzelnen Punkte klicken und bekommt auch eine Erklärung dazu. Es gibt natürlich auch ausführlichere Texte dazu. Ich kann jedem nur empfehlen, da mal reinzuschauen. Zum Beispiel, wie stark wirkt sich Fast Feedback auf Deployment Frequency aus? Das ist total spannend, sich mal damit zu beschäftigen, weil das dann eben wieder den Kreis zu den Werten schließt, die ich vorher erwähnt habe.
