Rendez l'agilité aux développeurs et développeuses !

Connaissez-vous les livres dont vous êtes le héros ?

Pour celles et ceux qui ne connaissent pas, vous allez voir, c’est très amusant.
Je vous propose de participer à une aventure : faire vivre, au travers d’une histoire, plus ou moins fictive, les aventures de Lily, développeuse Angular depuis 2 ans. Nous allons choisir, au travers de petites scénettes, ce qu’elle va vivre dans sa nouvelle entreprise SiCool.

Page 1 - Le premier jour

Lily a effectivement postulé un poste de Développeuse dans l’entreprise SiCool qui lui propose une mission en plateau pour l’un de ses clients TouDoux, spécialisé dans la vente de masques médicaux.
Le manager a hâte d’accueillir Lily : depuis quelque temps, le client TouDoux investit dans le numérique et souhaite ouvrir une plateforme de vente en ligne pour professionnels et particuliers. Tout est à créer et le nouveau manager manque d’expertise. Lily est donc sacrément attendue pour prêter main forte à l’équipe déjà en place pour proposer une solution de ventes en ligne adaptée.

Le jour de son arrivée, Lily est donc pressée de commencer : elle est motivée et veut faire ses preuves, elle veut montrer que SiCool a eu raison de la choisir parmi les différents candidats. Elle s’empresse donc de demander à son nouveau manager par où elle peut commencer.

Vous êtes le manager en question, vous êtes débordés (c’est d’ailleurs bien pour cela que vous avez besoin de recruter pas mal de monde en ce moment), que choisissez-vous de faire ?

1. Faire commencer Lily immédiatement à produire : après tout, le temps c’est de l’argent -> allez page 2
2. Prendre le temps de faire les présentations à l’équipe et son environnement -> allez page 3

Si je pose la question autrement : en vrai, sur les dernières années passées, lorsque vous démarriez une mission ou un nouveau job, avez-vous toujours été accueilli correctement ?

Si je repense aux dernières missions que j’ai vécues ces trois dernières années, j’en ai ramassé plus d’un à la petite cuillère : certains en pleurs après une première journée, première semaine ou premier mois quasi non accompagné. En 2019, j’en parlais déjà à des compatriotes agilistes, et encore dernièrement j’ai vu ou vécu de telles situations sous couvert d’autonomie et d’auto-organisation des équipes. « Débrouillez-vous ! » qu’ils disaient.

Alors on va choisir de faire commencer Lily tout se suite à produire.

Page 2 - Le début des travaux

Génial ! Lily a récupéré son PC dès son premier jour ! 😲
Formidable ! Elle a aussi récupéré son user et mot de passe. 😎
Incroyable ! Elle a accès à la documentation ! 😇

Oui mais… Toute seule devant son PC, dans la jungle de la documentation, Lily tente des installations, des configurations, des paramétrages : tout plein de petites bêtes étranges qui ne lui facilitent pas la vie. Informations dépassées, ambiguïtés, zones de flou, manque de précisions… Lily est perdue et aimerait bien poser des questions à quelqu’un.

Oui mais voilà : à qui ? La quasi-totalité de son équipe est en télé-travail, les personnes du bureau d’à côté ne lui ont pas été présentées… Elle toque, demande, interroge, mais on la renvoie sans cesse à cette documentation sensée tout contenir. Lily est bloquée, ne connait pas encore les process, bref, elle est perdue : sentiment d’abandon, de ne pas savoir se débrouiller, de doute… au final Lily se demande si elle a bien sa place ici.

Vous avez échoué : Lily est démotivée et va chercher un nouveau job ailleurs.

Aller en page 3 pour prendre le temps de présenter Lily à sa nouvelle équipe et lui présenter son environnement.

Page 3 - L’intégration à l’équipe

En tant que manager, vous prenez le temps de faire les présentations de Lily à sa nouvelle équipe. Elle se présente, chacun se présente à son tour. On partage, on échange, on montre à Lily qu’on l’attend. Idéalement, on est présent pour l’accueillir, partager avec elle son premier repas, discuter pro mais pas que, et puis on parle projet et organisation : qui fait quoi ? qui préfère faire quoi ? quel est le but du produit sur lequel on va tous travailler ?

