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

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

Starfish & Spider

Starfish & SpiderJe viens de terminer de lire le livre « The Starfish & The Spider : The Unstoppable Power of Leaderless Organizations » et j’ai trouvé pas mal de similitude avec les approches Agile et Lean.

L’idée derrière le livre est de démontrer la réussite ou la difficulté d’affronter des organisations fortement décentralisées (les STARFISH: les indiens Apaches, Les Alcooliques Anonyme, Al Qaeda, eMule, Wikipédia …) en comparaison de structures centralisées (les SPIDER: Inca, Major du disque …).

Pourquoi opposer Starfish et Spider, simplement parce que si vous coupez la tête d’une araignée elle meure, si vous lui arrachez une ou plusieurs pattes elle est moins efficace et peut en mourir, alors que si vous coupez une branche d’une étoile de mer, elle repousse et chez certaines variétés, la branche coupée peut donner naissance à une nouvelle étoile de mer.

Une analyse est faire sur les caractéristiques des organisations décentralisées et en particulier les personnes qui contribuent à leur développement (le catalyseur, le champion …) et leur interaction avec les cercles d’influence qui véhiculent la pensée de ces organisations. Le fait qu’il n’y ait bien souvent pas de règles établies chez les Starfish m’a fait penser au concept d’équipe auto-dirigée de l’agilité.

Le livre montre que derrière la réussite de plusieurs entreprises (Ebay, Google, Toyota …) qui semble centralisée, car elles ont un PDG, des départements etc., se cache un modèle hybride qui offre beaucoup de décentralistation (comme chez toyota ou les ouvriers se chargent eux-mêmes de proposer et mettre en place des améliorations de production)

Ce livre est écrit dans un anglais parfois difficile à lire pour un étranger (grammaire et vocabulaire assez développé)

Comment faire de la doc ?

Personnellement, Je n’ai jamais trouvé que l’agilité donnait une réponse précise à cette question 🙂

Par contre, j’ai trouvé une forme de réponse coté Lean. En effet, si le prend le point de vue de l’utilisateur final, la documentation qui n’est pas lue par l’utilisateur final peut souvent être considérée comme du « gâchis » et je considère qu’il y a donc une opportunité de réduction des coûts de production.

Depuis quelques temps, chaque fois que quelqu’un veut écrire un document, je lui pose la question suivante:

  • QUI VA LA LIRE ?

Les réponses sont le plus souvent l’une des suivantes:

  1. Untel la lit et l’utilise
  2. Je n’en sais rien mais quelqu’un devrait le faire
  3. Ce document est contractuel
  4. Notre processus dit qu’il faut la produire

Sur la réponse 1, je réponds : « C’est Ok, ce document est utile ».

Sur la réponse 2, je réponds simplement : « Mais pourquoi l’écris-tu ? », et bien souvent ce document est abandonné

Sur la réponse 3, je dis : « Ok, mais as-tu essayé de la réduire au strict minimum ? », car il y a souvent une volonté de bien faire alors que le juste nécessaire suffit souvent.

Sur la réponse 4, je dis : « Viens avec moi on va voir le responsable de ce processus pour voir si on peut le modifier ».

Lean à l’Ensimag

Le chemin est encore long pour avoir un cours sur le Lean Software Development à l’Ensimag, mais hier soir c’était l’unique sujet dont on parlait dans les locaux de l’école.

L’association des anciens élèves organisait une soirée « diner/débat » et j’étais l’orateur pour présenter le Lean de mary et tom poppendieck à une audience d’une 30aine de personnes constituée d’anciens élèves, de professeurs et de membres du groupe agile de Grenoble.

Je prends toujours un vrai plaisir à présenter les 7 concepts du Lean, même si le format limité à 1h15 me laisse un peu sur ma faim car je ne peux que survoler certains aspects et surtout, et à mon grand regret, je dois réduire le nombre d’anecdotes amusantes qui permettent de mieux comprendre « comment » implémenter le Lean.

Même si une partie de l’audience (les agilistes) était acquise à cette cause, il est vraiment toujours intéressant de batailler pour que certaines résistances s’ouvre un peu au Lean. Je suis conscient que les personnes ne sont pas ressorties entièrement convaincues, en 1h15 cela n’est pas possible, mais j’ai vraiment eu la sensation que ma présentation et la discussion qui a suivi les avait au moins amené à réfléchir sur leurs façons de faire … Je ne demande rien de plus !