Après nous être occupé dernièrement du Scrum Master, j’aimerais maintenant retourner vers les éléments, cérémonies et artéfacts, constitutifs de Scrum. Vous vous rappelez peut-être à cet égard que nous avions abordé le product backlog l’an dernier ?

La démo, puisqu’il le faut…

La démo ? C’est bien !

La démo, c’est vraiment bien !

La démo, c’est du feedback. Et le feedback c’est le nerfs de la guerre des projets agiles.

Alors, si c’est tellement bien, pourquoi ne fait-on cela qu’une fois par itération ? On devrait faire ça tout le temps !

Mais ce n’est pas le cas.

En fait, comme nous le rappellent Emilie Franchomme et Caroline Damour-Nobi, on ne parle pas de démo, mais de revue de Sprint. Ou plutôt, la démo est (ou est sensée être) juste une partie de la revue de Sprint.

Un anthropologue qui butinerait d’équipe Scrum en équipe Scrum rencontrerait 2 types de populations :

• Ceux qui sont heureux d’aller à la démo.
• Ceux qui appréhendent la démo.

En fait, dans les deux cas nous avons un problème. Commençons par le premier, même s’il vous parait probablement curieux d’identifier une équipe heureuse d’aller en démo comme un problème potentiel. Mais ce cas va nous permettre de répondre au point que nous avons laissé en suspens.

La démo c’est cool, on va pouvoir montrer ce que l’on a fait !

Oui, c’est parfois (même souvent) ainsi que l’on aborde la démo : on va dévoiler ce qu’on a réalisé.

Voilà une grave erreur. Nous sommes déjà au coeur du problème. Et ce problème s’appelle “définition of done” !

J’avais abordé il y a quelques temps la question de la définition de terminé. Je vais reprendre ce point de manière légèrement différente :

L’objectif de la démo est de montrer ce qui a été terminé durant l’itération, n’est-ce pas ?

Ce qui est considéré comme terminé doit correspondre à la “définition of done”.

Donc si les utilisateurs (et à fortiori le Product Owner) découvrent en démo les fonctionnalités implémentées, nous avons un problème !

Et ce problème, c’est que la définition de terminé ignore le feedback des personnes utilisant réellement le système. Oh, bien sûr on peut toujours se dire que le trait que nous traçons dans le sable pour délimiter notre responsabilité, c’est l’implémentation du backlog, pas la valeur perçue par les utilisateurs. Ou en tout cas que l’écart de cette valeur perçue sera traité plus tard, à l’itération suivante au mieux.

Bonjour, je voudrais voir mon burndown chart

Bref, si notre objectif c’est de délivrer de la valeur et non du code correspondant à des spécifications nous avons un problème.

Illustrons cela par un bon vieux burndown chart.

Donc, si vous avez tranquillement exclus le feedback utilisateur de la définition de terminé, votre burndown ressemble à la droite en vert. Le petit détail c’est que votre définition de terminé corresponds à de la livraison de fonctionnalité, mais pas nécessairement à de la livraison de valeur.

Si la livraison de valeur est votre focus, justement, alors votre définition de terminé doit inclure ce feedback et à ce moment là votre burndown a l’allure de la courbe en rouge. C’est tout de suite moins classe.

En fait, il y a bien un processus de développement qui met à disposition l’ensemble de produit en fin de cycle de développement : le cycle en cascade !

Grâce à la démo, retrouves le charme oublié du “cycle en V” !

En stigmatisant la démo en fin d’itération, Scrum nous ouvre une brèche pour retomber dans nos vieux démons du cycle en cascade. Oh, bien sûr, telle n’est pas l’intention des géniteurs de Scrum.

En fait, la définition de terminé permet de remettre un poids du bon côté de la balance. Mais la cérémonie de la revue de sprint étant très structurante elle tend à occulter le premier.

La revue de Sprint, en fixant un point de rendez-vous en fin de sprint nous laisse penser que nous pouvons avoir un produit “en chantier” durant l’itération. Traduisez : un produit qui n’est pas stable. Une impression qui est accentuée par l’idée qu’il faut laisser l’équipe tranquille pendant l’itération. On ferme les portes, ce qui se passe pendant cette durée de Sprint ne regarde pas les autres !

