Libérez, Délivrez !
Hey Thomas ! pourquoi tu veux faire des itérations aussi courtes ? on ne pourra rien embarquer là-dedans !… Thomas, j’ai bien réfléchi on va repousser la livraison comme ça on pourra embarquer plus de contenu. Dis Thomas, franchement ça ne sert à rien de livrer si la feature n’est pas complète, ça n’intéresse pas le métier.
C’est facile de trouver des excuses pour repousser les livraisons. Peur de casser un outil de production opérationnel… Complexité d’organisation…
Pourtant livrer fréquemment fait partie des principes de base du manifeste AGILE, c’est même le 3ème principe dans le manifeste.
Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois, avec une préférence pour les cycles les plus courts.
On a tous beaucoup à gagner en livrant fréquemment, que ce soit les développeurs, testeurs, équipes de conception ou bien sûr les utilisateurs. Laissez-moi vous en persuader.
Les vertus du “Deliver Frequently”
Visibilité et Feedbacks
En livrant régulièrement on assure d’abord une visibilité importante sur nos réalisations. Que ce soit auprès de l’équipe bien sûr, mais aussi des utilisateurs, ou même du management. Les livraisons régulières sont l’occasion de démontrer notre avancement et surtout d’obtenir des feedbacks. C’est un bénéfice précieux pour l’équipe de s’adapter régulièrement.
Communication et Confiance
En mettant en place des itérations courtes, on va impliquer régulièrement l’ensemble de l’équipe dans des rituels et ateliers collectifs. Ces rendez-vous vont permettre d’avoir une vision claire sur l’activité en cours mais aussi renforcer le sentiment d’appartenance à un collectif et le sentiment de confiance. C’est particulièrement vrai pour les rituels agiles auxquels participent tous les acteurs de l’équipe comme les ateliers de priorisation, les démos ou encore les rétros.
La communication est la base de la confiance.
Adaptation progressive de l’utilisateur
L’équipe de développement n’est pas la seule à être impactée par le delivery. L’utilisateur final l’est autant, voir plus ! C’est lui qui utilise le produit au quotidien, il a ses habitudes, sa façon de travailler avec. La livraison d’une nouvelle version peut le déstabiliser, en particulier si elle contient des changements importants.
Livrer régulièrement va permettre de lisser les évolutions. Il va pouvoir adapter ses habitudes de façon progressive, parfois même sans s’en rendre compte.
Diminution du stress de la livraison
Toucher à une application en production est parfois vécu comme une source de stress pour l’équipe. Les utilisateurs comptent sur leurs outils pour assurer le business… pas le droit de leur planter la production.
Mais paradoxalement livrer régulièrement va permettre de réduire ce stress. L’équipe va se roder à l’exercice ce qui va permettre de dé-dramatiser l’événement. De plus, les versions vont être plus petites, on va réduire automatiquement le risque de rencontrer les versions Big-Bang 😨
Flexibilité dans le Delivery
(Mais pas dans la date ! 👮♂️)
Le rythme imposé par les livraisons fréquentes va permettre de challenger régulièrement les priorisations. Les priorités dans le Backlog pourront être adaptées en fonction des retours utilisateurs. Éventuellement des quick-win non anticipés pourront être embarqués dans la version courante .
Dynamique de la Équipe
C’est ce que je préfère, en gardant en vue des objectifs concrets à court terme, l’équipe reste constamment focus, chacun sait exactement ce qu’il a à faire. L’émulation créée par les différents rituels et la satisfaction de livrer régulièrement le fruit de son travail va donner à la équipe une dynamique énergisante.
C’est un cercle vertueux :
plus on livre ➡ plus on est satisfait
plus on est satisfait ➡ plus on est motivé
plus on est motivé ➡ plus on est efficace… 😊
Comment enclencher la dynamique ?
Le cadencement fixe ⌚
On trouve encore de nombreuses équipes qui déterminent leur date de Delivery en fonction du contenu qu’elles veulent embarquer. Ça donne généralement lieu a des versions épaisses, pilotées par le contenu plutôt que par la date de Delivery.
Dans ce mode de fonctionnement, on peut facilement se retrouver face à l’argument : « On ne livre pas tant qu’on n’a pas fini le périmètre prévu », anti-pattern de l’agilité… Les fins de version sont donc souvent douloureuses, avec des membres qui se retrouvent bloqués en attendant que leurs collègues aient terminé leurs derniers tickets. L’organisation et la planification du travail de l’équipe devient souvent ingérable dans ce contexte.
Plutôt que de subir le rythme des versions, on peut choisir de se l’imposer en mettant un place un cadencement fixe. L’équipe choisit ensemble le rythme de Delivery selon lequel elle veut pousser des versions en production. Ces dates fixes vont permettre de cadencer les itérations, donner de l’énergie à l’équipe en particulier si les itérations sont courtes.
Dans chaque itération, l’équipe va embarquer les tickets en fonction de leur priorité et créer un package avec le contenu disponible à la date prévue pour la livraison. En procédant ainsi, on « s’impose » de pousser régulièrement en production les stories et ainsi d’apporter de la valeur en continu au business.
Construire ensemble les Stories
Bien sûr fonctionner avec des itérations courtes va demander une organisation précise. On ne pourra pas se permettre de perdre du temps en cours d’itération à rediscuter de règles imprécises, rechallenger un besoin, chercher des cas de test ou autres…
Les stories devront être parfaitement claires pour l’ensemble des acteurs, et en particulier pour ceux qui vont devoir les développer et les tester. La priorisation devra également être comprise et approuvée. Le meilleur moyen en tant que développeur ou testeur pour comprendre les US est de participer à leur processus de priorisation et de rédaction.
Finie l’époque où les développeurs/testeurs se posaient en consommateurs des stories rédigées par l’équipe de conception, aujourd’hui il est indispensable de co-rédiger les stories, c’est le meilleur moyen de garantir la parfaite compréhension de la carte.
Le 3 Amigos est bien entendu l’atelier qui va permettre la co-construction de la story ; mais pour être efficace il devra être précédé par un Story Mapping et un Event Storming, pour comprendre la priorité du besoin, l’approfondir et déterminer ensemble un premier découpage en stories.
Report d’US / Agile Mindset
Délivrez régulièrement ne veut pas dire qu’on livrera à chaque fois l’ensemble du périmètre prévu.
Parfois on en livrera plus… parfois on en livrera moins. En général c’est dans ce 2ème cas que ça coince et qu’on risque de rencontrer des réticences pour livrer la version selon le planning établi.
Pourtant il est impératif de respecter la date de livraison planifiée sous peine de désorganiser notre belle mécanique. C’est le principe des méthodologies Agile; la date est fixe, c’est le périmètre qui est variable.
Pour limiter la déception des utilisateurs en cas de feature non livrée, il est primordial de les embarquer eux aussi, dans les ateliers de préparation et priorisation. Dans ces ateliers ils vont s’imprégner du mindset Agile, comprendre que ce qui guide l’équipe c’est de livrer les features qui amènent le plus de valeur au métier, et que le périmètre n’est qu’une “estimation” de notre capacité à produire, pas un contrat gravé dans le marbre.
On s’arrangera bien sûr pour traiter les features à forte valeur métier le plus tôt possible dans l’itération, afin d’éviter qu’elles ne soient pas terminées le jour de la livraison. Il sera toujours plus facile de faire accepter un report pour des US de moindre valeur.
En délivrant régulièrement, on pourra également limiter la déception en expliquant que la prochaine date de livraison est proche, et que la feature aura donc une nouvelle chance d’être mise en production rapidement 😉
Conclusion
J’espère vous avoir convaincu sur les bénéfices des livraisons fréquentes. Pour moi, cette façon de travailler apporte beaucoup d’énergie et de confiance à l’équipe. Le travail est cadencé, normé et laisse peu de place au flottement. Et quel plaisir de voir son produit évoluer régulièrement, que ce soit pour les utilisateurs ou pour l’équipe de développement (au sens large) 😀
Je n’ai pas voulu rentrer dans le détail de l’automatisation, car c’est un sujet beaucoup trop large pour être embarqué dans cet article, mais ce sera également un élément important dans la mise en place de votre Delivery. Que ce soit au niveau des tests, du déploiement ou même pour la génération de la documentation , l’automatisation vous permettra de gagner en confiance et en rapidité sur le process.
A vous de jouer maintenant, réunissez votre équipe, choisissez la fréquence qui vous convient le mieux et lancez la mécanique !
