eXtreme « Selection »

08 February 2013

Dans la préparation d’une conférence, il y a une étape importante : la sélection des sessions. Cette étape est toujours délicate, et il doit exister autant de façons de faire que d’équipes d’organisation. Pour l’édition 2012 de l’Agile Tour Montpellier, j’ai proposé une approche inspirée par une pratique d’estimation qui avait été présentée par Jonathan Scher (@jonathan_scher) et Guillaume Duquesnay (@duquesnay) lors du dernier Agile France : eXtreme Quotation. Comment passer, allez-vous me demander, d’une pratique d’estimation à une pratique de sélection de sessions ? C’est tout l’enjeu de ce billet 🙂

eXtreme Quotation

Tout d’abord, un petit tour du propriétaire. En quoi consiste eXtreme Quotation ?

Peut-être faites-vous partie d’une équipe qui travaille en mode Agile, et qui organise un Planning Poker dès lors qu’on lui demande une estimation. Peut-être ressentez-vous dans votre équipe une sorte de lassitude, voire de mécontentement  quand se profile devant vous un atelier de release planning interminable. Passer 5 heures à estimer 80 ou 90 User Stories peut effectivement être un peu lassant.

eXtreme Quotation est une technique qui consiste à avoir une première estimation d’un backlog en quelques minutes seulement. Le secret, qui n’a rien de magique je vous rassure, consiste à estimer très rapidement une grande partie des User Stories qui ne pose finalement aucun problème d’accord dans l’équipe. Le déroulement est le suivant :

• Les User Stories sont disposés sur une table. Sur une autre table, ou sur un mur, on identifie plusieurs emplacements chacun correspondant à l’une des tailles du Planning Poker (0, 1/2, 1, 2, 3, 5, 8, 13, etc., même le ?). L’équipe prend connaissance des User Stories sans en parler.
• Une première itération a lieu. Celle-ci est très courte : entre 2 et 5 minutes grand maximum. Pendant cette itération, chacun peut prendre une User Story et la déplacer sur l’autre table en lui affectant une taille. Personne ne se parle. Les membres de l’équipe peuvent cependant demander un éclairage au Product Owner. Dans le temps imparti, il faut dans l’idéal que toutes les User Stories se trouvent sur l’autre table, qu’une taille lui soit affectée ou non (grâce au ?)
• On enchaine avec une 2e itération, plus longue (10-12 minutes). Lors de cette itération, les membres d’équipes ont le droit de déplacer les User Stories, s’ils trouvent que la taille affectée n’est pas la bonne, mais toujours sans se concerter. Ce que je conseille de faire, c’est de mettre un petit point sur la carte de la User Story chaque fois qu’elle est déplacée.
• On réalise enfin une 3e itération encore plus longue (20-25 minutes) lors de laquelle les membres continuent à déplacer des User Stories mais peuvent se concerter.

Généralement, on observe qu’un grand nombre de User Stories n’ont pas bougé (celles qui n’ont pas de point). D’autres en ont peu, et certaines en ont beaucoup. Au bout de ces quelques itérations, on demande à l’équipe son niveau de confiance (en mode ROTI) quant à l’estimation globale. Le résultat est assez étonnant, car ce niveau est assez élevé.

En fait, on vient d’éliminer les User Stories les plus « évidentes » en quelques minutes. Certes, il en reste encore qui posent question, et là un Planning Poker complémentaire peut s’avérer intéressant. Mais le temps gagné est considérable !

On peut reprocher à cette approche le manque d’échanges et le fait que l’on perd la possibilité de laisser chacun s’exprimer sur l’estimation (ce qui n’est pas totalement vrai…). Pensez que cet atelier sert à estimer beaucoup de User Stories, plutôt à l’échelle d’une release. Vous aurez toujours le temps de confirmer ces estimations lors des sprint plannings avec votre jeu de cartes. Si vous cherchez des pistes pour réaliser cet atelier, allez quand même à la source ici. Et vous avez un feedback de participant à l’atelier ici.

Sélectionner des sessions

Ce que j’ai retenu comme idée forte dans cet atelier, c’est la capacité à régler 80% du problème (si je suis la loi de Pareto) en très peu de temps, c’est-à-dire l’ensemble des questions qui font naturellement consensus. Et c’est justement le sentiment que j’avais en 2011 pour notre première édition de l’Agile Tour Montpellier : beaucoup de temps passé à discuter, en arrivant à un consensus uniquement par une prise de pouvoir de l’un des membres. Je me souviens que nous avions éliminé les sessions qui nous intéressaient moins, mais que nous avions dû repêcher dans ce stock pour composer un programme et remplir les slots horaires.

Il y avait donc deux problèmes à résoudre : être plus efficace dans notre choix, et ne pas perdre de temps dans la composition du programme une fois les sessions choisies.
La cause profonde, à mon sens, du deuxième problème est que nous n’avions pas pris assez tôt en compte les contraintes imposées par le programme. La solution a donc consisté à intégrer très tôt le programme et les slots horaires dans notre réflexion. A chaque fois que quelqu’un voulait une session, il fallait qu’il lui trouve une place dans la grille du programme.

