Améliorez votre résilience d’équipe avec Agile Lotto !

Comment renforcer la résilience d’une équipe ?  Il y a quelques temps, je suis tombé sur l’article de Daniel Lebrero “CTO day 7: Lucky Lotto, chaos engineering but for teams” qui aborde le sujet de façon simple en s’appuyant sur certains principes d’ingénierie du chaos.

Pendant 2 mois, j’ai pu expérimenter auprès de l’équipe que j’accompagne Agile Lotto et vous livre les résultats de cette expérimentation au sein de cet article !

Pourquoi s’intéresser à la résilience d’une équipe ?

Pour commencer, voici ma définition de la résilience. Elle se base sur mes études en génétique des populations (he oui !). Car oui, il n’y a pas qu’une définition de la résilience. Pour moi, la résilience désigne “la capacité d’un système à retrouver un état d’équilibre après une phase d’instabilité due à une perturbation extérieure ou interne”.

Pssss : Si vous voulez découvrir un sujet connexe à la résilience, on parle de métastabilité dans cet article.

Et du coup ? Dans une équipe agile ?

Connaissez vous le “bus factor” ? Non ? Alors en une phrase : « Combien de personnes dans votre équipe peuvent se faire renverser par un autobus avant que votre projet échoue ? »

Si la réponse à cette question ne vous semble pas satisfaisante, alors il peut-être bénéfique de travailler la résilience de votre équipe !

Généralement le bus factor diminue (et donc le risque augmente) mécaniquement lorsque la taille de l’équipe diminue…ou même… avec le temps !

En effet, généralement, plus le temps passe et plus l’équipe de développement concentre de la connaissance : Le système sous sa responsabilité ayant tendance à augmenter en périmètre ou complexité, les connaissances s’accumulent sur les membres de l’équipe en tirant ainsi à la baisse le bus factor car la capacité cognitive d’un humain est limité alors que la complexité d’un système ne l’est théoriquement pas.

Bien heureusement, de nombreuses solutions existent pour augmenter le bus factor. Entre autres, le pair programming, la limitation des travaux en cours ou plus généralement toute manière de travailler permettant de diffuser les connaissances dans l’équipe permettra de limiter voir contrer l’effet décrit plus haut.

Dans cet article nous allons en présenter une nouvelle : l’agile lotto !

Vous avez-dit Agile Lotto ?

L’objectif avoué de l’Agile Lotto est donc que votre équipe puisse profiter des résultats de la disparition de ses membres. Vous le comprendrez mieux en découvrant les règles qui le compose :

Les règles :

• 1 – Chaque lundi, une personne au hasard gagnera Agile Lotto. (Pensez à Plouf-plouf.fr)
• 2 – Le gagnant travaillera sur un sujet alternatif TOUTE LA SEMAINE.
• 3 – Le gagnant sera totalement indisponible pour ses collègues et pour le reste de l’organisation pendant la semaine.
• 4 – Tout le monde, y compris le product owner et le scrum master participe !
• 5 – Chaque fois que la règle 3 doit être enfreinte, le gagnant doit l’identifier et mettre en place une manière de diffuser cette connaissance.

Au fait ! Annoncer à un membre de l’équipe qu’il a gagné au lotto est plus engageant que de lui annoncer qu’on veut travailler la résilience de l’équipe au cas il passerait sous un bus 😉

Des idées de sujets alternatifs ?

Cela dépendra des compétences de l’heureux gagnant, mais cela pourrait inclure :

• Amélioration du flux de travail.
• Recherche, Veille.
• Préparation d’un BBL/Talk.
• Travail important mais non urgent.
• Petits projets annexes pour les autres départements de l’organisation.
• Ecriture d’articles.
• Tourner une vidéo pour Scrum Life (private joke pour Jean Pierre).
• Participation à des conférences.
• …

Quelques précisions :

Il est possible de gagner plusieurs fois de suite à l’agile lotto.

Le gagnant ne doit pas complétement s’isoler : il peut toujours socialiser au café et/ou assister à des réunions comme les daily meeting mais il n’est pas autorisé à apporter sa contribution.

Si le gagnant DOIT faire une chose très importante que lui seul peut faire (si importante que si ce n’est pas fait, le monde sera détruit…) ALORS il FAUT identifier cette chose et la traiter de la manière décrite ci-dessous. C’est essentiellement le but de l’exercice. Évidemment, l’agile lotto ne souhaite pas mettre en péril le travail de l’équipe. Aussi si vous vous retrouvez dans ce cas :

• Identifiez la tâche dans un wiki ou autre référentiel de travail.
• Essayez d’amener un de vos collègues pour faire la tâche avec votre supervision en binôme.
• Cela va aider les membres de l’équipe à acquérir un profil en T, ce qui à long terme devrait rendre l’équipe plus fluide et plus adaptable.

