Découverte continue en Scrum / Agile
J'ai déjà écrit sur la façon dont les équipes produit agiles ou Scrum font tourner en parallèle la Product Discovery et la Product Delivery. J'ai également écrit sur le fait que les équipes en Product Discovery aiment parfois travailler avec le Timeboxing.
Dans cet article, je souhaite parler de la tendance croissante vers le Continuous Delivery et la Continuous Discovery.
L'idée du Continuous Delivery (livraison continue) se répand de plus en plus. De nombreuses équipes en ont parlé ces dernières années, mais désormais il y a aussi des équipes qui travaillent vraiment avec.
Presque toutes les équipes produit travaillent aujourd'hui avec des builds continus. Le principe sous-jacent est qu'il vaut mieux découvrir les problèmes tôt plutôt que tard. C'est pourquoi les builds sont généralement lancés dès que des modifications sont apportées.
Certaines équipes produit ont porté ce principe à un tout autre niveau. Elles ont appris que les problèmes d'intégration sont chronophages et qu'en intégrant tôt et fréquemment (au lieu d'une seule phase avant les tests), elles peuvent améliorer significativement leur débit global en minimisant le temps de travail en isolation.
De même, il est préférable de faire tourner en continu des suites de tests de régression automatisés pour détecter les nouveaux problèmes le plus tôt possible (ce qui réduit considérablement le nombre de sources d'erreurs ainsi que le temps de correction), plutôt que de tout tester dans une phase à la fin d'un cycle de release (même d'un cycle de deux semaines) et de découvrir tous les problèmes d'un coup.
La conséquence logique est que certaines équipes livrent maintenant régulièrement (connu sous le nom de Continuous Deployment). Cela signifie que chaque changement logique (ou groupe de changements) est livré directement en petits « micro-releases ». Cela présente plusieurs grands avantages. Le premier avantage est que c'est la stratégie ultime pour les releases incrémentiels et donc le mécanisme principal pour le Gentle Deployment – bon pour nos clients et bon pour nous. Le deuxième avantage est que la recherche et la correction de problèmes en production sont beaucoup plus simples quand on ne change qu'une ou quelques choses à la fois.
Cependant, tout ce que j'ai décrit jusqu'ici concerne la Product Delivery. Mais qu'en est-il de la Product Discovery ?
Je plaide depuis longtemps pour le même principe en ce qui concerne la découverte des Product Backlog Items. Au lieu d'une « phase de Product Discovery » de plusieurs semaines, où l'on crée des Product Backlog Items, les valide et les transmet ensuite au développement, j'encourage les équipes à pratiquer une Product Discovery continue, où nous identifions, validons et décrivons en permanence de nouveaux Product Backlog Items. Certains travaux de Discovery ne prennent que quelques heures, d'autres plus longtemps, mais c'est un processus permanent d'idéation, de validation et de description.
Dans le Dual-Track Scrum, le Discovery Track génère en continu des Product Backlog Items et dans le Delivery Track, ces items sont construits, testés et déployés en continu.
Au regard de la tendance du Continuous Discovery et du Continuous Delivery, de nombreuses équipes trouvent le processus Scrum un peu restrictif et considèrent le modèle Kanban comme mieux adapté dans ce cas.
Même si toutes les équipes n'ont pas nécessairement basculé vers Kanban, j'en ai vu beaucoup adapter Scrum vers Kanban précisément pour cette raison. L'adaptation la plus courante est, au lieu de livrer après chaque Sprint de deux semaines par exemple, de livrer les fonctionnalités et autres changements directement quand ils sont prêts – souvent plusieurs micro-releases par semaine. Dans ce cas, les équipes utilisent le Timeboxing de Scrum comme moyen de structurer leur travail et d'encourager des rétrospectives régulières.
Fondamentalement, la transition vers le Continuous Discovery et le Continuous Delivery est vraiment une bonne chose et beaucoup des meilleures équipes que j'ai rencontrées travaillent ainsi ; même si ici, comme partout, des compromis peuvent être nécessaires.
Ce texte provient du blog de Marty Cagan et a été traduit par nos soins en français.