Car une personne supplémentaire dans une équipe, c’est une nouvelle équipe : il faut retracer le périmètre de chacun, se rassurer et se donner de nouveaux repères.

BRAVO manager ! vous avez donné une première clé à votre équipe agile !

Grâce à ça, vous avez un pied dans la construction de l’identité de votre équipe. Vous avez rassuré et permis à tous de gagner de la confiance en soi. Enfin, vous avez permis de commencer à développer un sentiment d’appartenance pour tous. Vous pouvez maintenant tranquillement commencer à développer tous ensemble.

Page 4 - Le suivi opérationnel

Maintenant qu’elle sait où se trouve la documentation, les outils, les process, que tout le monde a bien compris son rôle et celui des autres, l’équipe se met au travail. Mais déjà, elle rencontre un problème sur son environnement. Oh ce n’est pas la stack technique non, ce n’est pas non plus le mode de déploiement, non, c’est l’outil de suivi du produit : Girafe.

L’équipe ne s’en sort pas, et vous demande, en tant que pilote transverse / PMO, l’autorisation d’utiliser un autre outil pour suivre ses avancées.
Que choisissez-vous de faire ?

1. Continuer comme vous avez toujours fait, les licences coûtent cher, il faut les amortir ! -> allez page 5
2. Laisser l’équipe choisir leur outil opérationnel -> allez page 6

En vrai je souhaite que Lily et son équipe ait eu l’idée de demander les droits d’administration sur l’outil pour pouvoir l’adapter à son usage.
Hélas, j’imagine que le pilote transverse, pour des soucis de « sécurité » ait pû refuser.

On va aller page 6, et on va continuer à utiliser Girafe, ça sera plus simple pour récupérer les indicateurs transverses et puis après tout, l’équipe est agile ! elle s’adaptera.

Page 5 - L’équipe galère

L’équipe tente : elle a besoin de répondre aux besoins d’indicateurs de l’entreprise, mais elle a aussi ses propres besoins : suivre un niveau de test supplémentaire ? elle ne peut pas changer le workflow ! 😒
Insérer un nouveau type d’information : elle n’a pas les droits d’en ajouter ! 😧
Tordre l’outil pour faire rentrer des ronds dans des carrés ? cela va impacter le suivi transverse ! 😫

Non, vraiment, l’équipe perd du temps à essayer de rentrer dans les cases, et un jour, pire que tout, le Product Owner, qui essaie de jongler entre attentes stratégiques et avancées opérationnelles, entend cette phrase coup de poing « mais quand est-ce qu’on va se mettre à développer ? ».

Vous avez échoué : l’équipe est démotivée et doute de l’agilité réelle de l’entreprise.

Aller en page 6 pour laisser à l’équipe prendre le temps de tester des façons de faire, des outils, des process.

Page 6 - L’autonomie de l’équipe

L’équipe se choisit un outil qu’elle connait déjà et qui est accessible par tous : Grello.
Elle se permet même un peu d’humour dans leur description de tableau, s’affecte les fonctionnalités, en change au besoin et commence à être à l’aise dans l’estimation d’un “reste à faire”.

Au bout de la première itération, les membres de l’équipe de Lily proposent même des axes d’améliorations, en ajoutant par exemple, en plus d’un état « en test », un autre état « en tests accessibilité » qui leur parait nécessaire, toujours pour gagner en efficacité.

BRAVO pilote transverse ! vous avez donné une deuxième clé à votre équipe agile !

En les laissant choisir un outil qui les rend plus efficaces, vous avez permis à votre équipe de se sentir légitime à tester de nouvelles choses et d’innover. C’est un réel gage de motivation supplémentaire.

Page 7 - L’avis extérieur

Pleine d’entrain, l’équipe de Lily fait vivre son produit. Mais au bout de quelques itérations supplémentaires, elle observe des bouchons : effectivement, dans la colonne “A tester”, Lily, pour la partie accessibilité, et le testeur officiel de l’équipe ont du mal à absorber la totalité des développements qui leur est transmise.
Pas de panique : l’équipe bénéficie d’un accompagnement agile transverse à toute l’entreprise.
Elle se retourne donc vers vous, coach agile et vous demande de les aider.

Vous choisissez de :

