Retour sur la soirée Hands-On Agilité

Le jeudi 6 Septembre s’est tenu un Hands-On sur le thème de l’Agilité, organisé par le groupe des DuchessFr. Pour rappel le format ‘Hands-On’ est une soirée lors de laquelle les participants viennent pour pratiquer la technologie présentée.
Luc Bizeul et Pascal Moreno, speakers de la soirée, après une présentation théorique, nous ont proposé un Serious Games, plus précisément un XP Game, mettant en avant différents aspects de l’agilité.
Voici plus en détail le déroulement de la soirée.

Déroulement de la soirée

En commençant par une présentation théorique, Luc Bizeul nous a présenté des notions fondamentales de la réalisation d’un produit et de l’agilité. Nous avons pu voir qu’il est fondamental de combiner les aspects réalisation, commerciaux et gestion d’un projet pour le mener vers le succès. Nous sommes habitués par nos métiers respectifs à ne pas toujours considérer ces trois aspects. Dans un modèle classique, les différents acteurs qui portent ces responsabilités sont distants; et cet éloignement n’est pas bénéfique et génère des perturbations. Les modèles agiles permettent de rapprocher les responsables du succès d’un projet : l’investisseur et l’équipe de réalisation.

Et si on commençait à jouer… 🙂

Les participants, développeurs pour la plupart, se sont répartis dans trois équipes afin de débuter le jeu. A chaque itération, chaque équipe a endossé tour à tour le point de vue du client puis du développeur:
rôle du client: validation du fonctionnel
rôle du développeur: estimation des tâches, constitution du sprint backlog

En pratique, nous avons en tant que client, vérifié que les user stories proposées (gonfler des ballons de différents diamètres, faire des pliages en papier de bateau/chapeau, faire des châteaux de cartes, trier des cartes), étaient claires fonctionnellement.
Puis en tant que développeur, nous avons constitué notre sprint backlog en sélectionnant certaines stories, en se basant sur leur  valeur métier et leur complexité (déterminée en fonction des compétences des membres de notre équipe notamment).
Est venu le temps d’exécution de ces stories, puis la phase de démonstration au client pour valider le travail effectué. Cette dernière phase a permis de soulever des points très intéressants sur notre façon de travailler et réfléchir, en voici deux exemples assez significatifs sur une tâche relativement claire a priori “Gonfler 5 ballons de 40cm de diamètres”  :

  • Nous tentons cette tâche relativement facile d’après nous : nous piochons 5 ballons, gonflons. En moins de deux minutes nous avons nos 5 ballons, ils sont assez grands, nous sommes sûrs de nous et demandons la validation de cette tâche. Et là c’est le drame, ça ne va pas du tout. En effet, nos ballons sont de plusieurs couleurs et pas du tout celle attendue. Nous n’avons pas discuté des critères d’acceptation du client, évidents pour lui, complètement inconnus pour nous. Nous devons recommencer, mais avec 5 ballons rouges cette fois.

  • Nous recommençons, nous avons 5 ballons rouges. Nous avons présenté notre travail au client afin qu’il le valide: tous, sans exception, avons gonflé des ballons trois fois plus gros que nécessaire. Ceci montre l’importance de prendre le temps de réfléchir avant de se lancer dans une réalisation. Réfléchir en amont permet de gagner du temps. En n’ayant pas fait cet effort, nous avons d’une part perdu du temps en gonflant des ballons trop gros, et d’autre part nous nous sommes mis en difficulté (il est plus facile de faire le noeud d’un petit qu’un gros ballon).

Une remarque intéressante qui nous a été soumise est de ne pas chercher à lister des critères d’acceptation en posant une liste de questions sans fin (cela agace le client, c’est évident pour lui), mais plutôt de se demander pourquoi une tâche est réalisée.

A la fin de cette première itération, nous avons été invités à constater quelle proportion de notre temps avait été employée à la planification et à la réalisation. Combien de stories aurions-nous pu réaliser si nous avions utilisé le temps de planification en temps de pure réalisation ? Sûrement le double…  N’oublions donc pas dans nos projets que seuls les moments où une réalisation est en cours produisent de la valeur.

