Catégorie : Coaching

Quelques petites réflexions autour du WSJF

Eric Lannemajou5 commentaires

L’histoire et la théorie

WSJF ou Weighted Shortest Job First rendu populaire grâce au framework Agile à l’échelle SAFe permet entre autre de prioriser les fonctionnalités à développer et est défini de la manière suivante dans SAFe :

Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs

La formule mathématique pour prioriser les éléments est la suivante :

Regardons maintenant rapidement les composantes du coût du retard qui est la somme de 3 éléments : la valeur utilisateur/métier, le coût lié aux contraintes de temps, le coût évité grâce à l’information (risque et opportunités) apportée par la fonctionnalité. Pour simplifier, on part alors du principe que plus on met de temps à mettre une fonctionnalité sur le marché (ou entre les mains de l’utilisateur final) , plus il devient urgent de livrer celle-ci afin de ne pas bloquer les autres items à développer.

Sans chercher trop longtemps sur le net, vous pouvez trouver ici un excellent article qui explique la provenance de cet outil ainsi qu’une vidéo ci-dessous de Don Reneirtsen son inventeur expliquant le coût du retard.

Le WSJF répond au premier principe Lean Agile de SAFe qui consiste à prendre des décisions se basant sur une vue économique. Vous pouvez utiliser le WSJF pour motiver toutes vos décisions concernant les fonctionnalités à réaliser, du moins c’est ce que dit la théorie. Mais en pratique ?

Les réflexions autour de la mise en pratique

Voici en vrac quelques réflexions et constats sur les ateliers WSJF :

  • La simplification par la suite de Fibonnaci dans le coût du retard
  • La simplification du délai de mise en oeuvre par la charge de développement
  • La fausseté des chiffres
  • Les biais cognitifs
  • La satisfaction client
  • Les fonctionnalités techniques

La simplification par la suite de Fibonnaci dans le coût du retard

Lorsque Don Reinersten a défini le coût du retard, il l’a envisagé avec une vision économique et c’est en toute logique que chacun des éléments du coût du retard s’exprime en devise financière et qu’ils peuvent donc être facilement additionnés puisqu’on effectue une opération sur des nombres ayant la même unité de mesure. On est ici dans une estimation absolue et non dans une estimation relative (on n’estime pas les éléments les uns par rapport aux autres). Donc pas de problème dans la théorie.

Mais en pratique, il est très difficile de pouvoir estimer le coût du retard en espèces sonnantes et trébuchantes. Heureusement qu’un certain framework à l’échelle a pensé à tout et propose de simplifier les valeurs du coût du retard en estimant de manière relative chacune des composantes de ce dernier. On va donc pour chacune des 3 composantes rechercher l’élément le plus petit et estimer les autres de manière relative par rapport au premier en utilisant la suite de Fibonnaci simplifiée (1,2,3,5,8,13,20,40). Voici un exemple avec deux fonctionnalités pour vous expliquer :

Valeur utilisateur/métier :

  • Fonctionnalité A : valeur estimée 1000 € c’est la plus petite de la liste donc elle prendra la valeur de référence 1
  • Fonctionnalité B : valeur estimée 100 000 €, elle est 100 fois plus importante que A donc avec la suite de Fibonnaci simplifiée elle sera probablement à 40.

Valeur du coût lié aux contraintes de temps :

  • Fonctionnalité B : perte de 10 € par semaine où la fonctionnalité est absente. C’est la plus petite et prend la valeur de référence 1.
  • Fonctionnalité A : perte de 1000 € par semaine où la fonctionnalité est absente. C’est 100 fois plus important que la fonctionnalité B donc on attribuera probablement la valeur 40 à cette fonctionnalité.

Valeur liée à l’information apportée par la fonctionnalité : A = B = 1

Coût du retard :

  • Fonctionnalité A : 1 + 40 + 1 = 42
  • Fonctionnalité B : 40 + 1 +1 = 42

On a donc le même coût du retard pour les deux fonctionnalités et si on s’arrête là, on ne peux pas prendre de décision sur cette valeur. Alors que si nous étions resté sur des considérations purement économiques , nous aurions probablement choisi de réaliser la fonctionnalité B avant A. On voit ici que le changement d’échelle entre les composantes amène à additionner des éléments qui n’ont finalement pas la même grandeur car exprimés en relatif. Au passage, les résultats perdent leur unité.

La simplification du délai de mise en oeuvre par la charge de développement

Le dénominateur est normalement le coût de mise en oeuvre de la fonctionnalité souvent simplifié par le coût de réalisation. Si on reste sur une évaluation économique, on a donc un coût du retard exprimé en devise par unité de temps (ex 500 €/semaine) et en dénominateur un coût qui correspond à un délai. Donc en multipliant le temps de réalisation par le coût du retard nous aurions le coût du retard pour le délai de mise en oeuvre. Vous suivez toujours ?

Prenons un exemple :

  • Une fonctionnalité A me fait perdre 1000€ par jour où elle n’est pas mise à disposition des utilisateurs. Si il faut 15j pour la mettre à disposition des utilisateurs alors je perdrai 15 000 euros (1000 * 15). Si au contraire il ne faut que 2j pour la mettre à disposition, je ne perdrai que 2000€.

Donc plus le délai de mise à disposition de la fonctionnalité est petit, moins je perds d’argent.

L’ambiguïté est encore une fois apportée par la simplification : le fait qu’une équipe puisse développer la fonctionnalité en 1 semaine ne signifie pas qu’elle pourra être mise à disposition dans le même délai. J’ai déjà rencontré des équipes programmes qui devaient attendre plusieurs mois pour voir livrée une fonctionnalité de quelques jours parce qu’elles n’avaient pas la main sur la priorisation de l’équipe de réalisation. Et je vous passe le fait que la suite de Fibonnaci simplifiée va encore rendre l’opération encore plus fausse. Vous pouvez trouver d’autres justification ici

La fausseté des chiffres

Nous avons donc des résultats complètement faux et ils sont faux car :

  • Une estimation est fausse de base et donc tous les chiffres fournis sont faux
  • L’opération mathématique est fausse car on ne tient pas compte des ordres de grandeur

Pourtant les chiffres et les mathématiques nous invitent à penser que ces résultats sont d’une exactitude implacable. Un petit peu comme dans les sondages. Un petit biais cognitif ici ? Au passage, j’en profite pour dénoncer le fait que certaines personnes pendant l’atelier savent très bien tirer parti de ces approximations pour infléchir les résultats vers les fonctionnalités qu’ils souhaitent voir développées en premier. Avec ces constats, je rappelle souvent aux participants que les résultats du WSJF ne sont pas une vérité immuable et que ce n’est qu’un outil d’aide à la décision.

Les biais cognitifs

Voici 2 biais cognitifs parmi les nombreux biais qui peuvent se manifester dans une séance de WSJF :

Le biais des coûts irrécupérables : l’exercice a pour vertu de se baser sur une vision économique et de contrer le biais des coûts irrécupérables; le biais des coûts irrécupérables est celui qui nous pousse à continuer à investir dans un élément même si il n’apporte plus de valeur parce que nous avons trop investi dedans :

  • Exemple : vous attendez un bus depuis 10 min et il n’arrive toujours pas, le tableau des horaires indique un retard de 20 min supplémentaires. Vous continuez à attendre à cause des 10 min que vous avez déjà dépensé au lieu de choisir un autre moyen de locomotion qui pourrait vous amener plus vite à votre destination.

