My Very Own Private Agile

Aucune remarque pour cette diapositive

Emilie F :
je m’appelle Emilie Franchomme
J’accompagne des équipes sur leur chemin agile. J’habite près de Nice.
Emilie E :
Je suis Émilie Esposito.
Je suis consultante chez Coactiv et j'aide les entreprises à devenir plus agiles en intervenant en tant que coach agile ou product owner dans les équipes.
Je suis également la fondatrice de la communauté podojo, qui aide les PO à s'améliorer par la pratique.

EF : Comme le dit Mike Cohn, l’agilité, c’est approprié pour des projets informatiques. Mais pas seulement.
Justement, je me suis mariée cette année… C’est ce projet (réalisation et préparation de mon mariage), que j’ai vécu, qui illustrera mes propos dans la suite de cette session.
EF @EE : Toi, Emilie, tu as aussi une expérience “hors logiciel” à nous raconter. Mais c’est pas (pas encore) un mariage…
Emilie E. : Plusieurs projets perso cette année, certains encore en cours : gérer ma séparation, trouver LE mec, avoir une vie équilibrée.

EE : Pour nous, ce qui a compté, c’étaient nos “produits persos” (le jour du mariage d’Emilie, la séparation puis la quête DU mec pour moi). On ne va pas vous raconter en détail nos “produits” , on va plutôt parler de nos “projets” : le chemin qu’on a suivi/qu’on suit pour atteindre nos objectifs. On va donc dérouler la vie d’un projet, de l’idée au produit “en prod”, en illustrant et en rebondissant d’anecdotes en anecdotes.
On veut partager avec vous NOTRE chemin agile :
- les parallèles qu’on peut faire entre nos projets “non-logiciels” et des projets agiles dans le monde du logiciel,
- les pratiques agiles qu’on a utilisé pour réaliser nos projets,
- les “déclics” (prises de conscience) qu’on a eus.
EF : Notamment, comme sur l’illustration, on a pris conscience de l’interconnexion entre la vie “perso” et la vie “pro”. Ca n’est pas hermétique, et ça communique dans un sens et dans l’autre.
Il y a comme une double boucle rétroactive entre les facettes “perso” et “pro” de la vie. On est une seule personne : les expériences qu’on a “côté perso” peuvent nous permettre de nous améliorer “côté pro”, et nos pratiques professionnelles peuvent nous transformer en tant qu’individu.
La vie, c’est comme un grand terrain d’expériences, très variées en terme de niveau d’implication, de temps projets etc…, desquelles on peut apprendre et s’améliorer.
EF @EE : Allez vas-y Emilie, raconte! Comment ça s’est construit ta recherche DU mec?

EE :
Chercher LE mec. Mmmmh, mais LE mec, c’est quoi ? Les critères physiques, intellectuels, d’âge, les centres d’intérêts… Est-ce que c’est ça qui fait une relation qui marche ? Finalement, LE mec, c’est celui avec qui j’aurai LA relation !
Du coup, je me suis demandé : quels sont pour moi les fondamentaux dans une relation sentimentale ? J’ai fait du deux en un, ma vision, c’était mes critères d’acceptance. Ces 8 critères d’acceptance ne sont pas tous vérifiables dès le début, mais ils sont tous testables à un moment ou un autre (je vous parlerai de mon kanban tout à l’heure…).
Par exemple :
- Avoir des sentiments amoureux l’un pour l’autre
- Avoir une excellente communication
- Ne pas habiter trop loin de façon durable
EF : Cette vision, ces critères, tu les as trouvés d’un coup ?
EE : J’ai construit ces critères de façon émergente : quand je rencontrais quelqu’un à qui il manquait quelque chose de fondamental pour moi et que je n’avais pas encore identifié, je le rajoutais.
EE @EF : Et pour toi? C’est une chose de dire “oui”, d’avoir envie de poursuivre sa vie l’un avec l’autre, c’en est une autre d’organiser le mariage, non?