Nous avons fait une seconde itération du jeu. Cette fois-ci certaines équipes ont voulu paralléliser les tâches. En effet, lors de la première itération une seule tâche pouvait être exécutée par équipe. Etant en confiance sur ce premier tour, certains ont voulu rajouter un peu de complexité en exécutant deux tâches simultanées.
Cette idée est de se rajouter de la difficulté est intéressante: le client a t-il demandé plus? Veut-il plus de rapidité? rentabilité? En fait, non, le client était content, il n’avait rien exigé de plus. Pourtant l’envie de faire plus de la part de l’équipe était présente. Ceci a d’ailleurs soulevé un autre phénomène: la spécialisation. En effet, le fait de paralléliser des tâches conduit à choisir d’en déléguer à certaines personnes et pas autres, impliquant une spécialisation de certains membres de l’équipe. Si au premier abord cette spécialisation peut-être vue comme rassurante, il faut s’en méfier. Que se passe t-il lorsque la personne spécialisée part en vacances? Certes la spécialisation permet sûrement de gagner du temps ponctuellement sur certaines tâches, mais elle fragilise l’équipe lorsque le spécialiste s’absente. La spécialisation fait baisser la prédictibilité de l’équipe, or c’est la constance et la régularité qui vont souvent être privilégiées au long terme.  Il est donc important de laisser les personnes travailler sur tout type de tâches même lorsqu’elles ne sont pas les plus expérimentées ou efficaces dessus. Il ne faut pas oublier non plus les passages de compétences entre membres de l’équipe afin de viser une certaine homogénéité des savoirs.

La fin du jeu

Suite à cette seconde itération, nous nous sommes retrouvés autour d’un buffet afin d’échanger nos expériences diverses en agilité.
La soirée s’est terminée dans un bar autour d’un verre pour les plus courageux (passionnés ? ;-)).
Ce jeu nous a permis de mettre en évidence des problèmes et des situations que l’on retrouve sur nos projets. Comme pour toute séance de Serious Game, le jeu n’est qu’un aspect de ce qui est présenté. Ce qui va créer de la valeur, générer des réflexions et de l’apprentissage, c’est toute la partie debrief, questions, remise en question, identification aux situations de la “vraie vie”.

Notre ressenti

Ludwine

Ce que je retiens de cette soirée, ce sont d’une part les échanges avec les autres participants, et d’autre part les motivations de l’agilité.
L’agilité peut sembler superflue pour certains. Les concepts qu’elle met en avant ne sont-il finalement pas que du bon sens ? Pourquoi inventer cette notion d’agilité ? De mon point de vue, même si certains concepts agiles reflètent du bons sens, les énoncer clairement peut leurs faire prendre une toute autre dimension.
J’ai beaucoup apprécié le jeu et l’accent qu’il a mis sur les dangers d’une spécialisation ainsi que sur la précipitation dont on peut faire preuve lors de la réalisation d’une tâche. On néglige trop souvent les temps de réflexions, pensant peut-être à tort que ce sera une perte de temps : l’exemple de la taille des ballons nous montre justement le contraire.

Stéphanie

Souvent lorsqu’on parle d’agilité, on utilise tout le vocabulaire qui l’entoure : Scrum, ses rôles, ses artefacts, les pratiques “xp”, kanban et ses lead time ou cycle time… S’il est important de pouvoir nommer avec précision les concepts que l’on manipule, il est également essentiel de ne pas noyer ces mêmes concepts derrière des termes inaccessibles (pour le débutant en agilité ? voire une personne réfractaire ?) ou flous (par exemple, combien de définitions ou de listes de tâches/rôles d’un ScrumMaster peut-on trouver sur Internet ?). D’un point de vue personnel, j’ai donc fortement apprécié la partie présentation et les diverses parties debrief qui ne consistaient pas en de longues listes de vocabulaire, mais plus dans une clarification des idées derrière l’agilité.

Nombre de vue : 23

AJOUTER UN COMMENTAIRE