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« . Lire la suite »

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. Lire la suite »

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.

Lean or Scrum

Article très intéressant de Jeff sur son blog: « The First Scrum: Was it Scrum or Lean?« , mais comme il est assez long, profitez d’un moment de calme pour le lire.

Jeff nous fait un historique de la création de Scrum afin de nous montrer que Lean et Scrum ont les mêmes origines: la théorie des systèmes adaptatifs complexes. Mais Jeff positionne clairement Lean et Scrum sur 2 plans différents. Scrum intrduit le chaos dans le processus de développement et utilise un système de contrôle empirique pour rapidement inspecter et adapter ce système qui évolue rapidement. En ce sens, Scrum est un moyen d’implémenter Lean au niveau du développement de logiciels. Lean de son coté est un bon outil de communication à destination des managers, et permet à des équipes Scrum de comprendre pourquoi elle ne réussissent pas avec Scrum, en implémentant du Kaizen et/ou des principes de’arrêt de production au moindre défaut (Stop-the-line).

Jeff rappelle également quelques principes de Scrum dont je retiendrais ceux-ci:

• Le nombre de testeurs et de documentalistes doit être supérieur au nombre de développeur afin d’éviter qu’ils produisent trop de code trop vite
• Rien n’est plus convaincant pour le management que de voir régulièrement (démo) du code qui marche
• Il est impossible pour les développeurs de développer du code de qualité sans avoir un environnement d’intégration continue en place

Management Agile

Intéressant article trouvé sur le site de Scrum Alliance décrivant le rôle du manager dans un contexte Agile.

L’article indique le besoin pour le manager de disposer de 3 grandes compétences et d’une méta-compétence.

Compétence 1: Gérer les équipes

• Etre un Leader ou un coach plutôt qu’un chef.
• Faciliter la résolution des problèmes par l’équipe elle même
• Gérer les ressources pour maximiser le flux de sortie (création de valeur) et non l’utilisation maximale des ressources (100% d’occupation)
• Adapter la mesure de performance au principe Agile (Inspect & Adapt) et donc éviter le bilan annuel comparatif des objectifs définis 12 mois plus tôt

Compétence 2: Gérer les investissements

• Investir dans ce qui crée de valeur immédiate et mesurer le ROI sur la base des métriques fournies par l’équipe
• Avoir des cycles plus courts de remise en cause du « portfolio « de produits.

Compétence 3: Gérer l’environnement

• Utiliser des approches issues du LEAN pour gérer les partenaires internes (Finance, RH …)
• Gérer la sous-traitance (locale ou off-shore) en s’assurant que la création de valeur reste maximale (surtout si le choix s’est fait sur des critères purement financiers)

Méta-Compétence : Gérer les changements organisationels

• Faire en sorte que cela fonctionne en facilitant l’adoption des méthodes Agile et le changement des pratiques établies

Un petit questionnaire est également disponible pour savoir quel est votre degré de maturité dans le management Agile