Agile, Lean, Scrum et informations diverses
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.
Voici quelques jours que la conférence s’est déroulée et je peux vraiment dire que c’était un vrai succès du fait de tous les retours positifs reçus des participants.
Les 201 personnes présentes (soit 2 fois plus que l’objectif initial) ont plébiscité l’invité d’honneur qui a vraiment lancé la conférence sur de très bons rails (excellente prestation de Jérôme Barrand) puis se sont naturellement répartis dans les autres salles pour écouter les différents orateurs qui ont été globalement très appréciés.
Nos craintes d’organisation sur la gestion de l’accueil, la répartition entre les salles et le timing de l’évènement ne se sont pas transformées en problèmes, et les buffets gratuits, pause café et dinatoire, ont été appréciés par tous. Bien entendu certains points sont à améliorer (merci à tous ceux qui nous ont donné un feedback) et nous tenterons de faire encore mieux l’année prochaine.
Un grand bravo à toute l’équipe organisatrice pour cette première sur Grenoble et ce succès qui fera date.
Quelques photos ici : http://www.flickr.com/photos/23117434@N00/
A lire absolument, le retour d’Eric Lefevre http://blog.valtech.fr/wordpress/2008/10/12/retour-sur-agile-tour-grenoble/ et ses photos http://flickr.com/photos/elefevre/sets/72157607935469125/
A lire également, le retour d’Aline http://techaline.wordpress.com/2008/10/13/pour-etre-en-forme-soyez-agiles/
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:
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.
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:
Merci emmanuel pour cette traduction en Français de l’article de Scott Ambler intitulé Beyond Functional Requirements On Agile Projects.
Traduction disponible ici: http://www.ehsavoie.com/2008/10/dpasser-les-exigences-fonctionnelles.html
Il faut rendre à César ce qui est à César et donc à Pascal Van Cauwenberghe et Portia Tung ce qui leur est dû (ce sont 2 personnes vraiment très sympathiques que j’ai eu l’occasion de rencontrer à Toronto lors de leur session de présentation des « 9 cases »)
Ce sont eux les auteurs de ce jeu qui est sous licence Creative Common à l’adresse suivante: http://agilecoach.net/Materials.html
La seule chose que j’ai développé est un jeu de slides en Français reprenant les différents points de la théorie des contraintes et décrivant le déroulement du jeu (je mettrais ces slides sur le site du CARA dès que possible).
J’ai animé en interne 2 sessions du jeu « Au secours mon processus m’étrangle » pour permettre au participants de mieux connaitre la théorie des contraintes. Ces sessions de 2 heures ont été très dynamiques et j’ai pris un réel plaisir à voir les 7 acteurs discuter et argumenter pour trouver la meilleure organisation pour produire le plus de bateaux et de chapeaux en papier en 5 minutes. Les feedbacks sont globalement très positifs, je retiens donc cette session à mon « catalogue » auquel je vais tenter d’ajouter d’autres jeux agiles dans le futur.
En résumé, la théorie des contraintes c’est:
Sachant cela il est vraiment dommage que la plupart des entreprises ne pensent qu’à l’élévation, que ce soit pour augmenter la production (quel manager n’a pas dit: « je n’ai pas assez de ressources », sans chercher à améliorer le système) ou pour réduire les coût (plan de licenciement).
Ces sociétés devraient mieux connaitre la théorie des contraintes pour commencer par mettre en place de l’exploitation et de la subordination ce qui leur permettrait d’améliorer leur système (le flux de sortie) par des actions peu ou pas onéreuse.
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:
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 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 :
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.
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).