L’amélioration continue est un objectif que nous souhaitons tous et toutes inclure dans notre quotidien. Pourtant, nous sommes plusieurs à «déprioriser» l’amélioration continue lorsque nous avons des feux à éteindre ou des tâches à valeur ajoutée concrète à réaliser pour nos collègues. Mais saviez-vous qu’il existe une réelle valeur financière à l’amélioration continue en développement logiciel? Dans cet article de blogue, découvrez le retour potentiel d’améliorer vos performances de livraison logicielle.
Afin d’estimer le retour potentiel de l’amélioration continue dans les équipes de développement, nous allons utiliser principalement les quatre métriques clés du rapport State of DevOps de DORA (DevOps Research and Assessment), une équipe de Google qui étudie la performance des professionnels de l’industrie technologique.
Les quatre métriques DORA sont séparées en deux catégories, soit la vitesse et la stabilité. Après avoir fait un sondage auprès de plus de 32 000 professionnels et organisations, l’équipe de DORA a pu distinguer quatre groupes de performance (élite, haute, moyenne et basse) en plus d’y associer des résultats de référence.
Les quatre métriques DORA sont séparées en deux catégories, soit la vitesse et la stabilité. Après avoir fait un sondage auprès de plus de 32 000 professionnels et organisations, l’équipe de DORA a pu distinguer quatre groupes de performance (élite, haute, moyenne et basse) en plus d’y associer des résultats de référence.
| Aspect de la performance de livraison | Élite | Haute | Moyenne | Basse |
| Fréquence de déploiement (combien de fois l’organisation déploie en production à l’utilisateur final) |
Sur demande (plusieurs déploiements par jour) |
Entre 1x par semaine et 1x par mois | Entre 1x par mois et 1x tous les 6 mois | Moins d’une fois tous les 6 mois |
| Délai nécessaire aux changements (le temps écoulé entre le premier commit et la livraison en production) |
Moins d’une heure | Entre 1 jour et 1 semaine | Entre 1 et 6 mois | Plus de 6 mois |
| Délai de récupération après un échec de déploiement (le temps nécessaire pour réparer le service à la suite d’un incident) |
Moins d’une heure | Moins d’un jour | Entre 1 jour et 1 semaine | Plus de 6 mois |
| Taux d’échec des changements (le pourcentage des changements en production qui causent un incident) |
0 to 15% | 16 to 30% | 16 to 30% | 16 à 30% |
Source : State of DevOps 2021, Google. Note : L’analyse des résultats dans l’édition 2022 du rapport sur l’état du DevOps n’a détecté que trois groupes : performances élevées, moyennes et basses. Afin de bien démontrer l’ampleur du retour potentiel d’une équipe performante, nous utiliserons les données de 2021 qui comportent les quatre groupes initiaux.
Dans le but de créer le maximum de valeur pour l’organisation, les meilleures équipes ont compris qu’elles doivent optimiser la vitesse de livraison. Il y a des pertes de valeur dans les coûts d’opportunité ou lorsqu’on consacre des efforts sur du travail sans valeur ajoutée (par exemple, du rework non nécessaire ou des tests manuels), mais qui pourrait être consacré à du travail à valeur ajoutée (par exemple, de nouvelles fonctionnalités). Il y a aussi une perte de valeur lorsqu’on repousse le déploiement d’un nouveau produit ou d’une fonctionnalité, notamment par une perte de revenus ou de clients que l’entreprise ne génère pas, mais qu’elle aurait pu attirer en livrant plus rapidement.
La capacité à découvrir et livrer plus rapidement à vos clients est un très grand avantage compétitif que fournissent les paradigmes du Lean et de l’agilité, et ils resteront des avantages pour les années à venir.
Les coûts évités par l’entreprise sont considérés comme un retour, car ils ont un impact direct sur les revenus et les dépenses du budget initial. Par exemple, si vous avez un budget initial de 100 millions $ en dépenses, et que par l’amélioration d’une technologie vous avez maintenant des dépenses qui s’élèvent à seulement 80 millions $, vous avez 20 millions $ de disponible qui n’étaient pas planifiés initialement.
Pour calculer le retour potentiel de s’améliorer, nous additionnerons donc la valeur recouverte dans le rework non nécessaire évité, la valeur ajoutée potentielle de réinvestir ce temps dans de nouvelles fonctionnalités et le coût des pannes que l’on peut éviter.
Prenons l’exemple de Michel, un directeur de l’ingénierie qui gère une équipe de 50 personnes pour un produit générant des revenus de 10 millions de $. Selon les métriques DORA qu’il suit activement, son équipe se situe actuellement dans le groupe de performance moyenne. Combien ça pourrait lui rapporter s’il réussit à améliorer son équipe vers de la haute performance? Faisons le calcul pour le découvrir!
Il faut reconnaître la valeur des heures travaillées par les gens, qui sont récupérées en réduisant les inefficiences. Les organisations obtiennent essentiellement une capacité supplémentaire sans avoir à recruter et à embaucher simplement en améliorant les processus.
Les recherches de Google montrent également que l’amélioration des pratiques DevOps conduit à une plus grande satisfaction des employés et que les employés des équipes très performantes sont 2,2 fois plus susceptibles de recommander leur organisation comme un endroit où il fait bon travailler.
Nous allons trouver la valeur du rework non nécessaire évité en utilisant cette formule :
Analysons chaque élément de la formule plus en profondeur.
Vous pouvez utiliser le nombre de personnes techniques de vos équipes. Pour l’exemple de Michel, nous avons déjà déterminé que son équipe compte 50 employés techniques.
Le salaire varie beaucoup selon l’emplacement de l’entreprise et le coût de la vie. Vous pouvez utiliser vos propres données, mais pour les fins de l’exemple, nous allons utiliser le salaire annuel moyen des membres de l’équipe de Michel, soit 85 000$. Il s’agit d’un exemple représentatif du marché si l’on se fie aux données rapportées par Glassdoor pour les développeurs au Canada.
En plus du salaire, l’organisation participe au coût des bénéfices pour les employés (par exemple, les assurances, les vacances, les régimes de retraite, etc.) qui sont généralement ajoutés au salaire. Chaque organisation a son pourcentage, soit environ 15% pour les petites entreprises et 30% pour les plus grandes. Par exemple, pour un salaire de 100 000$ annuellement, il faudra compter entre 15 000$ et 30 000$ supplémentaires avec les avantages sociaux. Il s’agit donc d’un multiplicateur de 1.15 à 1.3 du salaire de base. Pour les fins de l’exemple, nous utiliserons la donnée qui nous a été fournie par Michel, soit un multiplicateur de 1.15.
Ce nombre représente la quantité de temps consacrée à du travail sans valeur ajoutée, ou autrement dit, les heures travaillées qui sont essentiellement perdues en raison de l’inefficience. Notre référence ici sera le rapport State of DevOps de 2018, où les recherches démontrent que même les meilleures équipes ont un pourcentage de rework de 19%, et que nous pouvons viser un objectif d’amélioration à 18%. Nous allons donc utiliser 1% pour la formule des équipes élites, soit la différence entre l’objectif et leur réalité. Les équipes à haute performance ont rapporté un pourcentage de 19,5% de rework, alors que les équipes à performance moyenne et basse rapportent un pourcentage de 20% de rework. Nous leur attribuerons donc des valeurs de 1,5% et 2% respectivement.
C’est cette variation dans les pourcentages des quatre groupes (1%, 1,5% et 2%) qui nous permettra de comparer le coût du rework non nécessaire par année selon le niveau de performance de l’équipe, toutes autres variables étant égales.
Alors, si l’on applique la formule, nous obtenons les résultats suivants :
| Performance élite | Haute performance | Moyenne performance | Basse performance |
| 50 employés x 85 000$ de salaire x 1,15 de bénéfices x 1% de rework = 48 875$ |
50 employés x x 85 000$ de salaire x 1,15 de bénéfices x 1,5% de rework = 73 313$ |
50 employés x 85 000$ de salaire x 1,15 de bénéfices x 2% de rework = 97 750$ |
50 employés x 85 000$ de salaire x 1,15 de bénéfices x 2% de rework = 97 750$ |
Puisque l’équipe de Michel se situe dans le groupe de performance moyenne, il obtiendrait un retour potentiel de 97 750$ par année en récupérant 2% de son temps grâce au rework non nécessaire évité.
L’idée est de bénéficier du temps récupéré grâce à la réduction des inefficacités et de le transformer en valeur en l’utilisant pour générer des revenus grâce à de nouvelles fonctionnalités pour vos clients. L’inefficience d’une équipe engendre des coûts d’opportunité et met à risque le potentiel d’ajouter plus de valeur au produit. Bien que livrer de nouvelles fonctionnalités apporte des revenus, ce ne sont pas toutes les fonctionnalités qui sont gagnantes. Plusieurs expérimentations chez Microsoft en collaboration avec l’université Stanford ont démontré que seulement le tiers des fonctionnalités réussit. Les compagnies les plus performantes exploitent leur capacité à livrer rapidement en production pour expérimenter.
Pour nos calculs, nous allons baser le potentiel des revenus sur les revenus courants de l’entreprise. Nous allons donc utiliser cette formule :
.webp?width=2150&height=812&name=Capture%20d%E2%80%99%C3%A9cran%2c%20le%202023-03-14%20%C3%A0%2009%20(1).webp)
Source : The ROI of DevOps Transformation, Google
Analysons chaque élément de la formule plus en profondeur.
Nous allons utiliser la même méthodologie que dans la section précédente (par exemple, 2% pour les équipes ayant une performance moyenne comme celle de Michel). Il s’agit de la même donnée, puisque le temps récupéré est le temps que nous pouvons réinvestir.
Il s’agit de la capacité à tester des fonctionnalités sur des clients. Nous réutilisons donc la fréquence de déploiement selon la performance de l’équipe. Les équipes élites expérimentent 2 fois par jour (ou 730 fois par année). Les équipes hautement performantes expérimentent entre 1 fois par semaine et 1 fois par mois (en moyenne 32 fois par année). Les équipes moyennes expérimentent entre 1 fois par mois et 1 fois tous les 6 mois (en moyenne 7 fois par année), et les équipes de basse performance expérimentent moins d’une fois tous les 6 mois (en moyenne 2 fois par année).
C’est cette variation dans le nombre de déploiements des quatre groupes qui nous permettra de comparer la valeur d’expérimenter plus souvent en en utilisant à bon escient le temps gagné en éliminant le rework non nécessaire.
Les organisations peuvent avoir plusieurs unités d’affaires où chaque unité a un produit central pour servir ses clients. Pour les grandes organisations (plus de 8 500 employés), on peut estimer vingt lignes d’affaires en moyenne, alors que pour les organisations de taille moyenne (plus de 2 000 employés), on peut estimer huit lignes d’affaires en moyenne. Pour les petites organisations (250 employés et moins), on peut estimer une ligne d’affaires. C’est d’ailleurs le cas de Michel et c’est la donnée que nous utiliserons pour notre exemple, mais nous vous invitons à utiliser vos propres chiffres.
Tel que mentionné plus haut, selon l’étude de Microsoft, seulement le tiers (33%) des fonctionnalités envoyées en production ont un impact positif sur les métriques clés. Nous utiliserons donc ce chiffre pour les calculs.
Chaque changement qui a du succès a le potentiel de contribuer à générer plus de revenus ou de profits pour l’entreprise. Certaines fonctionnalités peuvent rapporter jusqu’à 200% des revenus, alors que d’autres n’en rapporteront pas (par exemple, 0,01%). En moyenne, nous allons estimer qu’une idée contribue à la hauteur de 1% du revenu.
Le revenu potentiel des nouvelles fonctionnalités est estimé en fonction des revenus courants du produit. Pour nos calculs, nous utiliserons le produit sur lequel l’équipe de Michel travaille qui génère 10 millions $ en revenus.
Alors, si l’on applique la formule, nous obtenons les résultats suivants :
| Performance élite | Haute performance | Moyenne performance | Basse performance |
| 1% de temps récupéré x 730 expérimentations x 1 ligne d’affaires x 33% de taux de succès x 1% d’impact sur les revenus x 10 M$ en revenus = 240 900$ |
1,5% de temps récupéré x 32 expérimentations x 1 ligne d’affaires x 33% de taux de succès x 1% d’impact sur les revenus x 10 M$ en revenus = 15 840$ |
2% de temps récupéré x 7 expérimentations x 1 ligne d’affaires x 33% de taux de succès x 1% d’impact sur les revenus x 10 M$ en revenus = 4 620$ |
2% de temps récupéré x 2 expérimentations x 1 ligne d’affaires x 33% de taux de succès x 1% d’impact sur les revenus x 10 M$ en revenus = 1 320$ |
En améliorant ses performances, l’équipe de Michel pourrait expérimenter davantage et aller chercher un retour potentiel considérablement plus élevé avec le temps de rework évité réinvesti dans le travail sur de nouvelles fonctionnalités à valeur ajoutée.
Les applications et les infrastructures peuvent subir des incidents qui mettent le service en panne et ces pannes engendrent des coûts pour l’organisation. Selon un rapport de Stephen Elliot, vice-président chez IDC, une firme spécialisée en intelligence d’affaires pour le secteur des technologies, le coût d’une panne à l’heure peut varier entre 1,25 jusqu’à 2,5 milliards de dollars pour les entreprises du Fortune 1000. Ces chiffres sont très variables selon la nature de l’entreprise.
Pour trouver le coût de ces pannes, nous allons utiliser cette formule :
.webp?width=1924&height=374&name=Capture%20d%E2%80%99%C3%A9cran%2c%20le%202023-03-14%20%C3%A0%2009%20(2).webp)
Source : The ROI of DevOps Transformation, Google
Analysons chaque élément de la formule plus en profondeur.
La fréquence de déploiement peut affecter combien de fois l’équipe court le risque d’introduire un changement qui cause un incident. Si l’on se réfère au tableau plus haut, les performances élites déploient 2 fois par jour (ou 730 fois par année), les hautes performances déploient entre 1 fois par semaine et 1 fois par mois (en moyenne 32 fois par année), les performances moyennes déploient entre 1 fois par mois et 1 fois tous les 6 mois (en moyenne 7 fois par année), et finalement les basses performances de déploiement moins d’une fois tous les 6 mois (en moyenne 2 fois par année).
Graphique de la fréquence de déploiement dans Axify
Il s’agit du pourcentage de déploiements entraînant un incident en production. Pour trouver ce chiffre, nous allons utiliser les métriques de DORA. Les performances élites ont un taux d’échec entre 0 et 15% (en moyenne 7,5%), les hautes performances ont un taux d’échec entre 16 et 30% (en moyenne 23%), les performances moyennes ont un taux d’échec entre 16 et 30% (en moyenne 23%), et les basses performances ont un taux d’échec entre 16 et 30% (en moyenne 23%).
Lorsqu’il y a une panne ou une dégradation, c’est le temps requis pour corriger la situation. Pour trouver le chiffre, nous allons utiliser les métriques de DORA. Les performances élites corrigent en moins d’une heure (en moyenne 0,5 h), les hautes performances en moins d’une journée (en moyenne 4 heures), les performances moyennes entre une journée et une semaine (en moyenne 24 heures), et les basses performances en plus de six mois (en moyenne 180 jours, ou 4 320 heures).
Les pannes peuvent être coûteuses pour l’organisation. Le coût d’une panne peut être très variable selon sa nature et son niveau de dégradation. Vous devrez utiliser votre propre donnée pour raffiner le calcul. Si l’on se fie au rapport de Steven Elliot mentionné plus haut, une panne d’infrastructure coûterait en moyenne 100 000$, alors qu’une panne critique coûterait en moyenne entre 500 000$ et 1 M$. Michel nous a confirmé que 1 000$ était une somme représentative pour son équipe. C’est donc le chiffre que nous utiliserons pour le calcul.
Ainsi, c’est le niveau de performance de l’équipe qui déterminera le coût d’une panne au sein de l’entreprise.Alors, si l’on applique la formule, nous obtenons les résultats suivants :
| Performance élite | Haute performance | Moyenne performance | Basse performance |
| 730 déploiements x 7,5% de taux d’échec x 0,5 h pour rétablir x 1 000$ de coût = 27 375$ (ou 38$ par déploiement) |
52 déploiements x 23% de taux d’échec x 4 h pour rétablir x 1 000$ de coût = 29 440$ (ou 920$ par déploiement) |
12 déploiements x 23% taux d’échec x 24 h pour rétablir x 1 000$ de coût = 38 640$ (ou 5 520$ par déploiement) |
2 déploiements x 23% taux d’échec x 4 320 h pour rétablir x 1 000$ de coût = 1,987 M$ (ou 993 600$ par déploiement) |
Vous constaterez que même en ayant déployé plus souvent (et donc en ayant plus de chances d’introduire des changements qui causent un incident), les équipes qui s’améliorent en continu pour tendre vers des performances élites subissent des pannes beaucoup moins coûteuses.
La solution pour réduire le coût des pannes n’est donc pas de réduire la fréquence de déploiement, mais plutôt de réduire le taux d’échec des changements et le temps moyen de restauration.
Maintenant que nous avons identifié les coûts principaux et les composantes de valeur, nous pouvons les combiner pour trouver le retour potentiel d’avoir une équipe plus performante.
.webp?width=2078&height=370&name=Capture%20d%E2%80%99%C3%A9cran%2c%20le%202023-03-14%20%C3%A0%2009%20(3).webp)
Source : The ROI of DevOps Transformation, Google
Nous allons donc additionner les variables trouvées précédemment :
| Performance élite | Haute performance | Moyenne performance | Basse performance |
| 48 875$ de rework évité + 240 900$ de rework réinvesti en ajout de valeur + 27 375$ en coûts reliés aux pannes évitées = 317 150$ |
73 313$ de rework évité + 15 840$ de rework réinvesti en ajout de valeur + 29 440$ en coûts reliés aux pannes évitées = 118 593$ |
97 750$ de rework évité + 4 620$ de rework réinvesti en ajout de valeur + 38 640$ en coûts reliés aux pannes évitées = 141 010$ |
97 750$ de rework évité + 1 320$ de rework réinvesti en ajout de valeur + 1,987 M$ en coûts reliés aux pannes évitées = 2,086 M$ |
On peut voir concrètement l’impact d’améliorer certains aspects de la performance d’une équipe de développement et le retour potentiel d’entreprendre une démarche d’amélioration continue.
Si l’équipe de Michel s’améliore pour optimiser le flow de développement, elle sera capable d’apporter des changements rapidement et fréquemment, pour livrer de la valeur plus souvent.
Récupérer 2% de son temps grâce au rework non nécessaire évité est un bel objectif en soi, mais il faut également se demander ce qu’on pourra accomplir avec le temps récupéré. S’il est investi en ajout de valeur pour le produit, le tableau ci-dessus démontre clairement la corrélation entre une meilleure performance et le retour potentiel.
Plus une équipe chemine vers une performance élite, même si elle récupère moins de temps de rework non nécessaire évité (1% vs 1,5% ou 2%), elle peut livrer plus de valeur avec ce temps, puisque ses pannes sont moins coûteuses et les changements sont déployés plus souvent. Ce sont ces équipes qui consacrent le plus de temps à la valeur ajoutée et le moins de temps à des tâches sans valeur ajoutée.
Peu importe où vous vous situez actuellement dans le tableau (et peut-être que vous vous trouvez à différents niveaux pour chacune des métriques), évoluer d’une seule colonne vers la gauche pour l’une des métriques DORA peut avoir un impact considérable sur votre organisation.
Une amélioration de la productivité peut apporter un retour à l’organisation en fournissant de meilleures capacités et une meilleure performance. Mais par où commencer? Pour s’améliorer, il faut fixer des objectifs. Et pour fixer des objectifs, il faut bien comprendre notre situation initiale. Axify est un outil vous permettant de récolter des données à partir d’outils que vous utilisez déjà pour afficher simplement vos métriques de flow, le moral de l’équipe et bien sûr les métriques DORA. Vous pouvez également créer des objectifs à partir de vos données et en suivre la progression dans le temps pour observer concrètement l’amélioration continue de votre équipe.
Pour plus d’informations sur la façon dont Axify aide les équipes de développement à mesurer les indicateurs de performance DORA, commencez votre essai gratuit ou demandez une démonstration.