EF : T’as vu juste!
Etant 2, on a commencé par expliciter nos attentes, et clarifier notre vision commune de ce qu’on attendait du “jour du mariage”.
On était bien alignés sur l’objectif principal : passer du “bon temps” avec amis et famille (why?). C’est à dire qu’un indicateur de réussite, c’est le plaisir pour nous (utilisateurs “principaux”) et pour les invités (utilisateurs “secondaires”) (who?)
On s’est appuyé sur nos expériences passées (et celles de nos amis et famille, en les questionnant), pour savoir ce qu’on aimait ou pas trop dans les mariages auxquels on étaient allés.
Pour nous, un moyen d’atteindre l’objectif, c’était de faire “un mariage qui nous ressemble”, avec une grosse fête où on danse.
EE : Ca donnerait quoi l’Elevator Pitch de votre mariage?
EF : Pour nous deux, qui voulons célébrer notre amour en passant un excellent moment avec nos amis et famille, notre mariage est une grande fête avec ceux que l’on aime et qui nous aime. Quitte à faire fi de certaines conventions, notre mariage nous ressemble.
EE : Pas besoin d’un document de 40 pages pour décrire la vision!
EF : Effectivement. Et c’est d’autant plus important que la vision soit claire et concise, parce qu’elle est ainsi très facile à partager avec tous ceux qui participent à la réalisation.
La vision est comme la boussole du projet, elle permet de garder le cap. C’est pour la réaliser que l’équipe se mobilise, est motivée. C’est ce qui permet de « courir » dans le même sens, et donc de ne pas s’écarter de la cible et d’obtenir les bénéfices attendus!

EF : Quand l’équipe s’élargit (ex : famille/amis qui aident, prestataires), il faut savoir bien communiquer la vision, reformuler, s’assurer qu’elle est bien partagée…
Exemple: on a reformulé notre vision. Pas claire du 1er coup, par exemple le fleuriste qui dit “Ah, votre thème c’est champêtre? ». Ben non, pas du tout. On est plutôt “urbains”/”geeks” comme gens. “Qui nous ressemble” pour nous ça veut dire : avec de la bonne musique (mon mari a plein de disques), coloré et gai (moi j’ai un faible pour les barbapapas…) On a trouvé le terme “Barbadisco” pour résumer notre vision!
EE : Donc vous ne l’avez pas organisé juste à deux votre mariage. A quoi ressemblait l’équipe?
EF : Si tu penses aux rôles de Scrum… on n’a pas vraiment utilisé ce cadre...
On peut dire que mon mari et moi étions le Product Owner (hum… à 2 têtes, certes…). Je dirais qu’on n’avait pas vraiment de Scrum Master.
L’équipe a été de taille variable, avec souvent des membres en même temps parties prenantes (mari, belle-famille …) ou “externes” (prestataires…).
Certains membres de l’équipe avaient des étiquettes d’expert (“chef Pinard”, “chef déco”, “responsable musique”).Pourtant, ça n’était pas synonyme de silo : équipe passez polycompétente, où chacun travaille sur son domaine d’expertise mais contribue aussi si besoin en dehors de son domaine d’expertise.
EF @EE : Et toi, t’es toute seule pour réaliser tes projets?

