Wat zijn DORA-metrics, en waarom zou ik me erom bekommeren?

Hoe weet je hoe je softwareorganisatie presteert? Hoe voorkom je dat je engineers gefrustreerd raken, vertrekken, overbelast raken of opbranden — en krijg je tegelijk eerlijke cijfers over hoe de teams het doen?

Bij ZEN Software vonden we het opvallend dat softwareontwikkeling — een vak dat tijdens het bouwen zo veel data oplevert en zo goed te observeren is — in de meeste organisaties nauwelijks gemeten wordt. We zagen dat de klassieke projectmatige manier van aansturen overheerste. Misschien herken je het volgende gesprek:

• Manager tegen engineer: “Hoeveel tijd heb je nodig voor deze taak?”
• Engineer: “9 uur”
• Manager: “Prima, maar ik controleer of je er niet meer aan besteedt! Want meer tijd aan deze taak lijkt me niet acceptabel.”
• Engineer: (stil) “Waarom zou je dat controleren? Deze taak is toch belangrijk?”

Het verzonnen gesprek hierboven laat de klassieke manier van softwareprojecten aansturen zien: op planning en uren. Dat kán werken, maar het heeft nare bijwerkingen. Het richt zich niet op de bedrijfswaarde van de taak, en 'planningsefficiëntie' staat op geen enkele manier in verband met de uitkomst van het softwareproject.

Sommige aanbieders van software-analytics pochen over efficiencyrapportages — om vervolgens micromanagementrapporten af te leveren. Bij een strak geplande, gedisciplineerd geschatte en efficiënt uitgevoerde operatie lijdt de techniek op de lange duur altijd flink. De combinatie van uit de hand lopende technische schuld, veel verloop en hoge druk op ontwikkelteams leidt uiteindelijk tot lage motivatie en burn-outs.

Is er een manier om 'de nare dingen' te vermijden bij het aansturen van softwareteams? Jazeker! Op basis van zes jaar onderzoek heeft het team van DevOps Research and Assessment (DORA) vier metrics geïdentificeerd die voorspellend zijn voor hoe goed je software levert:

1. Deployment Frequency (DF): hoe vaak je met succes naar productie uitrolt. Door dit te meten breng je het ritme van het uitrolwerk in beeld.
2. Lead Time for Changes (LT): de tijd tussen het committen van een codewijziging en het moment dat die uitrolbaar is. Deze metric is bepalend om de doorstroom van werk te zien.
3. Mean Time to Recovery (MTTR): de tijd tussen een storing door een uitrol of systeemfout en volledig herstel.
4. Change Failure Rate (CFR): hoe vaak wijzigingen of hotfixes van een team tot storingen leiden. Deze metric laat zien welke fouten er tijdens het ontwikkelen ontstaan.

Van deze metrics is aangetoond dat ze sterk samenhangen met:

• Minder verloop;
• Meer motivatie bij medewerkers;
• Hogere betrokkenheid van medewerkers.

DORA-metrics meten hoe softwareteams presteren en laten zien of ze “low performers” of juist “elite performers” zijn. Er is een snelle check van één minuut bij Google waarmee je ziet hoe je organisatie het in het algemeen doet, en hoe dat zich verhoudt tot bedrijven in dezelfde sector.

Met Agile Analytics van ZEN Software houd je alle DORA-metrics scherp in de gaten en leg je ze naast andere cruciale inzichten in je softwareorganisatie: Error Budgets, Teams en Kudos. Dat geeft een helder dashboardoverzicht van de organisatieprestaties en maakt datagedreven sturen mogelijk. Maar belangrijker nog: het leidt tot hogere productiviteit, snellere time-to-market, minder burn-out, meer betrokkenheid en gelukkigere engineers!