Au programme de l’évènement, une présentation du Lean pour le logiciel (votre serviteur), un Casino Game dans un espace ouvert (c’est une première pour moi), et beaucoup de présentations sur le Lean dans toutes ses déclinaisons (Lean et PLM, Lean et ERP, Lean Engineering, Lean Office …).

J’espère bien en apprendre beaucoup

En collaboration avec Fujitsu et l’Institut Lean France, Télécom ParisTech a le plaisir de vous inviter à la sixième séance du séminaire « Lean et Système d’information. »

Ce séminaire aura lieu le jeudi 7 octobre 2010 de 9h00 à 12h30 (café accueil à partir de 8h30) à Télécom ParisTech (46 rue Barrault, Paris 13e).

Régis Médina, et d’autres présenteront des sujets forts intéressants (voir le programme) … malheureusement je ne suis pas disponible

Et nous voilà reparti pour une nouvelle année avec plein de nouveautés

si, pour de nombreuses personnes qui comme moi ont des enfants scolarisés, l’année démarre en Septembre
.
.
.
.

• Des changements chez Agiletoyou avec des forces vives supplémentaires … Yeah !
• Des nouveaux challenges comme la mise en place d’une contractualisation agile pour les marchés publics … Pas facile !
• Plusieurs conférences en Septembre où je suis orateur … Chouette !
  • 14 Septembre à Lyon : 3ème matinale Agile organisée par le Cluster Edit – Piloter l’Agilité
  • 15 Septembre à Paris : Université d’été Daylight – Lean + Casino Game (jeu du Kanban)
  • 30 Septembre à Annecy-le-Vieux : Salon Progiciel organisé par Thésame – Lean + Casino Game (jeu du Kanban)
• La finalisation de la conférence AGILE GRENOBLE 2010 le 23 novembre à Grenoble sponsorisée par l’Agile Alliance, la METRO et de nombreuses sociétés de la région … Encore un effort !

Je vous donnerais plus de détail au fil du temps sur ces évènements mais je vous souhaite à tous une bonne reprise et beaucoup d’agilité pour la période à venir.

La lecture de cet article (Les étranges dessous de l’affaire Toyota) donne une vision nouvelle de la situation, et qui, même si je ne peux pas juger de sa véracité, me semble très intéressante à lire.

Intox et contre-intox diront certains, pourquoi pas, je ne connais ni le rédacteur de la note, ni la fiabilité du site knowckers.org, mais je vous laisse vous faire votre propre impression (merci pour le pointeur Franck )

Bien souvent les équipes de réalisation sont conscientes de cette dette mais ont un réel problème pour trouver du temps pour s’en occuper. Les Technical Story spécifiques sont bien souvent repoussées dans le bas du Product Backlog par le Product Owner et l’ajout de quelques items de qualité de code dans le TERMINE (DONE) est une bonne pratique mais bien souvent insuffisante pour s’attaquer réellement à cette dette.

Alors comment faire ?
Un de mes clients a trouvé une solution sans la chercher et tout cela grâce au Kanban.

L’objectif initial de ma mission était d’améliorer le fonctionnement de l’équipe de réalisation et ses interactions avec les équipes produit. Plutôt que de mettre en place Scrum et ses cérémonies que je ne trouvais pas vraiment adapté au contexte de ce client et à son fonctionnement, j’ai préféré conseiller l’approche lean et la mise en place d’un kanban comme outil de management visuel du cycle de vie des fonctionnalités.

Depuis quelques semaines ce Kanban est en place avec une colonne par étape et les limitations de WIP (Work In Progress) bien visibles. Cet outil a fait clairement apparaître un goulot d’étranglement (« Bottleneck ») au niveau de la validation fonctionnelles des exigences (~UAT) qui est en cours de traitement, et donc les tâches en amonts ont une tendance à s’entasser devant ce goulot. L’effet induit pour l’équipe technique est qu’il n’y a plus de place vide sur le Kanban (WIP) pour démarrer les réalisations et donc, d’une certaine façon, qu’elle n’a rien à faire !

Cette opportunité a immédiatemment été utilisé par l’équipe pour s’attaquer à la dette technique (une forme de 5S), ce qui leur permet de  passer du temps sur cette activité tout en sachant que cela ne pénalise pas la productivité totale puisque, par définition, la vitesse du flux de sortie est subordonnée par le goulot, donc tant que le goulot est alimenté en permanence le système est à son maximum de vitesse.

