Un article de Bruno Orsier    4 Commentaires

Lundi nous avons organisé notre premier dojo agile au travail. J’y pensais depuis quelque temps, à force de voir ce terme mentionné dans les divers blogs que je consulte, et Agile Tour 2008 à Valence m’a conforté dans cette idée, grâce à l’atelier L’art de grandir en équipe sur la question. Tiens, d’ailleurs je n’ai pas assez prêté attention jusqu’à présent à cette idée de grandir en équipe, c’est un bon thème pour un prochain dojo.

Introduction

Pour moi le but de ce dojo est de créer un espace d’apprentissage entre les sprints. En effet depuis bientôt 3 ans de pratique de Scrum/XP, nous enchaînons les sprints, mais il n’y a jamais de temps de relâche, jamais de moment à consacrer aux objectifs personnels (ceux fixés dans les entretiens annuels, et qui ne sont pas forcément liés aux projets), jamais de moments de partage de connaissances (entre équipes, entre projets). Bref nous avons toujours « la tête dans le guidon », et cela ne correspond pas à ce que je comprends de l’esprit de Scrum. La lecture de Scrum and XP from the Trenches me conforte tout à fait dans ma réflexion – en effet Henry Kniberg y parle des journées « labo » que ses équipes font entre les sprints. Durant ces journées les développeurs sont autorisés à faire essentiellement ce qu’ils veulent (idée venant de ce qui se fait chez Google), ce qui leur donne de réelles chances de garder leurs connaissances à jour, et qui constitue un avantage attractif pour l’employeur.

Nous avons un challenge particulier : un quart de nos employés sont des chimistes (nos logiciels étant utilisés dans le domaine de la chimie), c’est l’une de nos particularités, et l’un de nos points forts, car les utilisateurs sont très bien représentés au sein de nos équipes Scrum. Mais ces chimistes ne programment pas, et donc le challenge est de les impliquer dans ces dojos. Impossible donc de se limiter à des dojos de « codage ». C’est pourquoi j’ai retenu les trois activités ci-dessous pour ce premier dojo d’une durée de 3 heures.

Activité 1 : vidéos

L’idée est venue de mon collègue Sébastien, qui repère depuis quelque temps des vidéos intéressantes sur les bases du développement agile – son raisonnement étant que nous serions surement plus convaincants si nous laissions les pontes du domaine expliquer à nos équipes tous ces concepts, au lieu d’essayer de tout faire nous-mêmes (mal). Tiens, au fait les développeurs ne prennent jamais de temps pour visionner ces excellentes vidéos qu’on trouve sur InfoQ et autres sites spécialisés… Et si c’était parce qu’il n’y a pas de temps libre entre les sprints … Donc cette idée de vidéo tombe à pic pour enrichir le contenu des dojos – et en plus ca peut intéresser les chimistes ! Bingo !

ScrumMasters2

Pour s’échauffer, on commence par cette courte vidéo de 8 minutes, que Sébastien a trouvée sur youtube. Elle présente avec humour tout ce qu’il ne faut pas faire dans les mêlées quotidiennes. J’ai trouvé très plaisantes les réflexions dans l’assistance, du style « mais ils sont déjà venus voir chez nous ! ».

Ken Schwaber / Scrum et al, 2006

Fini la rigolade, là c’est du lourd ! Dans cette présentation faite chez Google, Ken Schwaber (le co-créateur de Scrum) explique Scrum en termes simples, et bien que nous ayons déjà trois ans d’expérience, ca ne fait pas de mal de revisiter les bases. Voici quelques points qui m’ont frappé :

