Accelerate, la vitesse conditionne l'excellence : un nouveau paradigme dans le développement logiciel
Introduction
Mardi 26 novembre 2019, OCTO et la tribu Accelerate (XLR8) avec comme speakers Henri Decourt et Fabien Arcellier, ont organisé une matinale sur le thème d'Accelerate avec comme titre "La vitesse conditionne l'excellence : un nouveau paradigme dans le développement logiciel".
Une matinale pour éclairer et rendre activable l'étude Accelerate qui démontre, chiffres à l'appui, que la performance logicielle est déterminée par la faculté à livrer le plus souvent possible. Faire mieux, plus vite et à l'échelle, c'est une réalité accessible : pour y arriver, 24 capabilités concrètes à mettre en oeuvre dans votre organisation, des tests automatisés à la réduction de la taille des projets et des tâches en passant par la transparence de l'information et le découplage de l'architecture. Ça va parler DevOps, produit, méthodologie, culture, architecture...
Accelerate un livre framework révolutionnaire ?
"Quelles sont les caractéristiques d’une organisation technologique performante ?"
A ce titre, nous percevons Accelerate comme un livre d’économie (du logiciel) qui établit scientifiquement la corrélation entre la performance du delivery logiciel et la performance économique d’une organisation.
L’ouvrage est la compilation et l’analyse des résultats d’une démarche scientifique démarrée en 2014 par les auteurs (Nicole Forsgren, Jez Humble et Gene Kim) qui a pour objectif de déterminer la recette magique des entreprises les plus performantes dans le delivery logiciel.
L’étude (DevOps Research & Assessment (DORA)), porte sur plus de 30 000 organisations de toutes tailles, de tous secteurs d’activités et de toutes les régions du monde. L’étude est un sondage déclaratif d’une série de questions sur le delivery de logiciel (les phases de conception et de design sont exclues de l’étude).
Cette étude, appuyée par un protocole scientifique robuste, permet de connaître l’état de l’art des pratiques en delivery logiciel pour faire émerger et partager les pratiques des meilleurs “performers” afin de rendre son organisation plus performante.
Un modèle de capabilités plutôt qu’un modèle de maturité
C’est là le cœur de l’ouvrage : une proposition de valeur fondée sur 24 capabilités concrètes adoptées par les organisations les plus performantes. La force du modèle de capabilités d’Accelerate tient essentiellement à deux choses :
- par rapport à un modèle de maturité qui adopte une approche systémique (on considère l’état de l’ensemble du système), le modèle d’Accelerate offre une vision pragmatique et fournit des leviers d’amélioration activables
- par rapport à un modèle de maturité qui pose une échelle de valeur subjective, le modèle d’Accelerate est intrinsèquement objectif puisqu’il se fonde sur la capacité d’une entreprise à réaliser telle ou telle opération de telle ou telle façon
En pratique, Accelerate présente 24 capabilités regroupées en 5 familles (en anglais dans le texte) :
- Product and Process (4 capabilités)
- Continuous Delivery (8 capabilités)
- Architecture (2 capabilités)
- Lean Management & Monitoring (5 capabilités)
- Culture (5 capabilités)
Ces capabilités sont interconnectées et, avant de vous présenter comment les appréhender, nous commencerons par la fin en vous livrant les résultats de l’étude et les indicateurs de mesure que prônent le modèle et la conclusion de l’étude. Nous aborderons les influences du modèle Accelerate (DevOps, Lean, Flow et Agilité) puis les points forts de celui-ci pour conclure avec des recommandations sur la façon de mettre en place ce modèle dans votre organisation.
Enfin Jérôme Didat, d’Essilor Instrument nous partagera son retour d’expérience sur l’application du modèle Accelerate dans son équipe.
1/ Les quatre métriques clés de la performance logicielle
La performance de delivery comme facteur de prédiction de la performance globale de l’organisation (business et non business)
#Spoileralert : La conclusion de l’étude fait ressortir que les organisations les plus performantes dans leur delivery logiciel atteignent en moyenne deux fois plus souvent leurs objectifs que les organisations les moins performantes.
Les auteurs avaient d’ailleurs eux-mêmes du mal à le croire ! Mais même en ajoutant d’autres variables liées à la performance d’une organisation, le résultat des études des années suivantes (2015/2016/2017) reste sans appel : c’est toujours la performance dans le delivery qui est le facteur principal permettant de prédire la performance globale d’une entreprise.
Mesurer la performance du delivery : une tâche complexe
La performance du delivery s’entend comme la faculté à fournir de façon continue un logiciel à valeur ajoutée à ses utilisateurs.
Pour éviter les biais et obtenir des indicateurs comparables et durables, les auteurs ont fait le choix d’un parti-pris fort en considérant que la performance du delivery se mesure à partir du moment où le code est terminé et mis à disposition (donc hors phases de design, conception et développement), ceci afin d’éliminer la variabilité parfois extrêmes inhérentes aux activités de design.
Historiquement trois principaux indicateurs de mesure de la performance ont été utilisés et/ou le sont toujours :
- Nombre de lignes de code produites : cet indicateur n’apporte aucune corrélation avec la performance. Cela peut paraître évident maintenant mais l’héritage de l’ère manufacturière où le résultat quantitatif de la production était associé à la performance a laissé des traces (plus je produis de lignes de code et plus je suis perçu comme un développeur performant). Produire le minimum de lignes de code n’est pas non plus synonyme de performance car cela veut probablement dire que personne d’autre que moi ne comprendra ce code et pourra le faire évoluer
- Taux d’utilisation des ressources : tout d’abord travailler beaucoup n’est pas une fin en soi, ensuite en cas d’imprévu cela diminue la performance car plus une équipe est utilisée plus il lui faudra de temps pour réagir. Au-delà de 75% de taux d’utilisation, la variabilité en cas d’imprévu augmente de façon exponentielle
- La vélocité (dans un contexte agile) : utiliser la vélocité comme un indicateur d’estimation capacitaire peut être intéressant mais celui-ci est relatif et propre à chaque équipe /projet. Autre biais, il est facile de manipuler la vélocité, il suffit aux développeurs d’augmenter artificiellement la complexité des tâches pour augmenter leur vélocité
Dans tous les cas, cet indicateur favorise l’optimum local au sein d’une équipe et pas l’optimum global à l’échelle d’un écosystème. Et l’on sait très bien qu’un SI est un ensemble de systèmes interconnectés entre eux et où de multiples équipes doivent travailler ensemble. Pour reprendre la citation de J-P Sartre “L’enfer c’est les autres”, il ne faut surtout pas oublier que “l’utilisateur voit le SI comme un produit qui rend un service mais pas comme un ensemble de logiciels”.
Mais alors, quelles sont les caractéristiques d’un bon indicateur de performance de delivery ?
3 critères principaux émergent :
- Global et non local, l’indicateur doit s’inscrire à l’échelle de l’organisation et favoriser la collaboration entre équipes
- Centré sur l’impact et non sur la productivité
- Stable et répétable, dans le temps, pour mesurer les progressions et se comparer par rapport à l’état de l’art
La performance dépend autant de la cadence à laquelle les choses sont produites que de la stabilité et qualité des éléments produits.
Il est bon de se rappeler que souvent, quand on va vite, on fait des erreurs, et c’est pourquoi les 4 indicateurs clés comprennent 2 indicateurs de vitesse et 2 indicateurs de stabilité.
Indicateurs de vitesse :
- Deployment frequency : mesure l’optimisation du flux de production de valeur
- Product delivery lead time : mesure la rapidité de mise à disposition en production du code finalisé
Indicateurs de stabilité :
- Mean time to repair : mesure la performance de correction d’un défaut
- Change failure rate : mesure la qualité du code livré
L’ouvrage regroupe les organisations en 3 niveaux de performers :
- High performers
- Medium performers
- Low performers
L’état de l’art en 2017
Les enseignements à en tirer :
- Les résultats sont très bons et sont des objectifs très ambitieux à atteindre
- Les Low performers vont peut-être aussi vite que les Medium performers mais ils le font beaucoup moins bien au regard de leurs indicateurs de stabilité
- Les High performers sont les plus rapides et aussi les plus stables
C’est l’une des grandes conclusions de l’étude :
Les organisations les plus rapides sont aussi les plus stables : entre vitesse et stabilité, il n’y a pas de choix à faire.
2/ Les influences d’Accelerate
Le modèle repose sur les meilleures pratiques issues des principaux courants de philosophie du développement logiciel.
DevOps
L’objectif est de briser le mur de la confusion entre développeurs et production.
Un des principes centraux de la culture DevOps est tout le monde est responsable :
- C’est le flux complet qui permet de rendre le service à l’utilisateur
- Toutes les équipes sont concernées par le delivery et la valeur créée : les équipes travaillent sur la même matière (code)
Lean
Nous retenons de la philosophie lean qu’il faut limiter la parallélisation (des tâches) pour aller plus vite.
Rappel de la LOI DE LITTLE (1961)
TEMPS DE RÉALISATION = TÂCHES EN COURS / DÉBIT
Pour aller plus vite, on peut donc soit réduire l’encours, soit augmenter le débit. La solution la plus simple et la plus économique, c’est de limiter l’encours.
Flow
L’objectif du flow est de mettre en place une cadence rythmée : l’IT est caractérisée par une forte incertitude et il faut en tirer partie pour amener le produit / service au plus vite vers les utilisateurs pour savoir ce qu’ils veulent / aiment.
Pour cela, le Flow recommande de réduire la taille des lots car plus le lot est gros, plus il est risqué et plus il s’auto-alimente. Parmi les principaux problèmes liés aux lots de travail de grandes tailles, on peut citer : l'augmentation de l'incertitude et du risque, l'augmentation du besoin et des coûts de pilotage, la réduction de la vitesse de la boucle de feedback et la démotivation des équipes.
Donc pour aller vite et réduire les risques, la meilleure option est de réduire la taille de vos lots.
Economiquement, cette approche peut aussi s’avérer extrêmement avantageuse lorsqu’elle est couplée aux capacités techniques adéquates. C’est ce que démontrent les deux graphiques ci-dessous qui mettent en évidence le lien entre le coût du stock par rapport au coût de transaction pour un ensemble de fonctionnalités.
- Coût du stock : quand une fonctionnalité développée n’est pas livrée, elle coûte cher
- Coût de transaction : qu’il faille déployer 1 ligne de code ou 10 000 lignes de code, il faut passer par les mêmes étapes
- Coût total : coût du stock + coût de transaction
- La taille optimale est le meilleur rapport coût / unités par lot
On constate que le principal levier d’action est le coût de transaction qu’il faut optimiser pour pouvoir livrer fréquemment à moindre coût. Cela passe par un ensemble de pratiques et de techniques à mettre en place : DevOps, automatisation, QA intégré dans l’équipe…
En conclusion, les méthodes sont importantes mais il faut implémenter les techniques associées pour pouvoir en tirer parti, faute de quoi les méthodes seules risquent de n'avoir aucun sens d'un point de vue économique.
Et l’agile dans tout ça ?
Chez OCTO, nous sommes de fervents partisans de l’agile dont nous portons les convictions auprès de nos clients dans toutes nos missions.
Nous savons également que le manifeste agile décrit un état d’esprit général, des valeurs, une culture, une façon de faire et qu’il ne recommande pas une méthode ou un ensemble de pratiques à acquérir. Il donne une vision globale du processus mais pas du développement logiciel en lui-même. En conséquence, il se prête bien à un modèle de maturité mais mal à un modèle de capacité.
Le prérequis fondamental du manifeste agile est d’aller vite en production pour chercher rapidement de la valeur. Ce principe s’exprime ainsi dans le manifeste : “Notre plus grande priorité est de satisfaire le client en livrant au plus vite et de façon continue un logiciel de valeur”.
En revanche, s’il expose la livraison rapide et continue de valeur comme un prérequis, il ne donne aucun indice concret sur la façon d’y parvenir.
(La réciproque est tout aussi valable : si vous ne livrez pas vite et bien, en continu au client alors vous n’êtes pas agiles).
Un autre principe est primordial :
“Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts”
Là encore, le manifeste ne donne pas un mode opératoire et c’est là que le modèle d’Accelerate entre en jeu et nous permet de trouver des réponses, notamment si notre objectif est d’acquérir la capacité et l’ambition de livrer au moment où on le souhaite (plus de détails dans la section suivante).
En conclusion
Ce qu’on cherche à faire dans le développement logiciel, c’est de se positionner au milieu de ce diagramme de Venn.
Et comment y arriver ?
Dans ce triangle d’or, la façon habituelle de réaliser les choses est héritée des usages de l’industrie manufacturière : 
Dans le développement logiciel, à cause de la nature incertaine de cette activité, nous avons la conviction qu’il faut faire l’inverse :
- aller le plus vite possible pour récolter du feedback des utilisateurs...
- ...ce qui implique de faire les choses bien pour suivre la cadence...
- ...et ainsi savoir plus vite quelle est la vraie bonne chose à faire ET être capable de l’ajuster en permanence (chose impossible dans le modèle classique)
3/ Le modèle Accelerate
Entrons maintenant dans le détail du modèle. Comment le mettre en place ? Quelle implémentation est préconisée ? Comment prioriser ? Par quelles capabilités commencer ?
La bonne nouvelle, c’est que vous avez probablement déjà mis en œuvre certaines pratiques donc personne ne part véritablement de zéro !
Le modèle en détail
Il comprend 24 capabilités, c’est-à-dire 24 pratiques concrètes et mesurables, regroupées en 5 familles :
Avertissement : le niveau de “zoom” des capabilités est hétérogène, tantôt haut niveau comme la gestion des versions dans le continuous delivery tantôt très spécifique et opérationnel comme le trunk based development.
Les capabilités haut niveau méritent d’être creusées en profondeur pour les rendre parfaitement activables sur le terrain (ex. “tests automatisés” est très générique).
Nous n’allons pas rentrer dans le détail de chacunes des capabilités mais plutôt vous présenter l’esprit d’Accelerate sur les grandes familles du modèle.
- Continuous delivery : “se donner visibilité et confiance”
Objectif : obtenir une vision pipeline de l’ensemble de mon application jusqu’à la production.
En pratique : sécurisation du pipeline, gestion automatique et maîtrisée de l’arrêt de la chaîne de delivery si des défauts sont repérés, versionning...
- Product & process : ”valider itérativement le besoin”
Objectif : se donner les moyens de garantir l’adéquation du produit au besoin.
En pratique : rendre le travail des équipes visible, recueillir rapidement les retours utilisateurs par des tests UX, travailler en petits lots…
- Architecture : ”favoriser l’autonomie”
Objectif : accompagner les équipes dans la maîtrise de leur périmètre en autonomie.
En pratique : l’architecte s’assure de la déployabilité et la testabilité du logiciel, il aide les équipes à devenir autonome en définissant des territoires d’autonomie.
// Infos importantes // L’étude met en avant le fait que cela fonctionne qu’importe l’architecture initiale en place (monolithe, micro-services…).
- Culture : ”mesurer les signes”
Objectif : agir sur les gestes du quotidien pour faire changer durablement la culture.
En pratique : pas de recette miracle, ce sont la mise en place des autres capabilités qui vont booster et changer votre culture.
On pense toujours que “la culture c’est les autres” (pour reprendre encore une fois la maxime de J-P Sartre). Ce qu’Accelerate propose en s’inspirant du béhaviorisme, c’est de renverser la perspective en s’attaquant à la culture par ses manifestations et non par ses fondements : pour changer la culture, il faut donc changer les gestes du quotidien plutôt que de tenter de modifier les systèmes de valeur ou leurs symboles les plus enracinés.
La philosophie de la démarche peut se résumer en une boucle continue entre mesurer l’impact et agir sur les capacités pour apprendre et s’améliorer. 
Comment et par où commencer ?
Recommandation 1 : Adopter une approche progressive et durable
L’implémentation du modèle implique des changements profonds qui impactent toute l'organisation. Pour autant, nous préconisons une approche incrémentale pour que le changement essaime et que les premiers résultats appuient la démarche.
Actions suggérées :
- commencer par l’accompagnement d’un petit nombre d’équipes (1 à 3 équipes) et les protéger du reste de l’organisation
- promouvoir autant les succès que les échecs avec des ambassadeurs, en évitant le syndrome Nouveau monde / Ancien monde
Recommandation 2 : Commencer local avant de viser global
Nous conseillons de débuter par les familles de capabilités internes à l’équipe (Continuous Delivery et Product & Process) pour poser des bases solides qui permettront le passage à l’échelle de l’organisation avec les familles de capabilités transversales (Culture, Lean management & monitoring et Architecture).
Par ailleurs, notre conviction fondamentale, c’est que la technique et la méthode se nourrissent mutuellement. Le fait de commencer par les deux familles Continuous Delivery et Product & Process crée une boucle de feedback qui se renforce et permet à l’équipe d’être encore plus efficace sur ces deux familles de capabilités. 
Recommandation 3 : Mesurer le passage à l’échelle
Le passage à l’échelle, c’est le moment de tous les dangers. Bonne nouvelle, ça se mesure, notamment au regard de l’indicateur “nombre de de déploiements par jours rapporté au nombre de développeurs”.
Les principaux constats :
- < 10 développeurs ⇒ pas de différences significatives entre les 3 niveaux de performers
- 100 développeurs ⇒ les différences commencent à se voir entre low performers et les autres
- +1000 développeurs ⇒ l’écart devient significatif et les high performers se détachent significativement avec une capacité exponentielle à déployer fréquemment
En d’autres termes, si vous augmentez la taille de votre organisation mais que votre fréquence de déploiement rapportée au nombre de développeurs stagne ou diminue, c’est que vous avez encore des capabilités à creuser avant de continuer à grossir.
Pour aller plus loin : en 2015, Amazon (pas AWS) déclare 50 M de déploiement par an (voir cette vidéo : https://youtu.be/esEFaY0FDKc?t=1125).
Recommandation 4 : Privilégier l’internalisation
L’étude révèle que le recours massif de prestataires externes (outsourcing) est un facteur d’influence négative sur les performances du delivery logiciel des organisations. Il est primordial que les compétences et les apprentissages liés à la mise en œuvre soient maîtrisés et maintenus à long terme par les membres de votre organisation.
Dans la mesure du possible, il faut internaliser les connaissances et le savoir-faire et n’avoir recours à des prestataires externes que pour des besoins ponctuels d'expertise ou de conseils.
#Instantpub Un cas d’usage pertinent pour faire appel à un prestataire externe serait de mesurer l’avancement de votre organisation sur chaque capacité du modèle Accelerate. Nous avons développé une offre de conseil outillée OCTOBench (disponible en français et anglais) pour répondre à ce besoin croissant.
La démarche s’inscrit dans la continuité de l’étude DORA, avec une démarche d’auto-évaluation de vos équipes à l'aide d'un support de questions déclaratives, détaillées et une restitution précise sous forme de radar.
Nos experts vous accompagnent dans l’organisation de l’étude : choix des équipes à évaluer, préparation à l’envoi des questionnaires, recueil et analyse des résultats et restitution et recommandations sur mesure par rapport aux résultats. Intéressés ? Intrigués ? Contactez-nous.
Exemples de rendu :
Questionnaire : 
Restitution :
Et si je veux commencer tout de suite, je choisis quelles capabilités ?
Nous avons observé 5 manques qui reviennent le plus souvent chez nos clients et nous y avons associé les 2 capabilités les plus essentielles pour s’engager dans un processus d’amélioration sur le modèle Accelerate (à l’exception du soutien aux équipes qui s’exprime par une seule capabilité).
A vous de définir leur implémentation en fonction de votre contexte, de vos douleurs et de vos objectifs. Gardez toujours à l’esprit que l’approche la plus efficace consiste à aborder les problèmes avec un double angle d’attaque, à la fois technique et méthodologique.
4/ Conclusion : les trois choses à retenir
Choisissez la vitesse ET la stabilité
Renversez les priorités
Commencez par l’équipe avant de traiter l’organisation
⇒ Retrouvez en vidéo, le retour d’expérience de Jérôme Didat d’Essilor Instrument la mise en œuvre du modèle Accelerate dans son équipe.