Et vous, comment trouvez vous du temps pour réduire votre dette technique ?

Vendredi dernier était le jour choisi par mon client pour la session de VSM. Toute l’équipe était réunie dans une même salle avec pour seuls outils un tableau blanc, des marqueurs et des cerveaux prêts à fonctionner … il ne me restait plus qu’à faire « prendre la mayonnaise »

… 2h00 plus tard, le VSM était réalisé et la discussion était vive sur les ratios obtenus pour les 2 cycles de vie analysés (12% et 3 %) et quelques idées d’amélioration étaient même déjà discutés.

Le fait de rendre le gaspillage temporel visible sur un tableau permet à l’équipe de s’appuyer sur ce support pour discuter, évaluer des pistes de solutions et inviter simplement d’autres acteurs à la réflexion.

Cela confirme que le VSM est un outil particulièrement performant et comme il est plutôt simple à mettre en place, pourquoi s’en priver.

(*)VSM : Technique qui consiste à partir du client et de son besoin, puis d’identifier toutes les opérations « utiles » qui s’enchaînent avant de revenir au client avec un besoin satisfait. La durée de chaque opération est notée, de même que les temps pour passer d’une opération à une autre et le ratio final est calculé en divisant la somme des temps utiles par le temps total. La difficulté réside dans l’évaluation des durées moyennes et la notion d’opérations « utiles pour le client ». (Wikipedia en anglais)

L’approche Lean se focalise sur la satisfaction du client final, et en particulier cherche a éliminer les gaspillages de temps et donc à livrer le plus rapidement possible au client final.

Il m’a toujours semblé qu’il n’y avait pas d’antinomie entre les 2 approches … et pourtant !

En Scrum, lorsque les items du Backlog sont déclinés en tâches lors du Sprint Planning Meeting, il est recommandé à l’équipe de choisir en premier les tâches associées aux items de priorités les plus fortes et de respecter ces choix quoi qu’il arrive. Le Product Backlog est renseigné avec différents éléments, des exigences fonctionnelles, des besoins non-fonctionnel et des bugs.

Cette façon de procéder est basée sur quelques principes :

• Répondre aux attentes du Product Owner qui cherche à produire de la valeur ajoutée rapidement
• Éviter les changements de contexte qui consomme beaucoup de temps à l’équipe
• Assurer que des items du Backlog seront réellement terminés et qu’il ne sera pas nécessaire de revenir dessus

De plus,à titre personnel, je note bien souvent un intérêt grandissant au sein de l’équipe lorsque tous les membres travaillent sur le même item, l’écoute et l’entraide sont alors nettement meilleurs.

Pour le Lean, la satisfaction du client et la réduction des coûts passent en premier, et il est donc nécessaire de chercher à réduire les temps moyens d’attente. Lors du XP Days, Marie-Pia nous a présenté un exercice simple pour illustrer ce principe qui consistait à faire passer 15 passagers à la douane avec le moins d’attente possible sachant que les certains passagers passent en 1′, d’autres en 4′ à 7′, et certains entre 15′ et 25′. La solution optimum pour réduire le temps d’attente moyen des passagers consiste à spécialiser un douanier dans les passagers rapides.

En général, la correction des bugs prend moins de temps que la réalisation des exigences fonctionnelles, dans la logique du Lean, il serait plus efficace de gérer un backlog de bugs indépendant et dédier 1 ou 2 membres de l’équipe à leur correction. De plus, cela pemettrait d’éviter de dire aux utilisateurs que leur « petit » bug ne sera corrigé que dans 4 sprints compte tenu des priorités existantes, ce qu’en général il ne comprend pas … à juste titre.

Coté méthode Scrum, la recommandation est de gérer les priorités de tout ce qui est à faire – bugs inclus – à un seul endroit, le Product Backlog, puis de respecter les priorités … et donc de ne pas choisir la solution qui réduit le temps d’attente moyen des clients au minimum.

Etonnant non, comme dirait Mr Cyclopède

Non seulement c’était très bien organisé (cadre agréable, prestations de qualité …) et très intéressant, mais c’était également l’occasion de revoir et discuter avec un grand nombre des agilistes francophones, pour échanger des idées, des impressions, définir des actions à mener en commun … ou régler quelques contentieux si nécessaire

Pour ce qui est des sessions, voici mes impressions en vrac :

