Catégorie : Experience

Agile Tour 2008 – Genève

Un saut de voiture à Genève hier après midi et voilà ma participation à l’Agile Tour 2008 de lancé.

Nous avons été accueilli au Genève Business Center par Jacques et François qui avaient organisé des sessions de présentations dans 2 salles en parallèle. Une 50aine de personnes étaient présentes, majoritairement novices à l’Agile que expérimentées à ce qu’il m’a semblé, et les échanges ont été nombreux et fructueux, que ce soit durant ou entre les sessions. Un grand merci aux organisateurs pour cette réussite, le prochain évènement d’importance sera les XPDays Suisse le 30 mars 2009 … restez à l’écoute.

J’ai eu l’occasion de présenter la démarche « Process » de Yahoo International de 2005 à 2008 et le basculement vers l’agilité à partir de 2006 avec des réussites diverses du fait de la différence de culture de certains pays.

Jeudi 9 Octobre, c’est le grand jour pour Grenoble, nous attendons plus de 200 personnes à partir de 13h30 pour un démarrage à 14h00 précise.

Quelques pointeurs:

Cycle en V

J’ai lu plusieurs articles récemment qui tendent à indiquer que le Cycle en V n’est pas applicable voir que c’est une aberration pédagogique. Pour ma part, je n’ai pas l’expertise suffisante pour dire s’il y a un aspect non pédagogique à l’apprentissage du cycle en V, mais je ne dirais pas que le Cycle en V n’est pas applicable.

J’ai eu l’occasion de pratiquer le Cycle en V à de nombreuses occasions et bien que je sois convaincu de la meilleure efficacité des méthodes agiles, lorsque je parle des mes expériences personnelles, celle que je trouve la plus réussie a été réalisée en Cycle en V … comprend qui peut !

J’étais le chef d’un projet qui consistait a réaliser un système d’arrêt d’urgence d’une centrale nucléaire de Lituanie. Je vous rassure tout de suite, le système est encore en parfait état de marche. Les logiciels de sureté nucléaire doivent être conformes à la norme CEI 60880 et se doivent de suivre un cycle en V très strict, pour vous donner une idée, même les documents de revue de document ont un cycle de vie. Ce projet a impliqué 20 personnes en pic de charge sur une durée de 18 mois, et nous avons commencé par les spécifications, puis la conception, puis le codage, les tests unitaires, l’intégration et enfin la validation. A l’arrivée, nous avons livré avec 3 jours de retard sur le plan initial (pas si mal au bout de 18 mois), pour une charge inférieure de 10% aux estimations et surtout, et c’est ma plus grande satisfaction, sans avoir à aucun moment demandé à l’équipe de travailler tard le soir ou le week-end.

Je pense qu’une grande partie du succès de ce projet est dû à mon approche agile/lean de la situation dont je retiendrais les points principaux suivants:

  • Planning/Gant précis à 3 semaines mais non détaillé au delà (le responsable logiciel n’a jamais vraiment voulu accepter que mon planning dépasse constamment les 18 mois – 29 mois au début – mais je me refusais à consommer du temps sur quelque chose qui allait forcément changer)
  • Point de synchro hebdomadaire d’une heure maximum le lundi à 9h (peu de perte de temps, adhésion des équipes) durant lequel chacun s’exprimait 3 minutes pour dire sur quoi il allait travailler durant la semaine
  • Plus 3 questions hebdo: Qu’avez-vous fait par rapport à ce qui était prévu? Pourquoi n’avez vous pas pu faire ce qui était prévu (bloqueurs)? Qu’avez-vous fait en plus que ce qui était prévu?
  • J’ai toujours demandé aux membres de l’équipe « combien de temps pour finir ta tâche » et ensuite je remettais le planning à jour. Je n’ai jamais dit « je te rappelle qu’il ne te reste que X jours pour finir ».
  • Affectation des tâches 1 par 1 à chaque membre, jamais de multi-tâches. Chaque membre de l’équipe connaissait la tâche qu’il devait commencer à la suite de celle en cours.
  • Planification d’une occupation maximale à 80% dans les plannings (les mercredi et vendredi après-midi étaient toujours chômés … du moins sur le Gant)
  • Souci constant d’anticipation de la synchronisation des échanges entre équipes (afin de réduire ce que je n’appelais pas encore ‘Waste’ ou ‘Muda’ – Cf. Lean Software Development) et des risques
  • Confiance de mise sur les travaux de l’équipe
  • Travail en équipe pour réduire la complexité des documents tout en respectant le format type et en obtenant la validation des autorités de sureté (parfois un peu équilibriste).
  • Proximité avec les équipes, je passais la plus grande partie de mon temps à me « promener » pour aller voir ce que faisais mon équipe, pas pour contrôler, mais pour comprendre ce qu’ils faisaient et comment ils le faisaient.

