Technical Agile Coaching with the Samman Method

1 - Introduction

• La méthode Samman consiste, pour un coach technique, à améliorer le niveau technique de plusieurs équipes en même temps, en divisant son temps en :
  • 1 - Learning hours, où l’équipe apprend des techniques par des exercices pratiques sous forme de katas.
  • 2 - Ensemble working, où l’équipe applique ce qui a été appris sur le code de production, accompagnée par le coach.
• Emily cite notamment le TDD et le refactoring comme deux piliers de son coaching technique.
• Le fait que les compétences techniques de l’équipe permettent une performance de l’organisation est appuyé par exemple par la recherche expliquée dans Accelerate.
• Une journée classique pour un coach technique comme emily consiste en :
  • 1 heure de learning hour avec deux équipes en même temps.
  • 2 heures d’ensemble working avec chaque équipe (donc 4 heures).
  • Le reste est partagé entre de la préparation et de la communication.
• D’une certaine manière, le coach technique qui pratique la méthode Samman a le privilège de faire du mob programming pour l’essentiel de son temps.

2 - The purpose of Samman Coaching

• Parmi les éléments techniques qu’Emily apprend aux équipes, il y a :
  • Les tests unitaires, et la manière d’en écrire de bons.
  • L’intégration continue, qui est une des techniques dont l’efficacité fait consensus.
    • On parle bien d’intégrer le plus souvent possible, avec pour objectif d’arriver à des incréments de quelques heures.
  • Le refactoring du code legacy, avec des techniques à base d’ajout de tests pour traiter le code sans avoir à le réécrire entièrement.
  • Le design incrémental, avec la capacité à savoir quand changer le design au cours du développement, quels design patterns appliquer.
• Les techniques de développement ne peuvent marcher que si l’ensemble de l’équipe les applique. C’est pour ça que l’apprentissage et la mise en place des pratiques se fait avec l’équipe entière.
• En 10 à 20 jours de coaching, les équipes acquièrent une compréhension des techniques fondamentales de développement, et du fait que le développement itératif permet une plus grande efficacité.
  • Par la suite, il s’agit d’augmenter leurs compétences générales de code et de design, et d’ancrer un changement culturel.
• Parmi les éléments à mesurer pour prouver l’efficacité du coaching :
  • Au départ, on peut mesurer l’enthousiasme des développeurs par des sondages, le nombre de tests écrits, la fréquence d’intégrations du code.
  • Par la suite, on peut mesurer les deadlines mieux tenues, les bugs moins fréquents.
  • Attention au fétichisme de la mesure, il faut malgré tout discuter avec les gens, et vérifier que les mesures qu’on obtient ont l’air cohérents.

Part I - Ensemble Working

• Emily reprend le concept de mob programming de Woody Zuil, et change quelques termes pour plus de clarté :
  • ensemble programming au lieu de mob pour insister sur l’aspect collaboratif.
  • Typist au lieu de driver pour bien insister sur l’aspect non décisionnaire de la personne qui a le clavier.

3 - Ensemble Primer

• L’ensemble programming utilisé dans la méthode Samman a les rôles suivants :
  • Le typist est la seule personne qui écrit au clavier.
    • Elle ne décide pas de ce qu’elle fait, elle doit écouter les autres membres de l’équipe, et en particulier le navigator.
  • Le navigator représente l’ensemble de de l’équipe qui n’écrit pas, et guide le typist dans ce qu’il faut faire.
  • Les team-members participent en intervenant quand ils ont une suggestion, une question ou toute autre intervention qu’ils jugent pertinente.
  • (optionnel) Le facilitator veille à ce que les rôles soient correctement tenus et qu’il y ait une rotation, et que la collaboration se passe bien. Son rôle peut devenir non nécessaire avec le temps.
  • (optionnel) Le researcher se détache de temps en temps pour chercher quelque chose de spécifique, et laisser le groupe avancer. Dès qu’il a trouvé, il revient vers le groupe pour partager sa trouvaille.
  • (optionnel) L’archivist écrit les décisions du groupe pour en garder une trace. Il peut aussi écrire l’objectif actuel du groupe, et tenir une liste de choses à faire que le groupe met de côté momentanément.
• Il y a régulièrement des phases de discussion, auquel cas les rôles sont suspendus, et l’ensemble des participants peuvent exprimer leurs idées sur un tableau.
• Les rôles tournent régulièrement, souvent avec l’aide d’un outil automatisé qui indique quand tourner.
  • En général la bonne idée c’est que le navigator courant devienne le typist.

4 - Let the Ensemble give you Superpowers

• Parmi les avantages de l’ensemble programming :
  • L’équipe entière est responsable du code, et s’aligne sur les pratiques de code.
  • La connaissance se diffuse à une vitesse incroyable : si un des membre sait faire quelque chose, très peu de temps après tous sauront le faire.
    • Exemple : si une configuration Kubernetes doit être faite et qu’une personne a des connaissances sur ça, elle dit quoi faire au typist, les autres posent des questions, et la prochaine fois ils sauront aussi le faire.
  • L’onboarding est hyper rapide : l’équipe ne fait que parler de ce qu’elle fait en expliquant en permanence les détails, donc un nouveau développeur peut rentrer dans le bain en très peu de temps.
• Le coach se comporte comme un visiteur quand il rejoint une équipe qui fonctionne en ensemble programming de manière fluide : il s’insère rapidement et commence à contribuer comme les autres, en suggérant des opportunités de refactoring, de patterns de design etc.
  • La 1ère étape est donc d’aider l’équipe à fonctionner en tant qu’ensemble de manière fluide. C’est là que le coach pourra contribuer le mieux sur l’aspect technique.

5 - Coaching Behaviors in an Ensemble

• Pendant les moments d’ensemble programming, le coach va alterner entre différents comportements.
  • Enseigner : à certains moments, quand l’équipe est confrontée à une technique qu’elle ne connaît pas, le coach peut prendre quelques minutes pour expliquer le concept, avant de retourner au code avec l’équipe.
    • Ca peut être par exemple un cas où extract method object serait adapté, mais l’équipe ne connaît qu’extract method. On va alors sur le site de Fowler pour expliquer la technique en question, on en fait une petite démonstration sous forme de kata, puis on l’applique dans le code de production en guidant tant que navigator.
  • Mentorer : pour les techniques où l’équipe a déjà une première expérience, mais où elle n’est pas encore complètement à l’aise, le coach va proposer un guidage.
    • A mesure que l’équipe devient à l’aise, le coach va intervenir de moins en moins en tant que navigator, et ne donner que des petites indications.
    • Tant que l’équipe progresse, le coach les laisse faire.
  • Faciliter : dans certains cas le coach adopte un rôle neutre pour aider une solution à aboutir.
    • Par exemple, si deux solutions de design sont proposées par l’équipe, il les aide à essayer la première, puis la deuxième, et enfin à faire un choix.
  • Coacher : dans le cas où l’équipe a déjà la connaissance théorique et pratique sur un sujet, mais a besoin d’un petit coup de pouce pour embrayer sur une technique, le coach peut utiliser une question de coaching pour aiguiller.
    • Ca peut par exemple être quand un navigator est coincé parce qu’il ne sait pas quel test écrire, en lui demandant quel serait le prochain scénario.
    • Si ces petites questions ne marchent pas, le coach revient sur du mentoring, voire même une petite session d’enseignement.
  • Observer : si l’équipe avance bien, le coach peut se mettre en retrait et noter des choses, qu’il pourra communiquer à l’équipe par la suite.
  • Prendre des pauses : le coach peut, comme les autres membres, prendre des pauses à tout moment et laisser les autres continuer.
    • Emily conseille aussi au moins une pause collective pour couper la session de 2 heures en deux, et une pause à la fin si elle enchaîne avec une autre équipe.
