Vidéo : de la vision à l’increment

English version published on Scrum.org website.

Transcription de la vidéo.

Bonjour, je suis Fabio Panzavolta, Professional Scrum Trainer à la Scrum.org ! Je vais vous parler aujourd’hui de Product Ownership. C’est une discussion que j’ai eu avec un collègue de travail. On était en train de discuter sur son Product Backlog et de ses difficultés sur un workshop de génération d’idées, des nouvelles features qui devaient aller dans le Product Backlog

On n’arrivait pas à comprendre pourquoi il y a eu un tas d’idées qui étaient déconnectées du contenu du Product Backlog. Il n’y avait pas vraiment de cohérence entre les nouvelles idées et les idées générées précédemment. Et donc assez rapidement dans la discussion, j’ai posé la question à propos de la Vision. J’ai demandé : est-ce qu’il y a une vision pour ce produit ? est-ce que la vision est transparente ? est-elle visible pour tout le monde ? est-elle claire ? Il me répond : « Mmh oui, on a une vision mais ça fait longtemps qu’on ne la met pas à jour, on n’y a pas vraiment pensé ».

C’est important la vision réponds au « Pourquoi » : pourquoi nous faisons ce projet ? est-ce que ce produit est aligné avec la vision stratégique de l’entreprise ? quelle est la valeur que nous voulons délivrer à nos clients à travers cette vision ? Donc, quels sont les liens que je réalise entre la vision et les propositions de valeur pour le segment de clientèle à qui nous souhaitons nous adresser. Cela se connecte aux idées qui sont générées. 

Qu’est-ce qui se passe quand on commence à avoir des idées qui manquent de fluidité, de clarté ? Il se pourrait que nous ayons détecté une nouvelle promesse de valeur ?  Quelque chose que nous n’avions pas imaginé avant d’écrire le produit. Cela peut aussi être une discussion dans notre vision. Toutes ses idées qui sont générées, qui sont raffinées sur lesquelles on fait du Product Backlog Refinement avec la Development Team au cours de cette activité finissent dans un Sprint et dans le Sprint, la Devteam va créer un incrément “Done” à la fin. Nous avons une connexion sur le pourquoi, le quoi et le comment. On peut relier la vision à l’incrément. 

Sauf que tant que cet incrément, il n’est pas mis sur le marché, notre Product Owner est en train de réfléchir sur des hypothèses. Elles vont être confirmées ou pas par la mise sur le marché. Bien évidemment, on inspecte et on adapte régulièrement le Product Backlog mais il ne faut pas oublier que cette inspection et cette adaptation doivent être aussi opérées au niveau de la vision et la promesse de valeur (échanges). La partie du Pourquoi et Quoi et lui donner un nouveau sens ou une direction légèrement différente qu’on avait imaginé avec les hypothèses. 

J’espère que cette vidéo vous donne des nouvelles idées, des pistes. Vous avez plein de vidéos sur le site scrum.org et à une prochaine !

DONE (DoD) : une définition incomplète ou un manque de confiance ?

rawpixel-1187642-unsplash_small

English version published on Scrum.org website.

Il y a quelques jours, j’observais une Sprint Rétrospective. L’équipe Scrum a décidé de travailler sur la définition de “Done” (DoD), identifiée comme le sujet le plus important à adapter pour le prochain sprint. Les discussions étaient ouvertes et animées. Puis, une conversation inattendue a émergé au cours de la session.

Deux nouveaux développeurs ont récemment rejoint la DevTeam, composée de cinq personnes. La croissance de l’équipe a changé la dynamique, ajoutant de la complexité et la nécessité d’une révision de la définition de “Done”.

Le Scrum Master a invité le Product Owner et la DevTeam à générer des idées pour la DoD. Après quelques minutes, de nombreux post-its ont été proposés et partagés dont certains plus détaillés et d’autres moins.  La discussion s’est ensuite figée au niveau la documentation, notamment à des fins de test.

La question qui s’est posée : à quel point la DoD devrait-elle être précise et détaillée ? Devrions-nous être spécifiques, par exemple: “tests de non-régression documentés, validés par un paire, exécutés et le résultat stocké dans le dossier XY”. Devrions-nous simplement nous contenter d’une phrase comme: “tests de non-régression” ?

La réponse à cette question ?  La décision prise par le Product Owner et la DevTeam ensemble est acceptable, améliorée continuellement par l’inspection et l’adaptation.

C’est à ce moment-là qu’une nouvelle discussion s’entame entre les membres de la DevTeam : l’un d’eux arguant que le seul fait d’écrire des “tests de non régression” ne garantirait pas que le collègue effectuait des tests “de qualité” et “assez” significatifs. Il aurait simplement pu faire quelque chose pour se débarrasser du test et passer au suivant.

Un son de cloche sonne alors dans ma tête. Un néon rouge avec les lettres “C O N F I A N C E” commence à clignoter aussi… (oui, des choses étranges se passent, parfois, dans mon cerveau :-))

daria-nepriakhina-474036-unsplash_small

Partant de l’hypothèse que la DevTeam est un groupe de professionnels qui s’auto-organise pour créer un incrément “Done” à la fin de chaque sprint, s’ils ne parviennent pas à s’entendre sur un DoD et utilisent des expressions du type “comment puis-je savoir si vous avez réellement fait un bon test ?”, le souci repose fort probablement sur la confiance accordée au travail des autres.