Je ne conclurais pas que le Cycle en V est une bonne méthode, mais simplement que la méthode n’empêche pas d’être intelligent.  L’être humain se doit de prendre le dessus et de rechercher en permanence des leviers d’amélioration et prendre des risques pour être plus efficace. Cela peut s’avérer payant, comme dans mon cas sur ce projet, ou parfois être source de conflit avec sa hiérarchie, mais le jeu en vaut la chandelle car le succès est plus souvent au rendez-vous.

A défaut de pouvoir être « pur agile », ce qui permet d’atteindre l’efficacité maximale, je dirais simplement à ceux qui sont dans l’obligation de suivre un cycle en V qu’il y a toujours des marges de manoeuvre pour être plus agile … il suffit de vouloir les trouver !

Avoir le réflexe Agile

Logo CARALors de la préparation de l’AT2008 (le 9 octobre à Grenoble), nous avons identifié une liste de tâches à faire avant le début de la manifestation (mise en place de tables pour l’accueil et le buffet, organisation des salles, affichage des posters …). Pour nous organiser au mieux, nous avons donc lister les tâches sur notre Wiki et de demander à des volontaires du CARA d’inscrire leur nom en face de chacune des tâches. Comme disent les anglais : « Cela fait du sens ».

Lors de notre dernière réunion de préparation, j’ai challengé cette approche car je ne la trouvais pas vraiment Agile. En effet, elle nécessite la présence d’un coordinateur (qui a dit un chef de projet ?) pour gérer les dépendances entre tâches et les impacts liés aux éventuels retards.

Nous avons donc décidé de nous organiser de la façon suivante :

  • L’équipe organisatrice identifiera l’ensemble des tâches, le nombre de personnes nécessaires pour la mener à bien et les classera par priorité (Product Owner)
  • Chacune des tâches sera écrite sur un Post-It qui sera affiché sur le mur de la salle de conférence (Scrum Master)
  • Les volontaires se retrouveront devant le mur de Post-It, prendront le premier Post-It disponible, réaliseront l’action et reviendront chercher une nouvelle tâche etc … (Team)

De cette façon nous pouvons démarrer dès que suffisamment de volontaires sont disponibles pour réaliser la première tâche, pas besoin d’attendre que tout le monde soit là, si un volontaire arrive en retard il ne pénalise pas le projet, nul besoin de coordination (pas de ‘muda’) car l’équipe s’auto-organise, et si une tâche prend plus de temps que prévu ce n’est pas un problème en soi.

Il n’y a pas que les projets informatique qui se prêtent à l’Agilité et avoir le réflexe Agile permet souvent de trouver des solutions plus efficaces que celles auxquelles nous pensons en premier lieu.

2 for Scrum and Scrum for 2 …

Régulièrement, des personnes viennent me voir pour me dire que compte tenu de la taille réduite de l’équipe (2 personnes), elles n’ont pas l’intention de mettre en place l’ensemble des cérémonies Scrum (les réunions comme les « Daily stand up » ou « Demo »)

Même si cela ne me plait pas vraiment,  en général je laisse filer car je n’ai pas vraiment d’arguments à leur opposer et je ne connais pas vraiment les risques qu’ils encourent à se comporter comme cela. Bien entendu, si la taille de l’équipe est de 3 ou plus, j’évoque les besoins de synchronisation, de prioritisation et de communication pour inciter ces personnes à mettre en place toutes les cérémonies Scrum. Mais s’ils ne sont que 2, je suis généralement moins convaincant car moins convaincu.

J’ai donc décidé d’expérimenter par moi même « Scrum for 2 » puisque je suis en charge d’un nouveau projet  où nous sommes 2 dans l’équipe (je rassure ceux qui me connaissent, il n’a rien de technique).

Je suis le Product Owner, Laurent est le Scrum Master et l’équipe de réalisation est constituée de Laurent et Moi 🙂

Nous allons appliquer la méthode « in the book » ce qui me permettra de mieux appréhender la plus value apportée par chaque cérémonie et avoir plus d’arguments à opposer à ceux qui veulent faire sans.

Bref, c’est une action à suivre …

Bravo ManU !

Je me joins à Claude (qui doit travailler la nuit à Toulouse car son post est daté de 00:06) pour féliciter ManU pour son excellent article sur les pratiques agiles de son équipe et surtout par ses illustrations grâce à de nombreuses photos réelles de leur espace de travail (je le sais, j’y étais il y a 2 jours).

Je recommande TRES FORTEMENT de prendre le temps de lire attentivement le document décrivant le retour d’expérience de ManU

Scrum – Premier echec

Cela devait bien arriver et c’est malheureusement arrivé !