En effet, imaginons qu’une fonctionnalité a été développée à moitié à la fin d’un incrément (cf SAFe). Il y a de fortes chances que lorsqu’on va recalculer le WSJF pour cette fonctionnalité, le délai de mise à disposition chute et donc que la fonctionnalité remonte mathématiquement dans la priorisation. Si cette fonctionnalité métier pour une raison ou une autre perd de la valeur utilisateur/métier alors le numérateur baisse et le résultat fera descendre le résultat du calcul.

Le biais de conformité : l’atelier doit permettre à tous les acteurs présents de s’exprimer librement lors du poker planning des items. après un premier tour de vote, on peut voir apparaître un biais qui force les personnes qui n’ont pas vraiment d’avis à se ranger dans le camp de la majorité.

La satisfaction client

Bon, faisons fi du calcul et des biais, vous obtenez une liste d’items ou de fonctionnalités priorisées et vous vous dites donc que vous allez donc prendre les premières et les développer pour le Minimum Marketable Produit (produit minimum répondant au besoin utilisateur). Mais au final, qu’en est-il de la satisfaction client ? Est-ce que les fonctions produisant un effet wahou sont effectivement dans cette liste ? Comme on aurait pu les trouver à l’aide du diagramme de KANO ? Pas certain que la valeur utilisateur du coût du retard ou la valeur liée à l’information ait inclus cet aspect. Qui par la même sera très difficile à chiffrer…

Les fonctionnalités techniques

Autre difficulté rencontrée : que faisons nous lorsqu’un item à prioriser n’apporte pas directement de valeur au client ? Dans le cas de fonctions purement techniques par exemple ? Problème de découpage vous me direz ? Mais parfois des API Back Office doivent être développées et mises à disposition avant que les services consommateurs puissent être disponibles. Dans ce cas, c’est la composante liée à l’information qui porte la valeur du composant. Encore une fois, cette valeur est difficile à estimer… Le WSJF va permettre grâce aux différentes composantes du coût du retard, de redonner du poids à tous les items qui ne sont pas visibles de l’utilisateur (comme les items techniques) mais qui sont néanmoins nécessaires à toutes les autres fonctionnalités.

Le WSJF, cela fonctionne !

Donc au final, nous avons des items difficiles à estimer, des estimations fausses, des opérations fausses…Et pourtant cela fonctionne quand même le WSJF ! Oui cela fonctionne ! Alors comment ? Et Pourquoi ?

Briser les silos et transmettre la stratégie de l’entreprise!

Le WSJF est selon la théorie une instance de décision et sa vertu réside surtout dans le travail préparatoire sur les items et des personnes effectuant ce travail. En effet, nous allons pendant ce travail préparatoire à la recherche des coûts, faire collaborer les personnes du marketing avec les architectes, les développeurs, les sponsors… Ces personnes vont se retrouver ensemble dans des séances de WSJF qui peuvent parfois durer plusieurs heures alors qu’elles n’auraient peut être pas pu avoir cette occasion d’échanger. Le format de l’atelier doit en théorie permettre à chacun de s’exprimer librement… Ces échanges et recherches autour de la valeur sont aussi le moyen de faire passer des informations sur la stratégie de l’entreprise !

Le consensus et l’alignement !

Tout le monde va se retrouver dans un même atelier et choisir de s’aligner autour d’une liste d’items. Que celle-ci soit juste ou fausse, importe moins que l’alignement et le consensus autour de cette dernière. Le consensus est obtenu après plusieurs échanges; charge quand même à l’animateur de faciliter les débats : à la vue des approximations, inutile de débattre plusieurs heures pour trancher entre une valeur de 1 ou 2 même si on passe du simple au double. L’exercice d’alignement fait prendre conscience à tous les acteurs, des enjeux et contraintes de chacun. La DSI prend connaissance des enjeux métiers et contraintes de temps liées au marché et le métier à son tour est informé des contraintes liées à la réalisation des fonctionnalités.

Donc le véritable sens ou but des séances de WSJF seraient moins de prioriser des items que de faire collaborer des personnes entre elles et de les faire commencer à s’aligner sur des objectifs . Du moins c’est mon interprétation de l’exercice !

Encore une suggestion avant de terminer, pourquoi ne pas intégrer dans le coût du retard une composante indiquant le coût carbone de la fonctionnalité ? Je pense que cela pourra bientôt être fort utile. Qu’en pensez-vous ?

Remerciements : Merci à Anne Doublier, Maud Guyot et Yann Tisseyre pour leurs retours et aide sur cet article.

Ressources :

Publicité

Apprendre à découper des user stories en jouant

Eric LannemajouLaisser un commentaire

Découper une user story est un des problèmes souvent remonté par les équipes qui travaillent en SCRUM. Vous pouvez trouver sur internet plusieurs articles qui définissent le format d’une user story et je vous renvoie notamment vers le blog de Oeil de Coach– comment rédiger des user stories comme hulk pour en savoir plus. Le site de SAFe (en anglais) indique aussi ce format ainsi que plusieurs axes pour découper une story selon :

  • les étapes du workflow
  • les règles métier
  • l’effort majeur
  • simple/complexe
  • la variation dans les données
  • les méthodes sur les données
  • les opérations
  • les qualités du système
  • les scénarios, uses cases
  • les études techniques ou spikes

Ces différents axes sont visualisables ici sous la forme d’un poster mais le découpage selon ces critères reste toujours un peu compliqué.

Mike Cohn qui est l’auteur de plusieurs livres sur les user stories, se base quant à lui sur 5 axes qu’il a décrit sur son blog à travers l’acronyme SPIDR :

  • S pour Spike : les études techniques ; si une user story vous paraît compliquée et que vous ne savez pas comment la réaliser, vous pouvez toujours effectuer dans un premier temps une étude technique ou fonctionnelle afin de récupérer des informations qui vous aideront par la suite à évaluer sa complexité.
  • P pour Paths : les chemins ou les différentes façon de faire une activité ; si vous avez par exemple une story qui vous précise que l’utilisateur souhaite acheter un objet avec différents moyens de paiement, vous pouvez préciser dans une première story les étapes du paiement par carte bleue, dans une deuxième les étapes relatives à un autre moyen de paiement comme le virement, dans une troisième…et ainsi de suite.
  • I pour Interfaces : les différents navigateurs web, le hardware…
  • D pour Data : les différents types de données ; si vous avez une story par exemple sur l’affichage du nom et du prénom d’un utilisateur, vous pouvez choisir de la découper pour afficher le nom dans une première story et le nom et le prénom dans une deuxième. Les deux stories sont alors indépendantes et vous pouvez donc choisir celle à implémenter en fonction de la priorité et du budget que vous avez.
  • R pour Rules : les règles métier ; vous pouvez choisir d’implémenter le cas le plus simple et créer des user stories complémentaires pour gérer les règles supplémentaires…

Pour vous aider à découper vos stories, vous pouvez jouer à Elefant Carpaccio crée par Alistair Cockburn, l’un des signataires du Manifeste Agile. Ce jeux nécessite une disponibilité de 1h30 à 2h. Mais si vous avez moins de temps, je vous propose de partir des axes de split de Mike Cohn ci-dessus et d’apprendre à découper les stories en jouant à split my story. Le jeu permet dans un premier temps de se familiariser avec les axes de SPIDR puis dans un second temps de créer vos propres stories découpables. N’hésitez pas à me poser des questions si vous souhaitez avoir davantage d’informations et merci de me donner vos feedbacks afin de continuer à améliorer le jeu 😉

