Les meilleures « démo de sprint » de ma vie

En ~12 ans de « nous travaillons en méthodes agiles »¹, je n’ai vécu des bonnes démos de sprint que pendant un an².

Comment se passaient ces bonnes démos ? Qu’est-ce qui les rendait bonnes par rapport à celles que nous subissons si souvent ?

À l’époque, je travaillais dans une entreprise où les sprints duraient trois semaines. Ils étaient synchronisés entre les trois équipes de développement. Les démos³, toutes les trois semaines donc, duraient une petite heure et offraient la chance à chaque équipe d’intervenir pendant un à trois créneaux de 10 minutes.

Dans mon équipe⁴, le matin du dernier jour du sprint, nous nous réunissions pour décider quels sujets nous allions présenter l’après-midi. En nous concentrant sur un petit nombre de sujets impactant pour l’entreprise et ses clients, nous garantissions que nous serions écoutés et que nous ne lasserions pas notre audience.

Voici quelques exemples de sujets :

• « Nous avons développé ce nouveau contrôle dans l’application X, qui va permettre à nos clients d’économiser entre 3 % et 5 % sur leurs achats de matériel. »
• « Nous avons intégré la dernière préversion de la règlementation qui deviendra obligatoire dans deux mois, pour permettre à nos clients de simuler ses effets, sur leur usage réel des mois passés. »

Des sujets semblant plus techniques entraient aussi dans nos démos – parce qu’ils apportaient eux aussi de la valeur :

• « Nous avons investi 30 jours de développement pour refondre l’import de fichiers XYZ où nous avions accumulé pas mal de dette technique au fil des ans. Nous ne passerons donc plus qu’environ 10 jours à chaque prochaine évolution règlementaire trimestrielle, au lieu d’environ 20 jours actuellement. Nos clients disposeront ainsi plus rapidement des futures évolutions règlementaires, avec un cout réduit pour nous. »
• « Nous avons changé de bibliothèque de génération et d’affichage de graphiques utilisée sur nos logiciels. Notre nouvelle solution travaille côté frontend et plus backend et offre désormais aux utilisateurs des graphes qu’ils peuvent manipuler, filtrer, et reconfigurer. »

Pour chaque sujet, nous décidions ensuite qui allait le présenter au reste de l’entreprise. Un ou deux autres collègues étaient souvent disponibles pour aider à préparer⁵ : scénario de démo, jeu de données, déroulé de la présentation, explication de l’intérêt pour les différents services de l’entreprise et éventuels points d’attention.

En fin de matinée, nous nous regroupions à nouveau, pour une répétition devant l’équipe.
L’occasion de valider, en groupe, pour chacune de nos démos :

• Le message : montrons-nous réellement ce que nous souhaitions présenter ?
• Le ton et la forme : le discours est-il clair ? Comment pourrions-nous l’améliorer ?
• La démo : montre-t-elle ce qu’il faut — et rien de plus pour ne pas complexifier ?
• Le timing : tenons-nous dans les 10 minutes qui nous sont allouées ?

Nous invitions parfois nos product-owners / experts métier à cette répétition : leurs connaissances fonctionnelles et leur capacité à échanger avec d’autres métiers que le nôtre étaient toujours d’une grande aide.

En début d’après-midi, venait le moment de la démo 🎉

Toute l’entreprise se retrouvait dans un grand espace équipé d’un écran géant et chaque équipe présentait les sujets qu’elle avait choisi de partager.

J’insiste sur toute l’entreprise :

• les développeurs et développeuses des autres équipes, qui savaient ainsi sur quoi travaillent leurs collègues ;
• les équipes commerciales, qui disposaient de nouvelles billes à pousser à leurs clients et prospects ;
• le service formation, qui allait ajouter ces sujets à ses prochaines sessions ;
• et le service support, qui allait commencer à recevoir des demandes de clients — et qui constitue un excellent point d’entrée pour des idées d’améliorations futures.

Très souvent, le PDG était lui aussi présent, sans doute fier de voir le travail accompli par ses équipes et la valeur de nos réalisations pour nos clients et utilisateurs.

Dès le lendemain, chacun avait du boulot.
Par exemple, des commerciaux rappelaient des prospects avec qui ils avaient déjà échangé pour leur annoncer la bonne nouvelle « nous venons d’intégrer une fonctionnalité qui va vous aider ».

Nous repartions tous et toutes de ces démos avec un sentiment d’appartenir à un tout, avec un sentiment de réussite et d’accomplissement.

C’étaient de bons moments et nous sommes nombreux à en garder, encore aujourd’hui, de bons souvenirs — malgré, parfois, une certaine difficulté à s’exprimer ainsi en public.

Ailleurs, dans d’autres entreprises ou à d’autres moments, la démo de sprint est vue comme une obligation à laquelle peu veulent se soumettre. Ou seulement 1/3 des développeurs y assistent. Ou la majorité des équipes disent « nous n’avons rien à montrer ». Ou les product-owner n’y vont jamais car les démos sont trop techniques. Ou d’autres réunions sont planifiées au même moment.

Pourtant, le déroulement des démos de sprint, les personnes qui y interviennent, la vision⁶ qui y est transmise… Pour moi, c’est très révélateur d’un état d’esprit d’une entreprise et de ses équipes.

Êtes-vous fiers de ce que vous accomplissez ? Fiers de le présenter ? Et curieux de ce que font les autres équipes et de ce que vos collègues sont fiers de présenter ?

Je suis persuadé qu’une entreprise où la réponse est « oui » à ces questions a de beaux atouts dans sa manche !

Et, bien sûr, les démos comme le développement, ça marche mieux quand on évolue dans un climat de confiance, quand chacun et chacune ont le temps⁷ de faire du travail de qualité. Mais je ne vous apprends rien ;-)

Illustration par Stem List sur Unsplash