EE : Trouver LE mec, c’est un projet très perso, à moins de demander de l’aide à une marieuse ;-) Pour le coup, j’étais seule pour réaliser mon projet : PO, SM, équipière…
EF : C’était un projet top secret? Tu n’as discuté de tes projets avec personne ?
EE : Je vois où tu veux en venir… Tu as raison, je ne suis pas tout à fait toute seule. Mes amis me coachent régulièrement : ils m’écoutent, me font prendre du recul avec leurs questions, me conseillent parfois… Cela m’aide énormément dans ma démarche d’amélioration continue, ils animent mes rétros en quelque sorte.
En super-bonus, être coachée dans ma vie perso, cela m’a aidé à mieux coacher dans ma vie pro. Je me mets plus facilement à la place des personnes que je coache, et je pense que j’arrive beaucoup mieux à équilibrer la posture que je prends dans mes missions de coaching.
Transition EF (OPTION LONGUE) : ON A PARLÉ DE LA VISION, DE L’ÉQUIPE. DANS LA PLUPART DES PROJETS, AVANT DE DÉMARRER LA RÉALISATION, ON FAIT ENCORE UN PEU DE “CADRAGE”. IL FAUT VÉRIFIER LA FAISABILITÉ, ÉTUDIER LES OPTIONS (AVANTAGES ET INCONVÉNIENTS), IDENTIFIER LES CONTRAINTES.
Transition EF (OPTION COURTE) : DANS LES PROJETS, POUR PASSER À LA RÉALISATION, ON DÉCLINE - AVEC L’ÉQUIPE- LA VISION EN UN backlog produit : la liste - grossière au départ - de toutes les fonctionnalités nécessaires pour réaliser la vision.
On ordonne ce backlog et on l’affine au fur et à mesure qu’on avance.
Pour chaque élément, il faut expliciter et se mettre d’accord sur “comment qu’on valide et qu’on sait qu’on a fini?”
On trouve dans nos expériences des exemples d’explicitation de critères d’acceptance et de definition of done

OPTION LONGUE
EF :
Une fois la vision établie, il y a plein d’options de réalisation.
Il s’agit d’étudier la faisabilité de ces options, voir leurs avantages et inconvénients, identifier les contraintes, et faire des choix. Ca n’est pas du “big-planning upfront” : c’est identifier les critères qui dirigeront les choix.
- Faisabilité financière: estimation grosse maille (merci les REX budgets de l’INSEE et d’autres sources…). On a une idée de l’enveloppe financière, c’est faisable (on peut débloquer le PEE…)
*** Contrainte : rester dans l’enveloppe budgétaire (“ce qu’on peut se permettre”, “ce qu’on trouve raisonnable de dépenser”)
- Faisabilité logistique:
* identification du lieu : dans le sud (Var), plusieurs options possibles (location salle, resto, terrain du papa) => avantages et inconvénients de chaque option (contraintes horaire pour “vider les lieux”, ménage à faire, traiteur imposé…)
* identification de la date : pour que les gens puissent venir / ils n’habitent pas à côté (risque de montée en flèche des prix de billets ou indispo si vacances, ascension, festival de cannes, grand prix de monaco…). On a fait des petits sondages pour vérifier les dispos amis/famille…
EE : Est-ce que toutes ces contraintes étaient aussi importantes les unes que les autres ? Tu sais, en informatique, on a notre fameux triangle coût, périmètre, délais…
EF : C’est vrai aussi pour les projets non-informatiques. On a défini notre matrice de trade-offs:
- une fois fixée : la date - non-négociable (<= projet date-driven)
- négociable : budget
- flexible : périmètre (<= sauf les “must-have”!!!)
Application de la matrice de trade-offs :
- terrain du papa : contrainte “wc” => la fosse septique est faite pour “les besoins” d’une famille de 4 personnes environ.. il faudra trouver des toilettes d’appoint!
=> comment on choisit?
Je préfèrerais des toilettes sèches (mon côté biobio, l’aspect esthétique…). Mais c’est une trèèèès grosse dépense. Des toilettes en plastique répondent au besoin, et ça reste dans l’enveloppe budgétaire. Et voilà, c’est choisi!
Transition EF : Avec la phase de cadrage, on crée un backlog produit, la liste - grossière au départ - de toutes les fonctionnalités nécessaires pour réaliser la vision.
On ordonne ce backlog et on l’affine au fur et à mesure qu’on avance.
Pour chaque élément, il faut expliciter et se mettre d’accord sur “comment qu’on valide et qu’on sait qu’on a fini?”
On trouve dans nos expériences des exemples d’explicitation de critères d’acceptance et de Definition of Done