NB : sur conseil de Jérôme Carfantan, je rajoute ce lien vers le jeu Split Poker de SOAT. Merci Jérôme.

Ressources du jeu

splitmystory-cardsTélécharger
splitmystory-cards_axes_with_iconsTélécharger
splitmystory-diplomaTélécharger
splitmystory-rules_v1.1Télécharger

Liens et références :

Le « tu » tue, ou la mécanique des mots

fxbravoLaisser un commentaire

Il vous est certainement arrivé de terminer un échange, avec une ou plusieurs personnes, déçu et frustré de ne pas avoir bien communiqué.

Cette situation banale peut déboucher sur un blocage.

Je me propose de décortiquer le processus permettant de résoudre des problèmes de communications internes (avec soi-même) et externes (avec un groupe) à travers ces différents outils:

  • la Stratégie de résolution de problèmes,
  • la Systémique,
  • la Communication Non Violente,
  • et les 5 Phases du deuil.

Une fois l’échange fini, vous avez peut-être eu envie d’en discuter avec votre entourage. Dans la majeure partie des cas, votre entourage vous conseille avec du « tu aurais dû » ou « tu aurais pu », en utilisant un ton bienveillant. La plupart de ces conseils peuvent être logiques d’ailleurs, et résonner en vous.

Et plus vous en discutez avec votre entourage, plus vous ressassez l’échange, et n’arrivez pas à passer à autre chose. Vous bouclez.

Afin de résoudre ce problème il est intéressant de se servir de l’excellente méthode de résolution stratégique des problèmes de Giorgio Nardone.

Résultat de recherche d'images pour "La stratégie de résolution de problèmes"
La stratégie de résolution de problèmes – G. Nardone

Dans son livre, Nardone insiste sur la première étape qui est de bien définir le problème.

Ceci constitue le premier pas vers la solution (assez logique). Il s’agit donc de décrire de la manière la plus empirique possible les termes de la situation problématique afin de parvenir à en dessiner une image tangible.

Précision :

  • Si le travail se fait en équipe, il faut arriver à un accord unanime sur la définition du problème.
  • Si le travail se fait seul, il est fondamental d’appréhender le problème sous tous les angles possibles avant d’en donner une définition. Il peut être utile de demander à des proches s’ils ont la même lecture de notre problème. cette démarche permet d’éviter de rester prisonnier de ses idées préconçues.

Très souvent, les personnes brûlent cette étape car ils la considèrent comme allant de soi. Si vous ne voulez pas partir sur de mauvaises pistes, il faut prendre le temps nécessaire à la bonne définition du problème: y revenir plusieurs fois, demander l’avis extérieur, examiner sous tous les angles possibles, ….

Voilà pour cette première partie importante.

Après avoir passé en revue un maximum de possibilités, vous arrivez, dans le cas présent, à l’établissement d’un tableau à 2 colonnes:

  • Ce que j’ai fait pendant l’échange
  • Ce que j’aurais dû faire (pensé par moi-même ou par les conseils d’autres personnes)

Dans la première colonne, vous marquerez tout ce que vous avez fait pour remédier au problème de communication avec votre interlocuteur.

Dans la deuxième colonne, vous noterez tous les inputs/conseils qui vous ont été adressés lors de vos divers échanges avec votre entourage.

Une fois les 2 colonnes remplies, vous vous poserez la question suivante: vu que je sais ce que j’ai fait et que je sais ce que j’aurais dû/pu faire, pourquoi cela me tracasse-t-il encore?

Le Penseur in the Jardin du Musée Rodin, Paris March 2014.jpg
Le penseur de Rodin

Ayant déterminé d’où pouvait venir le problème, vous pouvez passer à l’étape de modélisation systémique. Pour ceux qui ne connaissent pas la systémique et les 2 types de boucles de rétroaction, je vous en fait un rapide résumé:

  • une boucle de renforcement a, comme son nom l’indique, une action amplificatrice.
  • une boucle d’équilibrage a, quant à elle, une action d’équilibration.

Boucle de renforcement

La boucle se lit de la manière suivante: au plus je suis « frustré », au plus j’en parle et j’obtiens des « conseils », et au plus j’ai des « conseils », au plus je suis « frustré » de ne pouvoir les mettre en application.

Une fois cette boucle de renforcement posée, il faut trouver ce qui peut moduler son amplification.

Boucle d’équilibrage

La boucle se lit de la manière suivante: au plus je suis dans la « projection » (le terme est ici employé dans sa définition psychanalytique) au plus je suis dans « l’action », et au plus je suis dans « l’action », au moins je suis dans la « projection ».

Vous avez vos deux boucles. Mais cela ne suffira pas à régler intégralement le problème. Il vous faudra savoir ce qui active la boucle d’équilibrage, qui active à son tour la boucle de renforcement.

Pour cela, il est possible d’utiliser d’autres outils, comme la Communication Non Violente (CNV), créé par Marshall Rosenberg (psychologue).

Les 4 étapes de la CNV (Wikipedia)

La CNV est un processus de communication en 4 étapes:

  • Observation (O) : décrire la situation en termes d’observation partageable ;
  • Sentiment et attitudes (S) : exprimer les sentiments et attitudes suscités dans cette situation ;
  • Besoin (B) : clarifier le(s) besoin(s) ;
  • Demande (D) : faire une demande respectant les critères suivants : réalisable, concrète, précise et formulée positivement. Si cela est possible, que l’action soit faisable dans l’instant présent. Le fait que la demande soit accompagnée d’une formulation des besoins la rend négociable.

Voilà d’où peut venir le blocage: vous êtes dans l’incapacité d’agir, de mettre en pratique les conseils de votre entourage, car la situation est tout simplement passée. Une vraie injonction paradoxale!

Les conseils prodigués par vos proches, qui sont tous pleins de bonnes intentions, vous ont fait boucler à chaque fois. Vous ne pouvez tout simplement pas appliquer leurs conseils car cette échange ne se reproduira pas.

Ainsi, lorsque vous transformez tous les conseils du type « tu aurais dû/pu » en « il aurait été possible de », la boucle d’équilibrage opère son changement: vous n’êtes plus dans la projection d’une action, mais dans l’explication théorique générale.

Le « tu » peut être bloquant, culpabilisant et entrainer une boucle (sans fin) de « J’aurais dû/pu ». Le « il » a une vertu de neutralité et de distanciation, qui permet de prendre un recul nécessaire sur la situation.

Bien sûr, certaines personnes ne réagiront pas de la même manière à ce même problème. Ceci dit, les mécanismes décrits dans l’article peuvent se produire dans une multitudes d’autres cas (Les conflits, les TOC, les phobies, ….)

En communication, un mot peut faire toute la différence (avec soi-même et avec les autres).

Pour finir, et vérifier que le problème est bien résolu, vous pouvez vous servir de l’outil créé par Elizabeth Kubler Ross: les 5 phases du deuil

Comme vous pouvez le voir sur le schéma ci-dessus, à la suite d’un échange « traumatisant », il faut passer par un processus distinct de 5 phases. La personne peut passer alternativement de la phase 1 à 4. Tant que le système traumatique est actif, il est impossible d’accéder à la 5ème étape.

En conclusion, si vous avez des conseils à prodiguer, communiquez par le biais du « IL », pas du « TU ». Inspirez-vous de la Communication Non Violente ou autre technique de communication. Les personnes en face vous remercieront.

