Scrum vs XP – La guerre des méthodes

La dernière enquête du French Sug (Lire Enquête sur les méthodes agiles en France) suscite bon nombre de commentaires sur les blogs ces derniers jours . Que ce soit ceux qui n’aime pas la façon dont XP est traité dans l’enquête (réduit à des pratiques) et appellent au boycott ou ceux qui remettent en cause le but non lucratif de l’association du fait que le formulaire contient le nom, la société et l’adresse mail.

Pour couper court à la polémique Scrum vs XP, je vous invite à lire l’excellent post de Denis (XP sans Scrum, Scrum sans XP) auquel je souhaite ajouter quelques mots. Lire la suite »

01 Informatique (Bis)

Après la parution sur Papier – et la difficulté de trouver des exemplaires … surtout en région Rhône Alpes … allez savoir pourquoi ? – 01 Informatique se met à l’heure du Web Communautaire et publie certains articles sur le web, en particulier le mien paru dans l’édition du 16 octobre 2008.

Accès à l’article en ligne : http://forum.01informatique.fr/infrastructure-f11/methode-agile-scrum-aide-des-developpeurs-yahoo-france-mieux-gerer-les-priorites-t211.html

C’est également un moyen d’avoir un retour direct des lecteurs dans les commentaires, et comme rien ne vaut le feedback direct du client, c’est parfait

Scrum For 2 … 5 itérations plus tard

Il y a 5 semaines, j’avais évoqué mes incertitudes sur l’application de Scrum pour une équipe de 2 personnes et je suis maintenant en mesure de faire un premier retour.

Scrum est parfaitement adapté à une équipe de 2 personnes et voici comment nous avons pratiqué:

• Le Product Backlog est consitué uniquement de Post-IT sur un mur proche de mon bureau (de temps en temps je remets à jour le Wiki avec les éléments identifiés sur les Post-IT)
• L’itération dure 1 semaine. Démarrage et Fin tous les Vendredis après-midi.
• Le Daily Stand-Up est formel et nous nous réunissons tous les matins vers 9h pendant 10 mn environ devant le mur de Post-IT
• Les critères d’acceptation de chaque item sont clairement définis et affiché sur le mur.
• Les tâches ne sont pas pré-affectées et il nous est arrivé plusieurs fois de prendre une tâche qui semblait « mieux » adaptée à l’autre Lire la suite »

Des tuyaux pour mieux aspirer le Web

Cela fait quelques jours qu’un collègue m’a montré comment on pouvait utiliser un produit sympa chez Yahoo appelé pipes.

En quelques clics, des drags & drops et un peu de savoir faire, il m’a été vraiment facile de faire une agrégation des différents blogs que je lis régulièrement. J’ai maintenant sur ma page d’accueil MyYahoo une seule zone mise à jour avec les derniers articles, classés par date, en lieu et place des 15 zones dont j’avais besoin précédemment. Et vive le « Keep it Simple » du Lean.

Ce n’est surement pas le seul outil à pouvoir faire cela, mais il est vraiment d’une extrème convivialité et simplicité d’utilisation, et comme c’est un outil Yahoo … je ne vais pas me gèner pour en dire du bien

Agile à l’international

Une de mes activités professionnelles consiste à promouvoir la méthode Scrum comme alternative aux méthodes traditionnelles en France et dans plusieurs autres régions du monde (Europe, Asie, Inde, Canada). J’ai appris beaucoup des succès et difficultés rencontrés, et en particulier l’importance de la culture propre à chaque pays sur la façon d’aborder l’Agilité.

Ce petit article ne se veut pas être une liste de vérités absolues mais simplement ma perception de la situation dans les différents pays régulièrement visités. De plus, il est important de limiter mes propos au périmètre de mon entreprise (les personnes avec qui je travaille) et ne pas généraliser à l’ensemble du pays.

FR : Une bonne implication des équipes techniques, mais une forte résistance du management dû à la crainte d’une perte de pouvoir, une volonté de micro management et globalement la satisfaction des méthodes traditionnelles (on échoue mais on sait pourquoi, donc tout va bien et on ne change rien).

UK : Une démarche purement individuelle basée sur l’atteinte des objectifs définis par le top management qui empêche la mise en place d’un vrai sentiment d’équipe. Un certain manque de maturité sur l’importance de la qualité logiciel (et les bonnes pratiques associées) et la satisfaction réelle à être le héros que tout le monde admire. Lire la suite »

Comment il a aidé les développeurs …

… à mieux gérer les priorités.

Article, au combien intéressant, sur le 01 Informatique d’hier expliquant la mise en place d’un simple outil pour faire prendre conscience à l’équipe que le fait de tout commencer en même temps conduit, le plus souvent, à ne rien terminer.

Bon d’accord, je ne suis pas impartial puisque je suis le sujet de l’article, mais j’assume ce plaisir narcissique et ne résiste pas à l’envie de le partager.

Google Chrome: Projet agile ?

Petit article sympa sur SearchSoftwareQuality.com décrivant la méthode utilisée pour le développement du nouveau GoogleChrome et la référence au « Bon Sens » mis en oeuvre chez Google. « Bon Sens » qui ne se veut pas être une des méthodes agiles reconnues (Scrum, XP …) mais qui intègre malgré tout de très bons principes agiles.

Parmi ceux-ci, je retiens plus particulièrement:

• La planification agile trimestrielle
• Des fonctionnalités minimales et très ciblées
• Des équipes auto-organisées
• Automatisation des tests (Unitaires, Système …) pour allez vite
• Livraison d’un « Build » fonctionnel toutes les semaines
• Prise de feedback d’utilisateurs (internes) permanente

Alors, Agilité ou Bon Sens … peu importe, pourvu que cela soit efficace pour l’entreprise in fine. Mais si votre équipe n’a pas la maturité nécessaire pour faire preuve de « Bon Sens », alors préconisez l’utilisation d’une méthode Agile avec discipline, puis le temps aidant, donnez lui plus de libertés.

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:

• Methods & Tools blog

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

Lors 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.