EF :
Par exemple, pour la fonctionnalité “Faire-part (papier)”, un de mes critères d’acceptance, qui est tout simplement dérivé de la vision, c’est :
- “qu’il nous ressemble”
Le test, c’est que chacun de nous y voit un “bout de lui”, une représentation d’un trait de son caractère.
Au cours de la réalisation, ce test a été “rouge” : j’ai dit “mmm, y a beaucoup de toi là-dedans, mais j’y trouve pas beaucoup de moi”. On a ajouté des Barbapapas, et le test est passé au vert!
(VL) Autre exemple, pour la fonctionnalité “Musique à la mairie”, le critère d’acceptance de mon mari c’est :
- “du son de bonne qualité”
Le test, c’est qu’on entend bien la musique, et on peut parler sans crier
Cette fonctionnalité nécessite de déplacer notre propre système de sono (on a des grandes enceintes…). Certes, c’est beaucoup plus d’effort que d’utiliser la petite chaine hifi dispo à la mairie… Mais sinon ça n’aurait pas été “validé”!
NB : ne pas parler de TDD (on n’a pas fait les tests first!)
EF@EE : Tu nous as déjà parlé de critères d’acceptance pour la recherche du mec, tu as d’autres exemples ?

EE : Oui, j’ai même d’autres leçons :-)
Depuis quelques mois, j’ai du mal à aller me coucher le soir. Le meilleur moyen que j’ai trouvé pour travailler sur ce sujet, c’est d’en faire une user story. Une vraie, hein, avec un “afin de” (très important pour se motiver, cf ce qu’on disait sur la vision) et des critères d’acceptance !
En essayant d’écrire les critères d’acceptance de ma user story “Retrouver un rythme de sommeil équilibré”, j’ai commencé par fixer des heures de lever et de coucher, en semaine et en week-end. Mais en fait, ça ne me paraissait pas suffisant. J’ai compris à ce moment là qu’il fallait aussi que je travaille sur la qualité de mon rythme de vie : prévoir du temps pour moi, du temps pour mes amis, du temps pour la communauté, du slack, des exceptions… Ma story s’est enrichie, elle est devenue : “Avoir durablement un rythme de vie équilibré, afin d’avoir l’énergie pour profiter des choses agréables et faire face aux choses moins agréables”
J’ai finalisé ma user story en lui ajoutant des critères d’acceptance sur le fait de faire du sport.
Message : Les critères d’acceptance permettent d’affiner la user story
EF : Tu affines ta User Story… Très bien, mais comment tu sais que tu as fini?
EE : Tu as raison. La user story dit “durablement”, comment je sais que j’ai terminé ma user story, qu’elle est done, done ? Il paraît qu’il faut 21 jours pour prendre une nouvelle habitude. Mon definition of done est donc “Les critères d’acceptance sont validés chaque jour pendant 21 jours consécutifs”.
Message : Trouver un definition of done pertinent, ça ne se limite pas à “développement terminé”, c’est possible même quand on ne parle pas d’informatique, ça demande du recul et une bonne compréhension de la vision

EE : D’ailleurs, en travaillant sur mon rythme de vie, j’ai appris une autre leçon !
Quand j’ai écrit ma user story pour avoir un rythme de vie équilibré, j’avais besoin de l’avoir sous les yeux pour me responsabiliser. J’ai regardé les murs de mon salon, je ne trouvais pas d’endroit où l’afficher. Et j’ai eu une illumination : ma table basse est recouverte d’une vitre, j’allais m’en servir de support de communication envers moi-même !
J’y ai mis ma user story, j’ai également recopié mes fondamentaux pour une relation amoureuse (que jusque là je n’avais que dans un mail à moi-même), j’ai ajouté deux autres messages de moi pour moi, le tout dans des couleurs vives, que j’aime bien. J’ai ajouté quelques dessins, et voilà le résultat.
Et j’ai vu une vraie différence ! Difficile d’ignorer la vision produit quand on l’a aussi souvent sous les yeux ;-)
Aujourd’hui, la sous-US sur le rythme de mes soirées est done. Il me reste les autres (rythme de sommeil et sport) mais j’y travaille :-)
Un point intéressant : le fait que tout cela soit aussi accessible, visible, lance des discussions passionnantes quand mes amis viennent me voir (feedbacks). Et c’est évolutif : il me suffit de soulever la plaque de verre pour changer les messages.
Message : Une bonne communication visuelle est visible / accessible, amusante à faire, facile à faire évoluer, et jolie à regarder. Elle invite à la discussion.
EE @ EF : Et vous, vous avez utilisé du management visuel dans l’organisation de votre mariage ?