1. Vous positionner en tant que référent agile et indiquer un maximum de tâches en parallèle -> allez page 8
2. Faire s’inspecter l’équipe de Lily et l’accompagner dans sa recherche de solutions -> allez page 9

Le coach agile n’est pas un stylo bic 4 couleurs : il ne peut switcher de situation en trois secondes quand il a plusieurs équipes, voire toute une entreprise, à accompagner.

Vous avez déjà une solution possible à proposer, par expérience elle fonctionne à merveille dans une équipe voisine, vous proposez donc à l’équipe de Lily de tester le maximum de tâches en parallèle.

Spoiler alert : la distribution de solution magique ne fonctionne pas, mais voyons ce que cela va donner dans ce cas précis.

Page 8 - La solution magique

L’équipe fait confiance à son coach agile : elle met donc en oeuvre la solution discutée.
Problème : elle a été abordée rapidement et malheureusement mal comprise.

L’équipe de Lily instaure ainsi un maximum de tâche en parallèle… par personne !
Quelque chose de logique se produit : dès qu’on souhaite limiter le nombre de tâches d’une personne, automatiquement elle va se focaliser sur son expertise. Lily n’aide plus son testeur, elle se concentre sur son développement et le testeur se retrouve seul à tester.

L’équipe fait l’exercice sur un itération avant de faire le bilan : c’est un échec ! Le bouchon est toujours là et pire que tout, ce n’est plus sur une colonne qu’il y un bouchon, mais… sur une personne, car de la méfiance se crée.

Vous avez échoué : l’équipe se sent incapable de mettre en oeuvre correctement une façon de faire agile.

Aller en page 9 laisser à l’équipe le temps de s’inspecter et de trouver ses solutions.

Page 9 - Les solutions de l’équipe

En tant que coach agile, vous allez être un socle de l’équipe. Vous allez leur présenter les outils, les process, les astuces utiles et possibles à tester, à approuver ou non. Mais c’est bien en prenant le temps de leur présenter ces pratiques que vous allez les aider, et non en choisissant à leur place.

Vous rappelez à l’équipe que le maximum de tâches à parallèles est à spécifier par état, et non par personne. Vous leur parlez aussi de la DOR (definition of ready) qui, si elle n’est pas vérifiée, peut apporter des bouchons par la suite, vous parlez qualité aussi, car peut-être que les tests bouchonnent faute de tests unitaires dès les développements, vous parlerez aussi peut-être TDD…

Bref, vous offrez du temps et un panel de solutions possibles dans lequel l’équipe va venir piocher en fonction de ses propres réflexions et de ses décisions.

BRAVO coach agile ! vous avez donné une troisième clé à votre équipe agile !

En les laissant réfléchir quant à leur façon de faire, vous avez permis à votre équipe de se sentir légitime à tester de nouvelles choses mais aussi, vous avez planté la graine de l’amélioration continue en leur offrant cet espace et ce temps de réflexion et de prise de décision.

Page 10 - L’évolution du produit

L’équipe arrive maintenant à réaliser des fonctionnalités de qualité et de manière efficace.
Le Product Owner demande à ce que vous, le client / l’utilisateur, vous veniez valider l’aspect fonctionnel de leur produit, et ce très régulièrement, sans attendre le produit final.

Que choisissez-vous de faire ?

1. Faire confiance à l’équipe, valider en une seule fois l’ensemble des modifications, c’est plus efficace -> allez page 11
2. Consacrer fréquemment du temps à l’alignement du produit désiré et décrit, compris et réalisé par l’équipe -> allez page 12

On est un client sur-booké, on intervient sur plusieurs sujets et en plus nous ne sommes pas bien accompagnés dans cette nouvelle façon de fonctionner : on va se la jouer cool et on va choisir de faire confiance et de se revoir plus tard.

Page 11 - Le produit final

Au bout de plusieurs itérations donc, l’équivalent d’à peu près 3 mois de développement, l’équipe a compilé 18 fonctionnalités qui sont prêtes à être livrées en production. Après la validation du client, il n’y aura plus qu’à appuyer sur un bouton pour le déployer et le rendre disponible aux utilisateurs.
On organise donc un point de validation avec nous, client. Forcément, il est un peu costaud parce qu’il y a 18 fonctionnalités à valider, on va partir sur 3H… Et là, c’est le drame ! on n’est pas du tout content !

