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.
Symptômes
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 ?