EF : Oui. Je pense que la meilleure illustration c’est le plan de table :
- on l’a rendu visuel dès la préparation : une feuille par table, un post-it par personne (ou couple) => on voit tout de suite que cousin machin ne peut aller qu’à la table de copain bidule! Et puis on peut éloigner si besoin des personnes qui ne s’entendent pas trop…
- et aussi pour le jour J : une grande toile, repérage des tables par couleur, nom des invités reporté à leur place
Messages: pour moi, il y a au moins ces 2 intérêts-là à rendre les choses visibles :
- on réfléchit mieux, et on peut améliorer le résultat plus facilement
- chacun peut “se gérer tout seul” et trouver sa place : c’est une façon de déléguer une charge de travail/d’organisation, en permettant à chacun d’être autonome.
Transition EF :
OPTION LONGUE (->Manifeste) : Je pense que le management visuel favorise l’auto-organisation.
OPTION COURTE (->Incrémental) : Je pense que le management visuel favorise l’auto-organisation. Par contre, d’un point de vue personnel, ça n’est pas toujours facile. Ca demande de “lâcher-prise”, de sortir du comportement “command&control”, de faire confiance aux personnes pour atteindre le résultat.

OPTION LONGUE
EF : L’autoorganisation, c’est un des principes du Manifeste Agile.
Mon expérience m’a permis d’un peu mieux relier l’autoorganisation à un autre principe, le 5ème. Sans le 5ème principe, il me semble difficile qu’il y ait de l’autoorganisation.
Pour favoriser l’autoorganisation :
- partager la vision : facteur de motivation pour les individus, les objectifs sont clairs. Dans le cas du mariage, l’équipe est complètement impliquée : elle participe à la réussite du projet et profite du résultat (“eat your own dog food”)
- faire confiance : => D’un point de vue personnel, ça n’est pas toujours facile. Ca demande de “lâcher-prise”, de sortir du comportement “command&control”, de faire confiance aux personnes pour atteindre le résultat.
- rendre visible / utiliser du management visuel : ça aide à lâcher du contrôle, en permettant l’autonomie des personnes tout en aidant à suivre l’avancement
EE : T’aurais pas un exemple concret?
EF : Si, quelque chose dont j’ai pris conscience après coup, et où je me suis dit “mais bon sang, pourquoi je n’ai pas davantage rendu les choses visibles? Ca aurait été tellement plus fluide et agréable!”
On avait une 20aine d’amis qui sont venus quelques jours avant le jour du mariage. On a pris notre repas tous ensemble. La préparation des repas aurait pu être beaucoup plus efficace et agréable en favorisant l’autoorganisation!
L’objectif “manger tous ensemble” : on a fait des courses et imaginé un menu, chacun est prêt à mettre la main à la pâte (équipe motivée, qui a les moyens).
Concrètement, ce qui s’est passé, c’est que j’ai été un goulet d’étranglement : avec des amis qui viennent demander “qu’est-ce que je peux faire?”. Ca, ça n’est pas agréable, et c’est même assez stressant.
Et si… on avait utilisé un tableau comme le ScrumBoard? Chacun aurait pu mieux voir l’objectif et piocher (voire rajouter) tout seul les tâches à faire : couper les tomates, les oignons, préparer le bbq…
Sans ça, on a du compenser par énormément de communication orale, et on n’avait pas du tout de vision de où en était quoi.
J’ai pris conscience de la puissance du management visuel, avec un ScrumBoard par exemple, comme moyen de communication, facteur d’autoorganisation.

