Récemment, mes lectures m’ont fait tomber sur cet ouvrage, paru en 2018 :
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, par Nicole Forsgren, Jez Humble, et Gene Kim.
Il s’agit du résultat de 4 ans d’études de la performance des équipes de développement logiciel de plus de 1000 entreprises différentes, et d’analyse des principaux facteurs qui l’affectent. Ce qui rend ce livre vraiment intéressant, c’est que les auteurs ne se contentent pas d’y raconter leurs conclusions, mais également leur méthode d’analyse. Autrement dit, les auteurs ne se contentent pas de nous dire quelles pratiques fonctionnent ou non, ils nous donnent également les outils pour vérifier que cela fonctionne également dans le contexte de notre boîte et de notre équipe, et surtout des métriques à observer pour nous y aider au quotidien.
C’est un ouvrage assez long, qui aborde de très nombreux aspects du métier, et le fait que ses conclusions soient le fruit d’une étude scientifique rigoureuse me donne envie de pouvoir m’y référer facilement à l’avenir.
Dans ce billet je vais résumer les points qui me semblent importants à retenir des premiers chapitres.
- Mesurer les performances de la production du logiciel
- Mesurer et changer la culture d'une organisation
Mesurer les performances de la production du logiciel
Comment NE PAS mesurer la performance d’une équipe
Le livre mentionne trois exemples de mesure de performances qui sont couramment utilisées et qui sont en réalité contre-productives.
- Le nombre de lignes de code produites : cet indicateur pousse les développeurs à produire du code en quantité plutôt qu’en qualité, et a un impact très négatif sur la maintenabilité des projets,
- La vélocité : la vélocité d’une équipe est à l’origine un outil d'aide à la planification basé sur une estimation a priori de la complexité du travail à accomplir. Cette grandeur est spécifique à chaque équipe (elle ne peut pas servir de point de comparaison), et s’en servir comme un KPI incite les équipes à surestimer leurs tâches et à abattre le plus possible de user stories pour gonfler la vélocité au détriment de la qualité, ce qui détruit tout l’intérêt de mesurer leur vélocité à l’origine.
- L'utilisation, c’est-à-dire la proportion de leur temps que les ingénieurs passent à travailler sur des tâches planifiées. Le problème de cette mesure est que plus l’utilisation des ingénieurs s’approche du 100%, plus les équipes mettent de temps à accomplir quoi que ce soit car elles n’ont alors simplement plus le temps de s’occuper d’améliorer le logiciel, de réagir à des changements de plans ou d’absorber des tâches non planifiées.
Choisir de bons indicateurs de performances
Pour mesurer efficacement la performance, il faut utiliser des indicateurs qui représentent des résultats globaux (global outcomes), afin d’éviter que les indicateurs ne poussent les équipes à se tirer dans les pattes : l’exemple le plus classique de ce problème, c’est de mesurer les performances d’une équipe de développement en fonction de la quantité de logiciel écrite et celles de l’équipe opérationnelle par la stabilité du système.
Le second critère d’un bon KPI est qu’il doit refléter un résultat (outcome) et non "la quantité produite" (output), de manière à ce qu’il n’encourage pas les gens à s’agiter pour produire de grandes quantité de travail qui ne sert à rien.
Les auteurs proposent quatre mesures de performances qui satisfont ces critères :
Delivery Lead Time
Le "Lead Time" est une métrique caractéristique de l’approche Lean, qui consiste à mesurer le temps entre le moment où un client exprime un besoin et celui où ce besoin est satisfait. Le cas particulier du logiciel impose quelques adaptations : un ticket pour une nouvelle fonctionnalité peut être créé longtemps avant qu’un développeur ne travaille dessus, et les tâches en question ont une complexité très variable, et c’est normal.
Dans ce contexte, le Delivery Lead Time mesure le temps entre le moment où le code d’une fonctionnalité est commité, et celui où la fonctionnalité tourne correctement en production. Le temps de design et de production du code (qui dépendent en premier lieu de la complexité des tâches à accomplir et sont extrêmement variables) n’est donc pas pris en compte.
Plus ce temps est court, plus le feedback de la part des utilisateurs est rapide, plus il devient facile de s’adapter aux changements de plan et, évidemment, de réagir lorsque l’on constate un bug ou une panne.
Dans leur étude, cette mesure pouvait prendre les valeurs suivantes :
- Moins d’une heure,
- Moins d’une journée,
- Entre une journée et une semaine,
- Entre une semaine et un mois,
- Entre un mois et six mois,
- Plus de six mois.
Deployment Frequency
Une autre métrique caractéristique de l’approche Lean, c’est la taille des "batches" de travail. Autrement dit, il vaut mieux morceler le travail pour le produire en petites quantités régulières. Transposer cette notion à la production de logiciel où il n’existe ni stock ni inventaire n’est pas aisé, et les auteurs proposent d’utiliser la fréquence des déploiements comme un proxy pour cette grandeur : plus une équipe déploie fréquemment, plus les déploiements représentent de petites quantités de travail livrées.
L’étude classifiait les résultats selon les valeurs suivantes :
- À la demande (plusieurs déploiements par jour),
- Entre une fois par heure et une fois par jour,
- Entre une fois par jour et une fois par semaine,
- Entre une fois par semaine et une fois par mois,
- Entre une fois par mois et une fois tous les six mois,
- Moins d’une fois tous les six mois.
Time To Restore
Les deux indicateurs précédents mesurent le tempo auquel le logiciel est produit et déployé, mais il importe que l’amélioration de ce tempo ne se fasse pas au détriment de la qualité et de la fiabilité du logiciel.
En général, la fiabilité se mesure comme le temps qui sépare deux défaillances. Dans le contexte du logiciel, c’est un peu plus compliqué : la complexité des systèmes modernes et la vitesse à laquelle ils changent font que les défaillances sont inévitables. Autrement dit, la question "à quelle fréquence observons-nous des défaillances" n’est pas aussi intéressante que de savoir "à quelle vitesse le service est rétabli en cas de défaillance".
Autrement dit, cet indicateur mesure le temps moyen que mettent les incidents à être résolus et les bugs à être corrigés, avec les mêmes valeurs types que pour le Delivery Lead Time.
Change Fail Rate
Ce dernier indicateur mesure également l’aspect qualité de la performance. Il s’agit de répondre à la question "quelle proportion de changements apportés au produit résultent en une défaillance lorsqu’ils sont déployés ?".
Il s’agit donc de quantifier la confiance avec laquelle on déploie des changements.
Résultats
Pendant plusieurs années consécutives, les auteurs ont étudié les caractéristiques de nombreuses organisations qui produisaient du logiciel, de toutes tailles (de la startup de 5 personnes aux mastodontes d’Internet) et de tous types (en incluant par exemple des agences gouvernementales américaines). Je vous laisse vous plonger dans le livre pour avoir leur méthodologie exacte.
Les premiers résultats intéressants sont les valeurs que prennent ces 4 indicateurs dans les organisations qui sont les plus performantes :
- Deployment Frequency : à la demande (plus d’une fois par jour),
- Delivery Lead Time : moins d’une heure,
- Time To Restore : moins d’une heure,
- Change Failure Rate : entre 0 et 15%
Ce qui est peut-être plus intéressant, c’est le reste de l’analyse. D’abord, l’étude confirme qu'il n’y a aucun compromis à faire entre la vitesse à laquelle on livre le logiciel et sa qualité : les organisations qui réussissent le mieux excellent sur les deux, ce qui confirme les prédictions des philosophies Agile et DevOps. D’ailleurs, les organisations qui ont tendance à favoriser la vitesse à laquelle le logiciel est livré au détriment de sa qualité forment un cluster clairement identifiable aux performances médiocres. Autrement dit faire les choses vite, c’est les faire rigoureusement bien, tout le temps.
Mais ce qui est encore plus intéressant, c’est que la performance de production du logiciel telle que mesurée ici est un prédicteur des performances organisationnelles (commerciales) et non-commerciales de l’organisation. Autrement dit, les quatre indicateurs de performance que nous venons de définir ont une influence directe, indiscutable, sur la réussite d’une entreprise ou d’une organisation, et donc il est important d’y accorder la plus grande attention.
En somme, non seulement mettre la qualité logicielle au centre du développement est la seule manière de le produire rapidement et d’en tirer rapidement un retour sur investissement, mais cette hausse de performance a également un impact direct sur le résultat de l’entreprise. Cet impact est bien souvent le chaînon manquant lorsque l’on discute de mesures pour améliorer la qualité du code avec des décideurs qui en sont déconnectés : le voici, on ne peut plus clairement caractérisé ici.
Ces résultats fournissent également un argument de poids contre le fait d’outsourcer le développement de logiciel quand celui-ci revêt une importance stratégique pour l’entreprise : il y a tout à gagner à le développer en interne afin de maîtriser ces indicateurs.
Mesurer et changer la culture d'une organisation
Attends.. quoi ?! 
Afin de mesurer l’impact de la culture des organisations sur leur performances, il est nécessaire de trouver un moyen de la quantifier. Pour cela, les auteurs ont utilisé une typologie développée par le sociologue Ron Westrum en 1988, qui permet de classifier la culture d’une entreprise selon trois grandes catégories (les extrémités et le centre d’un continuum) :
- Pathologique ("orientée pouvoir") : il s’agit d’organisations qui marchent à la "peur" ou la "menace", où l’information est souvent retenue ou distordue pour des raisons politiques.
- Peu de coopération,
- Le "messager" est puni en cas de mauvaises nouvelles,
- Les responsabilités sont esquivées,
- La transversalité ("bridging") est découragée,
- Un échec/une défaillance conduit à la recherche d’un coupable,
- La nouveauté est rejetée,
- Bureaucratique ("orientée règles") : ces organisations se composent généralement de divers "départements" indépendants qui tiennent leur "terrain" et sont poussées par le respect des règles et des procédures.
- Coopération modeste,
- Le "messager" est négligé,
- Les responsabilités sont finement ajustées et limitées,
- La transversalité est tolérée,
- Un échec/une défaillance conduit à "la justice",
- La nouveauté apporte des problèmes,
- Générative ("orientée performances") : il s’agit des organisations concentrées sur leur mission où chaque décision est subordonnée à l’atteinte des objectifs et aux bonnes performances.
- Haut niveau de coopération,
- Le "messager" est formé,
- Les risques sont partagés,
- La transversalité est encouragée,
- Un échec/une défaillance conduit à une "enquête" pour en comprendre les causes,
- La nouveauté est implémentée,
Il est à noter que la bureaucratie n’est pas nécessairement mauvaise : le but de la bureaucratie est d’établir des règles qui contribuent à l’équité et à supprimer l’arbitraire dans toute l’organisation. Par ailleurs, cette notion de culture est totalement orthogonale au fait que l’organisation soit une startup ou une grosse société ou fasse même partie de la fonction publique :
Westrum’s description of a rule-oriented culture is perhaps best thought of as one where following the rules is considered more important than achieving the mission—and we have worked with teams in the US Federal Government we would have no issue describing as generative, as well as startups that are clearly pathological.
Les auteurs détaillent la façon dont ils ont construit et validé une mesure quantifiable de la culture "Westrum". Il n’est pas utile que je m’étende plus là-dessus ici.
Résultats
L’étude confirme les deux hypothèses suivantes :
- La "culture Westrum" est un prédicteur tant de la performance de production du logiciel que de la performance commerciale/organisationnelle des entreprises,
- La "culture Westrum" est un prédicteur de la satisfaction au travail.
Les conclusions que les auteurs tirent de ce résultat sont nombreuses et enfoncent ce qui me semble être des portes ouvertes : la qualité de la coopération et de la communication entre les gens, influencée par la culture de l’organisation, se reflète sur la production du logiciel et donc sur la performance organisationnelle. Ce n’est rien de nouveau, mais c’est irréfutable.
Une conclusion peut-être moins triviale porte sur la réaction que l’on devrait avoir face à une défaillance ou une panne : au-delà du fait qu’il est contre-productif de chercher un bouc-émissaire, l’investigation d’une panne ne devrait jamais s’arrêter à "cause: erreur humaine". Cela devrait plutôt être le point de départ de l’investigation, puisque le but est d’améliorer la façon dont l’information circule dans l’organisation, ou se doter d’outils plus efficaces pour éviter que les défaillances ne puissent se produire à nouveau.
Mais le résultat vraiment intéressant ici, c’est celui qui vise à répondre à la question "comment changer la culture de mon organisation ?". Les auteurs prouvent que le moyen le plus efficace n’est pas de s’attaquer à ce que pensent les gens, mais à leur comportement. Pour ce faire, ils ont établi que l’adoption de pratiques de management Lean d’une part, et des pratiques associées au Continuous Delivery d’autre part, sont deux prédicteurs de la "culture Westrum".
Autrement dit : la meilleure chance dont on dispose pour changer la culture d’une organisation, c’est de changer ses pratiques et de laisser les flux de communication entre les gens s’adapter en conséquence.
J’aurais tendance à vouloir tempérer cette conclusion : ça a l’air facile, dit comme ça.
Dans la réalité, il ne suffit pas de changer n’importe quoi ni de jeter du Agile sur une équipe de développement pour que tout aille mieux dans le meilleur des mondes.
Encore faut-il s’assurer que ces pratiques sont adoptées dans un but clair et précis (améliorer les performances de la production du logiciel), dans un effort de la part de toute l’organisation, et pas pour des raisons purement politiques ou idéologiques ("définir des nouvelles règles qui marcheront peut-être mieux"). C’est un changement radical que l’on ne peut pas se permettre de faire à moitié, sous peine de résultats potentiellement désastreux pour l’organisation.