• La session doit se terminer par 15 à 25 minutes de rétrospective, où l’équipe et le coach parlent de la session pour essayer de prendre conscience de ce qu’ils ont fait, ce qu’ils ont appris, les points d’amélioration etc.

6 - Kindness, Consideration and Respect

• Le rôle du coach est de veiller à ce que les membres de l’ensemble soient respectueux les uns envers les autres.
  • D’ailleurs la recherche montre que traiter les autres avec gentillesse fait qu’on les aime par la suite davantage, plutôt que dans le sens inverse.
• Plutôt que de critiquer le code legacy qu’on améliore, il vaut mieux partir du principe que la personne qui l’a écrit a fait de son mieux, en particulier si elle est présente, pour ne pas la rabaisser.
• Une règle générale est de construire par dessus ce que les autres navigateurs ont fait plutôt que de refaire. On dit “Oui, et …”.
• Quand les relations s’enveniment, il faut marquer une pause, laisser chacun aller se calmer avant de reprendre.
  • Au besoin, il pourra être nécessaire de traiter le sujet en dehors, avec des 1&1.
• Le typist doit écouter les instructions qu’on lui donne, sinon il n’y aura pas d’ownership collectif de ce qui est fait de la part de l’équipe. Il faut donc s’assurer que ce soit le cas, et au besoin rappeler au typist qu’il doit être à l’écoute et non pas à l’initiative.
• Ne pas hésiter à pointer ce qu’un des contributeurs un peu timide dit de pertinent, pour marquer que ce que dit chacun est important.
• Quand certains membres se distraient et commencent à faire autre chose, le mieux est d’augmenter la vitesse de rotation pour qu’ils soient navigator plus souvent.
• Dans le cas où une personne dit ou fait quelque chose d’inacceptable qui ne peut pas attendre la rétrospective, il faut le recadrer : “nous ne faisons pas ça ici”.
  • Dans le cas où il dirait que c’était une blague, on peut rétorquer : “Oui j’en suis sûr, mais nous ne faisons pas ça ici”.

7 - Coaching Situations Illustrated with Stories

• Quelques exemples de situations où un coach Samman peut intervenir :
  • Un navigator est hésitant et n’arrive pas à avancer, le coach lui pose la question “Que devrions-nous faire maintenant ?”
    • Si le navigator ne sait toujours pas, le coach essaye de poser des questions pour l'aiguiller, par exemple “A quelle étape du TDD sommes-nous ?”, “Quel scénario nous reste-t-il ?”.
  • Un navigator est hésitant et n’arrive pas à avancer, le coach fait appel à l’équipe.
    • Si le navigator n’y arrive pas du tout, le coach peut donner le rôle de navigator à une autre personne, puis le redonner à la personne qui n’y arrivait pas au tour d’après.
  • L’équipe est bloquée suite à un désaccord, le coach propose à l’équipe de réaliser des expérimentations pour trancher collectivement.
    • Il s’agit d’être orienté vers l’action, avec du code écrit tout s’éclaircit.
    • Laisser l’équipe mener des expérimentations est une meilleure option que de trancher la question du haut de sa stature de coach.
  • L’équipe commence l’écriture de code, mais a besoin de créer des scénarios pour commencer, le coach facilite la découverte des scénarios en posant des questions et laissant les membres de l’équipe donner leurs idées.
    • Une telle session peut typiquement prendre 5 à 15 minutes, avant l’écriture du code en TDD, et permet de garder un cap pour savoir quel test écrire ensuite.
    • Ça peut être pas mal qu’un membre de l’équipe note les scénarios, ou les prenne en photo pour que l’équipe ne les perde pas.
  • Le typist ne comprend pas les instructions du navigator, le coach aide le navigator à être plus explicite.
    • Dans l’ordre, le navigator doit exprimer :
      • Son intention.
      • Puis si le typist ne comprend pas, indiquer la position sur l’écran où intervenir.
      • Et enfin si il ne voit toujours pas, indiquer des détails jusqu’à quoi taper caractère par caractère.
  • Le navigator saute sur l’écriture du code sans test qui échoue, le coach lui rappelle qu’il faut un test en posant des questions.
  • Le typist oublie d’utiliser un raccourci clavier pour aller plus vite, le coach l’aide en le lui rappelant, ou en le lui apprenant.
  • Le navigator demande à déclarer une nouvelle fonction mais au changement, le navigator suivant ne sait plus à quoi elle servait, le coach lui demande de revenir à l’endroit où elle doit être utilisée plutôt que là où elle est déclarée.
    • Cette technique s’appelle le consume-first design, et permet de mieux communiquer l’intention derrière le nouveau code, en partant du contexte d’utilisation.
  • Le navigator demande à écrire du code et des tests en chaîne, le coach lui demande de compiler et jouer les tests pour avoir du feedback plus souvent.
  • Le navigator enchaîne sur un autre test, du code ou un refactoring, le coach lui rappelle de demander un commit vu qu’un étape a été complétée.
  • Le typist est la seule personne de l’équipe qui connaît un sujet et les autres n’arrivent pas à le guider, le coach demande à quelqu’un d’autre de prendre le rôle de typist, pour que l’information circule à travers plusieurs personnes.
  • L’équipe entière ne connaît pas une partie du code, le coach demande qui connait cette partie, et demande à cette personne si elle peut venir temporairement les aider.
    • Si ça arrive trop souvent, le coach en parle avec le manager pour trouver une solution plus pérenne.

8 - Retrospectives

• Chaque session de 2 heures doit contenir une rétrospective de 15 minutes à la fin, c’est l’occasion de réfléchir à comment améliorer les sessions suivantes.
• En tant que coach, il vaut mieux avoir des stylos, ou un template de rétro (pour le remote) déjà prêt.
• Il vaut mieux varier les types de rétrospectives, voilà des exemples :
  • On donne 5/10 minutes pour que chacun écrive des observations sur des post-its, puis on lit les observations à haute voix.
    • On peut marquer notre accord avec certains post-its.
    • Si un post-it donne lieu à une discussion trop longue, on la décale à plus tard.
  • On donne du temps pour que chacun écrive des post-its à propos de 3 catégories : “Ce que j’ai aimé”, “Ce que j’ai appris”, “Ce qui a manqué”.
    • Chacun lit ses post-its, ce qui peut donner lieu à de courtes discussions.
  • On demande à chacun de dire une chose qu’il a trouvé bonne pendant cette session, l’idée étant de favoriser les bons comportements.
• Le coach doit aussi faire une sorte de rétrospective pour lui-même, en écrivant de petites notes privées après chaque séance :
  • Noter où en étant l’équipe à la fin de la séance pour s'en rappeler la prochaine fois.
  • Noter des choses pour pouvoir faire un rapport au management à la fin.
  • Noter des décisions de design qui ont été prises, telle ou telle personne qu’on devrait encourager à parler, des éléments spécifiques qu’il faudrait travailler la prochaine fois.
• La rétrospective est une compétence qui s’apprend, à force de pratiquer, l’équipe va être de plus en plus attentive à ce qui se passe pour pointer ce qui va ou ne va pas.

9 - Remote Ensembles

• Il est important de voir les visages des membres de l’équipe, ça permet de véhiculer les émotions.
  • Si on en a la possibilité, ça peut être pas mal d’avoir le code sur un écran, et les visages sur un autre écran pour pouvoir alterner entre les deux souvent.
