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.La méthode Scrum fonctionne également dans un contexte non logiciel ce qui est plus délicat pour la méthode XP. En effet, il est très efficace d’utiliser la méthode Scrum pour générer de la documentation ou pour gérer un projet personnel. La méthode XP est indissociable des pratiques d’ingénierie logicielle XP et dans les 2 contextes évoqués, plusieurs pratiques XP ne sont pas applicables, et au niveau de la méthode XP,  l’étape de « refactoring » n’est pas toujours réalisable en dehors d’un contexte logiciel.

La faiblesse et la force de Scrum vient de la définition du DONE (ou Terminé) qui est un aspect fondamental de la méthode (sans DONE pas de succès possible) mais dont la méthode ne précise pas la façon d’obtention.

La force vient de la liberté offerte à l’équipe pour obtenir le DONE et  permet d’appliquer Scrum dans de nombreux contextes hors du logiciel, puisque seul le DONE est vérifié.

La faiblesse vient du manque de pratiques pour obtenir le DONE dans un contexte logiciel. Il me semble donc naturel d’emprunter certaines pratiques proposées par XP car ce sont bien les plus efficaces (TDD, Pair Programming, Intégration Continue …).

Donc pas de guerre, mais simplement une façon intelligente d’utiliser les aspects les plus performants de chaque approche.

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

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
• Les cérémonies (Review, Rétro, Product Backlog Review et Sprint Planning meeting) se déroulent sur 1 heure maximum le vendredi de 14h à 15h.
  • La Review consiste à imprimer ce que nous avons produit (des standards de bonnes pratiques) et les mettre sur le mur afin de visualiser l’avancement du projet. Un mail est également envoyé à tous les stakeholders et reviewers (nous l’appelons le Friday Mail) et contient l’ensemble de la production de l’itération.
  • La Rétro est formelle et enregistrée sur le Wiki
  • La Vélocité de l’itération est calculée et enregistrée sur le Wiki
  • Le Product Backlog Review consiste à discuter des actions nouvelles identifiées durant l’itération (cela arrive fréquemment car le projet est dans sa phase créative – on ne sait pas encore vraiment où on va arriver, mais nous avons défini le comment nous allons y arriver) et de choisir les priorités des items.
  • Le Sprint Planning Meeting consiste à écrire les Post-IT de l’itération et les coller sur le mur
• Nous n’utilisons pas de BurnDown de sprint ou de Backlog (et pour l’instant cela ne nous manque pas vraiment)

Ce que nous a apporté la méthode Scrum sur ce projet de 2 personnes (à temps partiel) après 5 itérations

• Nous produisons des éléments chaque semaine car nous nous focalisons sur une liste de tâche réduite
• Notre engagement à produire quelque chose toute les semaines me semble plus fort car il est rendu visible sur le mur de Post-IT
• La vision des Post-IT nous focalise sur nos priorités de la semaine et cela nous permet de ne pas nous perdre dans des discussions intéressantes mais longues et stériles à ce moment du projet sur « vers quoi nous allons » (nous sommes en train de le découvrir itération par itération)
• L’affichage permet un gain de temps substantiel car il est très rapide de réécrire un Post-IT mal formulé puis de jeter l’ancien en le remplacant par le nouveau voir de jeter une Post-IT qui n’a plus de sens du fait de l’avancement du projet (cela nous est arrivé)
• La discipline avec laquelle nous réalisons les cérémonies Scrum nous donne la garantie de ne rien oublier (en particulier vrai pour la rétrospective car nous trouvons une idée d’amélioration à chaque fois)

Je suis maintenant convaincu que si nous n’avions pas été formel dans notre application de Scrum, nous n’aurions pas eu la même productivité sur ces 5 dernières semaines car j’ai clairement en mémoire une itération qui a été « sauvée » par l’application stricte de la méthode car sans elle nous aurions repoussée l’échéance à la semaine d’après et créé un précédent de mauvaise pratique.

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

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.

TW : Une curiosité naturelle pour tout ce qui est nouveau, mais freinée pas une hiérarchie omni-présente et omni-potente (tant technique que produit). Les équipes vivent l’agilité comme une pression supplémentaire car il est interdit de descoper pour ne pas « perdre la face ».

KR : La phrase qui résume le mieux ma perception m’a été dite il y a 18 mois « Alex, it’s incorrect to challenge ! » ce qui veut dire qu’il n’y a jamais de remise en cause de ce qui a été dit ou écrit. Le Scrum Master agit comme un chef de projet et la discipline est assurée, mais contrairement à ce que l’on pourrait croire, plusieurs bénéfices liés à Scrum dans ce contexte commencent à être visibles.

HK : Bonne implication des équipes techniques mais sous tutelle stricte de la direction produit (une relation client-fournisseur exacerbée du fait d’une relation excessive vis à vis de l’argent). Une fois la direction produit rassurée sur la possibilité de garantir des dates de livraison (4h de négociation au lieu de 1h initialement prévu), Scrum est en cours d’implémentation avec succès.

IN : Manque total de confiance du management envers les équipes techniques, ce qui se traduit par des responsables techniques qui veulent être maître de la situation en permanence. Ils ne doivent pas échouer sous peine de lourdes sanctions et donc ne laissent aucune liberté aux équipes (CMMi est par ailleurs un grand succès en Inde).

CA : Les Mr Jourdain de l’agilité, ils sont agiles (et pas font) sans le savoir ou presque, j’adore les canadiens Un esprit d’équipe ultra poussé (soutenu par le management qui s’implique) allié à une proximité avec la direction produit leur permet de délivrer des produits superbes qui sont de vrais succès commerciaux.  La taille réduite de l’équipe est surement le critère principal de succès, alors attention à ne pas perdre cet esprit lorsque l’équipe grandira.

Comme indiqué ci-dessus, ce n’est que ma perception actuelle retranscrite en quelques mots et je suis conscient que la situation est surement différente dans une autre société.

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.

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.

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

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 !

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.