Cette pente glissante se traduit par deux symptômes étroitement liés:

• Une difficulté à pouvoir montrer un produit stable à la démo. Un paradoxe !
• Un choix de l’équipe d’établir une “période de freeze” avant la démo pour corriger le tir. C’est parfois quelques heures, le plus souvent une demi-journée, voir une journée. Parfois même on augmente la dose.

Ce n’est pas une bonne façon de faire, ce ne sont pas les bonnes mesures préventives. On a juste transformé le Sprint en mini cycle en V ! Et c’est la démo qui nous a tranquillement amené là.

Oubliez la démo ! Le produit doit être stable tout le temps. Scrum nous dit de faire remonter les problèmes à la surface : supprimez la période de freeze. La démo suivante sera calamiteuse. Travaillez alors la stabilité du produit, non pas une fois par sprint, mais tout le temps.

Nous nous sommes occupé de ceux qui sont heureux d’aller en démo. Que pouvons-nous dire de ceux pour qui c’est la hantise ? Bien sûr, c’est pire !

Direction le tribunal

Parfois, la revue de Sprint, cela ressemble à ça :

Dans ces moments-là, la revue de sprint n’est plus seulement le moment les utilisateurs découvrent ce qui a été fait mais jugent et statuent sur ce qui ne va pas. Je ne parle pas ici de feedback, c’est à dire d’une dynamique où les invités de la revue de sprint aident à identifier les apports positifs et les points sur lesquels il faudra concentrer l’effort, mais d’un simulacre de revue de sprint où les utilisateurs, les consommateurs devrais-je dire, viennent noter ce qui a été réalisé.

Dans les cas extrêmes, certains des invités sont là dans le but de “prendre l’équipe en faute” ! Vous pensez que j’exagère ? Hélas non.

On ne saurait reprocher à Scrum des perversions qui ne viennent pas du framework, mais des personnes qui sont impliquées. Cela pose plusieurs questions :

• Lorsqu’une dynamique des personnes impliquées dans la définition du produit ne fonctionne pas, qui doit corriger le tir ? Le Scrum Master ou le Product Owner (car on est côté définition du produit…) ?
• Le Scrum Master doit-il fixer des protocoles plus cadrés lors de la revue de sprint si elle ne fonctionne pas correctement ?
• Est-ce une option valable de ne plus inviter une partie prenante si elle affiche sciemment une position négative ?

De temps en temps aussi, le biais ne vient pas des invités de la revue de sprint, mais de l’équipe.

Revue de sprint ou réunion de spécification

“dites-nous ce que vous voulez”. C’est ainsi qu’un Scrum Master a ainsi conclut la partie démo d’une revue de Sprint où les invités avaient été particulièrement silencieux.

Ca part d’une bonne intention. Et effectivement il faut à un moment poser la question, même s’il s’agit plus de comprendre ce dont ils ont besoin plus que ce qu’ils veulent.

Hélas cette simple phrase va changer la nature de la revue de sprint en une seconde. On n’y évoque plus ce qui a été fait, mais ce qui aurait pu être fait. C’est parfois, assez souvent même, intéressant. Cela aurait d’avantage sa place dans un atelier du type “design thinking”. Parfois ce travail d’exploration n’a pas été correctement fait et la revue de sprint en est le symptôme. Mais la revue de sprint n’est le lieu, ni pour collecter les spécifications, ni pour refaire le monde.

Micro-démo

Nous avons vu ce que nous ne devons pas faire, et pourquoi la démo de fin de sprint qui donne une odeur de cycle en V me gêne terriblement. Il est temps de voir ce qu’on peut faire.

N’attendez pas pour avoir du feedback sur les fonctionnalités, la démo de fin de sprint. La “définition of done” doit figurer le feedback sur l’utilisation de la story (que ce soit par le PO ou par les utilisateurs), pas seulement les acceptante tests. Pour cela on organise une petite démonstration impromptue dès que la story est achevée et les acceptante test sont passés. C’est ce qu’on appelle parfois la “micro démo”.