• La prise de parole doit être régulée consciencieusement.
  • Il faut faire attention à ce que les gens ne se parlent pas l’un par dessus l’autre, et modérer leurs interventions en particulier s’ils ne sont ni navigator ni typist.
  • On peut demander à lever la main si le besoin s’en fait ressentir.
  • Si un sous-groupe veut avoir une discussion à côté, ils peuvent soit le faire dans le chat, soit le partager avec tout le groupe.
• Il faut absolument faire les pauses, elles sont d’autant plus nécessaires en remote.
• Dans le cas où on ne dispose pas d’outil collaboratif en direct comme VSCode LiveShare, on peut utiliser une branche commune où chaque typist commit et push, puis le suivant pull et commit par dessus avant de push etc.
  • Dans le cas où le processus de changement de typist deviendrait trop lent, il vaut mieux garder un rythme de changement de navigator élevé, et diminuer seulement le rythme de changement de typist.
• Dans le cas où on aurait des problèmes de réseau, le bon compromis est de faire en sorte que le typist n’ait pas de lag vis-à-vis de l’éditeur, et que le lag soit plutôt entre l’éditeur et les non-typists.
• Pendant les phases de discussions de design, l’équipe a besoin d’un outil graphique pour représenter des schémas. Ça peut être une personne qui dessine en local, ou encore un outil collaboratif si ça marche par rapport au réseau.
  • Même chose pour les rétrospectives : il y a les outils collaboratifs qui peuvent poser des problèmes de réseau, et sinon il y a soit le chat, soit les outils locaux.

Part II - Learning Hours

• Emily conseille de créer ses propres supports d’apprentissage. Et même si on s’inspire de supports existants, il faut se les personnaliser pour se les approprier.

10 - Explaining Why you should hold a Learning Hour

• L’idée que l’apprentissage doit se faire au travail plutôt que sur son temps libre n’est pas forcément partagée par tous. Emily donne quelques arguments pour défendre le fait qu’il faille passer 1 heure par jour de son temps de travail en apprentissage.
  • Les développeurs doivent apprendre tout au long de leur carrière, sinon ils vont rester peu efficaces malgré l’expérience, et même finir par avoir des connaissances datées.
  • Faire une heure d’apprentissage par jour permet de normaliser la pratique sous forme d’habitude, et d’être sûr de globalement ne pas la louper en cas d’absence.
  • Le fait que le temps d’apprentissage soit très régulier permet de mettre en pratique sur le code de production entre chaque petite session d’apprentissage.
• Quand on sait programmer mais qu’on ne connaît pas le TDD, apprendre le TDD va faire perdre du temps au début le temps de le maîtriser, puis permettra d’aller bien plus vite.
  • C’est comme apprendre une nouvelle technique de ski : on connaît le chasse neige qui nous permet d’avancer mais qui n’est pas très performant, mais quand on apprend la nouvelle technique plus performante, au début on est plus lent qu’avec le chasse neige, et c’est seulement après plusieurs essais qu’on accélère.
  • Il ne faut surtout pas abandonner dès le début, sinon on restera avec la technique initiale qui est peu performante même si on la maîtrise déjà.
  • Le fait d’avoir un groupe et un coach, et de s'entraîner d’abord sur des katas avant de passer au code de production, permet d’avancer pas à pas et d’avoir moins de risques d’abandonner.
• Emily fait en général les learning hours avec les équipes qu’elle coach, et les donne parfois à plusieurs équipes en même temps quand elles partagent les mêmes problématiques techniques.
  • Elle conseille de laisser l’invitation ouverte pour des personnes extérieures à l’équipe, ou ayant des rôles non codeurs, et aussi aux futurs coachs qui veulent voir comment ça se passe.

11 - The Theory and Practice of Teaching and Learning

• L’objectif le plus important des sessions d’apprentissage est dans quelle mesure les apprenants pourront mettre en pratique leur apprentissage.
• Le coach doit d’abord parler aux membres de l’équipe, et jeter un œil à leur code, pour avoir une idée de leurs connaissances, et adapter les learning hours en conséquence.
• Emily met en avant le bloom model pour l’apprentissage, créé par Benjamin Bloom dans les années 50.
  • Il met en avant 6 catégories d’apprentissages :
    • 1 - Se rappeler
    • 2 - Comprendre
    • 3 - Appliquer
    • 4 - Analyser
    • 5 - Evaluer
    • 6 - Créer
  • Chaque catégorie est associée à un verbe, par exemple si on veut avancer sur l’apprentissage de l’approval testing, on peut demander de :
    • Se rappeler : Décrire les caractéristiques de l’approval testing.
    • Comprendre : Comparer l’approval testing et l’assertion-based testing.
    • Appliquer : Utiliser le framework d’approval testing pour écrire des tests.
  • On peut utiliser les catégories du bloom model pour classer les objectifs d’apprentissage, en commençant par les 3 premiers, puis en passant aux 3 derniers une fois que les 3 premiers sont au point.
• Un autre modèle dont Emily s’inspire est le 4C model de Sharon Bowman, qui met en avant que chaque personne vient avec son background et ses motivations, et que l’apprentissage doit l’utiliser pour s’y greffer.
  • Elle conseille le livre de l’auteur Training from the back of the Room.
  • Le modèle implique de diviser le cours en 4 parties :
    • Connect : rassembler les apprenants et les faire collaborer.
    • Concept : donner de nouvelles informations au groupe.
    • Concrete : pratiquer dans des exercices concrets.
    • Conclusions : laisser les apprenants consolider leurs connaissances.
• Shanon Bowman a aussi écrit le livre Using Brain Science to Make Training Stick, qui explique comment créer des cours efficaces pour l’apprentissage selon la science.
  • Bouger est plus efficace que de rester assis. Il faut idéalement faire en sorte que les élèves bougent toutes les 10/15 minutes, par exemple en faisant en sorte que le typist doive s’asseoir sur une chaise particulière à chaque rotation.
    • En cas de session remote c’est plus compliqué de les faire bouger, il faut essayer de prendre au moins des pauses régulières.
  • Parler est plus efficace qu’écouter. Parler renforce la mémoire, et permet d’avoir du feedback. C’est typiquement ce qu’on fait en pair ou ensemble programming.
  • Les images sont plus efficaces que les mots. Il vaut mieux démontrer visuellement quelque chose que de l’expliquer.
    • Si on ajoute en plus des émotions aux images, la mémorisation sera d’autant plus efficace.
  • Écrire est plus efficace que lire. On se concentre beaucoup plus et on s’investit alors physiquement. On peut demander aux apprenants d’écrire des notes, des conclusions etc.
  • Court est plus efficace que long. Il vaut mieux diviser la learning hour en morceaux de 10 à 20 minutes, ponctués de pauses de 1 à 2 minutes où le groupe fait autre chose, par exemple discuter ce qu’on vient de voir, poser des questions, noter des observations etc.
  • Varié est plus efficace que constant. Il faut varier les situations et les activités pour générer des émotions et créer de la surprise. Par exemple, en plein TDD en pair, on demande à tout le monde de passer au vert dans la minute, puis de s’échanger le code entre pairs.
• On peut diviser les techniques en micro-compétences, comme le fait de diviser le TDD en l’identification du prochain test, l'écriture d’un test, le refactoring etc. Et on peut alors les travailler isolément. On appelle ça la deliberate practice.
  • On va par exemple travailler la capacité à identifier de la duplication comme sous-compétence du refactoring, pour être ensuite plus efficace sur le TDD.
  • L’idée c’est d’identifier les micro-compétences sur lesquelles les élèves ont du mal, et les cibler spécifiquement.

