Les DORA Metrics, oui mais pour quoi faire ?
Un dogmatisme en chasse un autre…
Les DORA Metrics c’est bien...
Si vous ne connaissez pas le livre Accelerate et plus globalement le travail du DORA ainsi que le rapport qu’ils éditent chaque année, vous passez à côté de quelque chose ! 1
Le DORA Model, c’est une véritable mine d’or :
Un modèle, avec des preuves empiriques basées sur des corrélations statistiques significatives, qui illustre et explique le lien entre un certain nombre de pratiques d’ingénierie logicielle et la performance de livraison (le delivery) ainsi qu’avec les résultats de l’organisation : autant sa performance commerciale que non-commerciale, et également le bien-être des collaborateurs.
Des métriques clés — les célèbres DORA Metrics — pour mesurer la performance de delivery, ainsi que des benchmarks permettant à chacun de positionner son équipe ou son organisation par rapport à l’état de l’art et par rapport à l’ensemble des praticiens.
Un référentiel de pratiques, d’outils et de métriques permettant d’outiller toute démarche d’amélioration continue, d’audit ou de transformation.
Le modèle se focalise sur l’ingénierie logicielle et donc sur “l’IT“, mais les répondants viennent de toutes les industries : cela ne s’applique donc pas uniquement aux solutions “IT for Tech“. Au contraire, tous les départements IT sont concernés, y compris dans la majorité des organisations où l’IT n’est pas la finalité mais une fonction support du business — du “IT for Business”. Bref, ça s’applique à tout le monde, pas d’excuse possible ! 2
Bon, je m’arrête là. En résumé, va te renseigner dessus, ça va changer ta vie.
Le site du DORA 👉 dora.dev
Des métriques sacralisées
Le travail du DORA et notamment le livre Accelerate ont eu un tel impact, que les DORA Metrics ont été positionnées dans de nombreuses organisations, conférences et meetups comme un mètre-étalon à avoir absolument.
Jusqu’au point où, comme souvent avec ce qui marche, on rentre dans le dogmatisme…
Il faut avoir ces métriques, et puis voilà !
Le but de cet article est de challenger cela.
Et de poser cette question, un peu coquine :
Les DORA Metrics, OK, mais POUR QUOI FAIRE ?
Une mise en œuvre pas si évidente que ça
Quand on lit les rapports DORA, on a une définition qui semble claire des différentes métriques, ça a l’air super, on se dit qu’on n’a qu’à y aller et les mettre en place.
Mais en pratique… ça ne marche pas comme ça.
À chaque fois que j’ai accompagné une organisation à les mettre en place, c’est compliqué.
À chaque fois :
Soit on n’arrive pas à mettre en place toutes les métriques, et on finit avec une vision incomplète et orientée
Soit on bricole en prenant une définition qui ne reprend pas exactement celle du DORA, avec le risque d’être moins pertinent
Ou les deux en même temps 😬
À chaque fois, on bute sur des projets où la réponse technique de comment mesurer n’est pas évidente.
⛔ On n’a pas accès aux bonnes choses (droits d’accès et outillages)
🫢 Manque de rigueur pour avoir les éléments (on ne trace pas de manière claire, précise et sans ambigüité les mises en production)
📚 Diversité des outils de références, toutes les informations utiles ne sont pas au même endroit, et c’est compliqué de tout recroiser
⚙️ Utilisation de progiciels (comme des ERP) où les développements se passent dans des écosystèmes spécifiques et avec des contraintes propres
🤷 Ou on ne voit tout simplement pas comment s’y prendre !
Premier constat : toujours ce même perfectionnisme qui a du mal avec l’approximation et avec l’apprentissage empirique. Se dire qu’on va y aller avec quelques pilotes et aviser ensuite, ce n’est pas évident.
Et quand on passe ce cap, on bute cette fois à la difficulté à se positionner dans un temps long, en faisant évoluer progressivement les approximations et incomplétudes.
Bien sûr, on bute sur toutes ces contraintes sans intégrer à quel point ce sont des symptômes de choses bien plus graves :
On n’est pas capable de savoir quels ont été les déploiements et leurs contenus exacts ? C’est en soi un problème bien plus grave que celui de ne pas réussir à extraire les DORA Metrics…
On n’est pas capable de faire la différence entre des déploiements normaux et planifiés, ainsi que des déploiements de type hotfix de correction en urgence ? Même remarque…
On ne sait pas remonter dans l’historique GIT jusqu’au premier commit ? Ca pose beaucoup de questions sur la rigueur de l’utilisation de GIT… La pratique du squash est souvent là pour masquer l’inexistence ou l’inutilité des commentaires des commits intermédiaires. 3
Mais surtout, pour quoi faire ?
Oui, à quoi bon s’embêter si ces métriques sont si galères à mettre en place ?
La réalité est la suivante :
Souvent, trop souvent, on ne se pose pas vraiment cette question du
“pour quoi faire ?”
On a juste vu l’émulsion autour des DORA Metrics, ce sont devenus autant de buzzwords qui font rêver sans qu’on ne sache trop pourquoi, et cela s’est alors imposé comme une évidence qu’il fallait les mesurer.
La suite logique : on mesure… Et on en fait du reporting. Bête et méchant.
On a alors perdu complètement de vu l’objectif du DORA :
“Get better at getting better”
L’objectif n’est plus l’amélioration continue, une vraie bonne démarche d’amélioration continue qui repose sur des métriques et plus largement qui se calque sur la démarche scientifique…
L’objectif devient les métriques elles-mêmes. 😭
Voici donc pourquoi mesurer les DORA Metrics 🎁
Si vous cherchez à rentrer dans une démarche d’amélioration continue via la mesure, vous n’avez pas besoin des DORA Metrics. Pas spécifiquement des DORA Metrics. Les DORA Metrics peuvent vous servir, mais elles ne sont pas les seules métriques pertinentes. Vous pouvez en utiliser d’autres.
Et même, vous devez en utiliser d’autres, a minima en complément, car les DORA Metrics ne suffisent pas.
Bien sûr qu’il vous faut des métriques. Pas nécessairement celles-ci.
Voici par contre 3 raisons qui justifient de se calquer spécifiquement sur les DORA Metrics :
Pour se comparer aux autres
Une des raisons pour lesquelles Accelerate a ébranlé la tech, c’était en apportant une vue globale et comparative de l’industrie, et la notion de performers.
Bref, fournir un benchmark public et reconnu auquel tout un chacun peut se comparer.
Si pour vous ou dans votre contexte cette notion de benchmark a de la valeur en soi, alors c’est pertinent d’investir dans la mesure des DORA Metrics.
Que cela soit pour frimer, ou comme levier de négociation en brandissant les rapports DORA, en mode “regardez comme on est nuls et comment on pourrait être incroyables, allez go go go” 😀
Pour utiliser le DORA Model comme framework de transformation
Le travail du DORA peut être utilisé comme base pour structurer une démarche complète de transformation. La sortie du DORA Core Model 2.0 avec le rapport de 2024 ne laisse plus de doute là-dessus, c’est un cas d’usage validé et encouragé par le DORA.
Par exemple, avec Robin Béraud-Sudreau, on avait appelé ça faire une data-driven transformation. On le promouvait sur Scrum Life via des formations et des accompagnements spécifiques. 4
Dans ce cadre, l’utilisation des DORA Metrics permet de légitimer l’approche en renforçant le lien avec le DORA Model.
Pour motiver les ingénieurs via une démarche reconnue à l’externe
DORA propose également un programme pour reconnaître publiquement l’utilisation du modèle. Ce sont les Google Cloud DORA Awards. 5
Comme la plupart des macarons à décrocher, c’est surtout un outil de communication, autant en interne pour motiver les collaborateurs, qu’en externe pour inciter des candidats à rejoindre la société. 6
“Start with why”
Mais surtout... Demandez-vous POURQUOI.
Vous pouvez par exemple faire un “Start With Why” de Simon Sinek 🙂
Les DORA Metrics ne sont jamais la finalité. Toujours un moyen.
📏 Partez de ce moyen
❓Demandez-vous POURQUOI dans votre contexte — POUR QUOI
🧠 Puis seulement après réfléchissez aux moyens à mettre en œuvre, en ayant en tête vos véritables objectifs : vous retomberez peut-être sur les DORA Metrics… Ou au contraire pas. Et vous vous éviterez alors bien des problèmes.
🚀 Enfin, et toujours en gardant en tête le Why, mettez-vous en action !
Nous avions d’ailleurs commencé sur Scrum Life une série sur le sujet, qui pose d’excellentes bases. Voici ci-dessous les vidéos principales, ainsi que les documents que nous offrions en complément des vidéos. Ces derniers ne sont plus disponibles suite à l’arrêt de Scrum Life.
Accelerate en résumé
Le DORA Core Model en français
Les DORA Metrics
Evolutions entre le livre Accelerate et le rapport DORA de 2024
Focus sur les Capabilities
Si ce que je viens d’écrire, c’est du chinois pour vous, je vous invite à lire l’article suivant qui pose les bases de GIT et plus largement de la gestion de version et de l’intégration continue
Je n’y évoque pas la notion de squash, en quelques mots c’est la possibilité dans GIT de fusionner plusieurs versions en une seule. Cela peut permettre de nettoyer un historique, mais mal utilisé on perd de l’historique, ce qui complexifie le calcul DORA du Change Lead Time qui se base canoniquement sur cet historique de versions dans GIT.
Nous avions fait sur Scrum Life une vidéo de retour d’expérience de notre intervention chez Cegid pour une démarche data-driven transformation.
Si ce type de démarche vous intéresse, je vous invite à vous rapprocher de Robin pour en échanger plus. Il a commencé ce type de démarche avant Scrum Life, il est un des pionniers d’Accelerate en France.
Si ça vous intéresse, je vous invite à nouveau à vous rapprocher de Robin Béraud-Sudreau qui a accompagné des organisations qui ont pu décrocher cette récompense.
Quand je vous dis que c’est le pionnier d’Accelerate en France !
J’ai envie de faire le parallèle avec le fameux “Best place to work” que vous avez forcément vu ici et là. Ce sont les mêmes enjeux de communication. Par contre, et contrairement au Best place to work, je ne considère pas les Google Cloud DORA Awards comme bullshit. Ce n’est pas le sujet de cet article, alors je n’élaborerai pas plus — on peut en discuter en privé 😉