Une idée, c’est comme une graine : pour germer il lui faut de l’eau, une terre riche et du soleil. Si tu plantes dans une terre aride sans arroser, tu auras le soleil et la terre, mais il manquera l’eau. Elle ne poussera pas ou peu. Si tu as beaucoup d’eau mais pas de soleil, elle peut même pourrir. Bref il lui faut un bon contexte.
Il lui faut aussi tu temps : tu peux tirer sur la tige tant que tu veux, cela ne fera pas pousser plus vite.
Et il lui faut du soin : si elle est piétinée ou que les premières feuilles sont mangées par les limaces, ça ne poussera pas.
C’est un peu pareil quand tu veux faire pousser une idée dans une organisation.
Il lui faut un contexte, du temps et du soin.
Au moment d’apporter une idée, j’en vois qui agissent comme s’il suffisait d’en parler et de prendre une décision pour qu’elle soit mise en oeuvre.
Ben non.
Tu ne l’as pas déjà vécu ce moment en rétro ou dans une réunion ?
Tu arrives enfin à faire passer une idée. Tu sens même de l’enthousiasme.
Et puis ?
Deux semaines plus tard il ne s’est rien passé.
En fait tu avais jeté une graine sans vraiment t’en occuper. Parfois ça pousse, mais c’est rare.
Pour qu’une idée grandisse, il faut un contexte, du temps et du soin.
- Le contexte : si ton contexte n’est pas favorable, ce sera forcement plus difficile. Savoir attendre le bon moment fait partie du contexte. Le bon moment n’est pas celui où tu es motivé, c’est quand les autres sont prêts à t’écouter et y consacrer leur attention. Soyons clair : tout changement coûte de l’énergie. Alors il vaut mieux attendre que tes collègues soient prêts à ça.
- Du temps : ça ne va pas se faire en un claquement de doigt. Il faut que tu réalises tout le chemin qui t’a amené à croire en l’idée que tu as envie de proposer. Tu l’a mûrie. C’est le fruit d’une expérience, de recherches, de difficultés. Avant que quelqu’un d’autre s’approprie l’idée, il lui faudra refaire toute une partie du chemin. Tu pourras l’aider en le guidant. Mais il aura quand même besoin de temps.
- Du soin : il va falloir y consacrer encore plus d’énergie que les autres. Car si tu es convaincu, ce n’est pas le cas de tout le monde. Sinon tu ne lirais pas cet article.
Mais tout ça reste encore théorique.
Alors je vais te raconter comment nous avons fait une mise à jour majeure de notre fonctionnement interne.
L’équipe comporte 12 personnes :
* 2 fondateurs
* 2 UX-designers
* 7 développeurs
* 1 community manager
Nous venons de démarrer le développement de mySofie.
L’ambiance est excellente. La volonté d’entraide et là.
Techniquement ça roule nickel. Entre artisans développeurs on se comprend et ça carbure.
Par contre il y a un point qui pose souci : l’information est éclatée sur plusieurs outils. Entre github, invision, Zeplin, trello, Basecamp et les feuilles excel qui pullulent, c’est une vraie prise de tête pour savoir quoi développer dans quel ordre.
On perd de l’énergie et parfois on développe des écrans obsolètes.
C’est le point #1 qui ressort de la première rétro.
Il FAUT faire quelque chose.
Tout le monde est d’accord : il faut réduire le nombre d’outils et concentrer l’information utile au développement en un seul endroit.
Sauf que, cet endroit n’existe pas. On sent bien qu’aucun des outils existant ne peut remplir ce rôle.
L’équipe étant distribuée, pas possible de partir sur mes outils préférés : le post-it et le feutre.
Je prends l’action de proposer quelque chose.
Premier réflexe, google. Je tape un truc comme ‘agile project management tool’. Et là je réalise rapidement que ça va être trop long de tout essayer.
Je change de fusil d’épaule et je demande à linked-in.
Je récolte de super retours ! Merci encore à tous.
Au passage je suis un peu surpris par l’engouement du post : 15.309 affichages et 82 commentaires me font dire que je ne suis pas le seul à me poser des questions…
Grâce au filtre Linkedin, j’identifie 3 candidats en liste finale. C’est finalement taïga qui retient mon attention :
“Après une shot list Tuleap vs Taiga vs Hygger, c’est taiga qui remporte le match.
* Tuleap me faisait peur dans son look et son ergonomie.
* J’ai stressé en démarrant la démo Hygger. Commencer pas une représentation en diagramme de gantt n’était pas la meilleure manière de me convaincre. En plus l’outil implique au delà de l’équipe technique.
* Taiga est au top. En 2 mns je l’ai pris en main. Bon j’avais déjà travaillé avec il y a 2 ans, mais je me souviens m’être déjà fait la même remarque à l’époque. J’avais l’impression qu’il était fait pour moi. C’est fluide et intuitif. J’ai particulièrement aimé la gestion des estimations et la gestion bug VS story. Je trouve leur manière de faire très intelligente en séparant les deux tout en permettant une passerelle. “
A ce stade je suis convaincu que Taïga est une bonne option. Par contre je suis encore le seul…
J’aurais pu m’arrêter là, ‘décider’ que c’était l’outil à utiliser. En tant que CTO, il suffit de décider pour que les autres agissent, non ?
Sauf qu’en fait ce problème d’outillage faisait apparaitre un autre problème moins visible mais encore plus important : nous n’avions personne qui jouait le rôle de product owner. C’est à dire quelqu’un qui alimente le backlog et qui le priorise. Ou plus exactement ce rôle était dispersé sur plusieurs personnes. Si bien que chaque équipe avait son backlog et ses priorités. Le problème d’outillage n’était que le symptôme, pas la cause.
Il fallait donc traiter les deux en même temps :
* le problème technique : changer d’outil.
* le problème organisationnel : centraliser le rôle de PO.
Je sentais bien que si j’y allais en mode “command and control” sans laisser aux autres s’approprier l’idée, j’allais peut-être réussir à faire adopter taïga, mais personne n’aurait pris le relai pour l’animer. Et je ne voulais pas le faire ! Ce n’est ni mon rôle ni ce que j’aime faire…
Je savais que si je me contentais d’un post sur Basecamp, pas grand monde n’irait regarder l’outil : il faut ouvrir un compte, faire l’effort de mettre des données, etc… Peut-être même que personne n’aurait vu le post tant l’information était abondante.
Et pourtant il était important que tout le monde commence à habituer leurs rétines. C’est important de voir les choses.
J’avais hésité avec une présentation plus classique en mode powerpoint.
Mais l’équipe est remote et je préfère de loin les interaction asynchrones dès que c’est possible : cela me permet de rester concentré sur mon travail et plus de flexibilité sur les horaires.
J’ai donc enregistré une vidéo de démonstration qui expliquait rapidement l’enjeu du changement d’outil, les raisons pour lesquelles je préférais taïga et enfin une démonstration rapide de l’outil.
Elle prend 10 minutes et elle est ici:
Cela m’a demandé un peu plus de temps qu’une présentation classique à préparer, mais surtout cela m’a demandé de faire un effort : tu te souviens ?
Une idée, il lui faut du soin…
Cela aurait été plus facile d’aligner quelques diapos en mode capture d’écran. Et puis zou je cale une réunion.
Là il m’a fallu rédiger le script, tourner, monter, publier et passer l’information via Basecamp dans un message rédigé. J’y mentionne bien entendu la vidéo de présentation ainsi que l’épisode #19 de la (super) série Scrum Life.
Ensuite j’ai demandé tous les jours du feedback pendant la daily. Pas grand monde ne s’était rué dessus…
Enfin on a organisé une réunion d’une heure et demi pour décider de ce qu’on faisait : on prend ou pas ?
L’autre gros avantage du mode asynchrone est qu’il a permis à chacun de s’intéresser au sujet quand il était disponible pour le faire. Tu te souviens le point sur le contexte ?
Et enfin chacun a pu donner son feedback à son rythme et moi de prendre la température.
Et s’il n’y avait pas de voix qui s’élevait contre, ce n’était pas gagné pour autant… Je ne retrouvais pas forcement l’enthousiasme qui m’animait !
Là où j’espérais des : “Ah ! Mais c’est génial, c’est exactement ce qu’il nous faut ! Merci !”
J’ai plutôt eu des : “Ah ? Ok. Ça a l’air bien, mais… Y’a ça et ça que je trouve bizarre…”
Ou des questions plus de fond sur l’intérêt de tel ou tel point.
Bref j’avais une équipe qui cherchait à comprendre et s’approprier les choses. Et c’est là que la patience est clef : laisser à chacun le temps de s’habituer, de comprendre, de s’approprier les concepts. Prendre le temps de répondre aux questions. D’intégrer aussi les feedback pour s’assurer que oui, c’est toujours le bon outil pour l’équipe.
Tout ça est juste normal.
Après il y a un moment où il faut y aller. Un peu plus d’une semaine plus tard il était temps que l’équipe s’engage dans une direction.
Nous avons calé une réunion de 90 minutes avec l’objectif de prendre une décision : taïga or not taïga ?
La réunion a été l’occasion de repasser sur les enjeux de la décision, sur toutes les questions soulevées dans les feedback. Mais cette fois tout le monde était préparé à la décision.
Souviens toi que l’enjeu était double : valider un outil, mais également identifier qui allait s’en occuper…
La discussion était constructive mais au moment de s’engager, la décision était plus difficile à prendre. Du coup on a décidé d’essayer avant de valider la décision. On se donnait 72h pour tester.
Tu vois, après toutes ces étapes, l’équipe n’était pas encore prête à s’engager.
Finalement le test a été concluant. Notre nouveau PO, un des deux fondateurs, s’est très vite approprié l’outil : il faut dire qu’il y a rapidement trouvé son intérêt car il pouvait enfin voir ce qui se passait en production et où en était l’équipe. Avant ça, il y avait eu quelques tunnels stressants…
Au final, c’est un des points positifs #1 qui est ressorti à la rétro suivante.
Il aura fallu de la patience, de la détermination, de l’engagement pour que l’idée prenne. Et surtout, un contexte favorable grâce à une super équipe engagée et constructive. Merci au passage à tous mes co-aventuriers.
J’espère que ce retour d’expérience te sera utile.
Si tu as aussi des exemples de comment tu as réussi à faire pousser des idées qui te tiennent à coeur dans ton organisation, je prends !