12 - Sample Learning Hours

• Dans ce chapitre Emily propose des plans pour 10 learning hours successifs autour de la thématique du TDD. Elle propose de les imprimer pour s’en inspirer.
• 1 - Travail incrémental en petites étapes
  • Vu qu’il s’agit de la 1ère session, la partie connect et le travail en pair sont importants.
  • On va expliquer le cycle du TDD, expliquer pourquoi on écrit les tests avant, et travailler sur une fondation pure toute simple.
  • Etapes :
    • Connect (10 mn) : on divise l’équipe en pairs, et on leur demande de discuter entre eux des avantages du TDD. Après 3 minutes chaque paire donne un avantage.
    • Concept (15 mn) : le coach prend la main, et montre comment coder un exemple simple en TDD (ici le kata Leap Years).
    • Concrete (20 mn) : on organise le groupe en paires ou en ensemble, et on leur demande de coder le même kata à leur tour en TDD.
    • Conclusions (10 mn) : on demande à l’équipe de synthétiser ce qu’ils ont compris du TDD en une phrase ou deux sur un post-it (ou dans un document partagé en ligne).
• 2 - Sélectionner et ordonner les tests
  • On part du kata FizzBuzz, sans avoir la liste complète des tests à écrire.
  • On va expliquer pourquoi faire un cas d’usage “todo list”, le coder en TDD, et décrire la technique de triangulation.
  • Etapes :
    • Connect (5 mn) : on donne une liste d’étapes du TDD aux élèves, et on leur demande de mettre dans l’ordre. Après une minute, on leur demande d’échanger avec le voisin, et de comparer. Puis une minute de plus et on leur demande s’ils ont des questions.
    • Concrete (10 mn) : on explique le kata FizzBuzz, et on demande au groupe de donner une liste de tests à écrire.
      • Dans le cas où ils proposent une fonction impure qui affiche du texte, on leur dit qu’il vaut mieux une fonction pure qui retourne le texte et qui sera testable, puis dont le résultat sera affiché.
      • On leur demande dans quel ordre il faudrait implémenter ces tests.
    • Concept (10 mn) : on prend la main, et on montre comment implémenter quelques tests en TDD, en montrant la technique de la triangulation.
    • Conclusions (2 mn) : on demande au groupe de décrire ce qu’est la triangulation dans un document.
    • Concrete (30 mn) : on demande au groupe de se mettre en pairs, et de recoder le kata FizzBuzz, en alternant de navigator toutes les 4 minutes.
      • Si certains ont fini avant, on leur donne des règles plus complexes à implémenter.
    • Conclusions (5 mn) : les élèves se mettent en pairs, et discutent de ce qui a été facile ou difficile dans l’exercice, et ce qu’ils ont trouvé utile ou ont appris.
• 3 - La règle d’or du TDD
  • Il s’agit dans cette séance d’essayer d’ancrer qu’il ne faut écrire du code de production que s’il vient faire fonctionner un test déjà existant, et donc ne designer que le code nécessaire et pas plus.
  • Etapes :
    • Connect (5 mn) : on demande au groupe de donner 5 choses à se souvenir à propos du TDD. L’une des personnes devrait parler de driver le code à partir des tests. On va s’appuyer sur ça pour la suite.
    • Concept (10 mn) : on introduit la règle d’or du TDD, on l’écrit quelque part et on l’encadre : do not write any production code until you agave a failing test that requires it.
    • Concrete (30 mn) : on met les gens en pairs, et on leur demande de faire le Shopping Basket kata. Ils doivent au moins constituer une todo list de tests, écrire un premier test, et du code. On leur demandera de le finir à la maison.
    • Conclusions (5 mn) : on demande au groupe de discuter de ce qu’il pense de cette règle en groupe ou en pairs.
• 4 - Le nommage des refactorings
  • On va introduire le sujet du refactoring, avec pour but d’introduire la notion, parler de la liste des refactorings, et utiliser extract function.
  • Etapes :
    • Connect (5 mn) : on demande à chacun d’écrire le nom des refactorings qu’il connaît pour ensuite mettre en commun. Il est possible qu’ils n’en connaissent aucun, dans ce cas on va en donner certains qu’ils utilisent sans en connaître le nom, comme rename variable, extract interface.
    • Concept (5 mn) : on donne la définition du refactoring de Martin Fowler, en expliquant certains points.
    • Concrete (10 mn) : on demande au groupe de regarder le code du kata Tennis1, et de donner des idées de refactoring, en leur disant le nom de ces refactorings dans la dénomination de Fowler.
    • Concept (10 mn) : le coach démontre l’application d’extract function sur le code de Tennis1.
    • Concrete (25 mn) : on demande au groupe de refaire ces extractions, et de continuer à améliorer le code s’ils ont du temps.
    • Conclusions (5 mn) : on demande au groupe de définir le refactoring, et d’écrire ce qu’ils en retiennent.
• 5 - Malentendus sur le refactoring
  • Le but est de mieux comprendre le but du refactoring, et de voir le refactoring rename variable.
  • Etapes :
    • Connect (15 mn) : on prépare des propos controversés ou faux sur le refactoring, et on les présente au groupe. On leur demande de les discuter et de dire s’ils sont vrais ou faux.
    • Concept (5 mn) : on explique le but du refactoring qui est de faire en sorte que le code soit plus facile à comprendre et modifier. C’est aussi une technique centrale pour permettre le design incrémental.
    • Concrete (30 mn) : on demande au groupe de refactorer le code du kata Tennis3. On leur parlera de rename variable qu’ils vont sans doute utiliser.
    • Conclusions (5 mn) : on demande au groupe de répondre par écrit à la question “Quand devez-vous refactorer ?”.
• 6 - Faire une liste de tests
  • Il s’agit d’apprendre à constituer une liste de tests initiale pour débuter une démarche en TDD.
  • Etapes :
    • Connect (5 mn) : Emily propose un jeu du type “Le livre dont vous êtes le héros”, où il s’agit de faire un choix et voir ensuite les conséquences. On prépare un tel jeu à un seul choix à propos du comportement initial en TDD, et avec les conséquences de chaque choix de l’autre côté, et on propose au groupe d’y jouer.
    • Concept (10 mn) : on va chercher les katas étudiés dans les séances précédentes, et regarde la liste des tests qu’on avait constituée. On demande ensuite au groupe quelles caractéristiques ont ces listes en commun. On les écrit ensuite pour tout le monde.
    • Concrete et Conclusions (40 mn) : on demande au groupe de se mettre en pairs, et on leur donne les spécifications du kata MarsRover pour qu’ils constituent une liste de tests initiale.
      • On répond à leurs questions en tant qu’expert métier.
      • Ils écrivent d’abord 4 à 6 idées de tests en 10 minutes.
      • Ensuite, ils montrent leurs idées à un autre groupe et en discutent, en essayant d’avoir des améliorations.
      • S’il reste du temps, ils peuvent faire la même chose sur d’autres katas.