J’ai validé mon hypothèse en posant quelques questions ouvertes. Maintenant, je sais que je dois aider la DevTeam à rétablir la confiance pour qu’elle redevienne efficace. Ce qui a commencé comme une simple discussion sur la définition de « Done » a finalement révélé un autre problème : le manque de confiance entre les membres de la DevTeam.

Je suis convaincu que cette équipe surmontera ses difficultés et redeviendra rapidement une DevTeam très performante !

À retenir

  • Vérifiez le niveau de confiance, à tout moment. C’est souvent LE problème. Vous pouvez consulter mon article “Un atelier pour découvrir les valeurs Scrum” pour vous donner des idées.
  • Les changements dans la composition des équipes peuvent en affecter la productivité, lisez les étapes de développement du groupe de Tuckmanpour en savoir plus.
  • Apprenez à cerner le problème, en vérifiant le sujet en question, le comportement des personnes, leur formulation et leur langage corporel.
  • Tenez-vous en au Guide Scrumet aux règles du jeu (surtout si vous êtes moins expérimenté) à maintes reprises, c’est le point de départ de mes explications.

Un atelier pour découvrir les Valeurs Scrum

English version published on Scrum.org website.

En 2016, cinq valeurs Scrum ont été ajoutées au guide Scrumcourage, attention, ouverture, respect et engagement.

A partir d’une idée de Gunther Verheyen, avec Mohamed Gargouri, nous avons récemment traduit les valeurs Scrum en français. Cela a été une opportunité d’explorer encore plus en profondeur leur importance et d’y apporter des précisions.

Ces valeurs, indispensables pour créer la confiance, constituent la pierre angulaire de Scrum et sont à la base de la transparence nécessaire au processus empirique pour inspecter et s’adapter efficacement.

Je me souviens de la première fois que je lisais les valeurs Scrum : j’étais perplexe quant à l’utilité réelle. J’ai ensuite approfondi mes lectures à ce sujet, en faisant attention à mon comportement par rapport à ces principes et en commençant à comprendre combien ils m’aidaient dans la relation aux autres personnes.

La prochaine étape, évidente pour moi, a été de réfléchir à la manière d’utiliser ces valeurs pour faire comprendre aux autres ce que j’avais moi même compris. C’est comme ça que j’ai commencé à experimenter un atelier, avec différents clients et dans différents pays, que je partage ici.

Atelier sur les valeurs Scrum (1 heure)

1 – Facilitateur – Définir le contexte (5 minutes)

  • Introduction aux valeurs Scrum. Préparez-vous en lisant le Scrum Guide et l’article de Gunther Verheyen.
  • Ne donnez pas trop de détails ou d’exemples sur les valeurs Scrum, laissez les participants les découvrir et y réfléchir. Laissez les gens vous surprendre !

2 – Petits groupes – Explorez les valeurs Scrum (5 minutes)

  • Au sein de votre groupe : pensez à une situation ou à un comportement actuel ou passé où quelqu’un a fait preuve de courage ou pas.
  • Quelles ont été les conséquences pour l’équipe et/ou les parties prenantes en termes de confiance ?

3 – Tous – Partagez vos découvertes (3 minutes par groupe)

  • Chaque groupe partage les résultats avec tout le monde. L’animateur peut résumer au tableau les commentaires (voir les images)
  • Laissez de la place pour les discussions, généralement de bonnes discussions commencent après le premier tour. N’ayez pas peur si le premier tour n’est pas si génial.

4 – Répétez les étapes 2 et 3 pour l’attention, l’ouverture, le respect et l’engagement (32 minutes au total)

5 – Conclusions (10 minutes)

Prenez le temps de terminer l’atelier en recueillant les impressions générales des personnes et en les laissant interagir. Si demandé, partagez votre expérience en tant que facilitateur. Il est maintenant temps de partager des exemples liés à Scrum. Soyez prêt et préparez-les à l’avance.

Matériel nécessaire

  • Un tableau blanc ou paper board
  • Post-its (facultatif)
  • Feutres, stylos

Configuration de la salle

  • Idéalement pas de tables ou de petites tables rondes
  • Petits ilots de 4-5 chaises en rond

Ce que j’ai appris des ateliers passés :

  • Le premier tour est parfois nécessaire pour s’échauffer, des discussions plus naturelles se déroulent lors des tours suivants.
  • Certaines personnes peuvent ne pas se sentir en sécurité pour participer à l’atelier. C’est pourquoi il est important de définir des règles de base, telles que : ne partagez pas les noms de personnes, de projets ou de produits. Ceux qui ne veulent pas participer sont invités à se retirer, à observer et à écouter les discussions.
  • Si le groupe utilise déjà Scrum, associez les valeurs avec les règle Scrum. Sinon, associez simplement les valeurs Scrum à la confiance dans les environnements de travail.

Conclusions

Les valeurs Scrum sont un excellent moyen de créer un climat de confiance entre les personnes et, par conséquent, un environnement de travail dans lequel on a envie de s’exprimer et où la mentalité des personnes et leur comportement est adaptée à la résolution de problèmes complexes en expérimentant des solutions audacieuses et innovantes ! Il ne vous reste plus qu’à tester cet atelier ! Je serai ravi de connaître vos retours d’expérience.

Téléchargez et imprimez le poster des Valeurs Scrum !