EE@EF : C’est marrant que l’agilité te permette de lâcher le contrôle. Moi, elle m’a permis de regagner de la maîtrise quand j’en ai eu besoin.
EE : L’année dernière, je me suis séparée de mon mari.
Quand on est mariés, qu’on a acheté une maison, une séparation, c’est énormément de choses à gérer. Quand on essaie de les lister, il y en a tellement qu’on a l’impression d’être en bas d’un mur très très haut à franchir. Et on n’est pas forcément au mieux de sa forme pour l’escalader. On a l’impression de ne plus rien maîtriser.
C’est naturellement que je me suis fait un backlog de séparation.
J’ai commencé par y mettre des épics, par ordre de priorité :
- trouver un appartement
- formalités administratives urgentes
- déménager
- vendre la maison
- finaliser les formalités administratives
- divorcer
J’ai commencé par affiner les deux premières épics, cela formait mon premier incrément. Et la liste détaillée des actions à réaliser était suffisamment petite pour ne pas me décourager. Ce premier incrément m’a pris un mois, à la fin duquel j’ai préparé l’incrément suivant. J’avais repris le contrôle :-)
Dès que je pensais à une action à réaliser dans le cadre d’une épic ultérieure, je la notais dans mon backlog, pour ne pas l’oublier, et je ne m’en préoccupais plus jusqu’à ce qu’elle rentre dans l’incrément courant.
Je connaissais les vertus de l’incrémental, mais je ne les avais jamais vécues à ce point :
- Mieux vaut des objectifs courts termes atteignables plutôt qu’un objectif long terme ambitieux : motivation, c’est faisable, le plaisir du done
- L’affinage progressif du backlog permet de gagner du temps au début et se concentrer sur l’essentiel
- On sait par quoi commencer, c’est plus facile de s’organiser, on ne se disperse pas
EE @ EF : Et l’incrémental, dans l’organisation d’un mariage, ça donne quoi ?

EF : On peut trouver plein d’exemples pour illustrer la notion “incrémentale” dans le projet Mariage.
On a aussi découpé notre backlog d’Epic en petites User Stories, affiné progressivement, priorisé, en intégrant les feedbacks au fur et à mesure.
Par exemple, pour l’Epic “Faire-Parts” : En tant que futurs mariés, nous voulons inviter amis et famille afin qu’ils soient à nos côtés le jour du mariage.
On s’est servi des critères d’acceptance pour découper en US plus fines, et pouvoir les prioriser, et faire des petits incréments
* US1 : Communiquer date/lieu au plus tôt = afin que les gens réservent au moins la date, soient au courant, puissent prendre leurs dispositions
=> “Minimum Viable faire-part”, cad version cheap/indispensable/urgente du faire-part : envoi d’un mail
* US2 : Communiquer date/lieu et détails + “fun” = afin que les gens aient un souvenir matériel de notre mariage (même pour ceux qui ne peuvent pas venir)
=> faire-part papier via la poste
EE : Et ce faire-part papier, vous l’avez réalisé “parfait d’un coup”?
EF: Euh, non, pas vraiment. Là aussi, itération+incréments+feedback!
=> On peut avoir du feedback tout au long de la réalisation, y en a de plein de sortes! Il n’y a pas que celui de la revue une fois que c’est done… Ca permet de s’assurer tout au long qu’on n’a pas d’erreur et que ça correspond à la vision
* Peer-review : vérifier que c’est compréhensible, qu’il n’y a pas de faute
* Maquettage : pour trouver l’idée qui nous convient pour le faire-part papier
* Prototype : avec du matos pas cher pour vérifier que l’idée est réalisable (avant d’aller faire les courses pour le vrai matos qui coûte cher)
=> On peut aussi décider de livrer plus tôt une partie :
* Réalisation / Mise en prod : on a refait plein de fois les mêmes activités (impression, découpage, collage, mise en boîte, étiquettage/adressage, postage). On a fait des “batchs” d’envoi, car pour certains on n’avait pas les adresses postales (pas de stock inutile : quand c’est ready, on envoie!!).
OPTION LONGUE
- Idem pour d’autres features : pour la robe (croquis, échantillonnage de tissus, prototype de robe, essayages et ajustage des détails/finitions, et enfin livraison), le repas (on goûte chez le traiteur), le vin (séances de dégustation), les menus papier... etc…

