Catégorie : Agile

Contexte

Votre Sprint s’achève. Votre incrément est terminé, vous avez codé proprement, vos batteries de test unitaires et tests d’intégration sont au vert clair, vous êtes fiers de votre travail. La Sprint Review se déroule sans accrocs. La Sprint Retrospective permet à l’équipe de trouver 1 ou 2 axes d’amélioration sans révolutionner le monde.

Bravo !

Vous enchaînez sur votre Sprint Planning, identifiant un sympathique Sprint Goal comme cible, une dizaine d’item du Product Backlog comme trajectoire et un joli Sprint Backlog pour y arriver.

Pendant ce temps, dans le bâtiment voisin, vos utilisateurs favoris (collaborateurs internes de l’entreprise) vont faire quelques tests fonctionnels, quand leurs obligations professionnelles quotidiennes leur en laissent le temps.

Il se trouve que ces tests fonctionnels leur font trouver des défauts assez graves pour mériter d’être traités « rapidement » plutôt que d’attendre le prochain Sprint. La Product Owner insiste, peut-être un peu lourdement, pour que des correctifs soient apportés dès le Sprint courant, bousculant fortement votre Sprint Backlog voire mettant en péril le sacro-saint Sprint Goal.

Et malheureusement, ce schéma se répète Sprint après Sprint.

Vous observez que les Sprint Planning deviennent très délicats car vous vous rendez-compte que vous avez énormément de difficultés à estimer la capacité réelle de travail de l’équipe de développement. Vos objectifs de Sprint sont également perturbés, bien trop souvent à votre goût.

L’équipe se trouve dans une position très inconfortable où elle n’arrive pas à maîtriser et stabiliser son Sprint Backlog.

Causes

En appliquant les « 5 why », vous comprenez que la première cause que vous identifiez à votre problème est le nombre très variable, mais jamais nul, d’anomalie à corriger en urgence, par suite des tests fonctionnels de vos utilisateurs du bâtiment voisin.

Pourquoi ? Parce qu’ils doivent tester après vous car les tests actuels sont incomplets

Pourquoi ? Parce que l’incrément n’est pas réellement terminé

Pourquoi ? Parce qu’il manque de faire les tests fonctionnels à l’intérieur du Sprint

Pourquoi ? Parce que l’équipe ne sait pas quels sont les tests fonctionnels pertinents à dérouler

Pourquoi ? Parce que la « Définitions Of Done » n’inclue pas le passage des tests fonctionnels, en tant que critères d’acceptation de chaque item, et encore moins leur automatisation et que rien n’est mis en œuvre pour que ces tests soient réalisés par l’équipe de développement pendant le Sprint.

Remèdes possibles

Le cadre Scrum nous aide à prendre conscience des freins de l’organisation, mais il nous laisse trouver l’approche qui convient le mieux à notre contexte pour faire évoluer progressivement l’organisation, tout en ayant le courage de respecter Scrum sans en modifier les règles.

Le premier pas consiste à enrichir la « Definition Of Done ». Celle-ci doit (petit à petit, soyons pragmatiques) amener à un niveau de qualité tel que l’incrément est réellement livrable et utilisable en production par l’utilisateur final, au plus tard à la fin du Sprint.

Maintenant, comment arriver à ce que l’équipe de développement exécute elle-même ces nouveaux tests et arriver au Saint Graal de l’incrément réellement terminé ?

Comme toujours, plusieurs options sont envisageables, en fonction du contexte qui est unique, mais en synthèse, la question revient à trouver un moyen pour que l’équipe de développement soit autonome dans l’exécution des tests.

Une première option est que l’expert métier lui-même soit intégré à l’équipe de développement, puisqu’il a une contribution critique pour obtenir un incrément terminé. Cette option est complètement alignée avec l’esprit du cadre Scrum qui révèle les problèmes issus du fonctionnement en silos, ici entre l’IT et le métier. La présence de l’expertise « métier » dans l’équipe permet de concevoir et exécuter les tests pertinents et juste au bon moment, par l’équipe. Le gain est évident pour l’équipe de développement qui renforce ses compétences, à condition que le nouveau membre de l’équipe accepte les règles du jeu et s’intègre bien dans l’équipe. Mais l’entreprise le paie pour sa compétence à traiter efficacement des « dossiers », pas forcément pour fabriquer un produit et si sa présence dans l’équipe est trop sporadique, il deviendra un goulot d’étranglement douloureux.

Une autre option est de restreindre le travail de l’équipe de développement pendant le Sprint à l’exécution voire l’automatisation des tests, mais pas à leur conception. La conception des tests se fait alors avant le Sprint, lors du raffinage des items du Product Backlog, en présence de l’expert métier et de l’équipe Scrum ou du moins des bons représentants. Lors du Sprint Planning, les items sont ainsi « prêts » à être réalisés et testés par l’équipe de développement qui dispose déjà des scénarios de tests (critères d’acceptation), créés en collaboration avec l’expert.

Il y a encore d’autres options à explorer telles que la montée en compétence (formation, mentoring…) du Product Owner ou de l’équipe de développement si elle en a l’appétence (profil de Business Analysts par exemple), afin de gagner en expertise et donc en autonomie sans perturber l’équipe Scrum par l’ajout de nouvelles personnes.

