Retour sur la conférence Agile France 2012 (part 1/2)

La 7ème édition de la conférence Agile France a eu lieu les 24 et 25 mai dernier au Chalet de la porte Jaune.

L’événement, organisé par l’association Agile France a été une grande réussite en abordant des thèmes divers et variés tels que : Scrum, XP, Kanban, BDD, TDD, Contractualisation Agile, etc.
Cette année, ce sont environs 230 personnes qui se sont retrouvées dans un cadre idyllique pour échanger autour de l’agilité. Le programme étant chargé, il a fallu faire des choix, et je vous propose ici une petite synthèse des conférences/ateliers auxquels j’ai eu la chance et le plaisir de participer.

Large Scale Scrum : assurer la polycompétence dans vos équipes

Lors de cette première présentation, l’animateur Damien THOUVENIN, partage avec nous son retour d’expérience sur les enjeux de la polycompétence dans une équipe Scrum et pourquoi il s’agit d’un facteur clé dans un projet de transformation Agile à grande échelle. Lors d’un premier sprint, la vélocité avait été estimée à 9 point de complexités, et force est de constater qu’il n’est pas rare de se retrouver avec une vélocité effective de 1 voir 0… Deux problèmes justifient cette vélocité :

• Une mauvaise répartition des charges dans les stories au niveau des compétences attendues
• Une attente entre les membres de l’équipe qui dépendent les uns des autres

Deux obstacles majeurs empêchent une amélioration globale de l’équipe :

1. La barrière psychologique due à la mise en place de l’agilité/Scrum
2. La multi-compétence au sein des membres de l’équipe

Pour permettre de lever ces résistances, il peut être mis en place des entretiens individuels qui ne sont pas des entretiens annuels, où les personnes ne seront pas notées. Le but ici est plutôt d’échanger et de partager la vision de chacun. On peut par exemple demander à chaque personne comment ils vivent le passage à Scrum. A propos de la polycompétence, il sera important de noter que :

• Les experts doivent rester des experts
• Former et se former demande du temps
• Personne ne sera forcé

D’un point de vu organisationnel, il est intéressant de demander à chacun les compétences :

• qu’il maitrise
• auxquelles il s’intéresse
• qu’il ne souhaite pas acquérir.

Et de dresser un tableau permettant de quantifier la capacité disponible.
En parallèle, pour chaque User Story, il faut essayer de quantifier la charge nécessaire par compétence et la comparer à la capacité. Ainsi, il sera possible d’identifier :

• Les éventuels goulets d’étranglement
• Les transferts de compétences intéréssants

Au moment de la formation à ces nouvelles compétences, il ne faut pas chercher à former des experts et ce qui est important est de faire un premier pas.
En appliquant ces principes, les résultats obtenus sont les suivants :

• Déploiement rapide
• Moral des équipes
• Intérêt pour les différents métiers
• Qualité des livrables

Les prochaines étapes sont :

• La transversabilité des compétences
• La complémentarité des équipes

Les problèmes de compétences transverses sont de nos jours de plus en plus récurrents et nous avons eu ici un retour d’expérience intéressant. Des outils simples à mettre en place ont permis d’améliorer la polycompétence d’une équipe et peut être un bon complément aux outils proposés par Michel Goldenberg lors de sa conférence publique « Techniques pour amener les équipes à l’excellence »

Agiliste, es-tu un Hacker ?

Avec ce titre accrocheur, Olivier Inizan, nous a présenté une rapide comparaison entre les Agilistes et les Hackers afin de mettre en avant les pratiques, les principes et les valeurs de chacun. On y fait la connaissance, ou pour certains un rappel, de 3 hackers :

• Richard Stallman qui une éthique et encourage le logiciel libre
• Eric Raymond qui à plutot un business plan et l’un des pères de l’Open Source
• Linus Torvalds qui à une famille et encourage la technique

Ce fut une présentation enrichissante, qui d’apparence s’éloigne de l’Agilité, mais où on retrouve finalement des similitudes.

De Scrum vers Kanban, où comment gérer de manière agile une équipe transverse

