En pleine période de covid-19, on se questionne beaucoup sur les possibles impacts qu'aura ce virus sur notre vie de tous les jours, et par conséquent sur nos conditions de travail. Un des sujets qui m'est venu à l'esprit a été : Que vont devenir les pratiques de développement qui se sont mises en place dernièrement chez Bonita ? En effet, on voyait régulièrement, 5 personnes de la R&D se regrouper devant un écran, ils appelaient ça du "Mob programming". Qu'en est-il aujourd'hui, avec les nouvelles règles de distanciation sociale imposées ? J’ai donc proposé à Julien, un de nos développeurs de me parler un peu de "Mob programming", m'expliquer comment c'était avant ? Et ce qu'il en est aujourd'hui ?
Découvrez les réponses que m'a apportées Julien, en commençant par :
C’est quoi le mob programming ?
Le "mob programming", c'est lorsqu'une personne travaille alors que le reste de l'équipe la regarde travailler.
Comment vous est venue cette idée ?
Suite à la présentation “Mob Programming : A Whole Team Approach” de “Woody Zuill” à MixIT 2019, j’ai, comme beaucoup, été premièrement très réfractaire à l’idée de travailler à cinq derrière un écran, c’est souvent dur de changer les habitudes. On peut vite penser que :
“Cela ne paraît pas du tout efficace...”
“C’est techniquement compliqué à mettre en place…”
“Ce n’est pas compatible avec le télétravail…”
J’ai malgré tout été vraiment intrigué, la présentation était très bien faite et très prometteuse. Et après quelques recherches et échanges sur le sujet, je me suis dit qu’après tout, peut-être que la magie pourrait opérer ?
Comment t’as réussi à convaincre l’équipe de se lancer ?
Cela n’a pas été très compliqué car :
Nous étions en pleine restructuration d’équipe. Deux nouveaux développeurs venaient de nous rejoindre.
→ On avait donc pas mal de transfert de connaissance à faire.
Nous avions déjà quelques frustrations concernant le nombre de tâches trop élevé que nous tentions de réaliser en parallèle, et le nombre d'interruptions que cela engendrait.
→ Nous avions beaucoup de mal à avoir un focus commun à l’équipe.
Et finalement le fait de fonctionner en Sprint, rendait l'expérimentation peu coûteuse.
→ Nous pouvions facilement time boxer l’expérimentation sur un sprint.
Du coup explique-moi un peu comment vous avez lancé l’expérimentation.
Pour bien comprendre, je peux peut-être commencer par présenter l’équipe ?
Elle se compose de cinq personnes, assez hétérogènes au niveau des compétences et des personnalités (comme toutes les équipes j’imagine), dont :
- Anthony, développeur senior Backend et Frontend, plutôt réservé
- Julien, moi-même quoi, développeur senior Backend et Frontend, difficile de se qualifier
- Dumitru (alias DumDum), développeur junior, Backend et Frontend, très motivé et expressif
- Bishal (alias BiBi), développeur Junior Frontend, réservé avec un très bon sens du design
- Nathalie, PO et ergonome, malheureusement très indisponible
Nous devions designer et tester une page d’application avec une complexité moyenne, et un fort couplage avec les API existantes de la solution Bonita.
Le développement s’est fait dans un projet construit avec Gradle,
la page à livrer devait être faite avec l’outil de développement de page Web UI Designer, les tests devaient être fait grâce à Cypress.
Autant dire que pour de nouveaux arrivants, cela faisait pas mal de choses à intégrer.
Après avoir validé l’objectif et la méthodologie à suivre lors du sprint planning, nous nous sommes simplement réservé une partie de l’Open-space, où nous avions la place d’être à cinq, avec un portable et un écran de taille standard, et nous nous sommes lancés.
Et cette première itération a été concluante ?
A première vue, cela a plutôt été un succès. Une page développée très rapidement avec une meilleure qualité d’implémentation, une bonne couverture de test.
Mais malgré tout il y avait quelques tensions ou frustrations dans l’équipe :
Tous les sujets transverses ont étés mis en pause.
L’expérimentation a été assez éprouvante (Peu de pauses accordées)
La communication a parfois été un peu rude (Mix de passion et de fatigue)
Perte d’attention de certains membre de l’équipe (due à des notifications de téléphones pro ou non, ou par des phases de débat trop longues)
Pour comparer avec l’agilité, au cours des 8 dernières années notre apprentissage s’était fait par étapes :
1 - Apprendre avec un cadre fort
2 - Modifier ce cadre
3 - Vivre sans le cadre
Concernant le “Mob programming”, avec le recul je pense que nous avons commencé directement à l’étape 2.
Malheureusement, ignorer ou minimiser certaines règles de base nous a privé de leurs bienfaits.
Petit rappel des règles de base :
Il y a un pilote, un navigateur et des chercheurs.
Le pilote doit se contenter de coder ce qu’on lui demande.
Le navigateur consulte ses chercheurs et donne les ordres au pilote.
Les rôles doivent changer de personne toutes les 15 à 30 minutes.
Donc finalement le résultat de la première itération a plutôt été "mi-figue, mi-raisin" car nous avons été convaincus par le résultat, mais pas par la forme.
Malgré tout nous étions persuadés qu’il fallait plus creuser cette démarche en faisant des ajustements pour en retirer le plus de bénéfices possibles.
Qu’est-ce que vous avez modifié dans votre application de la méthode ?
Suite au premier sprint, toujours avec la même équipe nous avons tout d'abord décidé d’appliquer ces règles de base plus strictement.
En effet, faire tourner les rôles régulièrement à beaucoup plus de bienfaits qu’il n’y paraît. Cela permet entre autres de :
Garder toute l’attention et l’implication de l’équipe (sachant qu’on sera navigateur également)
Aider à avoir une bonne répartition du temps de parole (forcer les plus timide, limiter les plus expressifs)
S’assurer que chacun intègre bien le travail en cours (être Navigateur/Driver demande une bonne compréhension du travail en cours)
Également ne donner la parole principalement qu’au navigateur permet d’entendre beaucoup plus les personnalités plus effacées, et il est très important pour ce navigateur de pouvoir aller au bout de son idée, même si les chercheurs pensent que ce n’est pas une bonne idée. Effectivement, l’apprentissage par l’erreur peut être bénéfique, ou simplement l’idée du navigateur avait été mal comprise.
Nous avons également appris à utiliser le “Mob programming” de manière plus appropriée.
Par exemple, nous ne l’avons pas trouvé très adapté pour les Bug fix, que nous faisons plutôt en “Pair-Programming”.
Nous avons également déterminé des périodes fixes pour travailler en “mob-programming”, afin de permettre à chacun d’avoir des créneaux disponibles pour les activités hors Sprint.
La présence de Nathalie (la PO) n'est plus nécessairement de 100% du temps. Nous la consultons seulement lorsque l'on se trouve face à des choix compliqués d'ergonomie, ou lors de phase très axées sur le design de la page.
Il a été important de définir plus de temps de pause.
Pour finir, il a été primordial d’ajuster l’environnement de travail :
Nous avons rapidement échangé notre petit écran pour un écran géant et remplacé l’ordinateur portable par un vrai bureau/souris/clavier face à l’écran.
Nous avons également essayé de trouver un lieu le plus calme possible.
Et qu’avez-vous tiré comme bénéfice de cette méthodologie ?
Nous avons constaté énormément de bienfaits induits par la méthodologie.
Gain de temps
éviter les blocages lorsque le membre de l’équipe qui a la connaissance requise n’est pas disponible
Suppression du temps de revue de Pull Request
Suppression des éventuels conflits de Merge
Disparition des interruptions entre des membres de l’équipe travaillant sur des sujets différents
Réduction des interruptions externes (Il paraît plus compliqué d'interrompre un groupe, qu’une personne isolée)
Meilleur focus de l’équipe, on finit plus rapidement les choses
Réduction de la durée du stand-up meeting (Moins de sujets en parallèle)
Partage de connaissance globale
Même niveau de connaissance pour tous sur les nouveaux développements
Ramp-up des nouveaux membres sur le code legacy
Qualité
Globalement les solutions implémentées sont plus qualitatives (plus “smart” dans la réalisation, mieux testées)
Moins de bug dans les pages délivrées (ce qui au passage est un monstrueux gain de temps)
Avec le recul, on s'aperçoit également que le code a été fait de manière très modulaire, les modifications ultérieures ont été très simples à réaliser.
Esprit d’équipe
Nous avons profité de l’hétérogénéité dans le groupe plutôt que de la subir
Nous avons beaucoup appris à communiquer (la communication entre les membres de l’équipe est un facteur clé de succès)
Et donc, c’est bien la solution miracle dont tout le monde parlait ?
Effectivement, au delà des bienfaits cités précédemment, et malgré le scepticisme de départ, on y a finalement trouvé une certaine magie.
On a pu voir émerger des implémentations vraiment smart grâce à ce phénomène d'intelligence collective.
On a également amélioré notre satisfaction quotidienne, en délivrant plus rapidement des choses chaque jour.
Mais l’apprentissage n’est pas terminé je pense, on a juste atteint un bon rythme de croisière =)
Mais alors, le "Mob programming" en période de confinement, c'est possible ?
Depuis la récente crise du COVID-19, tout le monde est passé en 100% télétravail pour une période indéterminée.
Mais heureusement pour nous, nous avions atteint je crois un niveau de maturité suffisant pour pouvoir continuer le "Mob programming".
En effet, on continue à appliquer les bases, au travers des outils de visioconférence. Au détail près que l'environnement de développement doit être dupliqué.
La communication a forcément été un peu dégradée du fait de la visioconférence. Mais cela reste tout à fait correct.
Avant tout, le mob-programming c’est apprendre à communiquer efficacement au sein de l’équipe. De ce fait, l’apprentissage se fait au fil des itérations, et chaque équipe aura sa propre façon d’appréhender le Mob-programming, que ce soit en présence physique ou en télétravail.
Pour ce qui est du futur, je ne me risquerai pas à faire des prédictions. Mais quels que soient les scénarios, nous pourront toujours définir des périodes de mob-programming durant lesquelles nous serons en télétravail, et des périodes de présence physique dans les bureaux durant lesquelles nous appliquerons les règles de distanciation en vigueur.
De manière générale pour commencer le “Mob programming”, je crois que de bonnes bases seraient :
Appliquer les règles de base très strictement
Avoir un environnement de travail confortable (grand écran, souris et clavier, endroit calme et sans bruit ambiant qui pourrait perturber la communication)
Conserver des créneaux de temps libre, pour les activités hors sprint de chacun (Gestion des mail, projet transverse, …)
Définir des temps de pauses (exemple Pomodoro technique)
Merci Julien pour notre conversation !
J'en sais maintenant beaucoup plus sur le Mob programming, et je crois que parmi les méthodes de développement actuelles, le Mob programming pourra avoir sa place. J'ai pu voir qu'il est possible de tirer le meilleur parti de cette méthode, tout en l’adaptant aux circonstances actuelles.
