La fréquence de livraison indique le rythme auquel une application est mise à jour pour intégrer des changements fonctionnels et techniques. La valeur délivrée peut prendre plusieurs formes comme de nouvelles fonctionnalités, de meilleures performances, une optimisation de l’utilisabilité, de l’évolutivité ou de la maintenabilité. La fréquence de livraison apparaît comme un indicateur plutôt révélateur de l’interaction entre les acteurs de la chaîne de valeur et de l’efficacité de l’outillage de test et de déploiement, mais attention à ne pas tirer de conclusion hâtive. Une équipe peut par exemple être en capacité de livrer tous les jours, mais ne réalise des déploiements qu’une fois par mois à la demande de son client. Est-ce que la fréquence de livraison est un bon indicateur de performance d’une transformation agile ? Est-il suffisant ou complémentaire à d’autres ? Examinons ce qu’il cache.

La fréquence de livraison est assez variable en fonction des organisations. Certaines se contentent d’une livraison tous les six mois, tandis que d’autres (Etsy, GitHub) en réalisent plusieurs dizaines par jour. Elle reflète les enjeux business, la manière dont sont organisées les personnes autour du produit (utilisateurs compris) et les exigences techniques (Craftmanship, DevOps, outils). Peut-elle être un bon indicateur de performance ?

Une augmentation de la fréquence de livraison amènera les utilisateurs à disposer plus rapidement de nouvelles fonctionnalités. Le risque de régression sera diminué en raison d’une plus faible quantité de changement entre chaque livraison. Les nouvelles idées auront plus de “trains” (releases) pour arriver à destination. En moyenne, elles arriveront donc plus vite sur le marché (meilleur Time To Market).

Quels sont les effets d’une augmentation de la fréquence de livraison ?

Augmenter la fréquence de livraison va impacter tous les acteurs qui participent à la construction du produit et les utilisateurs.

Le client, habitué à proposer des projets et des cahiers des charges représentant plusieurs mois de travail, devra trouver des conteneurs fonctionnels plus fins pour exprimer ses besoins. Il pourra par exemple privilégier un vocabulaire orienté “fonctionnalité” et “user story”.

Les développeurs, habitués à travailler sur des tâches de plusieurs jours, voire semaines, vont devoir apprendre à concevoir des petits lots fonctionnels. La difficulté majeure réside dans la tentation pour un développeur à couvrir un périmètre fonctionnel plus large que prévu, ce qui perturbe l’organisation du travail de l’équipe. En effet, se limiter à une petite user story peut apparaître assez frustrant, surtout lorsqu’on connaît les autres user stories de la même fonctionnalité qui n’ont pas encore été priorisées.

Les testeurs vont être sollicités plus fréquemment pour mener manuellement la campagne de tests de non-régression. Malheureusement, que la quantité de changement soit faible ou importante, ils devront faire exactement les mêmes actions. L’augmentation de la fréquence de livraison conduira à un moment donné à la nécessité d’automatiser les tests. L’activité des testeurs s’en trouvera bouleversée, car ce ne sera plus leur compétence à reproduire manuellement des tests qui sera attendue. Ils seront au coeur de la stratégie de test en s’assurant qu’un maximum de scénarios soit couvert et en participant à la conception et l’évolution des robots de test.

Les utilisateurs vont accéder plus rapidement aux nouvelles fonctionnalités. Ils seront également informés plus souvent des apports de la nouvelle version. Le format de la communication sur la livraison sera différent. En effet, une conférence peut se justifier pour présenter l’ensemble des fonctionnalités développées sur les six derniers mois, mais une communication bien plus modeste sera envisagée pour informer des quelques nouveautés disponibles depuis la semaine dernière. Le support, lui aussi, devra assimiler plus souvent ces nouveautés; l’exercice n’en sera que plus digeste.

Chaque livraison entraîne un coût, un risque de régression mais aussi une charge émotionnelle pour l’équipe. En effet, cette étape, à l’instar d’une tempête, apporte généralement du stress puis du soulagement lorsqu’elle est terminée. Augmenter la fréquence de livraison amènerait un coût annuel et un risque de régression plus élevés. Cela rapprocherait également les pics de stress pour l’équipe. Pour minimiser ces effets, il est indispensable de se tourner vers l’automatisation et les pratiques DevOps. Certaines équipes arrivent à transformer la livraison en non-évènement.

La fréquence de livraison, un bon indicateur de performance d’une transformation agile ?

Une transformation agile est d’abord guidée par un objectif. Celui-ci n’implique pas systématiquement une amélioration de la fréquence de livraison. Une entreprise peut par exemple se satisfaire pleinement d’une livraison par mois et souhaiter simplifier la communication entre les personnes qui amènent le besoin et l’équipe IT.
Dans une stratégie pour organiser le changement, la fréquence de livraison se révèle un indicateur pertinent, car en améliorer le score va générer une dynamique de changement à tous les niveaux, comme les clients, les utilisateurs, l’équipe IT, etc. Il contribue également à un meilleur Time To Market de l’ensemble des fonctionnalités.
Cependant, il ne reflète pas exactement la capacité de l’équipe à livrer. Par exemple, celle-ci pourrait livrer toutes les semaines, mais elle se limite au besoin du client, qui est d’une livraison par mois. L’indicateur donne finalement peu d’information sur les optimisations locales à mener. Il faudra donc en complément s’intéresser aux différentes activités de la chaîne de valeur pour identifier les améliorations à réaliser.

photo credit: Saint George’s Lights via photopin (license)