• 7 - Arrange, Act, Assert
  • On va cette fois travailler sur la manière d’écrire un test, dans sa structure et sa lisibilité.
  • Etapes :
    • Connect (15 mn) : on prend les tests du kata Mars Rover, et on demande au groupe lesquels sont le plus susceptibles de contenir des bugs.
    • Concept (5 mn) : on explique que le code de test doit être le plus simple possible pour permettre de valider le code de production, sinon on devrait écrire des tests pour le code de test.
      • Pour faire un parallèle, on peut citer Brian Kernighan qui dit “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
      • On parle aussi de la structure Arrange, Act, Assert qui aide à avoir des tests simples et clairs.
    • Concrete (30 mn) : on demande au groupe de reprendre les tests du kata MarsRover qu’ils ont travaillé à la séance précédente, et de les améliorer sous forme Arrange, Act, Assert.
    • Conclusions (5 mn) : on demande au groupe de former des pairs, et de discuter la question : pourquoi le code de test devrait-il être plus simple que le code de production ?
• 8 - Commencer par l’assertion
  • Le but est de voir pourquoi en TDD il est préférable d’écrire un test en commençant par le bas, par la partie assert. Par exemple, la partie arrange n’aura alors que ce qu’il faut.
  • Etapes :
    • Connect (10 mn) : on prépare des post-its avec des concepts que le groupe a déjà vus, puis on demande à une personne différente à chaque fois de choisir un concept et de l’expliquer, en le guidant avec des questions si besoin.
    • Concept (5 mn) : on choisit un kata où il y a besoin de pas mal d’arrange, par exemple MarsRover, et on écrit un test en commençant par l’assert, puis act, et enfin arrange.
    • Concrete (30 mn) : on demande au groupe de s’exercer à écrire des tests en commençant par la fin, par exemple sur le kata MarsRover.
    • Conclusions (10 mn) : on remet les post-its de la partie Connect, et on demande au groupe en pairs d’écrire quel effet a le fait de commencer par l’assert, par rapport à ces thématiques.
• 9 - Une fonction à la fois
  • On va driver le code vers des fonctions chacune testables.
  • Etapes :
    • Connect (5 mn) : on présente une liste de phrases au groupe, et on leur demande de trouver lesquelles ont un rapport avec la thématique “overdesign“.
    • Concept (10 mn) : on prend le kata Yatzy qu’on explique, puis on demande au groupe s’ils voient une manière de faire une liste de tests. En général ils vont proposer de regrouper les exemples par catégories.
    • Concept (10 mn) : on prend le rôle de navigator en ensemble, en faisant tourner seulement le typist, et on drive le code en TDD jusqu’à arriver à ce que le code principal appelle des fonctions annexes pour chaque catégorie, qu’on va tester à part.
    • Concrete (30 mn) : on fait tourner le navigator, pour que le groupe s’approprie la suite du code et termine l’exercice.
    • Conclusions (5 mn) : on se met en pairs, et on discute de la manière dont on a divisé le problème en plusieurs morceaux, si ces morceaux sont testables, et s’il y a overdesign.
• 10 - Démo inspirante
  • Le but ici va être de démontrer ce que donne le TDD appliqué par une personne expérimentée.
  • Etapes :
    • Concept (45 mn) : c’est le coach qui va faire la démonstration. On choisit un kata qui ressemble à leur code et contient des problématiques qu’ils ont (ou encore mieux : du code extrait de leur codebase), et on code en TDD à partir de ça.
      • Il faut s'entraîner à l’avance pour que ce soit fluide, ou encore s’enregistrer pour commenter sa propre vidéo.
    • Conclusions (10 mn) : on demande au groupe d’écrire des observations sur des post-its, puis de les lire.

13 - Learning Topics

• Emily regroupe ses learning hours autour de thématiques majeures, et elle fait en général 2 ou 3 séances avant de changer de thématique.
• Elle donne la liste de ses thématiques, avec des exemples de séances :
  • Small steps : on travaille l’aspect itératif du TDD.
    • Les étapes du TDD : red, green, refactor.
    • Faire souvent des commits.
    • Revert sur un test rouge imprévu.
    • Designer incrémentalement une fonction.
    • Designer incrémentalement une classe.
  • Refactoring safely : on travaille les techniques citées dans le livre Refactoring de Martin Fowler.
    • Détecter les code smells.
    • Enlever la duplication.
    • Améliorer le nommage.
    • Combiner des refactorings pour un changement plus grand.
  • Legacy code : on travaille le code legacy pour le rendre testable et pouvoir travailler avec.
    • Le code coverage pour aider à créer les tests.
    • L’approval testing.
    • Le mutation testing.
  • Testable design : on travaille le design qui permet d’obtenir du code testable et refactorable.
    • Les fonctions sont faciles à tester.
    • L’inversion de dépendance.
    • Les heuristiques de design.
    • Avoir des niveaux d’abstraction cohérents.
  • Designing tests : on travaille les bonnes pratiques d’écriture de tests.
    • Arrange, act, assert
    • Styles d’assertion.
    • Stubs.
    • Fakes.
    • Mocks et spies.
    • Données de test.
    • Avoir des niveaux d’abstraction cohérents.
  • Double-loop TDD : il s’agit d’avoir un niveau de tests en relation avec les experts métier, qu’on peut appeler BDD, qui donnent ensuite lieu à une boucle de feedback plus rapide qui consiste à coder le détail en TDD, avec des tests à destination des développeurs.
    • Au moment de la pratique, une partie de l’équipe joue le rôle des experts métier, et l’autre des développeurs. Emily conseille de prendre des exemples du code de production de l’équipe.
  • Agile : on travaille la notion d’agilité et de DevOps, au travers de jeux.
    • Emily a réalisé le jeu pipeline game (opens in a new tab), qui permet de choisir la liste d’étapes de sa pipeline de continuous delivery.
    • Elle cite Kanban dot game (opens in a new tab), tiré du livre Kanban in Action de Marcus Hammarberg et Joakim Sunden. Ca permet de comprendre l’intérêt de limiter les tâches en parallèle.
    • Elle propose d’autres exemples sur le site Tasty Cupcakes (opens in a new tab).
• On peut bien sûr s’inspirer des thématiques d’Emily, mais on doit aussi faire les nôtres, qui pourront être basés sur nos préférences et compétences spécifiques.

14 - Remote Learning Hours

• Emily présente quelques outils pour les séances de learning hours en remote.
  • Cyber-dojo permet d’éditer du code collaborativement, et au coach de voir ce que font les élèves. On peut héberger son propre serveur.
  • VNC pour se connecter à une machine Amazon EC2 ayant un gestionnaire de fenêtre graphique. Tous les participants peuvent alors contrôler la machine à distance.
  • Les participants peuvent utiliser leur machine locale, auquel cas il faut penser au temps de setup à faire de préférence avant la session, et le switch qui peut être fait par des commit/push successifs.
• Pour ce qui est des rétrospectives, Emily a du mal à faire écrire des notes virtuelles aux participants. On peut au moins leur faire dire les choses à haute voix, et l’écrire nous-mêmes.

Part III - Samman Coaching Engagements

• La plupart des coachs qu’Emily connaît sont des freelances qui travaillent avec plusieurs organisations pendant des mois ou années.
• Il faut travailler sur la prospection, l’aspect commercial, marketing etc. pour trouver des missions.

15 - Finding an Organization and Teams to Engage with