• Schwaber a formé environ 5500 développeurs, et il leur a fait passer un test pour voir comment ils réagissent quand on leur demande de travailler plus vite (augmenter la vélocité, dans le jargon Scrum). Eh bien la plupart rognent sur la qualité (par exemple ils ne font plus de tests, ils dupliquent du code au lieu de le remanier) – en fait, dans son test, seules 120 personnes sur les 5500 refusent de rogner sur la qualité, soit 2%. Donc il conclut que rogner sur la qualité est quasiment génétique chez les développeurs – et je dois hélas reconnaître que je fais plutôt partie des 98% (j’essaie tout de même de me soigner, notamment en écrivant divers articles pour me perfectionner).
• Il se sert ensuite de ces données pour expliquer le rôle du ScrumMaster : être le garant de la qualité, et donc éviter toutes ces pertes de qualité. C’est pourquoi le ScrumMaster est « la personne la moins aimée au monde », et que « sa durée de vie n’est que de 13-14 mois ». D’ailleurs on l’appelle « the prick », terme que The Free Dictionnary veut bien nous expliquer comme « 7.  Vulgar Slang A person regarded as highly unpleasant, especially a male« . Tiens, un de nos membres d’équipe a récemment expliqué à son ScrumMaster qu’il était le « casse-couilles » de l’équipe. Ca colle avec la définition !
• Et il utilise ces mêmes informations pour expliquer pourquoi de nombreuses sociétés se retrouvent avec une base de code si difficile à faire évoluer. En supposant qu’une équipe à une vélocité de 20, il arrive toujours un moment où le management (ou le marketing, etc.) veut leur faire faire mieux, pour de bonnes raisons. Sous la pression, les développeurs, arrivent à une vélocité disons de 22 – mais ils ont rogné sur la qualité. Donc au sprint suivant, ils font au mieux une vélocité de 18. Si on les pressure encore un peu, ils peuvent au mieux revenir à 20 – mais en rognant encore sur la qualité. Partant de là la vélocité ne fait plus que diminuer. Enfin, regardez la vidéo, c’est plus parlant. J’ai tout de même fait la courbe ci-dessous pour illustrer le concept :

Il y a beaucoup d’autres choses intéressantes dans cette vidéo, je la recommande vivement.

Activité 2 : exercice sur le « task-switching »

Depuis bientôt un an nous essayons d’examiner nos méthodes de travail dans le cadre du Lean Software Development, et donc nous essayons de trouver des sources de gaspillage. L’une de ces sources bien identifiée par les praticiens du Lean est le changement fréquent de tâches (voir par exemple le billet Travailler moins pour produire plus de Alexandre Boutin).  Or en pratique il s’avère difficile de convaincre les collègues que faire plusieurs choses en parallèle est néfaste : ils ont clairement l’impression d’être plus efficaces et plus utiles, et ils n’acceptent pas d’avoir des « temps morts », ce qui est tout à leur honneur bien sûr. Toutefois cela entraîne des dérives dans notre implémentation Scrum/XP, car on s’éloigne parfois de l’idée de focalisation sur l’histoire de plus haute priorité. Au lieu de finir rapidement l’histoire de haute priorité, on démarre en parallèle plusieurs autres histoires de moindre priorité.

Cette deuxième activité a donc consisté à faire l’exercice proposé par Clarke Ching, qui consiste en 3 projets :

• P1 : écrire les lettres A-J dans une 1ère colonne
• P2 : écrire les nombres 1-10 dans une 2ème colonne
• P3 : écrire chiffres romains I-X dans une 3ème colonne

Il faut réaliser ces deux projets selon deux méthodes :

• Multi-tâches : remplir le tableau ligne par ligne
• Séquentiel : colonne par colonne

Cela ne prend que quelques minutes – donc je vous encourage à le faire vous-mêmes. Tous les participants au dojo l’ont fait, et ont été quasi-unanimes : la méthode multi-tâches est plus difficile (risque d’erreurs) et prend plus de temps !

Activité 3 : le randori

Bon, personne ne m’a pris pour un fou quand j’ai parlé de randori ! Heureusement plusieurs participants ont déjà entendu ce terme dans le contexte des arts martiaux. J’ai brièvement expliqué les règles, que j’ai trouvées sur le site de Agile Finland, en complément de ce que j’ai appris lors de l’atelier L’art de grandir en équipe) :

• Programmation en duo, avec projecteur
• Remplacement toutes les 5 minutes
• Duo explique ce qu’il fait
• Duo stoppe si
  • l’audience est perdue
  • Audience pas ok avec design
• Duo travaille en TDD
  • Vert : audience peut commenter le design
  • Rouge : audience peut poser questions
• Code doit toujours être parfaitement « réfactoré »
• Favoriser tests et code plutôt que longues séances de conception
• Explorer toutes améliorations (ex : raccourcis clavier, outils)
• Favoriser la simplicité

Et les chimistes dans tout cela ? Eh bien j’espère les garder intéressés grâce au sujet du challenge de programmation proposé dans ce dojo – sujet qui sera l’objet d’un prochain billet !