L'IPI heap hourra !

Ce mercredi 3 février, c’était la traditionnelle journée agile de l’IPI — l’école d’informatique du campus IGS de Blagnac — organisée en collaboration avec l’association Agile Toulouse.
L’objectif de l’événement est de favoriser la rencontre entre étudiants et professionnels dans un lieu agréable et avec un format convivial sur le thème de l’agilité.

Les contraintes de cette année n’ont pas permis de se retrouver dans les loges du Stadium ou du Wallon et c’est bien dommage, mais elles n’ont quand même pas empêché l’événement d’avoir lieu et de réitérer un nouveau succès.

Depuis 10 ans Cyrille invite les agilistes toulousains à animer des jeux sérieux pour faire découvrir l’agilité tout en passant de bons moments de partage. Cette année ce fut plus compliqué pour beaucoup. Le format distanciel restreint le catalogue des jeux agiles, demande des adaptations, plus de préparation, entre autres freins. Une des compensations est que d’autres agilistes de France sont venus animer et participer (et aussi peut-être avec l’idée d’essaimer ensuite ailleurs, pourquoi pas ?).

Pour la préparation, plusieurs rendez-vous avaient eu lieu en soirée durant les 3 semaines qui ont précédé l’événement, pour s’exercer à mener divers ateliers, jeux à distance et assurer la qualité de cette journée.

C’est donc derrière nos écrans que nous avons dû nous retrouver à 9h, accueillis par Cyrille. Plus de 200 personnes ont participé à l’événement sur la journée. À cette échelle ce n’est plus un scrum (une mêlée) mais plutôt un heap (une foule) de personnes disséminées qui s’auto-organisent dans les différents lieux et jeux proposés.

Comme prévu, passer de la réalité 3D à l’écran 2D, ça limite, ça contraint. Même si les outils vantent toutes leurs possibilités, les interactions sont plus lentes, les prises de paroles plus timides, les bruits superflus vites perturbants. Les changements de salles ajoutent du stress : on rompt la connexion avec un endroit connu où tout fonctionne pour tenter de la rétablir ailleurs, en croisant les doigts pour ne pas faire de fausse manip.
Même si ça s’est plutôt bien passé, sur l’ensemble d’une journée je trouve personnellement cela plus fatiguant qu’en présentiel.

Le collectif agile radical a co-animé un atelier de conversations sur les valeurs du manifeste agile, réitéré 6 fois durant la journée, et un atelier de live coding le matin et un kata en mob programming l’après-midi.

Nous avons pu debriefer dès le lendemain matin pour parler de nos apprentissages et de quoi faire ensuite.
Les lignes ci-dessous retranscrivent quelques unes de ces informations sans spoiler vos futures expériences.

Value advocacy

Animateurs du jeu au pied levé: Rachel et Jean-Pascal

Avec un peu d’exercice pour découvrir le jeu ensemble le lundi soir, quelques slides fournis par Cyrille la veille, une relecture du manifeste agile d’origine et de notre manifeste de l’agilité radicale version longue, ainsi que la création d’un tableau de postits sur Mural le matin même, nous étions prêts. Au delà des règles du jeu on ne peut plus simple, nous avions envisagé plusieurs options pour s’adapter à l’incertitude du nombre de participants, du respect du timing et de quelques autres aléas qui pouvaient nuire à l’expérience des participants.

Sans vous dévoiler le jeu, ni le contenu riche de nos échanges, voici ce que je peux retenir d’important sur le fond.

Se faire l’avocat de valeurs c’est déjà difficile, alors quand il s’agit de défendre des valeurs auxquelles on n’adhère pas…

Contre toute attente, ce ne sont pas les équipes qui défendaient les valeurs agiles qui l’ont emporté.
La majorité des matchs ont été gagnés par des équipes qui vantaient les bénéfices des processus et outils, de l’importance d’avoir une documentation, un contrat et un plan.

J’émets plusieurs hypothèses à ce résultat que je peux formuler à partir du debriefing, mais qui appellent à plus d’expérimentation dans différents contextes, pour se vérifier:

• Les valeurs auxquelles ont croit profondément sont plus difficiles à défendre. Elles appellent à une certaine humilité, et les arguments peuvent manquer. “C’est pourtant évident !” Et pourtant, il a été difficile parfois de combler les 2 min pour exprimer pourquoi, de façon convaincante.

À l’inverse, afficher ouvertement une mauvaise foi est souvent plus praticable dans le jeu. On peut se lâcher, caricaturer sans risque. Ce n’est pas nous.

• Nous arrivons plus facilement à exprimer ce que l’on a l’habitude de voir et entendre, de reprendre les arguments tirés de notre héritage culturel, plutôt que d’énoncer ce qu’il conviendrait de faire autrement en étant agile. Parce que cet autrement n’est pas une nouvelle vérité de remplacement. Les valeurs agiles ne sont pas un remplacement mais un déplacement, un ajustement, et que cet ajustement de curseurs ne peut être que contextuel.

Je ne vous dévoile pas plus des rouages de ce jeu que je ne peux que vous inviter à essayer, avec toutefois la recommandation d’être assisté d’un accompagnateur agile qui pourra aider à faire la part des choses, et probablement à vous éloigner de quelques croyances, en bon penseur d’agilité plus que détenteur de vérité.

Kata de code

Guillaume Saint-Etienne et Anthony Cassaigne ont animé un premier atelier visant à faire découvrir par la pratique, le Test Driven Development et le Mob Programming. Nous avons embarqué un petit groupe composé de cinq étudiants pour le kata FizzBuzz. Nous avons commencé par présenter les trois règles du TDD :

1. N'écrire le code de production que pour faire passer un test unitaire qui échoue.
2. N'écrivez pas plus d'un test unitaire qui échoue (les échecs de compilation sont des échecs).
3. N'écrivez pas plus de code de production que nécessaire pour faire passer le test unitaire au vert.

Pour le TDD nous commençons donc par écrire un test qui échoue, nous vérifions qu’il échoue pour la bonne raison et ensuite nous développons le minimum de code de production afin de passer ce test au vert. Il convient de ne pas oublier l’étape suivante : le refactoring. Après cette présentation succincte, nous avons introduit rapidement le fonctionnement en mob programming en simplifiant les rôles.

Cela a suscité d’intéressants échanges sur cette façon de développer en groupe, en comparant notamment cette approche avec l’approche crystal.

Au sein du Mob, Guillaume a conservé le rôle de driver tout au long de la séance et j’ai (Anthony) conservé le rôle de facilitateur. Les étudiants ont à tour de rôle pris la responsabilité de navigateur. En tant que facilitateur, j’ai également géré le temps entre chaque rotation (fixé à 6 minutes). Pour un premier kata introduisant à la fois le TDD et le mob programming, le tout en distanciel, nous pouvons être assez satisfaits des échanges et du code produit. Le groupe était attentif aux échanges et à l’orientation donné par le navigateur permettant ainsi la co-construire d’une solution pour ce kata.

Cette première séance s’est terminée au terme des 50 minutes convenues, j’ai ensuite laissé Guillaume et ce petit groupe d’étudiants continuer leur chemin sur la seconde séance de 50 minutes.

Remerciements

Merci Cyrille, merci l’IPI et merci aux organisateurs et animateurs des ateliers qui ont su se préparer et s’adapter ainsi que tous les participants, pour faire en sorte que la devise de l’association Agile Toulouse autour de l’agilité se concrétise une fois de plus :

Transmettre, Réitérer, Progresser