• Parmi les différents types entreprises clientes, il peut y avoir :
  • L’entreprise qui recherche l’excellence technique : si le responsable est sensible à l’amélioration continue, au fait d’avoir un haut niveau de qualité qui permette une efficacité et une rétention des développeurs, alors il pourra être sensible au coaching technique.
  • L’entreprise qui croule sous les bugs : plutôt que de simplement aider à redéfinir la stratégie de tests, il s’agit d’expliquer que l’important est que les développeurs utilisent les bonnes techniques et pratiques pour qu’il y ait moins de bugs introduits dans le code changé.
    • Pour convaincre des responsables non techniques, on peut notamment parler leur langage en parlant du pourcentage du temps passé par les développeurs sur les bugs, et en proposant de le diminuer pour diminuer les coûts perdus.
  • L’entreprise avec une codebase vieille de 20 ans : le code est complètement sclérosé, ils essayent de diviser la codebase en microservices pour pouvoir y refaire des modifications.
    • On peut leur proposer de reprendre le contrôle du code en repartant par de plus petites étapes : en ajoutant du test incrémentalement, refactorant le code petit à petit, et construisant une compréhension collective avec l’ensemble programming.
  • L’entreprise sous l’eau : entreprise qui voulait améliorer l’efficacité de ses équipes, et leur redonner du moral, mais qui n'arrivait pas à trouver une demi journée dans le planning de l’équipe qui était overbookée. Dans ce cas il vaut peut être mieux annuler : s’ils n’arrivent pas à libérer une demi journée, ils ne pourront pas libérer de quoi faire un coaching correct.
• Globalement dans les exemples qu’elle donne, Emily a trouvé ses missions via des gens qu’elles connaissait déjà, ou qui l’ont remarquée à des événements publics comme des conférences, ce qui souligne l’importance du réseau.
• Il faut laisser une bonne impression auprès des clients, pour être ensuite recommandé.
• Il faut adapter son sales pitch au type de public qu’on a en face : par exemple une personne technique ne sera pas sensible à la même chose qu’un CEO.
  • On peut décrire la méthode Samman en disant qu’il s’agit d’aider l’équipe à augmenter en compétence en pratiquant ensemble et avec le coach.
  • On peut mettre en avant les effets attendus : réduction de la dette technique, meilleurs tests, meilleure communication et alignement au sein de l’équipe.
• Emily donne sa proposition de coaching habituelle, qu’elle envoie sous forme de document, de slides, ou même de vidéo où elle s’enregistre en train de parler (ce qui marche assez bien).
  • Elle propose de coacher 2 équipes sur une période de 3 semaines, à hauteur de 10 jours sur les 15 jours ouvrés. Ensuite elle laisse les équipes cogiter sur ce qu'elles ont appris pendant 3 semaines seuls, puis elle revient pour une autre session de 3 semaines. Et elle peut alterner comme ça jusqu’à ce que les équipes se sentent suffisamment compétentes.
  • Chaque jour de coaching contient 2 heures d’ensemble working avec chaque équipe, et une heure de learning hour avec chaque équipe ou les deux réunies.
  • Avant de commencer les 3 semaines de coaching (au moins une semaine avant), elle fait quelques meetings de kick off, pour déterminer les problématiques de l’équipe et apprendre à les connaître. Elle s’en servira pour planifier le coaching.
  • Pendant les semaines de coaching, les équipes doivent prévoir de réduire le nombre de tâches à un tiers de ce qu'elles produisent habituellement.
• Questions qui seront posées par les clients :
  • Pourquoi ne pas faire plus d’ensemble working par jour avec chaque équipe ?
    • Les équipes n’ont généralement pas d’expérience de l’ensemble programming, elles vont donc être déconcertées et fatiguées au début.
  • Et si l’entreprise n’a qu’une équipe de développement ?
    • Il vaut mieux éviter de dépasser 2 heures d’ensemble working avec une équipe qui ne sait pas travailler comme ça.
    • On peut proposer des demi-journées de coaching, et faire soit autre chose pendant le reste du temps, ou alors faire du pair-programming avec les membres de l’équipe le reste du temps.
  • Et si l’entreprise a 10 équipes, lesquelles on coach ?
    • On pourrait faire venir un autre coach en même temps.
    • Ou alors on priorise les équipes :
      • qui sont les plus enthousiastes au coaching.
      • qui ont été constituées depuis peu, et auraient bien besoin d’activités de groupe pour se constituer en tant qu’équipe.
      • qui ont spécifiquement besoin d’aide pour faire face à leurs problèmes.
  • Pourquoi l’équipe produirait moins pendant la durée du coaching ?
    • Même si une bonne partie du temps est consacrée à travailler sur les tâches de production de l’équipe, le focus reste l’apprentissage et donc la productivité en elle-même sera moins élevée.
    • L’idée est de progresser dans l’utilisation de techniques plus efficaces,e t donc de ralentir la production, pour être plus rapide dans la production par la suite.
  • Et si l’équipe travaille avec plusieurs langages de programmation ?
    • A priori ça ne pose pas de problèmes puisqu’on va travailler en ensemble, et donc avec les compétences de l’ensemble de l’équipe.
    • Si ça pose problème, on peut tenter de diviser l’équipe en plusieurs groupes, un pour chaque langage.
  • Quelle est la différence entre un coach Samman et un Tech Lead ou un Architecte ?
    • Un Tech Lead fait partie d'une équipe, délivre du code comme les autres, mais a un rôle de responsabilité plus important où il s’assure que les parties les plus difficiles sont gérées, que les juniors montent en compétence etc.
    • Un architecte va en général aider plusieurs équipes à gérer leur architecture.
    • Un coach Samman est là pour aider l’équipe à gagner en compétences techniques. Par contre, il ne contribue pas au code de production ni aux décisions d’architecture.
• Quand on est face à des organisations ayant des centaines d’équipes :
  • Soit il s’agit d’organisations “élite” au sens d’Accelerate, c'est-à-dire que chaque équipe est responsable d’un module indépendant, avec un accès à leurs utilisateurs. Dans ce cas on peut les aider à s’améliorer équipe par équipe, en utilisant les métriques de feedback qu’ils ont déjà pour constater les progrès.
  • Soit il s’agit d’une organisation qui est à la traîne en termes de maturité technique et organisationnelle, auquel cas chaque équipe sera responsable de morceaux de code avec une forte interdépendance avec les autres. On peut toujours les aider à gagner en niveau, et améliorer leur code, mais ce ne sera pas significatif par rapport à ce dont aurait besoin l’organisation.
  • Dans les deux cas, Emily propose de commencer par quelques équipes, et de constater les résultats pour agir plus conséquemment ensuite :
    • Coacher 2 équipes pendant 3 semaines, puis 2 autres équipes pendant 3 semaines, et encore 2 autres pendant 3 semaines.
    • On refait ensuite une session de 3 semaines avec chaque paire d'équipes. Et on arrive à 5/6 mois de coaching.
    • On fait le point et on constate les progrès, puis on fait venir d’autres coachs, à la fois des apprentis, et des coachs pour prendre d’autres équipes.
• Une fois qu’on a convaincu l’organisation, il faut discuter du prix et finaliser le contrat.
  • Il y a une part de négociation pour le prix de la prestation. Emily conseille de déléguer la négociation à une autre personne qui négocie mieux.
  • Elle conseille le livre Secrets of Consulting de Gerry Weinberg, dont elle tient le conseil sur la délégation de la négociation.
• Il faut identifier le (ou les) sponsor(s), c'est-à-dire la personne qui approuve le budget ou décide de nous faire venir. Il faudra le contacter assez rapidement pour valider certains points, et initier une bonne relation :
  • Les jours où le coaching aura lieu, les équipes qui vont être coachées, le moyen de contacter les équipes.
  • Il peut aussi nous aider à organiser les kick off meetings avec les équipes.

16 - Beginning Coaching with a New Organization