Avant cette présentation je me suis dit : Génial !!! Un retour d’expérience sur la mise en place de Kanban. La séance commence de façon très originale par un poème présentant l’orateur : Thomas Bonset. Après cette petite littérature, Thomas nous présente le contexte, les rôles et les objectifs de son équipe transverse d’usine logicielle.
Scrum a été mis en place, mais il est vrai qu’il y a ses limitations, notamment lorsqu’il n’y a pas de Product Owner identifié et pas vraiment d’itération, d’où l’idée de passer à Kanban. On apprend alors qu’il ont fait évoluer le board en rajoutant des colonnes, en limitant le WIP (Work in Progess) et en ne réinitialisant plus le board…Mais c’est tout ? Et la date d’entrée d’une tâche ? Et sa date de sortie ? Et les indicateurs comme le cumulative flow diagram ?
Au final, je sors un peu déçu, n’ayant pas un vrai retour d’expérience sur la mise en place de Kanban mais plutôt sur une version personnalisée de Scrum.

eXtreme Quotation : le planning poker sous steroïds

On passe ici à un peu de pratique avec un atelier animé par Jonathan Sher, qui nous propose une autre méthode d’estimation qui permet de dépiler environs 80 stories en 20 minutes. Cet atelier ayant attiré un grand nombre d’entre nous, deux équipes se sont prêtées à l’exercice dont les principes sont plutôt simple. D’un point de vu logistique, nous avons :

• Une Backlog de 80 stories, rédigées sur de petites étiquettes et disposées en vrac sur une table
• 10/15 participants par équipe
• Une deuxième table avec la suite de fibonacci

 
Pendant les 10 premières minutes, chaque personne est invitée a lire, étudier et déterminer la complexité en déplaçant les stories sur l’autre table, uniquement en fonction de son intime conviction. Toutes les stories sont déplacées et estimées très rapidement. A ce moment, on entre dans la deuxième phase d’estimation, les animateurs invitent les participants à relire toutes les stories et a changer d’estimation s’ils estiment que c’est nécessaire. A cette phase du jeu, des discussions commencent a avoir lieu, pour déterminer au mieux l’estimation de telle ou telle story : dans le doute, c’est toujours la complexité la plus forte qui gagne. Petite précision qui a son importance, le produit était connu de tout le monde puisqu’il s’agissait de Gmail.

 
Au bout des 20 minutes, on se retrouve donc avec une Backlog de 80 stories qui a été entièrement estimée. L’avantage d’une telle estimation, c’est qu’il est possible de déterminer la complexité des User Stories très rapidement et de façon ludique, contrairement à un Planning Poker classique qui dure plusieurs heures… En revanche, je ne suis pas certain de l’exactitude de cette estimation, car contrairement au Planning Poker classique, il n’y a pas autant d’échanges sur chaque stories, et surtout il n’y a pas consensus et donc des estimations en accord avec l’expérience et la vision d’un individu et non d’un groupe.

 
Il s’agit ici d’un moyen simple de faire une pré-estimation, mais je pense qu’un vrai Planning Poker reste indispensable pour que toutes les personnes puissent échanger et faire une estimation au plus juste.

Agile : les sujets qui fâchent

Christophe Keromen et Dominique de Premorel, nous ont proposé un petit jeu / atelier. Deux équipes de 3/4 personnes, devant tour à tour soit défendre la cause de l’agilité soit au contraire l’attaquer au travers de thèmes récurrents (qui fâchent) comme par exemple, « Agilité, pas de chef de projet ? pas de pilotage ? », « Sprint, flux-tendu : l’agilité au final = plus de pression », etc…
Ce sont des phrases qu’on entend régulièrement, et c’est assez marrant de voir comme tout le monde entend toujours les même arguments. Ce qui est dommage, mais c’est le contexte qui voulait ça, c’est que tous les participants soient convaincu par l’agilité. En effet, entre un groupe « pour » l’agilité et un « contre » l’agilité, l’exercice d’inversion des rôles peut être intéressant pour sensibiliser sur ces sujets qui fâchent.

A venir

Dans un prochain article, je ferais la synthèse des autres conférences auxquelles j’ai assisté :

• Le contrat Agile : retour d’expérience
• Atelier : satisfaire complètement ses utilisateurs avec le software kaizen
• Des maux, des mots, démo
• Chouette, encore un bug
• L’île mystérieuse : Behaviour Driven Development et les tests d’acceptances
• Kapla World Tour : revisitez Scrum