La communication est un Art, et il faut toute une vie pour essayer de la maîtriser.

Systémiquement.

François-Xavier

Liens et références :

  • La stratégie de résolution des problèmes – G. Nardone – Enrick B. Editions
  • Thinking in systems – D. Meadows – Chelsea Green Publishing
  • Les mots sont des fenêtres – Marshall Rosenberg – Edition La Découverte
  • Sur la vie et le deuil – E. Kubler-ross et D. Kessler – Edition Pocket

La rétrospective : amélioration continue et systémique

Eric LannemajouLaisser un commentaire

220px-PDCA_Cycle_FR.svg

La rétrospective est le rituel SCRUM d’amélioration continue des équipes qui se base sur cette représentation communément connue à tort (cf cycle de Shewhart) sous le nom de roue de Deming ou PDCA : Plan, Do, Check, Act (Planifier, Développer/Réaliser, Contrôler/Vérifier et Ajuster/Améliorer en français). J’ai rencontré des équipes qui avaient tendance à négliger ce rituel, le trouvant trop long ou le sacrifiant sur l’hôtel de la productivité lorsque celles-ci n’avaient plus le temps de réaliser les fonctionnalités du produit ou encore lorsque leur performance n’était plus à la hauteur de leur engagement. Plusieurs raisons peuvent expliquer le fait que les équipes ne perçoivent pas la valeur de la rétrospective et parmi celles-ci, nous pouvons énumérer les suivantes:

  • L’équipe n’a pas compris le sens du rituel
  • Les actions issues de la rétrospective sont trop grosses pour être facilement réalisées
  • Les solutions apportées sont perçues comme des pansements
  • Les actions ne sont pas suivies dans le temps
  • (…)

Je pourrais encore continuer cette énumération mais je souhaite surtout porter votre attention sur les deux premières qui sont le sens de ce rituel et la taille des actions.

Le sens de la rétrospective

La rétrospective est donc le rituel SCRUM dédié à l’amélioration continue d’une équipe. Mais pour être plus précis, ce rituel va chercher à modifier la façon dont l’équipe travaille. En changeant sa façon de travailler, l’équipe va donc agir sur le système. Mais pourquoi s’intéresser au système et non aux individus ? 

Une première partie de la réponse pourrait être qu’une équipe est définie par les relations entre les individus. Lorsqu’une personne rejoint une équipe, cela influence les relations entre tous les membres de l’équipe. Il en est de même lorsqu’un membre de l’équipe la quitte. Pour approfondir sur le sujet, vous pouvez lire « Coaching d’équipe » d’Alain Cardon (polarisation, circularité, rôles délégués…) coaching_equipeou encore vous référer au modèle de Tuckman qui explique les différents états d’évolution d’un groupe. On comprend donc qu’il va falloir agir sur les relations entre les personnes en considérant l’équipe comme un tout, comme un système. Modifier la relation entre deux membres de l’équipe aura des répercutions sur les relations de tous les membres de celle-ci.

Deming dans son expérience des « Red Beads » nous donne un deuxième élément de réponse. L’expérience est la suivante :  dans un bac, mélangez 3200 billes blanches qui représentent les résultats attendus avec 800 billes rouges qui modélisent les défauts.  Convoquez plusieurs personnes dont les rôles sont les suivants :

  • Les employés, au nombre de 6,  dont la tâche est, à l’aide d’une planchette de bois percée, de récupérer 50 billes du bac en s’arrangeant pour avoir le moins de billes rouges possible dans l’échantillon.
  • Les inspecteurs, au nombre de 2, dont la tâche est de compter les billes rouges présentes sur la planchette de bois.
  • L’inspecteur général qui motive et contrôle le travaille des troupes
  • Le scribe ou comptable qui enregistre les résultats et effectue le total des essais des employés.
  • Des actionnaires qui investissent dans l’entreprise.

Faîtes leur alors jouer un jeu de rôle avec un processus très précis de récupération des billes dans le bac en effectuant une certaine pression sur les employés. Les meilleurs employés, qui remontent le minimum de billes rouges, sont récompensés et les moins bons sont licenciés.

Deming reproduit dans cette démonstration, ce qui pourrait se passer à l’échelle d’une entreprise. Parmi les nombreux constats et leçons que nous pouvons retirer de cette expérience :

  • Les performances ne dépendent pas des employés mais du rapport du nombre de billes rouges et blanches. En effet, un employé qui avait de bons résultats peut ensuite avoir des résultats moins bons alors qu’il s’y prend exactement de la même manière pour extraire les billes.
  • Rien ne sert d’essayer de jouer sur la motivation des employés ou encore en agissant sur une cause locale en leur indiquant de manière précise comment récupérer les billes. C’est le système qui impose les résultats obtenus.

Mais surtout,  l’expérience ne dépend pas des personnes choisies pour celle-ci. Et c’est là que cela devient intéressant. En effet, pour pouvoir améliorer la façon de travailler, il faut agir sur le système, de façon globale.

Ce point de vue est aussi partagé par Peter Senge dans la « cinquième discipline« . La cinquième discipline de Peter Senge

Dans les enseignements du jeu de la bière, ce dernier nous indique que la structure influence le comportement : « Des personnes différentes placées dans une même structure tendent à produire des résultats similaires… Plus souvent qu’on ne le croit, ce sont les systèmes qui produisent leurs propres crises, et non les forces extérieures ou des erreurs individuelles. » La structure ici, est une structure systémique; c’est en fait la dynamique de relations au sein d’un groupe et qui influence son comportement. Dans un système, l’effet de vos décisions dépasse les limites de votre propre position, votre succès dépend de tous les acteurs du système. Néanmoins, des petites actions locales peuvent permettre de modifier le système de façon globale. La méthode des petits pas est aussi connue par le concept japonais KAIZEN est la fusion de 2 mots KAI et ZEN qui signifient « changement » et « meilleur ».

Mais pourquoi faire des petits pas et non pas de grands changements ?

  • Parce qu’on se sent moins impuissant à réaliser de petites actions : Face à de petites actions, on se sent moins impuissant et le sentiment d’angoisse lié à l’échec est moindre. On évite les réactions du genre : « C’est trop dur, je n’y arriverai jamais »
  • Parce que ceci génère une satisfaction rapide : il est plus facile de réaliser de petites actions que des actions longues et compliquées. Le résultat associé aux petites actions se voit souvent assez rapidement. Ceci renforce la maîtrise et génère de la satisfaction.
  • Parce qu’on apprend plus vite : les petites actions sont moins coûteuses à mettre en place, le risque associé est donc moindre. Si vous vous trompez sur une action sur laquelle vous avez dépensé peu d’énergie, vous serez davantage disposé à revenir en arrière pour pivoter. Un exemple à l’échelle d’un produit est le MVP (Minimum Viable Product)
  • Parce que les petites actions génèrent moins d’opposition : C’est l’histoire de la grenouille qu’on ébouillante selon Peter Senge : Si on plonge une grenouille dans une marmite d’eau et qu’on augmente petit à petit la température de l’eau, celle-ci s’ébouillantera en restant dans l’eau. A contrario, si vous la plongez dans une marmite bouillante, celle-ci fera tout ce qu’elle peut pour en sortir. En systémique, les petites actions déclencheront à priori des boucles de rétroactions  de type régulateur moins importantes que les grosses. En simplifiant l’explication de ces effets régulateurs, on peut définir ceux-ci comme des actions engendrées par le système et visant à rétablir l’équilibre ; c’est à dire que ces actions auront des effets inverses à celles que vous avez engagées.
  • Parce que les petites actions peuvent faire boule de neige : toujours en systémique, les petites actions peuvent produire un effet d’amplification. Le rapport entre l’énergie dépensée et le résultat sera encore plus important et ceci augmentera encore davantage la satisfaction.