Les menus de l’application ne sont pas positionnés comme il faut, la couleur du site laisse à désirer (“OK on avait demandé cette couleur, mais vous voyez bien que ça ne rend pas bien !”), le navigateur compatible n’est plus le bon : “vous n’avez pas lu la note interne il y a 2 semaines ?” bref… tous ces retours pour seulement la première fonctionnalité…

Bref, même si toutes les fonctionnalités ne sont pas à jeter, le site ne peut pas être livré en production.

Vous avez échoué : l’équipe est frustrée, elle critique, et elle a raison, cette « fausse agilité » et le product owner, responsable aux yeux de l’entreprise en prend pour son grade.

Aller en page 12 pour prendre le temps de donner des retours régulièrement à votre équipe agile.

Page 12 - Le produit incrémental

En tant que Client, on a nous aussi notre rôle à jouer et on va se rendre disponible pour que les échanges soient plus nombreux et plus constructifs. D’ailleurs, idéalement, le client se fait lui aussi accompagner dans sa transformation agile, au même titre que l’équipe de développement.

Dès l’appel de l’équipe, en fin de première itération, on va regarder attentivement ce qui fonctionne déjà : pas grand-chose ? C’est logique vu le temps de développement et de tests passé et ce n’est pas grave : au contraire, le point va être rapide !

On a l’opportunité d’alerter tout de suite sur la mauvaise compréhension du menu : on le préfère à gauche plutôt qu’en haut, mais sinon tout est parfait : on valide la couleur, la police et les traits parfaitement droits des cadres !

De la même manière, à la seconde itération, l’équipe montre ce qu’elle a pu facilement modifier suite à cette première revue, ainsi que les nouvelles fonctionnalités prioritaires.
Etc… etc…

Finalement, en « perdant » un peu de temps par-ci par-là au fil de l’eau, on en gagne à long terme : on ne perd plus de temps à se tromper, à corriger ou revenir en arrière. On gagne du temps à aller vers la bonne direction et en empruntant le bon chemin.

BRAVO client ! vous avez donné une quatrième et dernière clé à votre équipe agile !

En prenant le temps de donner du feedback régulièrement, vous avez mis le pieds dans l’amélioration continue du produit. Cela vous permet, à l’équipe et vous, de partager une vision commune et toujours actualisée de ce qui est attendu et réellement utile. Mine de rien, c’est une vraie adhésion à l’équipe qui se crée : il ne serait pas étonnant que vous migriez plus proche de l’équipe à l’avenir tellement les échanges sont réguliers et nécessaires. Enfin, l’équipe se sent engagée grâce à vous vers un but salvateur : développer des applications utiles à ses utilisateurs !

Morale de l’histoire

Aventurier, aventurière, vous vous êtes égarés durant ce périple.
Les circonstances de ces dernières années ne vous ont pas aidées : pandémie, confinement, télé-travail… vos habitudes collégiales et vos déjeuners team-building en ont pris un coup.

Mais rappelez-vous que nous avons toutes et tous un rôle à jouer pour rendre les équipes de developpement agiles.

Alors rendons les clés de l’agilité à nos développeurs et développeuses, apportons leur du temps :

• Prenez le temps d’accueillir et d’intégrer les membres d’une équipe agile (ou pas agile d’ailleurs !)
• Prenez le temps de tester des façons de faire, des outils, des process
• Prenez le temps de vous poser, de réfléchir à comment mieux créer, réaliser, tester…
• Prenez le temps de donner du feedback sur ce qui est réalisé, et faites-le de manière constructive

A suivre, pour de nouvelles aventures…

Un grand merci aux organisateurs de AFUP 2020, AgiLeMans 2022, DevoxxFR 2022 et Camping des Speakers 2022 de m’avoir donné la chance de donner cette conférence en visio, en live, en amphithéâtre, en extérieur… que de bons souvenirs !
Lien vers les slides présentés à DevoxxFR 2022
Lien vers la vidéo de DevoxxFR 2022 en amphi bleu 😍
Lien vers les slides présentés à AgiLeMans 2022
Lien vers la vidéo de AFUP Day Tours 2020