OPTION LONGUE
EE : Je ne sais pas si ça été le cas pour toi, mais j’ai beaucoup de mal à estimer correctement mes user stories persos : difficile d’avoir une user story de référence...
EF: Ah oui, l’estimation c’est pas toujours facile. Pour nous aussi, la réalisation a pris bien plus de temps que ce qu’on avait pensé au début, par exemple pour la réalisation des faire-parts et des menus papier.
On a pu affiner et améliorer la justesse des estimations en faisant le prototype.
Et puis, sans forcément lerendre explicite, j’ai bien ressenti la notion d’estimation relative et la vélocité.
J’ai 2 stories :
- 50 faire-parts, avec les tâches : imprimer, découper des ronds et des flyers, coller les ronds pour faire le disque, glisser le disque dans la pochette, monter la boîte en carton, écrire l’adresse, coller le timbre
- 90 menus papier, avec beaucoup moins de tâches : seulement imprimer et plier, par contre il y en avait plus à faire (90 environ).
Je peux estimer de façon relative, par exemple : si 50 faire-part=5 story points, alors 90 menus papier=3 story points.
Une fois qu’on a vraiment fait 1 faire-part, on se rend mieux compte de combien de temps il faudra pour faire les 50 faire-parts.
Et idem, une fois qu’on a fait les 50 faire-parts, on peut extrapoler, en utilisant la vélocité (comme on fait avec le burndown chart de release), pour savoir quand on aura terminé les menus papier.

EE : On a parlé agilité jusqu’à maintenant, mais quand je discute d’agilité et vie perso autour de moi, on me parle souvent kanban. Il se trouve que j’ai justement compris des choses sur le kanban grâce à ma vie perso.
Dans mon projet de rechercher LE mec, je me suis vite rendu compte que sans un outil efficace, je n’arriverai pas à m’y retrouver. C’est devenu d’autant plus vrai quand je me suis inscrite sur plusieurs sites de rencontre.
Et là, j’ai pensé kanban, pour outiller mon processus de recherche et piloter mon flux de rencontres.
J’ai assez vite affiné les premières étapes du kanban, avec des definition of done plus ou moins clairs.
Je restais assez floue sur les dernières étapes : en intégration, en recette, en production, en me disant que j’aurai une meilleure idée quand j’en approcherai.
Je me suis vite rendu compte que j’avais un sacré goulet d’étranglement : la colonne “1er RDV planifié”… J’avais trop de RDV planifiés, c’était en contradiction avec ma user story sur le rythme de vie, je ne m’en sortais pas… Forcément, je n’avais pas défini de limite au WIP !
En plus, le processus n’était pas efficace : la plupart du temps, les rendez-vous étaient décevants, et je n’avais absolument pas envie d’en programmer un deuxième...
EE : J’ai commencé par faire une analyse de cause racine avec les 5 pourquoi.
Pourquoi j’avais autant de rendez-vous planifiés ?
Sur internet, c’est facile de se faire passer pour ce qu’on n’est pas. Donc j’essayais de rencontrer irl assez vite les personnes avec qui j’avais eu quelques échanges intéressants, pour confirmer rapidement. Si j’avais trop de RDV, cela voulait dire que ce filtre “quelques échanges intéressants” n’était pas suffisant.
Je suis passée en mode PDCA.
Déjà, j’ai commencé par bloquer définitivement toute personne que j’avais mis dans la colonne “Ca va pas le faire” de mon kanban : cela m’évitait de perdre du temps à repasser mes filtres à chaque fois (avec le nombre de contacts, on oublie les pseudos). Donc je devais obtenir moins de messages entrants, et a priori, moins de “déchets”. L’effet a été minime. Je n’avais pas amélioré la qualité de mon filtre, j’avais juste amélioré sa pérennité.
J’ai ajouté des critères : quelqu’un qui sait écrire (autre chose que “cc sava ?”, et bien pire encore...), une taille minimale,... Mais ça ne fonctionnait pas vraiment : le nombre de rendez-vous diminuait, mais leur qualité n’augmentait pas (ils n’allaient pas loin dans le kanban). Oui, parce qu’avec un kanban, on peut suivre son flux, et voir si on s’améliore :-)
Jusqu’au jour où j’ai fait ma table, vous vous rappelez ?, avec les fameux fondamentaux pour une relation.
Et là, j’ai compris beaucoup de choses… Je me suis dit que c’était la qualité que je cherchais et non la quantité, et que je voulais consacrer moins de temps à filtrer les “déchets”.
J’ai donc revu mon approche : autre photo, autre annonce, qui avaient pour but d’éloigner tous ces déchets, et d’attirer spécifiquement ceux qui pourraient satisfaire avec moi mes fondamentaux. Et là, l’effet a été drastique :
- de plus de 100 messages par jour à moins de 10
- un taux de 2ème RDV multiplié par 4
- et finalement, une mise en production :D
J’ai vécu le déplacement du goulet d’étranglement lors de l’optimisation de mon processus (chose que je n’avais pas bien comprise en formation), et la roue de Deming m’a aidé à déplacer ce goulet plus rapidement.