Vous pouvez penser à diminuer la durée des Sprint afin que les corrections des mêmes tests non passants puissent plus facilement attendre le Sprint suivant au lieu de perturber le Sprint courant qui arrive plus tôt. Mais ce remède symptomatique ne traite pas la cause racine du problème, en ne faisant que tolérer une implémentation de Scrum médiocre laissant s’installer l’habitude d’avoir des incréments « testables » mais toujours « non livrables ». Vous êtes alors voués à rentrer dans une spirale vous incitant à réduire de plus en plus la durée de vos Sprints, jusqu’à arriver à un point où les experts travailleront quotidiennement avec l’équipe de développement.

Conclusion

Le choix de la solution la plus pertinente dépend du contexte que vous seuls maîtrisez. Vous êtes les seuls à savoir ce qui est plus ou moins facilement faisable, ce que vous avez déjà réussi à faire. Alors maintenant, quelles autres options envisagez-vous ?

La notion de « Definition Of Done » (DOD) fait partie des éléments constitutifs du cadre Scrum. (Cf. https://www.scrumguides.org/scrum-guide.html#artifact-transparency-done )
La DOD est un élément nécessaire à plusieurs titres pour accroître la transparence du système. En particulier elle permet à l’équipe :
• de calibrer la quantité de travail pour l’itération qui débute
• de comprendre et partager le niveau de qualité du produit attendu et sur lequel l’équipe s’engage
• de comprendre la teneur des différents travaux techniques à entreprendre, en particulier sur les « exigences non fonctionnelles »

De manière générale, on s’attend à ce que la DOD du produit se durcisse avec le temps afin de faire croître la qualité du travail, réduisant ainsi la dette technique et le coût total d’acquisition, ce qui est un gage d’adaptabilité du produit.

En revanche, la « Definition Of Ready » (DOR) n’est pas un élément de Scrum mais une pratique complémentaire fréquemment utilisée par les équipes. Scrum suggère uniquement que l’équipe soit en mesure de déclarer si un item du « Product Backlog » est « prêt », dans le sens qu’il peut être sélectionné pour être réalisé dans un prochain sprint.

Attention, la DOR ne doit JAMAIS être utilisée comme une barrière stricte en recréant des silos entre le PO et l’équipe de développement, mais au contraire la DOR doit être un support pour faciliter une réelle collaboration entre le PO et l’équipe de développement.

Cf. https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog

Dans la pratique, l’équilibre parfait est très subtil à atteindre et encore plus à conserver. Ainsi la DOR d’une équipe va être soit trop laxe soit trop stricte.
Le problème est d’arriver à avoir une mesure objective qui permette à l’équipe de savoir dans quel sens faire évoluer la DOR.
Si la DOR est trop laxe, l’équipe va constater fréquemment que malgré sa bonne volonté à bien vouloir s’attaquer à tout ce qu’on lui demande, elle est souvent bloquée après avoir commencé à implémenter les items du « Sprint Backlog » : l’équipe commence les travaux d’implémentation mais doit s’arrêter fréquemment pour aller chercher des informations importantes manquantes pour poursuivre le développement de l’item en cours.

Chaque arrêt génère un gaspillage de temps, d’énergie et de perte de focalisation important. Un point de mesure simple mais naïf serait par exemple le temps de blocage cumulé pendant le sprint.

Si la DOR est trop stricte, l’équipe va constater qu’elle n’est quasiment jamais bloquée, ce qui semble intéressant. En effet, le temps de blocage cumulé pendant le sprint devrait être proche de zéro. Cela se traduit généralement par une vélocité « importante » car l’équipe n’est jamais bloquée et a l’impression de travailler sans gaspillage de temps, en livrant ainsi fréquemment un logiciel opérationnel (Cf. http://agilemanifesto.org/iso/fr/principles.html principe #3).
Malheureusement, la DOR utilisée ici comme bouclier protecteur pour l’équipe l’empêche alors d’être en mesure de prendre en charge rapidement des nouvelles idées et d’accueillir les changements de besoins, même tard dans le projet (Cf. http://agilemanifesto.org/iso/fr/principles.html principe #2). En effet, ces nouvelles idées devront passer par de nombreux ateliers, avec de nombreux acteurs avant que l’équipe ne considère que l’idée est enfin raisonnablement réalisable dans un prochain sprint.
Nous avons ici un excellent exemple de cas d’une optimisation locale au détriment de l’optimisation globale du système.

Le temps de cycle est une mesure intéressante qui permet à l’équipe d’apporter un niveau élevé de transparence, pour lui permettre d’inspecter l’efficacité de ses outils (tel que la DOR) et de guider les éventuelles adaptations à apporter au système.
Il est également très parlant pour mesurer si l’équipe arrive à accueillir les changements de besoins, indépendamment de sa cadence de livraison.
Enfin, si le temps de cycle englobe l’ensemble des travaux de l’équipe de «  développement » et pas seulement les travaux de « codage », il permet bien de mesurer l’efficacité globale de la chaîne de production de valeur, c’est à dire jusqu’à la la création d’un incrément de produit potentiellement livrable en production avant la fin du Sprint.

En synthèse, si la DOR est trop laxe, le temps de cycle sera détérioré par les nombreux blocages et si la DOR est trop stricte, le temps de cycle sera détérioré par des travaux préparatoires trop longs.

Dans tous les cas, la réduction recherchée du temps de cycle ne peut se faire qu’avec un travail collaboratif en équipe et avec le « Product Owner ».
Casser les silos permet de limiter les files d’attente et de lever rapidement les blocages en partageant rapidement l’information entre les différents acteurs.

Pour en savoir plus sur le temps de cycle : http://referentiel.institut-agile.fr/leadtime.html

Scrum on !