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.

Lean chez France Telecom

Il s’en passe des évènements en ce moment et je n’ai pas la place de tout raconter … ou presque

Lundi dernier, à la demande d’une amie en prestation chez FT, j’ai effectué une visite chez France Telecom pour présenter l’expertise de Yahoo dans les domaines du Lean et de l’agilité. Une quinzaine de personnes étaient dans la salle pour 2 heures de présentation du « Lean Software Development » puis 1/2 heure de discussions ouvertes.

Je pense encore une fois avoir fait mouche en suscitant des interrogations et en créant de l’intérêt pour le Lean et les approches Agile. Les participants n’étaient pas toujours d’accord avec ce que je disais, ce qui n’est pas inhabituel, mais il m’a semblé que la résistance au changement était particulièrement forte.

Ken Schwaber me disait un jour « les gens sont terrorisés à l’idée d’échouer avec une méthode qu’ils ne connaissent pas mais sont rassurés par échouer avec une méthode qu’ils connaissent bien« .

C’est un peu mon sentiment à l’issue de la présentation. L’équipe n’est pas satisfaite de la méthode qu’elle utilise et constate beaucoup de problèmes mais elle hésite a utiliser une autre méthode que « la bonne méthode », celle qui est définie dans les manuels qualité de FT.

Rester dans la « zone de confort » ou prendre des risques pour être plus efficace, je peux comprendre que le choix est difficile mais il faut clairement opter pour le mouvement et l’amélioration permanente.

J’aimerais bien pouvoir aider FT a évoluer dans le sens de l’agilité et j’espère que l’équipe va suivre mon conseil et faire un bilan en utilisant un SVM (Stream Value Mapping).

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 …

Travailler moins pour produire plus

Depuis déjà longtemps je recommande aux managers qui veulent améliorer leur productivité de ne pas charger leurs équipes à 100% et de ne pas les obliger à travailler plus longtemps.

A première vue, c’est contradictoire. En effet, comment produire plus en planifiant moins de tâches à réaliser et en travaillant moins d’heures.

Mais en fait, ca marche. C’est mon retour d’expérience personnel pour l’avoir mis en pratique sur des projets dont j’étais le chef de projet (cycle en V).

J’ai trouvé une explication rationnelle de ce phénomène dans le Lean Software Development qui explique, entre autre, que la meilleure productivité est atteinte lorsque l’on fait 1 seule tâche à la fois (passer d’une tâche à une autre génère un gâchis de 45 minutes ==> 3 tâches par jour = 2 heures de productivité nulle = 30% du temps de travail non productif). Le principe du ‘Pull’ plutôt que le ‘Push’ contribue également fortement à ce résultat.

Scrum implémente ces principes par structure puisque les efforts de l’équipe sont focalisés sur un seul objectif à la fois qui est la tâche de plus haute priorité et que le ‘pull’ est de rigueur lors du sprint planning meeting.

Il est donc rassurant de voir des mesures qui viennent confirmer ce que je recommande depuis plusieurs années. Le graphique qui illustre cet article est basé sur des mesures réelles chez OpenView Venture Partners et montre clairement que les équipes Scrum atteignent leur maximum de productivité autour de 35 heures (rappelez moi la durée légale du travail en France ?) et que même en travaillant 60 heures par semaine, les équipes en Waterfall n’atteignent que 50% de cette productivité.

Hyperproductivité avec Scrum

Superbe post sur le blog de Jeff Sutherland (en anglais) avec la description précise de la méthode utilisée par Scott Downey chez MySpace, pour mettre en place Scrum dans ses équipes.

Scott (Agile Coach) propose une méthode en 7 points pour passer à Scrum

1. Toutes les personnes de l’équipe doivent être formées par Scott à Scrum avant le premier sprint
2. La durée de chaque sprint est d’une semaine (*)
   
3. La définition du done est prédéfinie par Scott (User Story terminée + Code terminé + Pas de défauts connus + Approuvé par le Product Owner + Prêt pour mise en production)
   
4. Toutes les estimations sont faites en « story points »
5. Un « radiator » physique est utilisé et les tâches sont représentées par des Post-It
6. Toutes les cérémonies (Démo, Rétro, Revue PB, Estimation, Engagement du Sprint) sont regroupées en 1 seule réunion de 4 heures par semaine maximum
7. Le multi tâche est INTERDIT, le travail doit se faire dans l’ordre des priorités

Aucune dérogation n’est autorisée et l’équipe doit se plier à ces règles (qui sont donc parfois imposées) tant que l’équipe n’a pas prouvée sa maturité en remplissant les 3 critères suivants

1. L’équipe est Hyper Productive (>240% des objectifs initiaux)
2. L’équipe a réalisé avec succès 3 sprints consécutifs
3. L’équipe a identifié une bonne raison business pour changer une des 7 règles précédentes

Je viens de finir la lecture complète … et je suis totalement bluffé !

(*) A un développeur qui dit « mais en 1 semaine, je n’ai le temps de rien faire« , Scott répond simplement « alors une simple règle mathématique me conduit à penser que tu produiras 4 rien en 4 semaines« 

Agilité et country

Qui a dit que je n’étais pas Agile !

Pour ceux qui ne sont pas convaincu, jetez un oeil sur le Blog de Bruno, et admirez mon groupe de danse country en pleine démo le week-end du 6-7 septembre (je suis celui avec le chapeau … c’est pourtant facile … bon, j’ai également une moustache!).

Sinon, pour ce qui est de la line danse, je n’ai pas encore trouvé qui est le product owner et il est vrai que la définition du done varie un peu suivant l’état de fatigue du danseur … mais quel bonheur de se faire plaisir sur cette musique !

Dans 15 jours c’est démo à la foire au chèvres de Champ sur Drac … interdiction de rire

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

Bravo Pascal !

Juste un petit mot pour féliciter Pascal d’avoir son nom dans ce livre sur MySql (en remerciement d’une relecture assidue). Plus d’information sur DBNews

Lean chez THALES

Suite à ma présentation du « Lean Software Development » dans le cadre d’une soirée des Anciens Elèves de l’Ensimag, Emmanuel Chenu et Nicolas Blanpain de Thales à Valence (Drôme) m’avaient demandé de faire la même présentation sur leur site, et nous avions convenu de la date du 9 septembre (hier).

A mon arrivée, je suis accueilli par Manu et Nico accompagné de la responsable de la communication qui m’apprend que des affiches ont été faites et que des relances ont été envoyés aux employés. Après un tour rapide des bureaux (en particulier le bel open space Agile dans lequel travaille l’équipe de Manu et Nico) nous nous dirigeons vers la salle de présentation.

La salle fait près de 120 places et elle sera entièrement remplie !

Honnêtement je ne m’attendais pas à avoir autant de personnes devant moi, mais ce n’est pas une première pour moi alors cela ne m’a pas stressé outre mesure. Après une introduction du responsable Lean chez Thales (oui, oui, ils ont lancé cette démarche en interne), j’ai fait environ 1h45 de présentation devant une assemblée constituée à 45% de personnes du Logiciel et 55% de personnes de l’électronique ou autre.

J’espère avoir été suffisamment bon pour créer de l’intérêt ou de la curiosité pour cette approche parmi les participants et que cela aidera Manu, Nico et quelques autres dans leur « croisade » pour implémenter les méthodes Agile au sein de leur société.

Un grand merci à Manu, Nico et toutes les personnes de Thales qui ont fait de cette présentation un succès.