Ôde à l’Agilité

“L’agilité c’est du flan.”

C’est ce que je me disais, avant.

Nous, développeurs, avons une fâcheuse tendance à nos débuts à considérer tout ce qui tient de la méthodologie comme un truc de management nébuleux dont la seule fonction est de donner un cadre aux équipes, pour qu’un projet soit mené à bien.
Comme une Table de Commandements légèrement superflue, fixant des règles que seules quelques rares personnes n’appliquent pas de façon naturelle.

Mais en fait, non.

Ce préjugé, je l’ai définitivement ravalé grâce à une formation Scrum proposée par Xebia (et menée par le talentueux Scrum trainer Bruno Sbille) à laquelle j’ai eu le plaisir de participer. Formation certifiante Scrum Product Owner étalée sur 2 jours.
Et c’est, dès le premier jour, un exercice en particulier qui m’a remis les idées en place…

Le bien-nommé « Exercice des avions » !

Prenez 3 équipes de 5/8 personnes et demandez leur de produire le plus d’avions en papier en l’espace de 3 minutes.

Règle :
Personne ne doit faire plus d’un pliage à la suite sur le même avion, une personne incarne le ‘product owner’ ayant pour rôle de vérifier que chaque avion fini vole de façon correcte et ayant interdiction de plier.
Avant le lancement du chrono, chaque équipe dispose d’une minute pour adopter une stratégie et annoncer combien d’avions ils pensent pouvoir faire.

la-fi-tn-45-foot-paper-airplane-glides-over-ar-002

#badstrategy

Incertains, nous pensions en faire 4.
0 ont volés.

Les 2 autres équipes s’en sont mieux sorties que nous mais pas de quoi frimer non plus.
Nous avons ensuite eu l’opportunité de débattre une minute afin de corriger notre stratégie et donner une nouvelle estimation avant 3 autres minutes de pliage intensif.

Annoncés: 16.
Produits: 14.

3ème round :

18 annoncés…
Envolés : 18 !

Nous étions certes l’équipe avec la courbe de production la plus marquante, mais les statistiques des 3 groupes étaient saisissantes: nous partions tous d’un ratio inférieur à 40% pour finir tous à 100%.

Révélation, Choc, Illumination.

L’itération sur de courtes périodes de temps avec rétrospectives régulières permettent une amélioration du travail en équipe de façon spectaculaire.

tn_BLUES_BROTHERS-12

Autrement plus efficace qu’un classique cycle en V pour lequel le développement se fait de façon bêtement linéaire.
Couronné finalement par un bon gros débrief où chacun à l’occasion de saisir l’ampleur du dépassement, du surcoût et de la maigre proportion des fonctionnalités qui sont finalement parties en prod.

Alors oui, les méthodes Agiles restent un outil de méthodologie, de gestion de projet, un cadre de travail, avant tout là pour rendre les processus plus intelligents, plus souples et augmenter la productivité en réduisant les coûts.

Des considérations sans doute peu sexys vu de l’oeil d’un codeur.

Mais c’est aussi un outil incroyablement générateur d’émulation et très gratifiant.

Imaginez voir votre réussite d’équipe être tirée vers le haut à chaque « sprint » (itération) et votre qualité d’estimation s’affirmer, comme dans l’exemple des avions.
Excitant non ?

Imaginez faire vivre un projet à travers un tableau physique où chaque fonctionnalité est représentée par un post-it qui se balade de colonne en colonne…
Palpitant n’est-ce pas ?

Imaginez savoir constamment ce que vos 4, 5, 6 collègues développeurs sont en train de coder et d’avoir l’occasion d’adapter la stratégie commune à n’importe quel moment en fonction du délai ?
Epatant ?

Et bien oui ! 3 fois.

J’ai, depuis ce changement de perspective, le bonheur de nager dans un bassin d’agilité, et d’en retenir tous les bienfaits.

Alors ceci est mon Mea Culpa.

“L’agilité, je t’aime.

heart

Teasing: La plateforme IT sur laquelle je travail prépare actuellement sa transformation en dispositif « Feature Team » à la Spotify… Chantier qui s’annonce tout aussi douloureux qu’enrichissant. A suivre…

Laurent Masella, UX-Scientist @UX-Republic