• J’adore toujours autant les sessions de Pascal VanCauvenbergue et Portia Tung. Blanche neige et les 7 nains m’a ravi et le Business Value Game m’a fortement intéressé et intrigué (la longue discussion qui a suivi avec Laurent Morisseau qui était co-animateur m’a même permis d’envisager des pistes supplémentaires …)
• Très belle initiative des Alchimistes Agiles, les bien connus François Bachmann et Jacques couvreur qui œuvrent de l’autre coté de la frontière suisse,  qui nous ont expliqués le déroulement d’une rétrospecttive à grand renfort de nains, de rennes, d’elfes et de petits enfants.
• Suite à la présentation du Kaizen Lean de Marie-Pia et l’évaluation de la variabilité d’un système, j’ai pris un vrai coup sur la tête vis à vis de l’efficacité de la gestion des priorités en mode Scrum … mais cela vaut un article complet … disponible dans les prochains jours … le temps que je me remette de mes émotions !
• Petite déception pour la session du Planning Game car je connaissais déjà trop bien le sujet.
• Un peu frustré par la version écourtée de la présentation de Godefroy Beauvallet sur les raisons des échecs des méthodes traditionnelles que j’aurais bien aimé voir en entier … mais timeboxing is timeboxing.
• Bien aimé le « Product Owner qui es tu, où es tu ? » des Guillaumes, et même si l’exercice a été entièrement tronquée du fait du grand nombre de questions posées par les participants.

C’est sur, j’y retourne l’année prochaine, et si les organisateurs le veulent bien, j’animerais même 1 ou 2 sessions.

Accès direct à la vidéo : Presentation Lean Software Development

Cela ne m’était encore jamais arrivé … et je dois dire que cela me fait tout bizarre de me voir et m’entendre comme si j’étais dans la salle … mais c’est un super feedback pour m’améliorer encore et encore

Outre le fait que James est un bon orateur, qui plus est particulièrement sympathique comme les discussions d’après conférence m’ont permis de réaliser, il est encore plutôt rare d’assister à des présentations Lean en France alors je vous propose de partager mon plaisir en vous donnant les grandes lignes dans cet article.

La présentation a été filmée et sera mise en ligne prochainement par Adacore … je vous tiendrais au courant

James nous a d’abord fait une présentation rapide du Lean, du travail de W. Edwards Deming, de la notion de « Profound knowledge » et de la vision système propre au Lean. Puis James nous a donné des résultats comparatifs des différentes approches en termes de productivite et de qualité (y compris l’externalisation dont la qualité est particulièrement faible comparée aux autres approches), pour conclure que le Lean est bien plus productif que toutes les autres approches, et l’Agilité est en 2ème place … mais assez loin

Pour ce qui est de la comparaison entre Lean et Agilité, James identifie 5 points :

• Optimisation :
  • Le Lean requiert de construire une « Profound Knowledge » pour garantir la réalisation d’un système oprtimisé (Domain Design, Change-Driven Design)
  • Agile considère que la conception émergera de la réalisation et que l’optimisation sera faite dans une seconde étape (Refactoring)
• Level of Focus
  • Le Lean se positionne au niveau de l’entreprise et considère des systèmes de systèmes (Hoshin Kanri, QFD)
  • Agile est au niveau projet et considère un unique système (Extreme Modeling, Scrul Teams, Scrum of Scrums, Business participation)
• Vérification/Validation
  • Le Lean préconise de faire les choses bien du premier coup et ensuite d’évoluer vers quelquechose d’encore mieux (Poka Yoke, Jidoka, Autonomation, Cleanroom, Formal Methods)
  • Agile démarre de rien pour évoluer vers la bonne solution (Test Driven Development, Refactoring)
• Variation
  • Le Lean considère le business comme un processsus, et comme tout processus ses variations doivent être analysées pour identifier celles qui sont communes de celles qui sont spécifiques (Control Chart)
  • Agile ne mentionne pas de concepts de variations différentes
• Prédiction
  • Le Lean impose la prédiction systématique basée sur des hypothèses (PDSA, TRIZ, Change-Driven Design)
  • Agile considère que le futur est inconnu et que l’approche empirique permet d’accumuler de la connaissance pour se rapprocher de l’objectif (Emergent Behavior, Short Development Cycles, Customer Involvment)

En conclusion, James considère que les approches Lean ou/et Agile sont pertinentes, bien plus que les approches traditionnelles, mais que les bénéfices apportés par le Lean sont à la hauteur de la difficulté d’implémentation. Les bénéfices de l’Agilité sont moindres mais l’implémentation est relativement facile.

A vous de faire votre choix !