YourTurnChallenge
I’m writing a few posts in english thanks to the #YouTurnChallenge : http://yourturnchallenge.tumblr.com
I will write one post per day for the next 7 days. Every without a post is failed. I’m exposed.
I use to write in english a few years ago on my personal blog and it was painful, like multiplying my writing time by 5. Let’s see if I got better since.
EDIT after 1 week
5 success, 2 failed. Learning so much. Trying another week.
Retrouver la connexion entre l’équipe et le sponsor
Une formulation dans mon dernier article La démonstration n’est pas un stand up meeting m’a valu une réaction intéressante sur Twitter.
@av
[@…] mouais. Voir la revue d’itération comme un moment de reporting efficace, ça me gratouille un peu (beaucoup en fait).
@bm
[@…] perso je préfèrerais aussi ‘communication’ ou un truc comme ça certes, et efficace est sûrement trop fort (cc @duquesnay )
@duquesnay
[@…] ‘communication’ ne donne pas l’intention du meeting, ‘reporting’ ça gratte mais on sait ce qu’on vient faire là
@av
[@…] moi dans une revue de sprint, je viens pas faire du reporting. Ce qui m’intéresse, c’est le feedback. [@…]
Ces échanges me donnent envie de creuser un point qui me tient à coeur : le rapport des développeurs au reporting et au sponsor.
Je ne débattrais pas ici des buts d’une démonstration de fin d’itération. Admettons simplement que montrer l’état d’avancement du projet et mettre à jour les indicateurs d’avancement en fait partie.
Ce qui m’intéresse, c’est la gêne des développeurs quant on intègre le mot reporting aux pratiques agiles.
Avancement du projet, notion anxiogène
La mesure d’avancement est mal aimée chez les développeurs, et ça se comprend. D’un côté, elle s’appuie sur des estimations de tâches qu’on sait relativement aléatoires. Un développement évalué à une journée peut finalement prendre 1 semaine, une semaine devenir un mois.
De l’autre on est pris dans un système qui pousse à l’engagement, parfois contraint. La pression au résultat existe et s’accentue avec le poids de la hiérarchie ; on en vient souvent à confondre la réponse à laquelle on croit avec la réponse qui plaît. En atelier d’estimation, les développeurs s’inquiètent souvent :
Lâcher une estimation, oui, mais qui fera des nocturnes et des week-end si ça dérape ?
Qui voudra bien entendre qu’on ne maîtrise pas telle ou telle partie majeure du projet ?
Qui acceptera que l’enjeu est difficile à atteindre ?
Même si des approches existent pour limiter ce problème (l’agile en fournit un certain nombre), le sujet réveille des expériences douloureuses chez beaucoup d’entre nous. J’en ai connu mon lot : notre session Agile en projets courts êtes-vous prêts ? avec Jonathan Scher était à l’origine une session sur un projet que nous avions échoué. Je comprends qu’on serre les mâchoires lorsque la question de l’avancement arrive.
“Ce sera livré quand ce sera livré”, posture sourde
Ce qui me choque, c’est d’entendre certains au sein de la communauté agile réfuter la question elle même, et la pertinence d’une direction de projet à la poser. Pire exemple entendu entre pratiquants :
« Ce sera fini quand ce sera fini, on va pas leurrer le client avec une estimation… s’il ne comprend pas on devrait pas signer avec lui »
Je trouve cette posture nombriliste, aveugle au cadre. La situation d’une équipe de développement découle d’une relation d’intérêt avec l’organisation qui l’emploie.
Lorsque le premier jour du projet des développeurs, experts métier, graphiste / UX et Product Owner sont assis sur des chaises confortables devant des bureaux modernes supportant des ordinateurs double écrans dans un espace propre, chauffé et bien éclairé, tandis que la machine à café ronronne, c’est que quelqu’un a déjà mis de l’argent sur la table.
Version MasterCard :
8 chaises : 480€
8 bureaux : 2960€
8 ordinateurs : 15920€
8 prestataires : env. 4600€ / jour
1 salle 8 personne : 2900€/mois
Initier une bonne dynamique d’équipe : ça n’a pas de prix.
Certaines choses ne s’achètent pas.
Pour tout le reste, quelqu’un a sorti sa carte bleue.
Ce quelqu’un est le sponsor du projet.
Une équipe se trouve réunie sur un projet parce que le sponsor poursuit un objectif. C’est un risque financier, il aurait pu ne rien tenter, ou miser sur un autre projet. Son inquiétude est légitime. Je pense que s’en déconnecter amène une situation déséquilibrée.
Imaginons qu’il propose lui aussi de se déconnecter de l’intérêt des développeurs :
Ok pour ne faire ni estimation ni reporting, mais je ne sors pas un euro, aucun intervenant ne sera payé avant la livraison.
Ca gratouille côté compte courant chez les équipiers, non ? Vous sentez la relation d’intérêt réciproque ?
L’échange sur twitter m’a fait réagir pour cette impression de déconnection. En lisant « […] dans une revue de sprint, je viens pas faire […]. Ce qui m’intéresse, c’est […] », je vois beaucoup de « je ». Comme si la démonstration de fin d’itération était à l’initiative des développeurs et à leur usage principal, alors que c’est un point de rencontre avec un but collectif
Un projet agile performant est articulé autour d’une relation d’intérêt équilibrée. Le sponsor et l’équipe sont solidaires. Ils se parlent, ça cause enjeux et avancement.
Alors, pourquoi en est-on encore là ?
Dans mes observations la déconnection de l’équipe vis-à-vis des enjeux du projet va souvent de pair avec une distance entre le sponsor et l’équipe. Il est tentant d’accorder la faute au sponsor mais je pense qu’en fait les torts sont partagés. En tout cas c’est dommage, car le sponsor est l’ami le plus puissant de l’équipe. Il ou elle a du pouvoir, des ressources, apporte une vision élargie du contexte et se montre souvent pragmatique… s’il est suffisamment informé.
Comment réduire la distance entre sponsor et équipe ?
Dès que je fais une session où j’évoque la présence du sponsor j’entends cette question, preuve s’il en est que le problème est habituel. Lorsque la situation est installée, je pense qu’on a des leviers de résolution des deux côtés de la relation -comme je l’ai dit je pense que les torts sont partagés. Je vous propose quelques questions qui piquent pour commencer à les actionner.
Levier côté sponsor : réserver du temps régulier avec l’équipe
Quand avez-vous assisté à une démonstration pour la dernière fois ?
Avez-vous déjà essayé le produit ?
Quel est votre vision sur la performance de l’équipe ?
Levier côté équipe : questionner le sponsor sur les enjeux, se partager la tâche de reporting
Qui a déjà adressé la parole au sponsor ?
Connaissez-vous de tête ses 3 premiers enjeux sur ce projet ?
Qui a déjà vu la synthèse d’avancement envoyée à la direction ?
Pour aller titiller l’une ou l’autre des parties, tout acteur facilitant le projet peut intervenir : les managers directs, le scrum master, le coach s’il y en a un. Cependant, l’accès au sponsor est souvent plus délicat. Disponibilité rare, niveau hiérarchique intimidant, barrage des assistantes, on a pas toujours l’accès qu’on aimerait.
A mon humble avis, n’hésitez pas à mouiller le management sur le problème. Vous pouvez faire remonter formellement une demande, par exemple la présence du sponsor à une démo toutes les 4 semaines. J’écris “management” au sens large : le réseau des managers de l’organisation, ces gens dont le rôle est de graisser les rouages de la machine. Si plusieurs directions sont impliquées sur le projet, un autre directeur concerné par le projet peut passer le message, par exemple.
La présence régulière du sponsor est une clé pour la réussite du projet. Cette sensibilisation mérite vos efforts et votre insistance.
Le dernier levier est pour ma pomme, le coach. Je l’ai intégré depuis plusieurs années à mes pratiques, mais ça ne me fait pas de mal de le réécrire noir sur blanc. Je dois inclure dès le départ le sponsor et sa relation avec l’équipe dans le périmètre de l’accompagnement. Se plaindre de son absence et n’intervenir qu’auprès de l’équipe est un non sens.
Auto-questions qui piquent :
Ai-je évoqué l’accompagnement du sponsor lors du cadrage de l’intervention ?
Ai-je demandé un rendez-vous avec lui/elle avant le démarrage du projet ?
Lui ai-je proposé un reporting régulier sur mon accompagnement ?
Quand lui ai-je demandé des nouvelles du projet pour la dernière fois ?
La démo n’est pas un stand up meeting
“On peut avoir un aperçu des fonctionnalités qui sont en cours de réalisation ?”. Question posée en démonstration de fin d’itération par un Product Owner, et j’aimerai partager ma réponse ici. J’étais là en simple supervision, le projet tournant depuis plusieurs mois. Le processus étant rôdé, les participants habitués au rituel de la démonstration, le facilitateur hésitait à faire une entorse au protocole et s’est tourné vers moi.
Lorsqu’une équipe a de la bouteille, j’évite généralement les réponses catégoriques. J’aime bien proposer un nouvel angle de vue, une autre question qui lui permet d’apprécier au cas par cas les tenants et aboutissant de chaque possibilité.
Ici ce ne fut pas le cas. Ma réponse fut “non”.
Je m’explique. En démo, on ne passe pas en revue les user stories qui sont en cours de réalisation, commencées mais non terminées. Ce n’est pas à l’ordre du jour. La démonstration est un moment où l’on fait du reporting de manière efficace et concrète, en montrant ce qui peut être comptabilisé de manière certaine pour l’avancement du projet. Cela reste un moment de reporting, même si on l’a rendu plus dynamique et riche que la lecture d’un excel.
Si vraiment ce qui est en cours de développement vous intéresse, il existe un autre moment pour cela : le stand-up meeting. Tous les jours à la même heures, l’équipe fait un point quotidien de 10 minutes maximum. Rien de mystérieux, l’heure est affichée sur le mur jouxtant ses bureaux. D’ailleurs, le tableau de bord mural répond sûrement aux questions que vous vous posez : tout ce qui est en cours y est listé, c’est très lisible, très accessible, même si ça n’entre pas dans les détails. Il est là en permanence, en toute transparence, à irradier l’information.
Mais la plupart du temps, ceux qui posent la question lors de la démo connaissent déjà l’existence de ces éléments. Alors avant de remettre en cause un principe fort, j’ai plutôt envie de retourner la question : pourquoi avez-vous besoin de ces informations ? Plus précisément :
En quoi une information qui a trait au quotidien de l’équipe vous serait utile, alors que vous ne participez pas, ou plus, au stand-up meeting ?
Product Owner qui n’avez plus le temps de voir l’équipe, référents technique coincés en réunion transverse, chefs de projets débordés, je vous laisse méditer sur ce paradoxe.
Quelle posture adopter pour tirer parti d’une conférence
Depuis 1 an, j’ai une approche très différente des conférences auxquelles j’assiste. J’en ai pris conscience en juin à l’USI, et eu la confirmation à Agile Lean Europe où j’étais la semaine dernière (un chouette été, donc).
Avant, lorsque j’assistais à une session, j’étais critique. Je jugeais la prestation du speaker, indigné si ce n’était pas assez mis en scène, animé, ou clair, tout simplement. Ayant découvert l’univers des conférences surtout en tant que speaker ou organisateur (le snob, quoi), je jugeais les prestations d’un oeil d’expert jaloux. Et j’étais plutôt déçu.
Le phénomène s’est accentué terriblement lors de mes trois dernières années à Octo, où j’ai participé aux répétitions et à la constitution du programme de l’USI. A force d’aider des jeunes speakers à répéter et mettre au point leur session, les voir se mettre en quatre et produire finalement un résultat pointu sur le fond et percutant sur la forme, voir des speakers plus connus être moins que passionnant me faisait bouillonner. “Combien on l’a payé pour être là, déjà ? Il a décliné notre proposition d’aide pour répéter, c’est ça ? ».
Cet été j’ai assisté à l’USI pour la première fois en tant que “client”. Et un client qui paye sa place de ses deniers d’indépendant, il en pèse bien le prix (2000€ hors taxe, enjoy). Je m’attendais à être d’autant plus critique, craignant même que mon exigence ne me gâche l’expérience, mais l’inverse s’est produit.
Je me suis offert l’USI car les speakers sont capables de vous faire bouger dans votre têtes, de vous retourner. Et je me suis découvert bon public. La seule chose qui a compté, c’est ce qui se passait en moi. Ayant beaucoup investi pour le vivre, j’ai joué le jeu. Peu importe la qualité orale du speaker, j’en ai tiré le “jus”, l’idée qui tue. Parfois même, un speakers n’a pas été ébouriffant ni ses idées nouvelles. Mais moi j’en ai eu de nouvelles. Le fait de consacrer une heure à son thème, d’y réfléchir en l’écoutant, quelque chose dans son discours a résonné, produit une idée, une rupture.
Je me fous royalement que le speaker vaille le coup dans l’absolu ni même que d’autres l’aient vécu différemment. Moi j’ai bougé dans ma tête, j’en ai pour mon argent. Un truc s’est produit qui ne serait pas produit autrement. Ceci me rappelle d’ailleurs une citation de basket : lorsqu’on moque un joueur qui marque un panier en disant qu’il a eu de la chance, il pose le ballon par terre et dit “si je l’avais laissé là, y’avait combien de chances qu’il rentre ?”. Pour les sessions c’est pareil, je remercie le speaker lorsque il m’a fait bouger dans ma tête, et l’organisateur qui l’a invité là et mis à ma disposition.
Posture et engagement, comme toujours
La différence provient, je m’en rends compte à présent, de ne plus me positionner en contributeur de la conférence, qui, tourné vers la satisfaction de l’audience, jugeait le reste à cette aune. En simple participant, je suis bon public, comme je le suis au cinéma. J’accepte les codes, passe outre les défauts, je vis l’expérience qu’on me propose, et je suis capable de sortir de la salle en me focalisant sur ce que j’ai aimé et en négligeant ce qui ne m’a pas touché. La déception n’arrive que lorsque rien ne m’a touché ou fait vibrer.
Mon activité d’indépendant, démarrée depuis 18 mois, a boosté mon engagement de participant. Avant cela, la pression à tirer quelque chose de l’événement existait, mais j’y étais moins sensible. Aujourd’hui, mon temps a une valeur : en conférence je ne facture pas, je limite mes revenus potentiels. J’en tire une grande leçon sur la manière de vivre ces conférences.
Voici la manière dont je conçois aujourd’hui mon investissement :
- s’investir en tant que speaker, c’est se soucier de la qualité de l’expérience de tous les participants à ma session
- s’investir en tant qu’organisateur, c’est se soucier de la sélection du programme et du déroulement global
- s’investir en tant que participant, c’est rester égoïste, se moquer de ce que vivent les autres et ne penser qu’à soi, avec une attention soutenue
Toute la difficulté consiste, pour moi qui suis un engagé par nature, à me tenir à un rôle sans déborder sur les autres. Mon challenge sera donc de contribuer aux conférence avec un esprit d’exigence limité à mes sessions, et pour celles des autres redevenir un participant égoïste et bon public.
Indicateurs de pilotage : intégrer les risques
Le pilotage de projet en agile s’appuie sur des indicateurs simplifiés : en Scrum, un diagramme d’avancement compilant vélocité de l’équipe et complexité restante à faire. En Lean Software, un diagramme de flux intégrant temps de cycle et encours. Ces indicateurs sont des leurres si vous ne savez pas gérer les risques.
Vous avez déjà entendu les métaphores nautiques “le projet dérive”, “on tient le cap” ? Je vais prendre la métaphore au mot, et vous raconter une anecdote qui m’est arrivée.
Hissez haut !
Au cours de mes années étudiantes, je suis parti pour une semaine de navigation en voilier avec un skipper professionnel et 2 copains.
Très vite, on a vu que notre équipe fonctionnait bien. On s’entendait sans se marcher dessus, aspect fondamental dans ce huis clôt qu’est un habitable de 5,50m. Chacun ayant sa petite expérience de navigation, la coordination se rôdait, on manoeuvrait de plus en plus vite. Un soir, alors qu’on mouillait dans la rade de Port-Blanc, le skipper nous a proposé un défi :
“Demain, vent modéré annoncé. Vous êtes chaud pour les iles anglo-normandes ? Départ de nuit, longue journée de navigation, on doit tout planifier, comme des vrais marins.”
On a dit oui.
Cap vers Jersey
Pour naviguer loin de la côte, sans repère visuel et sur une telle distance, on a que la boussole pour s’orienter, donc il faut se fixer un cap et le suivre. Ce cap demande certains calculs.
Pour commencer, on calcule la dérive. On prend les cartes des courants marins et on additionne tous leurs vecteurs, heure par heure, tout au long du trajet, pour avoir la dérive totale. Disons que d’après ce vecteur on arriverait à 10 miles au sud par rapport à la destination théorique.
(corrupted image)
Donc on prend notre trajectoire par défaut, la ligne droite entre nous et Jersey, et on la compense, comme si l’île était en fait 10 miles au nord. Le cap (angle par rapport au nord) est mesuré pour suivre cette nouvelle ligne.
Dans notre cas, la précision comptait parce qu’au bout de 12H de navigation, on finirait fatigués. Tout retard puiserait dans nos forces, et ce serait que le début : selon l’heure et la position, on subirait des courants et des vents qu’on aurait pas intégrés, ça pourrait devenir une vraie galère. Les GPS ont beau éliminer le danger de se perdre, la mer est dangereuse, surtout pour un équipage épuisé et tendu sur un petit habitable de 5,50m. Donc chacun a recoupé les calculs pour être certains du vecteur de dérive et de l’angle de cap résultant. Avec nos bacs scientifiques fraîchement fêtés, on était quand même en confiance.
Le principe ensuite, c’est de lever l’ancre à l’heure prévue, suivre le cap à la boussole, et, déviés par le courant, on arrive à l’île. Fort de notre plan de navigation, nous nous sommes couchés pour un départ de nuit.
4H du mat, on me réveille.
“En fait y’a pas un pet de vent, on laisse tomber, on va suivre la côte jusqu’à Bréhat.”
Adieu Jersey.
On a accosté sur Bréhat dans la matinée sous un grand soleil. On s’y est reposé et baladé avant de reprendre la mer, c’était une journée magnifique. 
Du “projet qui dérive” à “l’avarie dans le projet”
Je reviens sur le pilotage de projet en agile.
Planifier nécessite l’hypothèse d’une progression simplifiée, linéaire. Les écarts que tolère cette hypothèse sont de simples dérives. Mais ce plan a un effet pernicieux : avec le temps que l’on investit dans nos calculs de prédiction, à sommer des éléments, prendre des marges, on tend à prendre l’hypothèse pour une réalité.
Hors la réalité n’est pas linéaire. Un imprévu peut faire exploser votre prévision.
C’est ce que je reproche aux courbes de vélocité et aux diagrammes de progression : ils incitent à penser que les imprévus provoqueront des dérives linéaires, des écarts de cap compensables. Je suis tombé dans cet écueil, et pas seulement à mes débuts en agile.
Je pense ne pas être le seul.
J’évoquai les métaphores nautiques, “projet qui dérive”, “tenir le cap”, etc. Mais on entend jamais “le vent est tombé”, “avarie dans le projet” ou “canot de sauvetage”. Les imprévus, les vrais, ceux qui comptent, ne font pas dériver la courbe. Ils la rendent caduque. Bien sûr, vous vous en rendrez compte, mais souvent ça prendra du temps, attachés que vous étiez à vos formules excel, et ce sera trop tard.
Quand le vent tombe, on jette ses calculs de courant, et on oublie Jersey. C’est un événement de rupture.
Comment intégrer dans le pilotage de projet un indicateur de progression qui donne le cap en conditions normales, tout en restant attentif à ces événements de ruptures, afin de lâcher le plan et prendre à temps les décisions qui s’imposent ?
Je croie en un pilotage schizophrène utilisant à valeur égale :
- un diagramme de progression, burnup chart ou burn down chart, qui prédit “qu’est ce qu’on va finir quand”
- une fiche de risques, récapitulant “ce qui ferait que ce diagramme n’a plus de sens”
Cette fiche de risques est une pratique classique de pilotage projet, je ne réinvente pas la roue. Cependant, je la trouve trop peu mentionnée dans le milieu de l’agile, et souvent oubliée par les équipes qui démarrent, donc j’insiste : elle doit être inclue et à jour dans vos documents de pilotage. Allons plus loin :
ce n’est pas qu’un élément d’information,
c’est un antidote contre la croyance en une progression linéaire.
Concrètement, j’en tire un principe pour les feuilles de route, diagrammes d’avancement, ou toute forme de projection qui vous sert à piloter :
on ne présente jamais un planning sans les risques à côté
Au mur, affichez la fiche de risque à côté de la roadmap. Dans vos excels, écrivez les risques sous le diagramme de progression, et pas dans un onglet séparé. En un seul regard schizophrène, vous aurez un oeil sur les indicateurs, l’autre sur les risques.
À venir : construire une matrice de risques (simplifiée)
Expliquer l’agile… en 5 minutes ?
Situation récurrente :
- Familial : “C’est quoi, Agile ?” me demande ma soeur en plein dîner de famille.
- Complice : “Tu peux m’expliquer rapidement, avant que je rencontre l’équipe ?” me chuchote le nouveau sponsor. Il attaque son 2e jour dans la boîte, il voudrait pas faire un impair.
- Amical, entre deux bières au Java User Group : “J’ai lu ton article, tu dis qu’on peut pas tout étiqueter ‘Agile’, mais alors on peut étiqueter quoi ?”
- Commercial : “J’entends parler de l’agile, mon chef de projet me dit que c’est plus efficace et j’ai envie de lui faire confiance, mais avant de faire appel à tes services j’aimerai bien savoir dans quoi je mets les pieds.”
- Syndical : “Comme on introduit de nouveaux postes, les syndicats aimeraient être briefés sur ce qu’est un projet agile. Sachant que la plupart ne connaissent ni le développement ni les démarches projet, tu pourrais leur expliquer en 20 lignes ?”
- Contractuel : “Les achats sont pour, mais ils sont très orientés cycle en V, tu aurais un quart d’heure pour leur expliquer ? c’est pour lancer un appel d’offre”.
C’est un signe de succès : plus l’agile s’intègre à l’entreprise plus on vous demandera cet exercice, décrire les fondamentaux dans un temps court. Est-ce possible ?
Oui, seulement ça s’apprend. Je pense même que si on ne sait pas expliquer l’agile en 60, 20, 10, 5, 1 minute, on aura des difficultés pour accompagner une équipe.
En ce qui me concerne, j’ai fait l’exercice pour la première fois en rejouant la session faites par Hervé Lourdin et Eric Pantéra à l’USI 2008, “l’Agile démystifié”, qui commençait par un tour de la méthode en 20 minutes. Ensuite, je l’ai refaite de nombreuses fois pour des clients. Un jour enfin, je m’y suis lancé à l’impro sur un paperboard, ce qui m’a libéré des slides originaux et a permis à mon discours d’évoluer.
Maintenant, cet exercice est une clé qui m’ouvre des portes tous les jours. Je module selon le temps, le rôle de mon interlocuteur, et les messages que je veux faire passer. En 20, en 10 minutes. Ou en 2, à table en famille. Ou en 5, pour une amie coach.
2 principes m’ont débloqué
- on ne peut pas tout dire, et c’est ok. Il faut survoler, choisir ses sujets, et laisser l’interlocuteur relancer par des questions s’il souhaite prendre plus de temps sur des points particuliers.
- d’abord s’appuyer sur un support papier pour dessiner. Ca permet de mieux maîtriser la structure de son discours et d’expliquer plus rapidement. Dans tous les cas, si votre discours dépasse les 5 minutes, vous devrez vous appuyer sur un support visuel, donc autant s’entraîner.
Si vous êtes formateur, coach, évangélisateur agile, je vous suggère de vous mesurer à cet exercice, par exemple en 10 minutes, puis 20, puis 5 et 1. Ca ne s’improvise pas, donc si vous n’êtes pas à l’aise, vous savez ce qu’il vous reste à faire pendant les 10 prochaines minutes : sortez un chrono, un papier, et essayez !