Vous remarquerez que l’agile lotto est en fait gagnant-gagnant : L’équipe deviendra plus résiliente à terme et le gagnant qui aura une semaine pour faire quelque chose de différent !

Dans la pratique

Tous les lundis à 9h30, avant notre daily meeting, nous utilisons plouf-plouf.fr (tout autre moyen de tirage au sort peut convenir) pour identifier le gagnant.

Après le daily meeting, nous passons quelques minutes avec le gagnant du lotto (généralement au café) en présence du reste de l’équipe et nous l’aidons à déterminer comment il va occuper sa semaine. Les suggestions des coéquipiers sont les bienvenues !

Après plusieurs semaines de pratique de l’agile lotto, voici mon retour sur cette pratique :

Résultat

Pour rester synthétique : Après un peu plus de deux mois, l’agile lotto a atteint son objectif premier en augmentant globalement le bus factor de l’équipe. Il aide en effet l’équipe à apprendre et couvrir les compétences et activités du gagnant.

Au fait, avant d’aller plus loin, nous déterminons notre bus factor en mettant en place une matrice comme celle-ci :

A titre d’exemple, notre seul et unique sachant sur une technologie (Mongo DB) a remporté le Lotto alors qu’un de nos objectifs de sprint était de résoudre un problème de performances majeur lié à Mongo DB. Résultat : 2 membres de l’équipe formés à Mongo DB en deux jours tout en atteignant le sprint goal. Chapeau !

Encore mieux : Pour le gagnant, ce fut une semaine très agréable. Il en a profité pour se former sur Kubernetes et préparer une présentation synthétique à faire à l’équipe lors de son retour.

Au delà de cet effet et tout comme Daniel à pu l’observer, nous avons bénéficié d’une pollinisation croisée car certains gagnants se sont grandement rapprochés de l’équipe métier pendant leur semaine.

Ici s’arrête mon observation. Que du positif. Je ne peux néanmoins m’empêcher de continuer cet article pour vous partager le retour d’expérience de Daniel sur le phénomène qu’il a nommé “la bonne semaine”.

La bonne semaine

En expérimentant l’agile lotto, nous avons un jour été confronté à la bonne semaine :
Une petite vague de panique a montré le bout de son nez le jour où LE développeur backend d’une des équipes a remporté le Lotto LA semaine des délais serrés et des promesses clients incontournables.

Le développeur (et le Product owner) a demandé de rejouer le Lotto afin qu’il puisse avoir un “bon Lotto” dans une semaine plus calme et qu’un autre développeur puisse en profiter cette semaine.

Cela a bien évidemment levé plusieurs sujets et je vous encourage à souvent ré-affirmer l’objectif de ce lotto.

Constituez des équipes résilientes. C’est tout.

Pourquoi ?

Pour être moins stressés à l’avenir, car nous aurons une équipe plus adaptable.

Travailler sur les priorités nécessite cette capacité d’adaptation or… nous sommes tous des spécialistes mais pas des généralistes. La résilience nécessite d’avoir des généralistes spécialisés.

Notez que la plupart d’entre nous ont déjà fait la partie difficile : devenir un spécialiste. Il ne nous reste plus qu’à faire le plus simple : apprendre suffisamment d’autres disciplines. Juste assez.

Comment ?

L’agile lotto fait « disparaître » un membre de l’équipe pendant une semaine, et le reste de l’équipe doit assurer le travail de la personne disparue.

Ainsi, une semaine réussie d’agile lotto est celle qui, par ordre d’importance :

• Permet la transmission des compétences entre les membres de l’équipe.
• Permet le binômage car ce moyen de partage est plus efficace que l’auto-apprentissage.
• Certaines lacunes de connaissances difficiles à transférer sont identifiées.
• Le gagnant peut faire quelque chose de différent.

Nous avons donc enrichit les règles :

Enrichissements des règles

En plus des règles décrites plus haut :

• Il n’y a pas de « punition » pour avoir enfreint la règle 3. Ce n’est pas bon ni mauvais. C’est un fait, et nous voulons le savoir.
• L’équipe doit éviter de retarder le travail d’une semaine.

MAIS N’OUBLIEZ PAS :
Il vaut mieux enfreindre la règle 3 que :

• Perdre 5 jours de travail de votre équipe.
• Perdre 5 jours d’un membre de l’équipe.
• Manquer une échéance importante.
• Laissez un coéquipier se débattre avec votre tâche pendant une semaine.

Pour conclure

Agile Lotto a plutôt bien fonctionné en tant que moyen de créer des opportunités sûres pour l’équipe d’apprendre, de diffuser les connaissances et d’augmenter notre bus-factor…tout en donnant au gagnant la possibilité de rompre avec la routine.

Et vous ? Avez-vous envie de tester l’agile lotto ?