Les boucles de rétroactions de type régulateur (actions contraires) ou amplificateur (boule de neige) peuvent souvent être accompagnées d’un effet retard ; c’est à dire que les effets de celles-ci ne sont visibles qu’après un certain délai. Lorsque vous réalisez des actions de rétrospective, il est parfois bon d’attendre un peu ou de répéter l’action suffisamment avant de tirer des conclusions trop hâtives et de pivoter.

Le Scrum master et les équipes doivent garder en tête que la rétrospective est leur chance de rester acteurs du changement et de faire évoluer le système de manière globale. Ceci est rendu possible grâce à de petites actions et aux mécanismes systémiques de régulation et d’amplification.

Liens et références :

Réduire la dette émotionnelle à Agile France avec Marilyn Kol

Eric LannemajouLaisser un commentaire

IMG_1056

J’étais à Agile France jeudi et vendredi dernier et c’est dans une salle de 25 personnes mais avec à peu près du triple de participants que Marilyn Kol nous a raconté comment gérer la dette émotionnelle d’une équipe Scrum. Selon Marilyn, chaque équipe, en plus de sa dette technique bien connue des développeurs et des Scrum Masters, devrait porter attention à une dette émotionnelle. Si on n’y prend garde, celle-ci pourrait s’amplifier au cours du temps et prendre des proportions ingérables. Cette dette qui tire son origine des conflits (opposition d’idées ou d’opinion réelle ou perçue comme telle entre deux groupes ou deux personnes) et irritants entre les membres d’une équipe, peut déraper jusqu’à atteindre le niveau 5 irrémédiable de « la guerre mondiale » où tous les membres de l’équipe sont en guerre. Mais il existe des solutions pour empêcher que le climat à l’intérieur d’une équipe ne se dégrade à ce point et Marilyn, forte de son expérience professionnelle, nous a prodigué quelques conseils.

Parmi ceux-ci, le premier est de reconnaître et d’assumer les problèmes. Ceux-ci peuvent, dans un premier temps, s’exprimer à travers le langage corporel des différents protagonistes lors des rituels Scrum et notamment lors du daily scrum. Vous pouvez identifier les signaux non verbaux à condition que vous soyez à minima empathique; que vous puissiez lire et détecter les émotions des personnes sans que celles-ci n’affecte les vôtres. Une fois le problème rendu visible vous pourrez essayer de résoudre collectivement celui-ci.

Afin de mieux cerner le problème, et dans le cas où celui-ci relève d’après vos hypothèses d’un malentendu ou de difficultés de communication, vous pouvez utiliser ou proposer l’écoute active; celle-ci consiste à écouter l’autre pour le comprendre et non pour essayer de lui répondre. Ensuite, vous pourrez reformuler afin de vous assurer de la problématique ou encore questionner les antagonistes avec la technique des 5 pourquoi afin de trouver les causes racines. Si vous pensez que vous avez plutôt à faire à une divergence d’opinion, de point de vue ou si le problème concerne des émotions, voici ci-dessous quelques outils qui vous seront fort utiles.

Afin de désamorcer un conflit, vous pouvez inviter les membres de votre équipe (si vous êtes Scrum Master) à se servir de la communication non violente (CNV).  Celle-ci détaille un protocole de communication en 4 étapes :

2018-06-15 22_43_41-Amazon.fr - Les mots sont des fenêtres (ou bien ce sont des murs) - Marshall B.

  • O pour observation, on relate les faits
  • S pour exprimer ses sentiments vis-à-vis de ces faits
  • B pour exprimer ses besoins
  • D pour formuler une demande

Vous pourrez retrouver plusieurs mises en situation dans le livre de Marshall Rosenberg; les mots sont des fenêtres (ou bien ce sont des murs).   Selon Marilyn, les personnes ont souvent du mal à utiliser ce protocole au début. Aussi n’hésitez pas à insister, parfois lourdement, en montrant l’exemple dès que possible (« lead by example »…). Afin de rendre votre intervention encore plus efficace, vous pouvez remplacer les questions en « pourquoi » par des questions en « en quoi ». Par exemple, au lieu de demander : « Pourquoi es-tu en retard au daily Scrum ? », vous pourriez reformuler par « En quoi est-ce difficile pour toi de venir à l’heure au daily Scrum ? ». Enfin, si vous sentez que quelqu’un est en retrait ou fait la moue à la sortie d’une réunion, vous pouvez, par exemple, utiliser quelques soupçons de psychologie positive : « C’est cool, la réunion a bien remotivé l’équipe! »

Dernier chapitre de la présentation. Marilyn nous a partagé quelques outils afin d’améliorer la communication d’une équipe et permettre à ses membres de mieux se comprendre :

  • L’atelier sur les valeurs : chaque personne va définir individuellement ses valeurs, partager aux autres leur signification ainsi que leur réaction si cette valeur était trahie. Puis, les valeurs communes vont être regroupées afin de former celles de l’équipe.

J’ai facilité un atelier de team building il n’y a pas très longtemps où j’ai fait construire à l’équipe un poster avec les valeurs. Je trouve intéressant dans l’atelier ci-dessus, que chacun exprime le sens qu’il donne aux mots et partage les limites qu’il ne souhaite pas voir dépassées. Marilyn nous indique que cet atelier peut être donné lors de la construction de l’équipe ou lors de l’arrivée d’un nouveau membre.  Selon elle, cet événement génère une nouvelle équipe.

Vous pouvez retrouver les différents stades de formation d’une équipe dans le modèle de Tuckman (article que je vous ai récemment partagé sur LinkedIn).

  • L’atelier sur les moving motivators issus du Management 3.0 et qui permettent d’identifier les facteurs intrinsèques de motivation; c’est-à-dire ceux qui apportent du plaisir par eux même.
  • La rétrospective Lego ou chaque personne doit construire sa manière de travailler privilégiée; seul ou en équipe ? Introverti ou extraverti ? Attention, un introverti n’est pas quelqu’un qui n’aime pas les gens mais qui puise son énergie lorsqu’il est seul.
  • Le MBTI qui permet de définir les personnalités selon 4 axes :
    • comment te ressources-tu ?
    • comment prends-tu tes décisions ?
    • comment recueilles-tu les infos ?
    • comment gères-tu le monde extérieur ?
  • IMG_1068[1]La rétrospective Empathy Map 
  • La rétrospective « Turn the table » afin de démontrer aux différents membres d’une équipe qu’ils se connaissent mieux qu’ils ne le pensent et qu’ils sont plus empathiques qu’ils ne le croient.

Pour les 5 dernières minutes, Marilyn a rapidement abordé les schéma ci-contre pour nous expliquer qu’il faut souvent creuser plus profondément que les comportements pour comprendre une situation.

La qualité de la mise en forme, le storytelling et l’énergie de Marilyn nous a tenu en haleine pendant toute la session.  L’ovation finale de la salle était amplement méritée.

 

 

Liens et Références

Qu’est-ce qu’un Scrum Master ? (Agile en Seine 2017)

Eric LannemajouLaisser un commentaire

