Catégorie : Lean

La vélocité des bugs

bugs2Scrum définit la vélocité de l’équipe pour une itération comme étant la somme des points des User Story terminées à la fin de l’itération. L’évaluation de la valeur en points d’une User Story est souvent faite par l’équipe à l’aide du Planning Poker de façon autonome, il est donc vain de chercher à comparer des vélocités entre équipe (Cf. Du bon usage de la vélocité). Cette vélocité est un élément indispensable de la planification agile.

Mais le Product Backlog ne contient pas seulement des User Story puisque l’on y trouve également des exigences non fonctionnelles (souvent des demandes techniques demandées par l’équipe) et des bugs.

Alors les questions qui se posent sont :

  • Est-ce que la vélocité d’une exigence non fonctionnelle ou d’un bug a un sens ?
  • Doit-on estimer ces vélocités avec les mêmes pratiques ?

Continuer la lecture de « La vélocité des bugs »

Lean : Réduire les gaspillages

robinet_fuiteLa démarche analytique est celle qui semble la plus naturelle lorsque nous cherchons la cause de nos problèmes. Par ce moyen, les entreprises qui souhaitent réduire leurs coûts espèrent trouver et faire disparaître des « zones de production » qui n’apporte pas suffisamment de valeur ajoutée. En fait, l’organisation d’une entreprise est complexe et ces zones n’existent bien souvent jamais unitairement et la direction se résout à faire des coupes à l’aveugle dans ses effectifs ou moyens, et négocie à la baisse les coûts de prestation de service (avec bien souvent une baisse de qualité à la clef du fait du manque de formation et de motivation des sous-traitants).

Continuer la lecture de « Lean : Réduire les gaspillages »

Le Lean pour mes problèmes

Afin de mieux répondre aux attentes de nos clients, nous devons garder en mémoire que nous sommes nous même des clients avec des problèmes à résoudre. Lorsque je regarde les problèmes que j’ai a résoudre et que j’imagine avoir recours à un prestataire externe, j’utilise l’approche Lean pour définir mes attentes le plus clairement possible et passer les messages suivants au prestataire (sans ordre d’importance) :

  • Résolvez mon problème totalement (Build Quality In)
  • Ne gaspillez pas mon temps (Eliminate Waste)
  • Procurez moi exactement ce que je veux, rien de plus (Respect People)
  • Montrez moi régulièrement ce que vous faites (Create Knowledge)
  • Evaluez et réduisez les impacts éventuels  (Optimize the Whole)
  • Mettez en œuvre votre solution au plus vite  (Deliver Fast)
  • Réduisez le nombre de décisions que je dois prendre pour résoudre mon problème (Defer Commitment)

Et bien que cela ne soit pas expressément demandé mais parfaitement illustré dans le modèle de Kano, le prestataire se doit de rajouter quelques élements qui me surprendront et me raviront, afin que ma satisfaction soit totale 🙂

FT & Lean 2ème

Ce matin, nouvelle visite chez FT Meylan pour parler du Lean … mon dada 🙂

Une dizaine de personnes dans la salle et une trentaine connectée par vidéo conf. Après pas mal de souci de mise en place de la vidéo conf, j’ai pu expliquer en un peu moins de 2 heures les 7 concepts du Lean tels que décrit dans le livre de Mary et Tom Poppendieck : « Lean Software Development : An Agile Toolkit« . Continuer la lecture de « FT & Lean 2ème »

Lean à ST Crolles

Environ 65 personnes étaient présentes hier après midi pour m’écouter faire la promotion des concepts « Lean Software Developement » et de plusieurs pratiques Agiles qui s’adaptent particulièrement bien dans ce contexte.

Encore une fois, j’ai eu du mal à tenir le timing initialement prévu car entre les questions de l’auditoire et les anecdotes réelles qui contribuent à mieux faire passer les messages, les 90 minutes ont vraiment passé très rapidement. Continuer la lecture de « Lean à ST Crolles »

Ca c’est du KANBAN

Pour ceux qui sont intéressés par le Lean et en particulier la mise en place d’un système KANBAN pour le développement logiciel, je vous recommande très fortement la lecture de cet excellent article de Clinton Keith (en anglais) sur la transition d’une méthode Scrum vers un système Kanban dans un contexte de développement de jeux vidéo.

L’article est plutôt long ou je dirais plutôt très complet, alors prenez votre temps 🙂

L’auteur explique de façon très pédagogique les apports de la méthode Scrum et ses limites dans le contexte du jeu vidéo. Il explique ensuite la manière dont l’équipe a mis en place puis surtout amélioré son système Kanban et révèle les gains de productivité associé (56%). Il détaille et argumente chaque changement en se référant aux 7 concepts du Lean Software Development.

Bref, pour moi qui suit un fana du Lean, c’était un pur moment de plaisir que de lire cet article, j’espère qu’il en sera de même pour vous, bonne lecture.

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

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

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

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.