Scrum, Dépasser le Mythe de la Livraison en Fin de Sprint

Scrum est conçu comme un cadre simple mais suffisant pour la livraison de produits complexes. Il n'est ni une solution universelle, ni une solution miracle, ni une méthodologie complète. Au lieu de cela, Scrum établit les limites minimales dans lesquelles les équipes peuvent s'auto-organiser pour résoudre un problème complexe de manière empirique. Cette simplicité est sa plus grande force, mais elle est également à l'origine de nombreuses interprétations erronées et de mythes entourant Scrum.

Aujourd'hui, nous abordons un mythe persistant. Le mythe se manifeste dans des déclarations telles que "Scrum est inflexible car de nouvelles versions ne sont possibles qu'après la fin du Sprint" ou "DevOps ou Kanban nous conviennent mieux car ils nous permettent de publier plus rapidement". En somme, le cœur du mythe est que Scrum ne permet aux équipes de livrer un logiciel fonctionnel qu'à la fin d'un Sprint, ce qui réduit la vitesse et la flexibilité si les équipes sont capables de le faire plus rapidement.

Débunkage du Mythe

Ce mythe est un exemple de faire passer le cadre pour plus important que l'objectif, bien qu'il soit basé sur une incompréhension du cadre dans ce cas. Le but du cadre Scrum est de développer des produits et de résoudre des problèmes complexes en utilisant une approche empirique qui favorise les retours rapides. Dans de courtes itérations, nous utilisons des retours (internes et externes) pour clarifier à la fois le problème et découvrir la meilleure solution. Ce faisant, nous évitons de résoudre le mauvais problème et/ou de mettre en œuvre une solution sous-optimale. Compte tenu de cet objectif, dans quelle mesure est-il probable que Scrum force les équipes à livrer un logiciel fonctionnel uniquement à la fin d'un Sprint ?

Le but de chaque Sprint est de donner à l'équipe de développement le temps et la concentration nécessaires pour transformer une sélection de travaux du backlog produit en un incrément "Done". Cette sélection est rendue transparente dans le backlog du Sprint et est guidée par un objectif précieux que le Product Owner souhaite atteindre. Cet objectif est capturé dans le Sprint Goal et est créé par l'équipe Scrum lors de la planification du Sprint.

Le type de travail nécessaire pour atteindre un incrément "Done" varie selon l'équipe et est rendu transparent dans une Définition de Fini. Certaines équipes incluent des types spécifiques de documentation, d'autres incluent la formation des utilisateurs, le déploiement dans un environnement de staging ou même la validation de nouvelles fonctionnalités par des métriques basées sur l'utilisation réelle. Quoi qu'il en soit, nous ne pouvons travailler de manière vraiment empirique que si "Done" inclut au moins tout le travail nécessaire pour amener l'incrément à un état où il peut être potentiellement publié immédiatement après le Sprint si le Product Owner choisit de le faire.

Plus les organisations sont capables de livrer un incrément "Done" à chaque Sprint, plus elles sont agiles. Après tout, les incréments ne sont vraiment utiles que lorsqu'ils sont entre les mains des utilisateurs et peuvent générer des retours concrets. Toute chose de moindre valeur signifie que la qualité et l'exhaustivité des retours, par les utilisateurs, les clients et ce qui se passe dans l'environnement après la publication, seront grandement réduites.

En ce qui concerne le mythe, le cadre Scrum définit le Sprint comme une limite minimale pour la livraison d'un incrément "Done". Il n'y a rien dans le cadre Scrum qui empêche les équipes Scrum de publier un logiciel fonctionnel tout au long du Sprint, à condition que le Product Owner participe à la décision de publication. En fait, Scrum l'encourage ! Après tout, c'est la meilleure façon d'optimiser la valeur du processus empirique qui se trouve derrière Scrum. Cela permet d'obtenir des retours plus tôt et les rend de plus en plus utiles et réalistes. Et cela permet aux équipes de générer de la valeur pour les parties prenantes plus rapidement. Comment ne pas le vouloir ?

