Accelerate vu par Zenika
Introduction
Comme tous les ans, l’étude state of devops 2021 est lancée. Cette étude permet d’alimenter les recherches qui ont déjà livré Accelerate, un livre qui fait maintenant référence dans le domaine de l’étude des processus de construction de logiciels.
Qu’est-ce qu’Accelerate ?
Comme déjà indiqué, Accelerate est une analyse statistique des résultats des études “state of devops” annuelles. Le gros intérêt de cette étude est de partir d’une vision brute des pratiques DevOps pour en tirer des enseignements dépassant les outils techniques utilisés.
Quatre métriques clés
L’un des premiers enseignements, et sans doute le plus médiatisé, est qu’il est possible de catégoriser le niveau de performance et de qualité d’une organisation à partir de quatre métriques facilement mesurables :
- Délai de livraison en production
- Fréquence de déploiement
- Temps moyen de restauration
- Pourcentage de livraisons en erreur
D’après Accelerate, ces métriques permettent de distinguer des organisations capables de livrer rapidement et efficacement du logiciel de qualité. C’est extrêmement intéressant, mais ça induit un biais bien connu : “quand une mesure devient un objectif, elle cesse d’être pertinente” (voir la loi de Goodhart).
D’ailleurs, Google, qui a repris les études, fournit une page (Are you an Elite DevOps performer? Find out with the Four Keys Project) détaillant l’impact de ces métriques et permettant la mise en place d’écrans les visualisant.
Autrement dit, mesurer ces métriques est intéressant pour situer une organisation en termes de capacité de livraison. Mais tenter d’optimiser ces métriques naïvement ne fonctionnera pas.
En fait, ce que montre Accelerate, c’est que ces métriques dépendent, par un jeu d’interdépendances démontrées par leurs études statistiques, de multiples facteurs.
Un réseau d’interdépendances incluant toute l’entreprise
L’un des intérêts de la méthode de sondage choisie pour les études sur l’état du monde devops, c’est de pouvoir déterminer les influences entre les différents facteurs. C’est ce qui permet aux auteurs de l’étude de produire ce schéma, qui montre tous les éléments influant sur la capacité d’une entreprise à améliorer ses résultats dans ces métriques. Et le moins qu’on puisse dire, c’est que les influences sont nombreuses et parfois peu intuitives.
L’un des exemples les plus frappants est la mise en place d’une culture organisationnelle correspondant aux critères définis par Westrum. Accelerate montre en effet que le fait d’avoir une culture d’entreprise générative, c’est-à-dire permettant la coopération, le lien entre les équipes, et abandonnant en un sens le contrôle managérial et la bureaucratie, est un élément contribuant notoirement à l’amélioration des fameuses quatre métriques.
Encore une fois, pour optimiser ces métriques, il ne faut pas chercher à les améliorer directement, mais plutôt optimiser les critères leur permettant de s’améliorer. C’est aussi intéressant que contre-intuitif. Et c’est l’une des leçons de cette lecture.
Et si l’approche présentée dans Accelerate est intéressante, elle n’est pas sans limites.
Les limites d’Accelerate
La vision produit est absente
La première chose à noter est que cette approche travaille effectivement l’accélération de la livraison et tout ce qui peut l’impacter, mais n’étudie absolument pas la vision de ce qu’est un produit logiciel : comment définir un produit logiciel, comment le faire vivre ? Ces questions, qui sont en fait des prérequis à la livraison de ce produit, et donc à la mise en place de DevOps ou d’Accelerate, ne sont pas traitées.
Le système socio-technique de l’organisation n’est pas étudié
Si Accelerate parle du management et de l’importance du mode d’organisation choisi, le livre ne développe pas les aspects liés aux liens entre l’équipe et le logiciel qu’elle produit.
On peut parler de l’application de la loi de Conway pour définir une organisation adaptée au logiciel produit, aux limites de ce qui est exprimable en rétrospective, ou d’architecture socio-technique… Dans tous les cas, une organisation est avant tout un artefact socio-culturel qu’il faut faire vivre au-delà de sa capacité à produire des artefacts techniques. Et ces aspects très intéressants, qui ont été présentés par les modèles d’organisation de Spotify, d’Amazon et d’autres entreprises, ne sont pas étudiés, alors qu’ils conditionnent clairement de nombreux aspects présentés par Accelerate.
Aucun chemin d’amélioration n’est proposé
Si Accelerate réfléchit aux moyens d’accélérer la livraison de code, et si l’équipe fournit également un outil d’assessment, il n’y a en revanche pas de définition d’un chemin de migration vers des livraisons plus rapides. Et en un sens, c’est normal. En effet, comme l’explique plusieurs fois le livre, chaque équipe est spécifique, elle a des forces et faiblesses particulières. Par conséquent, les défis à accomplir pour atteindre un haut niveau de performance dépendent très précisément de l’équipe et ne peuvent donc pas être normalisés. En un sens, c’est l’une des limites du type d’étude : en choisissant une vue “en coupe” de l’industrie informatique, on peut facilement voir les différentes méthodes et leur impact sur la capacité à livrer, mais il est difficile d’étudier les chemins qui transformeront une entreprise qui peine à livrer efficacement en un leader DevOps.
Accelerate n’est peut-être qu’une vision des modes
Accelerate est bâti sur quatre années d’étude des processus de développement. Or l’industrie informatique subit le balancier de la mode sur une période plus longue. Et les phénomènes qui étaient à la mode il y a quatre ans font encore partie des tendances lourdes. En revanche, si on regarde plus loin dans le passé, on verra que certaines pratiques, certaines méthodes, ont complètement disparu (par exemple la livraison de logiciels clients ne se fait plus actuellement, sauf dans le monde des smartphones). Et si ces pratiques ont disparu, leur intérêt ne peut être évalué comparativement aux méthodes actuellement employées. Et c’est normal, dans une étude fondée sur une démarche inductive, cherchant donc à valider des hypothèses à travers les cas présentés en réponse à l’étude statistique.
On peut donc voir dans cette étude certaines pratiques considérées comme mauvaises (par exemple les CAB, qui n’apportent d’après cette étude aucun avantage aux entreprises les pratiquant), mais aucune qui soit fatale à un projet. Parce que le plus grand biais est sans doute de n’interroger que les entreprises actuelles, et donc de subir le biais du survivant : les entreprises qui ont mis en place des méthodes qui leur ont été fatales ne sont plus là pour répondre au sondage.
Le métier n’est pas étudié
Enfin, et c’est sans doute le biais le plus important, il ne semble pas exister de métier au sein d’Accelerate. C’en est même troublant : on réfléchit à la boucle de feedback avec les utilisateurs à travers des ateliers, de l’A/B testing et d’autres pratiques, mais on ne réfléchit pas vraiment au métier, ni à la valeur que l’organisation livrant du logiciel doit apporter. Pourtant, c’est sans doute l’un des aspects les plus importants du développement : essayer d’apporter à l’utilisateur le bénéfice métier souhaité. Et ce sujet est sans doute aussi délicat que celui de la livraison logicielle pour définir les bons et les mauvais acteurs. Google est sans doute l’exemple le plus parlant : la réussite de l’entreprise n’est pas tant liée à sa capacité à livrer du logiciel qu’à la valeur métier produite par son application phare, le moteur de recherche.
Mais quel intérêt ?
Malgré ces limites, Accelerate est quand même une lecture extrêmement intéressante dans une entreprise comme la nôtre pour de multiples raisons.
D’abord, en tant qu’entreprise de conseil, Accelerate fournit à Zenika une façon parfaitement adaptée d’expliquer la raison pour laquelle nous fournissons des prestations couvrant l’accompagnement agile, l’artisanat logiciel, le devops, et autres domaines. Et si ce lien est particulièrement adapté au métier de notre entreprise, il permet aussi de lier les enjeux techniques des organisations aux impacts qu’ils auront sur ces organisations (par exemple, le fait que l’accélération de la livraison passe par une plus grande autonomie des équipes de développement quant à ces livraisons).
Au sujet des enjeux, la grande force est également de pouvoir partager ces objectifs entre tous les acteurs de l’équipe : qu’on soit coach agile, développeur, ops, manager, directeur, les objectifs présentés par Accelerate parlent à tous les membres de l’équipe, et permettent un alignement des travaux réalisés par les différents membres de l’équipe. Ces objectifs vont également permettre d’aligner les membres de l’équipe, mais aussi les différentes équipes de l’organisation, ce qui est particulièrement intéressant dans les entreprises de grande taille dans lesquelles les pratiques tendent à diverger. Et si cette divergence est source d’enrichissement, il ne faut pas qu’elle entraîne l’incompatibilité des pratiques. Or Accelerate permet précisément, au-delà des techniques utilisées, d’assurer une vision commune des bonnes pratiques. Parce que dans ces équipes qui ont des pratiques assez différentes, l’organisation du livre donne en quelque sorte les différents chemins permettant de s’améliorer, et de s’harmoniser au sein de l’entreprise, sans pour autant avoir une valeur prescriptive forte : si les axes sont les mêmes, les chemins d’amélioration dépendent de l’équipe, et permettent donc à chaque équipe d’avancer de la manière la plus adaptée à ses besoins et ses capacités du moment.
Enfin, et c’est peut-être l’un des aspects clés, Accelerate est fondamentalement une approche bottom-up : en partant d’une question simple “comment livrer plus rapidement du code de meilleure qualité”, les sujets abordés dépassent largement le simple cadre des outils techniques pour venir travailler au niveau organisationnel. Et grâce à des métriques facilement compréhensibles, les membres des équipes de développement peuvent facilement mettre en place des actions ayant un potentiel mesurable d’amélioration. Et le plus intéressant pour nous chez Zenika, c’est que cet objectif est atteint en travaillant également le sujet du bien-être au travail, ce qui en fait une étude améliorant à la fois la capacité technique des équipes, mais aussi la capacité à permettre l’épanouissement des personnes, en fournissant un objectif, un alignement, et une vision qui correspondent à des critères de qualité faisant de l’informatique un outil réellement utile et efficace.
Pour aller plus loin
Les travaux sur Accelerate continuent au sein du laboratoire DORA de Google. Ce laboratoire a mis en place un outil d’assessment rapide (https://www.devops-research.com/quickcheck.html). Il vous permettra facilement de mesurer votre niveau de maturité dans ce cadre. Par ailleurs, les capacités Accelerate ont été mises à jour, comme à chaque fois que l’étude State of Devops annuelle paraît.
D’un autre côté, Nicole Forsgren travaille maintenant chez GitHub où elle a produit le rapport SPACE.
Accelerate sert également de base aux livres édités par IT Revolution (https://itrevolution.com/devops-books/).
En France, certaines entreprises commencent à adopter les métriques définies dans Accelerate pour pouvoir étudier leur capacité à livrer et améliorer cette capacité.
Enfin, comme déjà écrit plus haut, nous utilisons de plus en plus Accelerate en interne comme cadre nous permettant de mieux qualifier nos interventions et nos pratiques.
Découvrez notre formation Accelerate
Bonjour,
Merci pour cet intéressant article. A OCTO, nous tirons des similaires conclusions de l’intérêt et des limites de cet ouvrage inspirant.
Je souhaite revenir sur les éléments différenciants de nos réflexions :
1) Accelerate est un ouvrage s’inscrivant dans le mouvement DevOps. Les 4 mesures s’intéressent à la vitesse et à la qualité logicielle de ce qui est délivré. Il me parait donc évident que les aspects « Produit » et « Métier » n’y soient pas abordés. Il n’y a pas de métrique comme le NPS des utilisateurs de la solution. Autrement dit, Accelerate s’inscrit dans les sphères « Do It Fast » et « Do the thing right », et non dans la sphère « Do the right thing ».
Identifier ces limites me parait être un amalgame confusant ; le DevOps est complémentaire à l’agilité.
2) La Vision Produit est-elle une « capability », au sens qu’elle soit concrète et mesurable ? Je ne pense pas. D’où son absence dans le modèle.
3) Le titre « aucun chemin d’amélioration n’est proposé » me parait putassier. Il nie la structuration du modèle de « capabilities » : c’est bien une multiplicité des possibles plutôt qu’un modèle de maturité avec un (ou quelques) chemins balisés. C’est donc une démarche humble. Cette formulation résonne avec l’horrible adage « one size fits all ».
Cependant la démarche d’assessment proposée s’appuie sur ces études statistiques afin de guider les groupes s’initiant à la démarche Accelerate. Et là, la limite reste que les aptitudes sont celles des familles « Continous Delivery », « Product & Process » ou « Architecture » ; à l’inverse, les sujets de culture organisationnelle ne sont pas proposés sur seules bases des 4 métriques.
4) Le biais du survivant n’est pas relevant. Est-il plus intéressant de se focaliser sur ce qui fonctionne, et permet de grandir vers un delivery digne d’un « eliter performer », ou de s’effrayer avec des pratiques fatales ?
De même, le propos de « les entreprises qui ont mis en place des méthodes qui leur ont été fatales ne sont plus là pour répondre au sondage » mériterait d’être démontré. A quel moment l’étude Accelerate avance-t-elle ces propos ? En 4 ans, certaines entreprises ont pu répondre au sondage, et disparaitre. Et ce pour des raisons différentes de l’efficacité de leur delivery.
5) Enfin, je souhaiterai davantage converser avec vous sur l’intrication entre une démarche DevOps et l’approche socio-technique. Encore une fois, Accelerate s’appuyant sur un modèle de pratiques concrètes et mesurables, et l’approche socio-technique s’appuyant, entre autres, sur des ressentis (charge cognitive) et des interactions, les 2 approches me paraissent davantage mutualisables que mélangeables.
Au plaisir d’en échanger avec vous
Bonjour Gilles, et merci pour ce commentaire
1) Si Accelerate est issu des mouvements DevOps, la particularité de l’ouvrage est de dépasser le cadre des simples considérations sur la capacité de livraison pour étudier également les aspects organisationnels : le management transformationnel, l’organisation selon les critères de Westrum, par exemple, sont des critères qui dépassent, et de loin, la capacité à livrer du code pour attaquer l’organisation de l’équipe. De ce fait, je pense que voir Accelerate comme simplement concentré sur DevOps est un peu réducteur : Accelerate s’intéresse au fait de livrer plus vite du meilleur code. Et quelque part, la définition de ce qui doit être livré est sans doute l’élément impactant le plus la capacité à livrer vite le bon code. Typiquement, si la définition du produit est mauvaise, le code livré ne pourra pas satisfaire les utilisateurs. Or, aussi technique qu’il soit, un code existe pour satisfaire un objectif métier. Et si ce sont des éléments qui sortent effectivement du scope d’Accelerate, je pense que c’est une erreur, parce qu’on ne s’intéresse pas à un critère impactant fortement les capacités de livraison.
2) C’est la pierre d’achoppement de notre désaccord : la vision produit est une capacité. Et elle est mesurable (les outils d’analyse de parcours utilisateurs, d’A/B testing sont là pour ça, entre autres). Elle est même l’un des éléments les plus précisément étudiés par les différentes méthodes agiles.
3) Je veux bien comprendre que le titre puisse heurter, en revanche, je ne vois pas le rapport avec le one size fits all. Par ailleurs, effectivement, Accelerate est présenté comme un résultat d’analyse, et pas du tout comme un modèle de maturité. De ce fait, il ne peut il ne peut pas présenter de chemin permettant de progresser dans sa capacité de livraison au-delà de présenter des capacités à développer. Je comprend parfaitement que, du fait que ce soit une analyse transversale et non longitudinale, on ne voie pas évoluer les pratiques des entreprises étudiées. Néanmoins, c’est en étudiant l’évolution de ces entreprises qu’on pourrait comprendre comment passer d’une entreprise qui livre difficilement à une entreprise qui livre rapidement du code qualité.
4) Effectivement, s’intéresser aux pratiques qui ne marchent pas n’est peut-être pas très joyeux. Mais Accelerate le fait, en évoquant notamment le cas des CAB, reconnus comme inutiles. Et pour aller plus loin, concernant le biais du survivant, j’ai travaillé – plusieurs fois – dans des entreprises dans lesquelles les 4 indicateurs auraient été très mauvais (par exemple dans celle livrant le logiciel aux clients sur CD). Est-ce une expérience que je choisis, en tant que répondant au sondage, d’évoquer ? Sûrement pas. C’est en ce sens que le biais du survivant est évoqué. On sait que les entreprises naissent et meurent bien plus vite que les individus. Et comme chaque entreprise bâtit sa propre culture de la livraison de code, certaines choisissent des cultures toxiques (comme par exemples celles qui développent ex-nihilo des systèmes remplis de microservices) qui ne leur permettront pas d’évoluer. Et je ne pense pas que les gens travaillant dans ces entreprises évoqueront leurs pratiques dans des sondages comme celui d’Accelerate.
Bonjour,
Effectivement, Accelerate est une étude de référence reconnue et comportant de très intéressantes analyses.
Elle a aussi ses limites dues aussi probablement au mode de fonctionnement par enquête, et comme vous l’indiquez au périmètre des sujets et pratiques qui y sont adressés, ainsi qu’aux angles de vue choisis par les auteurs.
L’ouvrage date aussi de quelques années maintenant (2018). Des évolutions récentes notables sur les systèmes socio-techniques (ex avec l’ouvrage Team Topologies) ou les techniques lean Value Stream Mapping et Value Stream Management apportent de réels compléments pour répondre à certaines des limites que vous évoquez ici.
Au plaisir d’échanger sur ces sujets passionnants
Patrice,
linkedin.com/in/patricecorbard
Ping : awesome french devops: GitHub File Free Download