EE : Emilie, après tout ce qu’on vient de leur dire, je pense qu’ils nous prennent pour de grandes malades...

EF : Ben en fait, on n’est pas les seules, loin de là! Voilà plein d’autres histoires agiles que vous pouvez retrouver sur les blogs par exemple

EF :
* On a tous en nous une graine d’agilité, c’est notre agilité naturelle (cf le Chasseur-Cueilleur de Pablo Pernot)
* La vie offre plein d’occasions - quelque soit le domaine (pro, perso, logiciel ou pas) - pour la faire pousser, s’exercer à être agile (culture du feedback / amélioration continue)
* L’agilité, ça n’est pas un but en soi. C’est un état d’esprit qui nous aide à arriver à destination, quand il y a de l’inconnu sur le chemin.

EE :
* Si on peut être agile dans notre vie perso, cela veut dire qu’on peut être agile quelque soit le projet
* Tout n’est pas des clous, on n’a pas qu’un marteau : on utilise les outils (pratiques, méthodes,...) propres à la situation, en restant dans l’état d’esprit agile
Et d’ailleurs, c’est en sciant que Léonard De Vinci…
EF :
Et vous, elle ressemble à quoi votre boîte à outils Agile?

EE : Vous voulez bien la partager avec nous ?
@Marseille :
Scrumboard des tâches ménagères
@Rennes:
ScrumBoard révision du brevet
Post-its sur sur le frigo (liste ordonnée) pour gérer les dates de péremption
ScrumBoard des tâches ménagères avec les enfants
Backlog d’amélioration de la maison

Jane demande à son colocataire John de passer l’aspirateur dans le salon.
Un moment plus tard, il revient tout fier, en lui disant “Ayé ! J’ai fini !”
Jane voit alors qu’effectivement le salon est propre, mais ne peut s’empêcher de remarquer que l’aspirateur trône en plein milieu du couloir, encore branché.
Jane ne peux s’en prendre qu’à elle-même, la definition of done était restée implicite (aspirateur débranché et rangé dans le placard)
=> Axe d’amélioration pour plus de satisfaction!

EF :
Illustration d’un flux tiré, avec limite imposé par le système (limite qui peut changer si le système change) :
Gestion du frigo / des courses avec un frigo/appartement “petit”
=> on “tire” une bière du frigo, on en met une nouvelle à refroidir.
EE :
Je vais même plus loin, mon flux a plus d’étapes :
- on “tire” une bière du frigo, on en prend une de la réserve dans la cuisine pour la mettre au frigo
- on jette un carton de bière vide dans la réserve de la cuisine, on va chercher un nouveau carton à la cave
- on finit une caisse de bière de la cave, on va en acheter une autre
EF :
Ca devient plus compliqué quand on reçoit des amis.
Il faut gérer en fonction des autres trucs dans le frigo (on ne fait pas en plus les courses pour la semaine quand on a un petit frigo et qu’on prévoit une soirée avec des potes buveurs de bières!!!)