Voici un retour un peu tardif sur les conférences de Agile en Seine du 20 septembre 2017 et notamment sur la présentation de Romain Couturier sur « Qu’est-ce qu’un Scrum Master ?« . J’ai réalisé un petit dessin qui centralise ce que j’ai retenu et je l’ai publié sur linkedIn dans un POST. Mais comme il est parfois difficile de retrouver les informations dans le flux dense du réseau social, je republie ce dernier ci-dessous 😉

20170920-scrummaster

Je vous propose aussi de pouvoir approfondir le sujet avec l’article de Jean Claude GrosJean, « Le ScrumMaster n’est pas un Coach Agile« 

 

L’estimation et la planification agile

Eric Lannemajou1 commentaire

L’une des valeurs du manifeste Agile est de favoriser l’adaptation par rapport à un plan établi. Cette valeur est parfois mal interprétée et ne signifie pas qu’il ne faut pas planifier. Mike Cohn nous explique dans Agile Estimating and Planning les raisons pour lesquelles il est nécessaire pour une équipe Agile de planifier.51I7-xMCQDL._SX408_BO1,204,203,200_

Dans mon expérience, j’ai rencontré plusieurs équipes qui se demandaient comment il fallait planifier et surtout comment estimer les stories. Faut-il estimer en point, en jours idéaux, avec la suite de Fibonnaci ? L’estimation du travail est souvent source de tension ou de conflit entre l’équipe de développement et les commanditaires du projet ou encore avec le Product Owner. Mais avant de se poser la question du « comment? », j’invite les équipes à revenir sur le « pourquoi? ». Pourquoi estimer ? A quoi et à qui cela sert ?

Mike Cohn nous explique ces raisons dans Agile Estimating and Planning. Un plan doit permettre de :

  • guider les décisions des investissements à réaliser.
  • savoir si un projet est sur le point de livrer des fonctionnalités que les utilisateurs attendent.
  • connaître le nombre de ressources disponibles pour travailler sur ce projet pendant une période définie.

Planifier est souvent difficile et les équipes peuvent tomber dans les deux extrêmes de ne pas planifier du tout ou de trop planifier. Planifier est une activité difficile et le cône d’incertitude ci-dessous nous démontre combien il est difficile d’estimer le projet dans les premières phases de ce dernier. A la définition du projet, l’incertitude est de 60% et il faut attendre le design détaillé pour réduire cette incertitude à 10%. Ce qui explique donc que plus de 2/3 des projets dépassent le coût estimé initialement.

coneOfUncertainty

Mais alors si cela est si difficile de planifier un projet, pourquoi effectuer cette activité ? Et bien tout d’abord pour :

  • réduire le risque : les discussions qui servent à estimer le projet permettent de mettre en lumière les potentiels risques du projet.
  • réduire l’incertitude : un des risques les plus importants d’un projet n’est pas de ne pas sortir dans les temps mais bien de développer des fonctionnalités qui ne répondent pas aux besoins des utilisateurs. Ce risque peut être atténué via une planification agile continue qui permet de récupérer les retours utilisateurs au fur et à mesure du projet.
  • aider à prendre de meilleures décisions : l’estimation du coût d’un projet et de sa valeur métier nous permet de décider si le projet doit être lancé.
  • établir la confiance :  les fréquentes livraisons de fonctionnalités permettent d’établir la confiance entre le client et les développeurs. Les estimations deviennent de plus en plus fiables au cours des itérations et permettent de prioriser les fonctionnalités en se basant sur l’estimation fiable de l’équipe de développement.
  • transmettre de l’information : un plan ne garantit pas la livraison d’un périmètre à une date précise mais permet néanmoins de fixer un niveau d’attente et l’approche pour arriver à satisfaire cette attente.

Maintenant que nous savons à quoi sert la planification et l’estimation agile, nous pouvons insister sur le « comment ». Certaines équipes estiment leurs stories en point de complexité/d’effort alors que d’autres les estiment en jours idéaux. Les jours idéaux sont des jours où chaque membre de l’équipe consacrerait 100% de son temps de travail dans la journée à la story sans être dérangé par d’autres activités professionnelles.

Les partisans du chiffrage en points mettent en avant que ce type de chiffrage :

  • permet aux équipe multi-fonctionnelles de pouvoir avoir une mesure commune.
  • est constant dans le temps, ne dépend pas du niveau de capacité ou de compétence de la personne qui va réaliser la story.
  • est une pure mesure de taille et ceci permet donc de pouvoir chiffrer par analogie, de manière relative. De plus, comme cette mesure est complétement abstraite, les équipes ne devraient pas être tentées de comparer cette estimation avec du temps passé.
  • est plus rapide grâce notamment à la possibilité de comparer de manière relative par analogie avec des stories de référence.

Enfin, les jours idéaux varient d’une personne à une autre. Cependant,  il est plus facile d’expliquer un chiffrage en jours idéaux aux personnes extérieures à l’équipe et pour une équipe qui débute, ce mode de chiffrage est plus facile à appréhender.

L’action de planification pour une équipe agile s’effectue à plusieurs horizons et plusieurs niveaux d’abstraction. L’action de planifier revient à se fixer des objectifs sur une période donnée et à les réviser tout en décalant des objectifs plus long terme. Pour une équipe qui travaille en SCRUM, l’équipe va fixer un objectif de release avant le premier sprint et réviser ce dernier au fur et à mesure des sprints. En effet, la release va être initialement estimée et planifiée puis revue à la fin de chaque itération pour évaluer comment le périmètre associé à la date évolue. L’action ici sur le périmètre du sprint a une influence sur le périmètre de la release. On parle ici de planification en couches successives ou en oignon.

Le dernier point détaillé par Mike Cohn que je souhaiterais partager est celui du niveau de détail de l’estimation et de la planification. A quel moment et niveau de détail faut-il arrêter de planifier ? Cette question peut aussi se poser dans un projet en cycle en V et j’ai déjà par le passé fait l’amère expérience de trop planifier un projet. Ce problème se présente par le fait de planifier de toutes petites tâches et donc de planifier tout le temps. Planifier devient alors l’activité principale et l’information portée par ce niveau de détail n’apporte pas assez de plus-value au projet. Mike Cohn nous explique ce travers avec le petit exemple suivant : « si vous vous demandez combien de cookies j’ai mangés l’an dernier, vous avez plusieurs options pour répondre à cette question :

  • Estimer le nombre de cookies au hasard
  • Demander à mes proches, mes amis, ma famille
  • me suivre pendant une journée, compter combien je mange de cookies et extrapoler sur un an.

Cependant, si votre but est de savoir si vous pouvez m’offrir ou non, une boîte de cookies, alors vous n’avez pas besoin d’avoir une mesure ultra précise et il n’est donc pas nécessaire d’effectuer trop de recherches. Dans ce cas précis, la première solution pourra convenir. Quand on planifie, il faut donc toujours se demander dans quel but afin d’évaluer le niveau d’effort et de détail que nécessite cette planification.