Origines du Mythe

Une origine de ce mythe est une incompréhension de ce qui constitue un "Incrément". Le Scrum Guide le définit simplement comme la somme de tous les éléments du backlog produit terminés pendant le Sprint. Bien que l'incrément puisse être un ensemble de nouvelles fonctionnalités à déployer en une seule fois à la fin d'un Sprint, il n'est pas nécessaire que ce soit le cas. Un incrément peut également être la somme d'éléments déployés tout au long du Sprint.

Une deuxième origine réside dans l'utilisation de termes tels que "Incrément potentiellement publié" ou "Incrément potentiellement expédiable". Bien que cela ne soit pas intentionnel, ces qualificatifs peuvent soutenir la croyance que les incréments ne sont (potentiellement) "expédiés" ou "publiés" qu'à la fin d'un Sprint.

Une troisième origine, plus récente, réside dans la distinction qui est parfois faite entre Scrum et DevOps. En utilisant une version de ce mythe, on soutient que DevOps est supérieur à Scrum car il permet aux équipes de publier un logiciel fonctionnel plus rapidement. Parce que DevOps ne connaît pas le concept de Sprint, on soutient que le logiciel fonctionnel peut être publié chaque fois que l'équipe le juge "prêt".

Mais Scrum et DevOps sont de bons amis, tous deux essayant de mettre en œuvre un processus empirique avec un cycle de rétroaction aussi court que possible. Alors que Scrum se concentre fortement sur le processus nécessaire pour construire ce dont les parties prenantes ont besoin, DevOps traite des pratiques et des facilitateurs techniques qui rendent cela possible. En un sens, Scrum et DevOps sont vraiment les deux faces de la même pièce.

Qu'en est-il de la Sprint Review ?

Mais quel est le but de la Sprint Review si tout a déjà été publié pendant le Sprint ? Si votre Sprint Review se compose uniquement d'une démo, alors oui, l'événement se résume à une simple répétition de ce que vous savez déjà. Mais regarder le logiciel fonctionnel n'est qu'une petite partie de la Sprint Review. Le but principal de cet événement est d'inspecter ce qui a été fait pendant le Sprint et de décider des prochaines actions à entreprendre pour optimiser la valeur.

"Plus l'incrément est "Done", plus les retours qui sont recueillis seront utiles."

Donc, si l'équipe a déjà publié un logiciel fonctionnel pendant le Sprint, cela fait de la Sprint Review une excellente opportunité pour inspecter les retours des utilisateurs réels et s'adapter en fonction des insights qui émergent de cela. La valeur de la Sprint Review augmente en fait à cause de cela, car l'accent passe de la rétroaction à la prise de décisions stratégiques sur le futur proche.

Conseils

En tant que Scrum Master, aidez votre équipe à élargir continuellement sa Définition de Fini. Plus simplement, aidez l'équipe à réduire la quantité de travail à faire après qu'elle le considère comme terminé (par exemple, tests, assurance qualité, déploiement, documentation) ;
Investissez dans l'apprentissage de DevOps et de ses pratiques associées, telles que les tests automatisés, l'infrastructure en tant que code, la virtualisation et la livraison continue. Ce sont des facilitateurs critiques pour publier plus rapidement sans compromettre la stabilité et la qualité ;
Si votre Sprint Review n'est qu'une démo et que votre équipe est capable de publier tout au long du Sprint, utilisez la Sprint Review à des fins prévues : recueillir des retours sur l'incrément livré, le backlog produit, les conditions commerciales et favoriser la collaboration entre toutes les parties prenantes ;
Avec votre équipe et au sein de votre organisation, réfléchissez à la quantité de travail qui doit être effectuée après qu'une équipe considère un incrément comme "Done" (par exemple, assurance qualité, déploiement). Aidez à la fois l'organisation et l'équipe à changer les processus et les pratiques pour réduire cette quantité de travail "Not Donet".