Les bottes à marde

Mario

Il y a quelques semaines, notre collègue Mario nous a raconté l’histoire de son ancienne copine qui avait grandi sur une ferme.

Quand venait le temps de prêter main forte, démêler un enjeu ou simplement aller voir ce qui se passait, elle devait retirer ses chaussures propres et enfiler ses “bottes à marde”.

Car sur le terrain, on ne sait jamais ce qu’on va rencontrer et y’a de bonnes chances qu’on s’y salisse.

Depuis, l’expression a fait son chemin dans notre vocabulaire.

Je vais mettre mes bottes à marde et….Va donc chercher tes bottes à marde et…

À quoi ça ressemble enfiler ses bottes?

Pour un tech lead

Ça pourrait vouloir dire…

• Travailler à régler des enjeux techniques qui bénéficieraient à tout le groupe, mais que personne ne veut ou ne sait faire.
  – Ex.: améliorer les temps de compilation de l’application. Solidifier le build. Bonifier le coffre à outils des devs de l’équipe. Etc.
• Refuser de livrer du nouveau code sans un niveau de qualité minimal et accompagner son équipe à l’atteindre. En assumer les conséquences.
  Ex.: ne pas livrer du code sans tests automatisés. Aider les équipiers à les écrire.
• Démêler un enjeu impliquant plusieurs systèmes ou équipes, en allant cogner à des portes, peu importe qui en est à l’origine.
• S’assigner des tâches moins intéressantes pour permettre à des joueurs moins expérimentés de se pratiquer et d’apprendre.

Pour un gestionnaire

Ça pourrait vouloir dire…

• Prendre des enjeux remontés par l’équipe et devenir le porteur de leur résolution même si ça ne l’avantage pas personnellement.
  – Ex.: un enjeu qui risque des conversations difficiles avec son propre gestionnaire ou avec un autre groupe.
• Sortir du confort de son bureau et venir voir comment le jeu se déroule sur le terrain.
  – Ex.: Cesser de dire “j’ai déjà été développeur moi aussi” et venir voir comment ça se passe réellement, ici, maintenant, pour ses équipiers.
• Accepter de leur déléguer des responsabilités et accepter qu’ils puissent faire des erreurs.
  – Ex.: laisser l’équipe expérimenter avec une de leurs suggestions. Par exemple, avec des sprints d’une durée différente et évaluer leurs résultats après un certain temps.

Pour un développeur

Ça pourrait vouloir dire…

• Investiguer des incidents de production, même s’ils sont complexes ou les outils en place ne sont pas optimaux.
  – Ex.: devoir éplucher des tonnes de logs sur plusieurs machines. Devoir faire avec de l’information partielle. Corriger le problème une fois trouvé. Tester et déployer le correctif. Et après tout ça, améliorer les outils pour faciliter le travail du prochain.
• S’intéresser suffisamment au domaine d’affaire de son application pour avoir des conversations génératives à son sujet.
  – Ex.: en apprendre assez sur le domaine(vente d’assurances, l’octroi de prêts, etc.) et sur vos compétiteurs pour pouvoir participer à des conversations de design/analyse/priorisation.
• Apprendre à maîtriser une technologie utilisée par son équipe, même si elle lui déplait ou n’aidera pas son CV.
  – Ex: s’approprier un outil peu vendeur sur le marché et s’efforcer à y appliquer ce qu’on apprécie d’autre techno pour en faire le meilleur de notre situation

Pour un Product Owner

Ça pourrait vouloir dire…

• S’intéresser suffisamment aux technologies utilisées par ses applications pour avoir des conversations génératives à leurs sujets.
  – Ex.: en apprendre sur le design de site Web, ce qui se fait ailleurs, les tendances, les nouveautés, les pièges à éviter, etc.
• Explorer, tester, etc. le produit qu’il commande à fréquence régulière.
  – Ex: ’enthousiasmer face au produit qu’on s’est fait construire. Se mettre dans la peau de l’utilisateur, vivre ses joies et ses frustrations. Contribuer à l’améliorer.
• Oser dire non à des demandes qui nuiraient au produit, à l’équipe ou à l’organisation.

Pour un ScrumMaster

Ça pourrait vouloir dire…

• Aller s’intéresser suffisamment sur les technologies et le domaine d’affaire des applications de son équipe pour avoir des conversations génératives à leurs sujets.
• Prendre des enjeux remontés par l’équipe et devenir le porteur de leur résolution.
  – Ex.: ne pas se contenter d’organiser ou faciliter des rencontres, mais également contribuer directement à améliorer le sort de l’équipe et des gens qui la compose
• Aborder des discussions du style “éléphant dans la pièce” même si elles risquent d’être difficiles.
  – Ex.: se rendre vulnérable face à des sujets difficiles qu’on ne peut régler seul et se permettre de les aborder en équipe.

Pour un coach

Ça pourrait vouloir dire…

• Montrer par l’exemple plutôt que suggérer, questionner, etc.
  – Ex.: Oser apprendre une techno, un projet ou un domaine qui nous est moins familier pour montrer des exemples pertinents, contextualisés à la réalité de l’équipe.
• Aller sur le terrain jouer la partie avec les équipiers plutôt que de rester sur la passerelle.
  – Ex.: parfois porter le chapeau de joueur-entraîneur et non seulement entraîneur.
• Se mettre dans le siège de l’apprenti et laisser un membre de l’équipe leur montrer un(e) nouveau(le) outil/technique/techno/pratique/etc.
  – Ex.: se montrer vulnérable et se permettre de laisser tomber sa posture d’expert devant ceux qu’on accompagne.

Pour chacun d’eux

Ça pourrait vouloir dire …

• Oser.
• Ramasser un enjeu que tout le monde regarde et n’ose adresser.
• Contribuer quelque chose pour le groupe qui n’est clairement pas dans sa description de tâche.
• Se rendre vulnérable et aller apprendre une nouvelle compétence.

Pourquoi?

Parce que si tous les équipiers sont prêts à enfiler leurs bottes, c’est

Qu’ils ont tous à cœur les objectifs du groupe,
Que personne n’est trop important pour ne pas se salir,
Qu’ils ont assez confiance aux autres pour oser,
Que tout ce monde se saura supporté par ses collègues

Et ça, ça sonne comme une équipe du tonnerre, prête à enfiler ses bottes et botter des culs.

À vos bottes ! 🙂