Je vais vous décrire une situation que j’ai déjà rencontrée et qui peut s’avérer être un parfait exemple d’une planification peu « agile ». Lors d’un projet avec un centre de service, j’ai travaillé avec une équipe qui chiffrait les stories en points en utilisant la suite de Fibonnaci. L’équipe n’était pas dédiée et le nombre de point d’une story, convertie par un coefficient donnait directement le nombre de jours et donc le coût de la story. L’équipe allouait un nombre/capacité de points différent à chaque itération qui représentait donc directement le nombre de jours pendant lesquels l’équipe allait travailler sur le produit. Cette situation peut aboutir à plusieurs effets pervers :

  • Comme l’équipe estime une capacité ou un coût de story fixe et que celui-ci représente le nombre de jours de travail sur la fonctionnalité, il n’est plus possible de lisser entre les stories d’un même sprint.
  • Comme l’équipe estime avec la suite de Fibonnaci et que les stories sont directement converties en jours/homme, une story légèrement supérieure à 8 passe à 13, ce qui n’est pas du tout le même coût : le commanditaire se sent lésé.
  • Comme les développeurs estiment chaque story et prennent un engagement sur chacune d’elles, ceux-ci ont tendance à se protéger et réhausser leur chiffrage.
  • Comme l’équipe n’est pas dédiée et que la capacité change à chaque itération, on perd la possibilité d’apprendre au cours des sprints.
  • Le fait de ne pas estimer de release et de changer la capacité à chaque itération supprime toute possibilité de planification.

Cette situation aboutit donc à une forte tension entre le commanditaire et l’équipe de développement. Sans compter que ceci rajoute aussi de la pression sur les développeurs qui doivent prendre un engagement à la story. Ce pattern qui favorise un rapport contractuel et impose une facturation à la story est selon moi anti-agile.

Liens et Références :

MVP et Design Sprints

Eric Lannemajou4 commentaires

Aujourd’hui, je voudrai vous parler de MVP; Minimum Viable Product (ou Produit Minimum Viable en français). On en entend souvent parler autour de nous et notamment lorsqu’un projet débute. Le MVP permettrait au Responsable de Produit (PO) d’apporter le maximum de valeur métier à ses utilisateurs en un minimum d’effort de la part de l’équipe qui réalise le produit ; effort souvent limité aux premiers sprints. De nombreuses Entreprises de services numériques (ESN) proposent donc d’échelonner leurs réalisations suivant ce MVP.

Mais qu’est-ce que le MVP ? Wikipedia n’est pas très loquace sur le sujet : « stratégie de développement de produit, utilisée pour de rapides et quantitatifs tests de mise sur le marché d’un produit ou d’une fonctionnalité » et nous renvoie notamment vers Eric Ries auteur de  The Lean Startup. Pour simplifier, le Processus du Lean Startup se base sur les trois composantes suivantes :

  • Build qui est l’étape de la construction methodology_diagramdu produit ou de la fonctionnalité
  • Measure qui est l’étape ou on mesure la plus-value de la fonctionnalité ou du produit construit à l’aide de métriques.
  • Learn qui est l’étape où on apprend auprès des utilisateurs et où on récupère leur feedback sur l’utilisation du produit ou de la fonctionnalité.

Le MVP est donc un outil ou une stratégie qui permet de mesurer la pertinence d’un produit ou d’une fonctionnalité auprès des utilisateurs concernés sans avoir pour autant besoin de construire ces derniers. Alexander Cowan dans son cours Running Product Design Sprints, nous explique que le MVP est utilisé pour tester la motivation des utilisateurs pour une fonctionnalité et valider des hypothèses concernant la plus-value métier de cette dernière. Les différents outils ou véhicules qu’il propose sont les suivants :

  • Sales vehicle :  technique qui consiste à vendre la fonctionnalité ou le produit. Il n’y a pas d’interaction entre les utilisateurs et la fonctionnalité ou le produit. Cette technique peut se matérialiser par un envoi de mail aux utilisateurs, par une page de publicité sur un site, par un sondage, un formulaire…
  • Wizard of Oz vehicle : technique qui consiste à présenter le produit/fonctionnalité ou du moins une interface qui va simuler le fonctionnement du produit ou la fonctionnalité. Cette technique peut se matérialiser par une démonstration, une présentation animée, un webinar ou encore une vidéo…
  • Concierge vehicle : technique qui consiste dans le fait de fournir la fonctionnalité à l’utilisateur, même si cette fonctionnalité est offerte manuellement. Cette technique ne nécessite pas forcément la construction du produit ou de la fonctionnalité finale.

Ces 3 techniques peuvent être combinées afin de valider les hypothèses de plus-value  formulées pour résoudre les problèmes utilisateurs et de nombreuses entreprises les ont utilisées avant d’investir des fonds dans la construction de leur produit ou des fonctionnalités.

Voici quelques exemples décrits dans le cours Running Product Design Sprints :

  • Les créateurs de DROPBOX ont commencé en publiant une démo sur YouTube puis en intégrant cette vidéo dans une page web avec un formulaire  pour récupérer des signatures : on reconnaît ici une combinaison Wizard of Oz et Sales.
  • Le créateur de ZAPPOS, le site de vente de chaussures online, Nick Swinmurn a commencé en prenant une photographie d’une paire de chaussures  et en la postant sur un site web pour savoir si des personnes achèteraient cette paire de chaussures. Une fois que les clients ont acheté la paire de chaussures, ils ont pu recevoir celle-ci à leur domicile. Le MVP utilisé  est le Concierge.
  • SPRIG est une entreprise de préparation et de livraison de plats préparés. Les créateurs se sont organisés dans une cuisine temporaire pour préparer des plats. Ils ont envoyé des mails à leurs amis et ont ensuite vendu les plats grâce au site EventBrite. Ils ont pu ainsi mesurer le succès de leur idée. Nous sommes ici dans un cas de Concierge puisque les utilisateurs ont pu expérimenter le service.

On peut trouver de nombreux autres exemples sur le net : Twitter, Groupon…Mais le but d’un MVP est d’apprendre et de valider des hypothèses sur les utilisateurs et selon Alexander Cowan, le Concierge MVP est celui qui permet d’en savoir le plus. Les habitudes des utilisateurs peuvent être mesurées sur le produit grâce à des tags et des indicateurs…Des interviews peuvent aussi compléter ces données.

Pour revenir au début de l’article, je ne suis pas certain qu’on puisse vraiment parler de MVP dans le cas où on construit un produit mais où on ne valide aucune hypothèse sur les utilisateurs. Le but du MVP, ne l’oublions pas, est de valider la pertinence du service proposé aux utilisateurs, en un minimum de temps et d’investissement.

Liens et Références

Agile Playground #27

Eric LannemajouLaisser un commentaire

Merci encore à GOOD de nous avoir reçu mardi dernier, dans ses locaux pour le premier Agile Playground après les vacances d’été. Nous étions bien plus d’une vingtaine pour cette rentrée Agile Playground. Nous avons commencé la soirée par un petit Icebreaker : le nombre secret, vous connaissez ? Chaque personne note un nombre sur un post-it et le garde secrètement. Il doit ensuite le faire deviner aux autres participants sans parler et sans dessiner ce nombre afin d’obtenir finalement une chaîne ordonnée de personnes du plus petit au plus grand nombre.

Nous avons ensuite commencé les jeux. parmi les jeux proposés, nous avions le choix entre :Carpaccio, mener un sprint planning en DUPLO, utiliser les Rory’s cubes pour une rétrospective, les vaginales; un jeu de cartes sur le concept du mille bornes et traitant du plaisir féminin. C’est bête, je n’ai même pas eu le temps de discuter avec les créateurs du jeu. On aurait pu s’échanger des tuyaux sur la création d’un jeu de cartes.

J’ai pour ma part décidé de participer au jeux de planification de sprint et au jeu d’utilisation des Rory’s cubes pour une rétrospective. Les deux jeux étaient animés par Daniel Paire et la soirée fut riche en information et en enseignements.