Voici la recette dans les grandes lignes:

• La micro-démo s’organise “à la volée” dès la story terminée. Pas le lendemain ou dans 2 jours, mais le jour même et si possible dans l’heure qui suit l’achèvement de la story. Avant que le développeur ou le binôme se soit replongé dans la story suivante…
• Pas de setup particulier: on fait ça sur le poste du développeur, on ne perd pas de temps à mettre des choses en place dans une salle de réunion.
• On va vite, on limite le temps imparti à 10 minutes environ. Pas de bla-bla. On exécute le scénario sur lequel on s’est mis d’accord en début de sprint. On réponds aux questions précises s’il y en a.
• S’il y a des ajustements à faire qui apportent de la valeur, l’équipe discute avec le PO de la pertinence de les prendre en compte (cela remet-il en cause le contenu de l’itération…). Si cela est pertinent, on prends ces modifications en compte et cela donnera lieu à une autre micro-démo.
• Un public limité : développeur, P.O., Scrum Master, testeur, et un ou deux utilisateurs clés s’il y a lieu. Pas plus. De toute façon la place autour du poste du développeur est limitée.

Grâce à la micro-démo, on valide non seulement le fonctionnement de la story (acceptante test), mais son utilisation. Il n’y a plus de surprise lors de la démo.

Mais alors, a-t-on encore besoin de la démo ?

La substantifique moelle de la revue de sprint

La revue de sprint, ce n’est pas seulement la démo. C’est aussi :

• Exposer la vélocité de l’équipe [Aubry12], p. 125
• Demander formellement l’acceptation du produit de l’itération [Lacey12], p. 186 ; franchement, c’est moins difficile si l’on est passé par des micro-démo avant !
• Montrer le produit à des personnes non impliquées dans la définition du produit mais qui ont besoin de constater que celui-ci progresse.

Certes, il n’y a pas que la démo dans la revue de sprint, mais quand même… Cela a-t-il toujours un sens de faire une démo dans la revue de sprint si l’on pratique les micro-démo ?

En fait, oui !

Tout d’abord c’est l’occasion de montrer le produit à des personnes que l’on ne peut toucher qu’occasionnellement, ou qui ne sont pas directement impliquées dans le produit. Ensuite, si la micro-démo permet de voir les fonctionnalités indépendamment, la démo de fin de sprint permet de mettre les pièces du puzzle ensemble et de faire des démonstrations de scénarios plus larges.

Une question de boucle de feedback

En développement agile, tout peut être ramené au niveau de la boucle de feedback. L’achèvement d’une story ne se termine pas avec la boucle de feedback des tests d’acceptance, elle doit inclure celle sur l’utilisation de cette story. Différer ce feedback à la fin d’itération, c’est créer un stock pour la fin d’itération sur lequel on risque de devoir revenir.

Les équipes travaillant en mode Kanban ou en mode mixte Kanban / Scrum tendent à mettre plus d’emphase sur le bouclage des stories, car il y a moins (ou pas) de poids sur ce qui se passe en fin d’itération. En fait, les cérémonies de fin et début d’itération traitent les éléments de travail par lots (un lot étant ce que contiendra le sprint), tandis que le Kanban travaille par flux. Et il est naturellement difficile de combiner travail par flux et travail en lots.

Alors, la démo, c’est mal ?

La démo, ou plutôt la revue de sprint s’avère une bonne chose. Elle permet :

• De montrer l’avancement du produit à un public large.
• De collecter du feedback global sur l’itération et l’état du produit.
• De mettre les pièces du puzzle ensemble

Mais il ne doit pas être l’outil qui transforme le sprint en mini cycle en V. Ne remettez pas le feedback des stories à plus tard, il doit faire partie de la “définition of done” !

Références

[Aubry12] : Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition – Claude Aubry – Dunod 2011 – ISBN : 978-2-10-056320-3

[Lacey12] : The Scrum Field Guide, practical advice for your first year – Mitch Lacey – Addison Wesley 2012 : ISBN : 978-0-321-55415-4