• Emily présente des conseils sur la manière d’organiser les kick off meetings pour faire connaissance avec l’équipe.
• Il faut trouver une occasion de se présenter : soit à un all-hands où on aurait 10 à 20 mn, soit à une réunion de guilde etc. en général le sponsor nous aidera à trouver l’occasion.
  • On peut expliquer notre parcours, notre méthode, et en quoi ce sera utile pour les équipes.
  • Il faut aussi laisser de la place pour des questions.
  • L’important est qu’on fasse bonne impression, pour que les équipes aient envie d’être coachées.
• Ensuite, Emily prévoit 2 heures de kick-off meeting avec chaque équipe qui sera coachée. Elle donne l’agenda du meeting à l’avance et demande un peu de préparation à l’équipe.
  • Team introduction (10 mn) : les membres de l’équipe se présentent à tour de rôle, en parlant d’eux, et en particulier de leur expérience dans le développement. On peut noter des informations pour avoir une idée du public.
  • Architecture overview (15 mn) : le but est d’avoir une petite idée de l’architecture globale et comment le produit de l’équipe s’inscrit dedans. On peut typiquement leur demander de préparer quelque chose à l’avance.
    • On peut leur parler du modèle C4 de Simon Brown, et leur demander un diagramme de context et de container.
    • On veut aussi savoir s’il y a un mécanisme de build de CI et de CD, un mécanisme review ou d’autres procédures. S’il n’y a pas de build de CI, on le mettra en place avec eux parce que c’est indispensable pour pouvoir profiter des feedbacks rapides.
  • Issues in the codebase (45 mn) : on leur demande de préparer ou de montrer sur le moment quelques exemples de code. On s’en servira pour avoir une idée de ce qu’il y aura à travailler, et s’il nous faut creuser des outils spécifiques.
    • Un test unitaire typique, un test d’intégration typique.
    • Du code qu’ils estiment bien designé.
    • Du code qui n’a pas de tests, et pour lequel ils en aimeraient.
    • Du code connu pour être buggué.
    • Du code récent représentant leur manière actuelle d’en écrire.
  • Structured discussion (30/40 mn) : le but ici est d’avoir l’avis de l’équipe sur les problèmes les plus importants qu’ils ont, et d’adapter le coaching en fonction de ça.
    • Pour les faire parler, y compris des sujets vraiment problématiques, on peut mener la discussion sous forme de Lean Coffee (opens in a new tab), en utilisant le jeu Speedboat (opens in a new tab), ou encore la Liberating Structure TRIZ (opens in a new tab).
    • Emily fait une version modifiée du Lean Coffee où chacun écrit des points qui ne vont pas sur un document local, puis tout le monde copie le contenu dans un document partagé en même temps.
      • Emily y ajoute une liste de problèmes qu’elle rencontre habituellement (qu’elle donne).
      • Ensuite on lit les possibilités, on en regroupe éventuellement certaines, et chacun va voter parmi toutes les possibilités, pour les 5 problèmes principaux.
      • On va alors prendre les 3 ou 4 problèmes les plus votés, et les discuter pendant 5 à 10 minutes chacun.
  • Takeaways (5 mn) : on conclut, et une fois le meeting terminé, on reprend nos notes, et on y met de l’ordre selon ce qui est frais dans notre tête.
    • Emily conseille d’organiser les notes avec un cahier, ou un document virtuel par équipe, sur lequel on reviendra tout au long du coaching.
• Quelque temps après le kick off meeting (quelques jours ou semaines après, et quelques jours ou semaines avant le début du coaching), Emily tient un chartering workshop, où il va s'agir de délimiter les contours du coaching avec l’équipe.
  • Résumé des problèmes principaux : on rappelle les problèmes principaux sélectionnés à la fin du kick off meeting, et on présente des thématiques de coaching que nous pouvons mettre en place pour y répondre.
    • Dans le cas où on n’a pas de réponse à certains problèmes, on le leur dit clairement.
  • Discussion structurée : on prend 90 à 120 minutes, structuré en morceaux de 20 minutes, pour aborder les thématiques de coaching qu’on propose à l’équipe. On présente d’abord avec des slides et une démo, et ensuite on s’arrête de parler pour recueillir l’impression de chaque membre de l’équipe.
  • Parmi les thématiques possibles de cette discussion :
    • Le travail collaboratif en équipe : on présente l’intérêt que peut avoir le travail en pair ou en ensemble, et la manière dont ça marche. Puis on demande à l’équipe si elle a déjà essayé, et si elle serait intéressée.
    • Développement incrémental : le TDD permet de développer itérativement, avec des feedbacks rapides. On demande à l’équipe ce qu’elle en connaît, on montre une démo, et on demande si ça les intéresserait.
    • Refactoring : on demande s’ils souffrent de dette technique et de code difficile à appréhender. Puis on fait une démo de refactoring , et on leur demande s’ils pensent que ça les aiderait.
    • Design des tests : on peut montrer l’un de leurs tests, et le restructurer dans une version plus lisible, en expliquant que le but est d’avoir un test simple, où les bugs ne peuvent pas se cacher. Puis on leur demande si leurs tests posent problème au moment du refactoring, et s’ils sont faciles à maintenir.
    • Design de code testable : on montre du code ayant une dépendance le rendant non testable, et on montre comment le rendre testable. Puis on leur demande s’ils aimeraient apprendre ce genre de technique.
    • Ajouter des tests à du code existant : on peut demander si l’équipe a peur de casser son code en le changeant, puis montrer comment ajouter des tests à du code existant, par exemple en utilisant l’approval testing. On peut aussi montrer l’utilisation du mutation testing. Et enfin on peut demander si ce genre de technique les intéresserait.
  • A la fin de la session, on fait comprendre qu’ils ont le choix : on choisit avec eux les thématiques de coaching qui vont leur être utiles, et on attend d’eux qu’ils soient investis pendant plusieurs semaines.
    • On écrit un résumé de l’accord mutuel entre l’équipe et le coach.
  • Dans certains cas, on tombe sur des équipes qui n’ont pas envie d’être coachées. On peut le savoir en amont grâce au management qui nous en a parlé, mais il peut aussi arriver qu’on le remarque pendant les kick-off meetings. Emily donne des exemples de situations et ce qu’elle fait pour y remédier.
    • Les seniors trop occupés : une fois Emily est tombée sur une équipe où seule une moitié s’est présentée aux meetings de kick off, puis aux sessions de coaching. Cette moitié c’était les juniors qui étaient délaissés, avec des seniors trop occupés à coder seuls pour tenir les deadlines.
      • Elle a décidé, avec le sponsor, de décaler le coaching à un moment où il y aurait moins de pression. Un des buts du Samman coaching est d’aider toute l’équipe à collaborer, et on ne peut pas le faire avec seulement une partie de l’équipe.
    • L’équipe trop avancée : dans l’une de ses missions, Emily a eu affaire à une équipe de développeurs connaissant déjà le TDD et l’utilisant au quotidien. Par contre ils n’avaient jamais travaillé en pair ou en ensemble.
      • Elle leur a alors proposé de les former sur l’ensemble programming, et des techniques avancées comme l’approval testing, le property-based testing, l’utilisation du code coverage, et les techniques de travail du code legacy.
      • L’équipe a accepté, et elle a réussi à négocier du temps payé pour préparer des cours spécifiques pour ce niveau avancé.
    • L’équipe ne fait que de la config : Emily a eu affaire à une équipe qui déclarait ne pas écrire de code. Elle a pu être en contact avec un des membres de l’équipe porté sur le TDD, avec qui elle a pu explorer un cas d’usage possible pour travailler sur du code, mais l’activité principale de l’équipe était effectivement de configurer des clusters Kubernetes.
      • Elle a donc décidé de reporter le coaching de cette équipe à plus tard, quand ils auront plus de code à faire.
    • L’équipe gère un code trop legacy : l’une des équipes était sur la migration d’un code de C de 30 ans vers un autre compilateur. Le TDD ne leur servirait pas vraiment puisqu'ils n’écrivaient pas de nouveau code.
      • Emily leur a proposé de travailler plutôt sur des techniques de refactoring et de design de test. Elle a pu leur montrer des techniques pour travailler avec le code legacy, et l’ensemble programming a permis du partage de connaissance.
    • Parfois, il est arrivé à Emily de ne pas trouver d’angle pour convaincre l’équipe, ou d’intérêt à le faire. Dans ce cas, elle laisse tomber la mission et passe à autre chose.

