Introduction
Les équipes et organisations qui utilisent le cadre agile Scrum espèrent toutes que les efforts porteront leurs fruits, et qu’elles seront bientôt sorties de tous leurs problèmes grâce à la magie de l’agilité.
La première étape consiste généralement à appliquer un cadre de travail avec plus ou moins de rigueur. Mais cette étape est souvent vu comme un objectif à part entière et non un simple premier pas. Nous allons explorer comment sortir d’une application mécanique de Scrum pour progresser vers une utilisation performante de Scrum.
Du cycle en V (waterfall) vers Scrum
Une comparaison entre l’agilité avec Scrum et le traditionnel cycle en V amène rapidement à considérer les 4 axes suivants :
- Amélioration forte sur la visibilité des travaux, l’état réel d’avancement (Cf. Manifeste Agile : Un logiciel opérationnel est la principale mesure d’avancement)
- Gain en adaptabilité et maintenabilité du produit (Manifeste Agile : L’excellence technique renforce l’agilité)
- Livraison de valeur pour les utilisateurs plus précoce (Cf. Manifeste Agile : Notre plus haute priorité est de satisfaire les clients en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée)
- Contrôle empirique des risques beaucoup plus objectif permettant de prendre plus vite de meilleures décisions.
Ces gains sont très importants pour l’organisation et sont souvent les principaux facteurs vers une transformation Agile.
Ils peuvent en outre servir d’indicateurs pour mesurer l’évolution de l’organisation vers plus d’agilité. Pour d’autres indicateurs, EBM (https://www.scrum.org/resources/evidence-based-management-guide) propose des options complémentaires.
Le gain en visibilité provient de la capacité apportée par Scrum de produire un incrément utilisable à chaque Sprint, ainsi que la Sprint Review qui permet aux parties-prenantes et à la Scrum Team d’inspecter ces incréments de produit, là où le fonctionnement traditionnel produit le célèbre effet tunnel.
Evolution de la visibilité entre un fonctionnement en cycle en V (rouge) et Scrum (bleu)
De même, le gain en adaptabilité provient directement de l’engagement de la Scrum Team à ce que les incréments successifs respectent les critères de qualité rendus transparents à travers la « Definition of Done », là où le fonctionnement traditionnel produit beaucoup de stock de travail en cours, toujours délicat à adapter en cours de route.
Evolution de l’adaptabilité entre un fonctionnement en cycle en V (rouge) et Scrum (bleu)
La capacité à livrer plus rapidement et fréquemment de la valeur provient également de la possibilité offerte au Product Owner de procéder à des déploiements des incréments utilisables dès que cela fait sens pour les utilisateurs finaux. Ainsi, la Scrum Team doit arriver à livrer le même produit, a priori pour le même effort, mais par des livraisons incrémentales et itératives et non par une livraison unique d’un produit supposé entièrement terminé. La différence de retour sur investissement est énorme puisque les investissements sont amortis plus tôt et que les utilisateurs peuvent bénéficier du produit beaucoup plus rapidement, ne serait-ce que partiellement.
Evolution de la livraison de Valeur entre un fonctionnement en cycle en V (rouge) et Scrum (bleu)
Enfin, les incréments utilisables apportent les preuves que les différents risques identifiés ou non ont bien été écartés ou adressés d’une manière ou d’une autre là où le fonctionnement traditionnel en phase nous réserve des surprises jusqu’au jour de la mise en production finale.
En fonction des risques avérés, Scrum nous offre la possibilité d’adapter l’orientation du produit à travers le Product Backlog, et ainsi que l’on va bien produire la meilleure solution possible avec les contraintes données, et non faire plus rapidement ce qui a été demandé initialement.
Evolution des risques entre un fonctionnement en cycle en V (rouge) et Scrum (bleu)
Notons que la transformation Agile vise à modifier l’organisation du travail, une simplification des processus internes et externes aux Scrum Teams en vue de mieux satisfaire l’utilisateur. Mais en aucun cas il n’est fait la promesse d’une croissance de la « productivité », qu’elle soit mesurée en termes de vélocité ou de débit.
Du Zombie Scrum vers du Scrum Professionnel
Qu’en est-il maintenant des différences entre une Scrum Team qui utilise le cadre Scrum de manière mécanique, comme une équipe de zombies, et une Scrum Team professionnelle qui serait à même de tirer parti au maximum de la puissance de Scrum ?
Une Zombie Scrum Team a généralement une Definition of Done qui stagne là où une équipe Scrum professionnelle, accompagnée d’un Scrum Master opiniâtre, va durcir sa Definition of Done avec le temps, afin de toujours réduire l’écart entre sa Definition of Done et l’état réellement utilisable de ses incréments.
Notons au passage qu’un durcissement de la Definition of Done va probablement introduire plus de rigueur dans le travail de l’équipe, souvent plus de tests ou de nouveaux outils à maîtriser, ce qui va avoir comme effet à court terme de faire baisser les indicateurs de productivité (Vélocité ou débit). Mais ceux-ci sont temporairement faussés tant que la Definition of Done ne reflète pas réellement un état utilisable des incréments et qu’il reste du travail à faire avant que l’utilisateur puisse bénéficier de l’incrément.
En outre, les Zombies vont souvent livrer les incréments après plusieurs Sprints là où l’équipe professionnelle arrive à livrer plusieurs fois par Sprint. Cela apporte beaucoup plus de transparence pour alimenter les Sprint Reviews puisque le feedback porte alors sur des items utilisables déjà délivrés depuis quelques jours et non pas seulement potentiellement livrables dans quelques semaines.
Evolution vers du Scrum professionnel (vert)
L’adaptabilité est elle aussi impactée par la stagnation de la Definition of Done et par l’accumulation non contrôlée de la dette technique. Dans une équipe Scrum professionnelle, l’équipe progresse avec le temps. Les critères de la Definition of Done se durcissent pour bénéficier des apprentissages de l’équipe. L’équipe maitrise également son rythme afin de rembourser toujours au plus vite sa dette technique, plutôt que se laisser déborder par des urgences qui feront exploser rapidement cette dette.
L’utilisation professionnelle de Scrum offre la possibilité au Product Owner de livrer dès qu’il le souhaite les incréments qui sont réellement utilisables, idéalement dès qu’un item du Product Backlog est prêt. La Scrum Team collecte ainsi beaucoup plus rapidement un feedback de la part des utilisateurs finaux, permettant ainsi de saisir les opportunités qui ne pouvaient pas toutes être imaginées au début du projet.
Dans le budget alloué, la Scrum Team doit normalement livrer finalement un produit apportant plus de valeur que le produit envisagé au lancement de l’initiative.
Présenté différemment, si la Scrum Team livre finalement exactement ce qui a été demandé initialement, elle n’aura rien appris en court de route et n’aura saisi aucune opportunité. Elle aura échoué à utiliser Scrum efficacement.
Encore une fois, il n’est pas même ici fait mention d’un changement sur la productivité de la Scrum Team.
Enfin, le durcissement progressif de la Definition of Done ainsi que des livraisons fréquentes permettent de réellement adresser les risques plus rapidement qu’avec une Definition of Done qui stagne et qui négligerait par exemple des critères de performance, de sécurité, de réglementation RGPD ou RGAA.
Conclusion
Mettre en place le cadre Scrum n’est pas suffisant pour tirer pleinement parti de la puissance du cadre. Il est facile de tomber dans le piège du suivi très mécanique et peu efficace des règles sans saisir les principes du cadre.
Pour arriver à une utilisation performante de Scrum, l’ensemble de l’écosystème, c’est à dire la Scrum Team et ses parties prenantes, doit en permanence faire preuve d’un grand professionnalisme, qui se concrétise par l’incarnation des 5 valeurs de Scrum que sont la Focalisation, l’Ouverture, le Respect, le Courage et l’Engagement.
Que la F.O.R.C.E soit avec vous !