Et pour être plus efficace et résoudre notre premier problème, nous avons opéré pour selon eXtreme Quotation, sauf qu’au lieu d’estimer, il fallait choisir des sessions :

• En préalable à la session de sélection, chacun devait prendre connaissance des sessions proposées. Le fait de découvrir sur place leur contenu est une grande perte de temps.
• Lors de la première itération, chacun devait prendre les sessions qu’il voulait voir et les disposer dans la grille du programme, tant qu’il y avait de la place. Les inversions étaient interdites. Seule chose autorisée : déplacer une session déjà sélectionnée pour la disposer ailleurs dans la grille et ainsi faire de la place. Nous avions timeboxé 2 minutes, mais à plusieurs (une bonne dizaine), tout cela s’est déroulé en 20 secondes ! En tout cas, nous avions une première grille.
• Lors de la 2e itération, là nous avions droit aux inversions, en ayant simplement le droit de poser des questions sur certaines sessions. Pas de discussion ou de débat sur l’intérêt d’une session ou d’une autre, juste de l’information neutre. Chaque fois qu’une session était retirée du tableau ou qu’une nouvelle l’intégrait, on devait marquer un point sur la carte correspondante. Nous avions prévu 12 minutes pour cette itération. A la fin, il y avait un certain nombre de sessions laissées de côté que personne n’avait disposé sur le tableau : elles se trouvaient sur la table et n’avaient aucun point. A l’inverse, celles présentes sur le tableau et qui n’avait pas de point non plus étaient les sessions que personne n’avait envie de rater, en tout cas au détriment d’une autre. Nous avons réglé ensemble le sort de ces deux types de sessions, en se demandant au préalable si par hasard l’une des sessions éliminées pouvaient être repêchées.
• Lors de la 3e itération, qui dura 25 minutes, nous avions le droit de discuter, débattre des sessions pour se faire un avis. A la fin de cette itération, nous avons de nouveau fait le tri, en commençant par les sessions qui avaient le moins de points. Pour celles qui se trouvaient sur le tableau, nous avons validé celles que nous voulions conserver. Celles qui étaient sur la table pouvaient être repêchées, ou à défaut étaient éliminées.
• Restaient celles avec un grand nombre de points. Celles-ci posaient beaucoup de questions. Pour les traiter, l’un de nous a proposé un double dot-voting : nous avions un certain nombre de points positifs et négatifs à distribuer. A l’aide d’un calcul savant nous en avons donc écarté certaines et conservées d’autres. Notre programme était établi !

Nous concernant, nous avons séparé en 2 sessions de sélection : l’une pour les ateliers, l’autre pour les conférences. Certes, tout n’était pas parfait, et certains verraient d’un bon oeil certaines améliorations. Je pense que si chacun vient avec des questions précises, et que l’ensemble démarre par un tour de table (pas trop long) de ces questions, cela peut permettre à tout le monde de se faire un avis, ce que le format initial ne facilitait pas. Bien d’autres améliorations peuvent être envisagées. En tout cas le coup d’essai a été accueilli positivement.

Il ne faut pas oublier que l’élément clé, c’est qu’on se projette très tôt dans la grille et dans les contraintes de sélection fixées (exemple : pas plus de 2 sessions pour un orateur, minimum de 30% de sessions de locaux, etc.). A la fin de chaque itération, il fallait que la grille ne contienne pas de vide, et ne soit pas surchargée par rapport à sa capacité.

Ce ne sont que des principes

Lorsque j’ai fait cette proposition de fonctionnement au groupe, j’ai senti beaucoup d’interrogations voire certains rejets. Comment peut-on adapter une pratique d’estimation à la sélection de sessions ?

Il faut simplement comprendre que le premier problème que résout eXtreme Quotation, ce n’est pas : Comment faire pour estimer ? C’est, à mon sens, avant tout une pratique qui veut accélérer le traitement d’un ensemble d’éléments important en faisant émerger très vite d’un côté ceux pour lesquels il y a consensus, et ceux pour lesquels il y a débat, tout cela de manière itérative évidemment. Et ce principe, puisque c’est avant tout un principe, se duplique à l’infini.

Lorsqu’on apprend une pratique, il est souvent intéressant de dépasser la seule pratique et comprendre son intérêt. C’est comme cela que l’on fait émerger des principes que l’on peut essayer d’appliquer ailleurs. Cette capacité d’abstraction n’est pas innée. Cela s’apprend par la pratique, justement, et c’est ce que j’essaye de faire continuellement.
N’hésitez pas utiliser cette façon de procéder, à la décliner, la challenger, ou la tordre en deux si ça vous chante. Il n’y a pas de licence (si ! copyleft !), ni de nom officiel d’ailleurs, car rien n’a été « inventé ». Mais si vous tentez de l’appliquer, je vous demanderai juste de donner du feedback à travers un billet de blog que vous référencerez dans les commentaires ci-dessous, ou directement en commentaire. Merci ! 🙂 Et Merci à Guillaume et Jonathan d’avoir partagé cela à travers une session !