Il y a 4 mois, J’ai coaché un projet en interne (durant 3 sprints de 2 semaines) pour aider les équipes à gagner en maturité sur la méthode Scrum que l’équipe utilisait depuis 3 mois. Je considère que ce coaching a porté ses fruits puisque l’équipe a pris conscience de certains de ses dysfonctionnements et a cherché à y remédier par elle même avec mon support. Le motivation de l’équipe était alors très bonne et la productivité supérieure à ce qu’elle avait été (bien que nous ne disposions pas de métriques fiables – comme une mesure régulière de la vélocité)

Aujourd’hui, force est de constater que ce projet s’éloigne de la méthode Scrum. Ce n’est pas encore visible sur la forme car l’équipe parle encore de Sprint, de « Scrum of Scrum » et fait des rétrospectives, mais sur le fond tout est changé et je vais me permettre de donner ma vision personnelle des raisons qui ont conduit à cela.

  1. Le management n’a pas eu suffisamment confiance dans la réussite de l’équipe auto-pilotée et a (re)commencé à faire du micro management pour se rassurer car lui aussi subit une très forte pression de la part de son management pour délivrer à temps
  2. Le conflit de priorité entre Produit (nouvelles fonctionnalités) et Engineering (Stabilité) n’a pas été résolu. La méthode Scrum oblige à prendre une décision, à la rendre visible dans le backlog et permet de focaliser les énergies sur 1 objectif commun. Plutôt que de prendre des décisions difficiles et lourdes de conséquences, les 2 entités ont préféré masquer le problème en changeant leur façon d’utiliser le Product Backlog et disant « on va faire un peu des 2 ». Le problème est toujours présent … mais comme on le voit moins, certaines personnes pensent qu’il est résolu (qui a dit que les managers croyaient en la Magie ?).
  3. Le micro management s’est traduit par un contrôle journalier de l’équipe sur la réalisation de tâches unitaires suivant un processus par étapes remis à l’ordre du jour (abandon du concept de sprint et surtout de ‘done’ en fin de sprint).
  4. Contrairement à la volonté de l’équipe, les ressources sont affectés à des tâches précises et chacun est responsable de sa partie. Fini l’engagement de l’équipe à délivrer itérativement quelque chose qui marche, voilà le retour de la justification individuelle !
  5. La plus grande partie du reporting actuel consiste à expliquer pourquoi l’avancement du projet n’est pas conforme à la roadmap définie initialement par … quelqu’un … sans implication de l’équipe. La seule question posée actuellement est « pour quand ce sera prêt ? » plutôt que « comment je peux t’aider à résoudre tes problèmes ? ».

Attention, mon propos n’est pas de dire que la méthode utilisée (Waterfall couplée à du micro-management) est mauvaise car je suis convaincu que l’équipe va délivrer les fonctionnalités demandées (j’ai moi-même utilisée cette méthode avec succès dans le passé). Mais comme pour la plupart des projets dans ce mode, ce sera avec du retard et avec un niveau de qualité non optimal (et cela devient déjà visible sur ce projet).

Mais je suis également convaincu qu’une approche Agile avec Scrum aurait permis de délivrer plus vite un produit de meilleure qualité. Car une équipe motivée, travaillant par petits incréments avec des objectifs clairs et partagés, est la plus grande chance de réussite d’un projet. Donc plutôt que de se concentrer sur le ‘pourquoi ca n’a pas marché’ il est plus important de se focaliser sur le ‘que reste-t-il à faire pour finir’.

Comme axe d’amélioration personnel, j’en retire qu’un coaching au niveau de hiérarchie supérieure aurait peut-être permis d’utiliser Scrum suffisamment longtemps pour prouver son efficacité et convaincre cette hiérarchie.

On apprend beaucoup de ses erreurs et puis il n’est pas dit que ce projet ne puisse pas revenir à l’agilité d’ici quelques mois, restons optimistes !

Scrum et Process – Mariage réussi

A toronto j’ai présenté une session avec Karl Scotland (qui a malheureusement quitté la société) sur l’historique de l’intégration de Scrum dans le « process framework » en vigueur chez Yahoo. Ce retour d’expérience décrit plus particulièrement la contribution des équipes Européenne à « l’agilisation » du framework entre 2006 et 2007.

L’article donne quelques informations sur les étapes de cette transformation, les difficultés rencontrées, les méthodes utilisées (mise en place de groupes locaux – le concept DICE) et les challenges toujours actifs.

En conclusion de cette article, nous considérons que le mariage est réussi entre la méthode Scrum et le Process Framework, à partir du moment ou les équipes en charge de la définition du process pratiquent le « inspect and adapt », ont l’ouverture d’esprit suffisante pour accepter les feedbacks et cherchent à faire adhérer (coaching) plutôt qu’à imposer (contrôle).

L’article est malheureusement en anglais, langue officielle actuelle de la communauté Agile, et je n’ai pas prévu de le traduire.

Accès à l’article en pdf : boutin-yahooeuropeagileexperiencereport