17 - Practicalities Before Coaching Begins

• Une fois que l’équipe accepte le coaching, il faut leur demander leurs horaires, leurs meetings importants, pour voir où il est le plus judicieux de placer l’ensemble working et les learning hours.
  • On leur demande de réserver une tâche dans leur prochain sprint planning pour l’ensemble working. Il faudrait quelque chose impliquant du code, et sans deadlines associées.
  • La tâche peut être une tâche courante qu’ils devaient déjà faire, ou encore une tâche spécifique pour améliorer un endroit du code qu’ils vont devoir bientôt toucher, ou qui est buggué.
• Dans le cas où on est en présentiel, il faut s’assurer d’avoir une grande salle, avec des tables qu’on peut placer côte à côte.
• On commence par utiliser la stratégie habituelle de l’équipe pour intégrer du code, et on essaye d'aller petit à petit vers du trunk based development si possible.

18 - Turn Up the Good

• Après les 10 jours de coaching, Emily conseille de demander du feedback à l’équipe.
  • On peut le faire sous forme de sondage.
  • Et il vaut mieux aussi le faire sous forme de rétrospective, soit en demandant à rejoindre une des leurs, soit en en organisant une pour parler du coaching.
  • Il faut aussi faire le point avec le sponsor.
• Idéalement on avait négocié deux fois 10 jours de coaching initiaux, et c’est après ça qu’on va discuter avec le sponsor la possibilité de continuer.
• Une fois qu’on a mené un coaching avec succès, on peut demander à l’organisation de faire venir un ou deux “coachs visiteurs”, qui pourront apprendre et aussi apporter leur feedback.
• Le réseautage est un pilier du coach freelance, il faut faire en sorte de parler aux gens, se faire des contacts, les aider etc.
  • Déjeuner avec diverses personnes de l’entreprise cliente est un bon moyen de construire son réseau.
    • On peut par exemple être mis en relation avec des managers, des personnes portées sur la qualité de code etc. via notre sponsor.
    • Il vaut mieux déjeuner en 1&1 avec la personne plutôt qu’en groupe, ça permet à la personne de parler plus librement, et donc de construire une meilleure relation.
  • Appeler des personnes de pouvoir au sein de l’entreprise cliente permet d’étendre son réseau.
    • On peut en particulier demander à son sponsor de nous cartographier les personnes importantes de la hiérarchie.
    • On peut les appeler pour se présenter, demander leur avis sur quelque chose, ou leur parler de notre travail.
  • Reporter au sponsor permet d’avoir une bonne relation avec lui, lui montrer qu’on est là et qu’il a bien fait de nous prendre. On peut par exemple :
    • Lui envoyer quelques phrases récapitulatives de chaque jour de coaching.
    • Lui envoyer un email plus long chaque semaine.
    • Caler un meeting de 30 minutes après 3 semaines de coaching.
    • Parler à un meeting régulier où il est là (type daily) pour faire un petit point d’avancement, et célébrer ce qui se passe bien.
  • Contacter les autres coachs de l’entreprise s’il y en a, pour s’aligner.
• Vu qu’on coach pendant 10 jours, répartis sur 3 semaines, on a quelques jours de battement dont on peut profiter pour peaufiner ses compétences, améliorer ses cours etc. C’est aussi l’occasion de laisser l’équipe seule, et voir si elle continue à appliquer ce qu’elle apprend.

19 - A Career as a Samman Technical Coach

• Le pair coaching dans une grande organisation est un excellent moyen de gagner en expérience en tant que coach.
  • On peut notamment préparer et co-présenter les learning hours, et participer tous les deux à l’ensemble working, l’un en tant que facilitateur, l’autre en tant que membre de l’équipe.
  • On peut faire une variante quand le nouveau coach est à l’aise est de se séparer juste pour l’ensemble working. Et après les 3 semaines, on peut réévaluer si on continue en pair ou séparément.
  • Ça se passe souvent quand un coach est déjà installé dans une entreprise, et fait venir ses connaissances. En général, l'entreprise paye les deux au même prix.
  • Il faut absolument penser à faire des feedbacks privés l’un envers l’autre pour progresser.
• Pour pouvoir être coach technique Samman, il faut avoir certaines compétences :
  • La connaissance et l’expérience du TDD, du refactoring, du software design, de la continuous integration, de la conception de tests.
  • La connaissance et l’expérience du pair et ensemble programming.
  • La capacité à faciliter des réunions, et présenter et expliquer des concepts en public.
• Pour progresser dans ces compétences, l’idéal est d’apprendre d’un coach en personne. Mais on peut aussi :
  • Créer un dojo de code avec son équipe.
  • Lire des livres et regarder des vidéos techniques.
  • Assister à des conférences.
    • Ne pas hésiter à parler aux présentateurs ou facilitateurs, leur poser des questions.
    • On peut aussi se proposer pour faciliter une session d’ensemble, et proposer à des coachs d’y participer pour nous donner des conseils.
  • Rejoindre des communautés de pratique ou des meetups internes ou externes.
    • Il existe de nombreux ensembles en remote, auxquels on peut participer gratuitement ou parfois avec quelques frais.
  • Une possibilité peut aussi être d’approcher un coach et de demander à participer en shadow, c’est-à-dire juste regarder la session, sans être payé.
• Emily elle-même a été initiée au coaching Samman par Llewellyn Falco, qui l’a invitée à faire du pair coaching en 2018. Elle a alors cherché des clients, et s’est petit à petit lancée.

20 - Final Thoughts

• Le plus important est : que nos clients nous aiment bien. Il faut nouer des relations pour mener une bonne carrière de freelance.
• L’autre chose à faire c’est de se remettre en question, de parler de ce qu’on fait, et écouter les autres coachs qui parlent de ce qu’ils font.
• Emily conseille d’avoir une ou deux personnes de confiance à qui on parle régulièrement de notre carrière de coach.
• Le Samman coaching va peut être finir par devenir un mouvement notable, l’URL de rassemblement est https://sammancoaching.org (opens in a new tab).

21 - Rerefences

• Développement incrémental :
  • Test-Driven Development: By Example de Kent Beck.
  • TDD de Jason Gorman.
• Refactoring :
  • Refactoring de Martin Fowler.
  • Refactoring to Patterns de Joshua Kerievsky.
• Code legacy :
  • Working Effectively with Legacy Code de Michael Feathers.
• Design testable :
  • Agile Software Development Principles, Patterns and Practices de Robert C Martin.
• Design de tests :
  • Growing Object Oriented Software Guided by Tests de Nat Pryce and Steve Freeman.
• Behavior-Driven Development
  • The BDD Books de Seb Rose et Gaspar Nagy.
• Enseignement :
  • Training from the Back of the Room de Sharon Bowman.
• Autre :
  • Accelerate de Nicole Forsgren.
  • The Phoenix Project de Gene Kim.