Revenons au premier jeu ou comment faire estimer un sprint backlog à l’aide de DUPLO. Daniel nous a expliqué que pour des équipes relativement novices en SCRUM, il modélisait la vélocité réelle d’un sprint en construisant une tour en DUPLO (parce que les DUPLO de sa fille sont plus gros que les Lego classiques et qu’il en faut donc moins pour faire une tour). lego_duplo_5538_z1Une fois la tour de vélocité construire et le PO positionné sous la forme d’un animal au sommet de celle-ci afin de signifier par la symbolique que la tour appartient au PO, Daniel a construit des tours plus petites, de différentes tailles; 1 à n DUPLO afin de modéliser les différents coûts d’une story; XS, S, M, L, XL. Il a ensuite créé une liste de stories et nous avons pu commencer à les évaluer. Il a intentionnellement créé une story de grande taille avec de nombreuses contraintes fonctionnelles afin que nous l’évaluions à la taille XL et que nous puissions nous rendre compte que celle-ci était visuellement plus grande que la moitié de notre tour de vélocité. Nous avons donc découpé cette story en stories plus petites. Les développeurs ne connaissent pas le rapport entre la taille de la tour et la vélocité réelle. ceci permet donc à ceux-ci de pouvoir estimer librement sans être tenté d’effectuer une conversion  en jours/homme. Le jeu permet aussi de donner un rythme différent et d’apporter un peu de nouveauté à ce rituel qui peut parfois être long et fastidieux. Daniel nous l’a affirmé : « si un développeur commence à estimer le rapport de conversion entre la tour DUPLO et la vélocité, alors il le changera aussitôt ». Mais alors me direz-vous , comment savoir si on suit la release planifiée. Daniel possède un fichier Excel qui lui permet de  convertir les DUPLO en vélocité réelle pour détecter toute variation par rapport à la planification! Il envoie la vélocité réelle au Product Owner…

Le deuxième jeu auquel j’ai participé est l’utilisation des Rory’s cubes pour l’animation d’une rétrospective. Ce jeu a tout d’abord été inventé par un psychologue Danois afin de susciter la créativité et l’imagination des enfants qui doivent inventer des histoires à partir de dés.

rorys-story-cubes

Le jeu est constitué de 3 séries de 9 dés. Dans un premier temps, chaque personne de l’équipe va lancer à tour de rôle les trois séries et retenir 3 dés pour chaque série.

  • A partir des 3 premiers dés, la personne doit indiquer quelque chose qu’elle a aimé ou non dans le sprint passé en utilisant le modèle : « dans le dernier sprint j’ai aimé… je n’ai pas aimé… »
  • A partir des 3 dés de la seconde série, la personne doit imaginer une solution pour faire perdurer ce qu’elle à aimé ou résoudre ce qu’elle n’a pas aimé.
  • La troisième série de 3 dés permet de définir une action concrète à réaliser pour mettre en oeuvre les solutions de la seconde série.

Dans un second temps, l’équipe va garder un seul dé de chaque série et inventer une histoire collective; cette seconde partie permet de travailler sur la cohésion d’équipe.

Une chose est sûre, ces deux activités permettent de rompre la monotonie que l’on peut parfois ressentir lors des rituels SCRUM. Merci Daniel pour cette soirée sympathique et pleine d’enseignements.

 

Une autre vision des user stories

Eric LannemajouLaisser un commentaire

Qu’est-ce qu’une bonne user story ? Est-ce un petit morceau de spécifications fonctionnelles ? Quel est le niveau de détail d’une user story ?

Beaucoup d’articles traitent de la construction des user stories mais j’ai récemment compris comment celles-ci expriment les valeurs de l’agilité. J’aime bien le fait qu’une user story soit définie comme une invitation à la communication ; comme un outil de conversation et de collaboration. Donc une user story n’est pas un petit bout de spécifications ; inutile d’essayer de tout préciser sur un petit bout de post-it. Cependant, la user story doit permettre de développer un logiciel ou construire un produit qui correspond aux besoins de l’utilisateur. J’ai récemment suivi un MOOC sur la construction des user stories selon les besoins des utilisateurs que j’ai trouvé intéressant et que je souhaitais partager avec tous ceux qui doivent construire un backlog de stories : ‘Getting Started: Agile Meets Design Thinking’ sur Coursera. Alexander Cowan et son équipe nous apprennent dans ce MOOC comment construire de belles user stories en se basant sur l’expérience utilisateur et sur le Venture Design Process.

2016-09-16-21_37_10-venture-design-process

Le Processus est très bien défini dans le site précédent mais voici pour ma part les quelques éléments que j’ai choisis de retenir selon mon expérience :

Les Personas, quand ils sont construits de manière rigoureuse, permettent de mieux comprendre les besoins utilisateurs. Ils constituent le point de départ du processus. Les Personas sont en général élaborés lors du cadrage du projet et permettent ensuite d’écrire les premières stories du backlog. Quand ils sont enrichis et utilisés tout au long du projet, les Personas sont une véritable source d’inspiration pour définir les user stories.

  • Afin de vous aider à construire les user stories à partir des Personas, vous pouvez commencer par exprimer des scénarios décrivant les problèmes auxquels font face les Personas et les alternatives qu’ils ont trouvées pour les résoudre .
  • Vous pouvez ensuite proposer des solutions qui apporteront une valeur ajoutée par rapport aux alternatives.
  • Puis vous pouvez construire des prototypes sous forme de storyboards pour expliquer la solution et sa valeur ajoutée. Ceci vous permet aussi de revenir et d’affiner votre proposition. L’outil StoryBoardThat permet de construire rapidement des storyboards efficaces qui vous permettront d’expliquer vos solutions.

Quand on respecte rigoureusement ces étapes, on se concentre davantage sur la compréhension des besoins utilisateurs que sur la mise en oeuvre de la solution. Et c’est là que cela devient intéressant. Pourquoi ?  Et bien parce qu’on va éviter le syndrome du « bouton bleu ».  Le syndrome du « bouton bleu », c’est quand on obtient une story du type : « en tant que.. je veux appuyer sur le bouton bleu afin [d’effectuer une action]. « Cette story est précise », me direz-vous ? Oui, un peu trop précise! Cette story ne laisse à l’équipe de développement et au designer, aucune chance d’exprimer leur créativité et d’être force de proposition :

  • Aucune chance d’être force de proposition car on n’a pas la clause qui exprime la plus-value apportée à l’utilisateur.
  • Aucune chance non plus de proposer la solution technique qui permettrait de réaliser la fonctionnalité exprimée.

Vous serez d’accord pour reconnaître que cette story laisse peu de place pour la confiance et la collaboration des personnes. Cette story construite selon le très célèbre format, « en tant que [] je veux [] afin de [] « , ne respecte pas les valeurs de l’agilité et peut être démotivante pour les équipes. Le format ne fait pas tout 😉

Alors d’accord, on va laisser les équipes collaborer et concevoir de manière collective. Mais il y a quand même des contraintes fonctionnelles et métier… Et c’est là que les cas de tests d’acceptance rentrent en jeu, pour exprimer ces règles métier.

Ex : Pour une recherche, s’assurer que l’on peut rechercher par date.

Alors oui, les stories sont INVEST, 3C… mais c’est avant tout un moyen de collaborer et communiquer avec :

  • les utilisateurs ou ceux qui les représentent.
  • les personnes qui vont réaliser les stories.

C’est en quelque sorte le format pivot entre les besoins et le produit réalisé.