Les dessous de l’affaire Toyota

Je me fais pas mal chambrer en ce moment car beaucoup de ceux qui connaissent mon fort intérêt pour le Lean, dont Toyota est le créateur, me demande ce que je pense des problèmes de qualité que rencontre Toyota actuellement, et certains en profitent même pour remettre en question l’approche Lean dans son ensemble … les petits sournois

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 )

La Variabilité avant les Gaspillages

Beaucoup de personnes associent systématiquement le Lean à la recherche et la réduction des gaspillages.

Cette approche est un réductrice car si la traque des MUDA (gaspillages en Japonais) est essentielle, elle n’est qu’un des 7 concepts du Lean pour le logiciel, il y en a donc 6 autres (Eliminate Waste, Build Quality In, Defer Commitment, Create Knowledge, Deliver Fast, Optimize the Whole, Respect People).

De plus cette approche par les gaspillages est erronée car elle ne tient pas compte de la notion de maîtrise de la variabilité qui doit arriver AVANT la réduction des gaspillages.

En effet, réduire les gaspillages sur un système à forte variabilité ne conduit pas automatiquement à une amélioration du système et donc à une augmentation de la satisfaction client.

Vous n’êtes pas convaincu ?

Lire la suite »

Le KANBAN pour réduire la dette technique

Le sujet de la dette technique est vaste et a même suscité l’écriture de quelques très bons livres comme celui de Michael Feathers « Working effectively with legacy Code » qui explique comment travailler par petites étapes et surtout la nécessité d’arrêter d’augmenter systématiquement cette dette ( »Stop Digging! »).

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

Feedback Immédiat

.

.

.

.

.

.

.

.

.

.

.

.

Excellente idée de l’équipe organisatrice de l’évènement sur Valence que d’avoir mis des grands papiers à la sortie des salles sur lesquels chacun pouvait mettre une note entre 1 et 5 pour donner un feedback immédiat à l’orateur sur la façon dont son intervention avait été appréciée.

Pour les 2 miennes ( »Lean Sofwtare Development : La vision des Poppendiecks » et « Artistes et Spécifieurs« ) que des 4 et des 5 … et une majorité de 5 … et j’arrête car mes chevilles et mes doigts enflent et je n’arrive plus à taper sur le clavier correctement

J’aime beaucoup cette idée pour 2 raisons principales :

• Elle est simple et donc très KISS (Keep It Simple Stupid), ce que les agilistes aiment particulièrement
• Elle est immédiate … et globalement, agilistes ou pas, nous n’aimons pas attendre

Bravo aux organisateurs Valentinois pour la conférence et pour cette idée

Value Stream Mapping

Le Value Stream Mapping(*) est un outil proposé par l’approche Lean pour visualiser un des 7 gaspillages qu’est le gaspillage temporel. Le VSM permet de calculer un ratio d’efficacité qui sert de référence pour évaluer l’efficacité des actions d’amélioration qui seront menées par l’entreprise.

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)

Lean Engineering Chez THALES

Pour ceux qui sont encore dubitatif sur l’application des approches Lean et Agile dans le développement de logiciel embarqué critique, voici un moyen de vous faire basculer du bon coté de la Force Agile.

Regardez la vidéo, trouvée par hasard sur DailyMotion, des équipes valentinoises de Thales qui mettent en application avec succès les approches Lean et Agile.

En plus ILS SONT BEAUX … bon d’accord, je ne suis plus crédible

Scrum, Lean et les priorités

L’approche Scrum insiste sur l’efficacité de bien définir les priorités du produit en un endroit unique, le product backlog, et de travailler en respectant les priorités définies précédemment.

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 !

Lire la suite »

La vélocité des bugs

Scrum 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 ?

Lire la suite »

Lean : Réduire les gaspillages

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

Lire la suite »

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