L’éléphant Lean

((/dotclear/public/photos/.photo_art_smalley_sq.jpg|Art Smalley|L|Art Smalley))Décidément, Art Smalley est prolifique en ce moment. J’ai traduit son article ++[« The Lean Elephant »|http://theleanedge.org/?p=2067]++.%%% %%% > Je pense qu’il est préférable d’être honnête et d’admettre que la plupart des descriptions du lean (ou du Système de Production Toyota) sont généralement parcellaires. En un sens, la question posée est assez simple mais la réponse n’est pas si facile qu’il y paraît. Selon l’angle ou l’approche que vous prenez, vous pouvez trouver des points de vue différents sur le sujet. Je vais en résumer quelques-uns et terminer avec quelques conseils.%%% > %%% > Si vous lisez des manuels de l’ancien Système de Production Toyota (TPS$$Toyota Production System$$), des livres ou des interventions de Taichi Ohno, vous constaterez rapidement qu’il y a plusieurs définitions du TPS ( aussi appelé Lean) ayant survécu au fil des ans. Tout le monde a probablement en tête des définitions comme « l’élimination des gaspillages », « la réduction du délai entre la commande et la livraison », « Kaizen », … Pendant longtemps, le « système » n’a pas vraiment eu de nom. Avec le recul, je pense que c’était un avantage.%%% > %%% > Sur la période allant de 1950 à 1973, Toyota a travaillé dur pour s’améliorer et ses efforts ont été vaguement surnommé Système Ohno dans certaines parties de l’entreprise. D’autres termes comme « méthodes du supermarché », « kaizen », « kanban », … ont bien sûr été aussi utilisées en fonction de l’objet de la discussion du moment. Entre 1950 et 1960, la plupart des améliorations étaient principalement baptisées, dans les documents publiés, sous le nom de 合理化 (Gorika), c’est-à-dire rationalisation des efforts.%%% > %%% > En 1973, Toyota a finalement publié le premier manuel TPS en japonais. Le titre de ce manuel était トヨタ式生産システム トヨタ方式. Voici un aperçu de la page de couverture.%%% > %%% > [((/dotclear/public/traductions/.Art-Smalley-TPS-Handbook-1973_m.jpg|TPS Handbook 1973||TPS Handbook 1973))|/dotclear/public/traductions/Art-Smalley-TPS-Handbook-1973.jpg]%%% > %%% > La traduction mot à mot est en réalité assez pesante : « Système de Production à la mode Toyota / Méthodes Toyota ». Plus tard, bien sûr, cela s’est un peu raccourci pour donner plus simplement le Système de Production Toyota. Le premier manuel ne définissait pas le TPS en une seule phrase. Au contraire, il abordait les différents composants qui sont aujourd’hui devenus si familiers et qu’il n’est pas utile de réexaminer ici. Taiichi Ohno a écrit la préface et a insisté sur le fait d’équilibrer les différentes dimensions que sont la qualité, la quantité et le coût, et ceci d’une manière qui devait éviter les gaspillages et permettre d’atteindre les objectifs de productivité.%%% > %%% > À certains égards, je pense que c’est une extravagance d’essayer de dépeindre le Système de Production Toyota comme une seule entité. Personne, à mon avis, n’a réussi à le faire jusqu’à maintenant. Peut-être est-il plus facile de l’aborder sous forme de systèmes multiples, tels qu’un système qualité, un système de productivité, un système de planification (JIT), un système de développement des personnes, un système de développement des produits, un système de développement des fournisseurs, etc. L’autre solution est de maintenir une position vague et de juste l’appeler l’Excellence ou la Démarche Toyota$$Toyota Way$$. Ce dernier terme a été employé par Toyota ces dix dernières années pour plus de simplicité.%%% > %%% > Que vous préfériez être comme Aristote en tentant de classer et de sous-classer les « éléments » du TPS ou, plutôt comme Platon, en vous concentrant sur les « formes » principales, cela reste une question de goût personnel et de préjugés à mon avis. Cela dépend aussi de là où vous en êtes dans votre cheminement personnel et de votre compréhension du sujet. Malheureusement, comme je l’ai souligné dans les discours des années précédentes, le résultat ressemble un peu à la parabole des aveugles et de l’éléphant … tout le monde confirme qu’il sait exactement ce qu’il a dans la main mais personne ne peut expliquer l’ensemble correctement. Note : cela reste malgré tout nécessaire à des fins de communication et d’apprentissage. Pour ma part, je vais sans doute continuer à écrire des choses sur les éléments du système de temps à autre.%%% > %%% > [((/dotclear/public/traductions/.Art-Smalley-Lean-Elephant_m.jpg|Lean Elephant||Lean Elephant))|/dotclear/public/traductions/Art-Smalley-Lean-Elephant.gif]%%% > %%% > Mon dernier conseil sur le sujet serait de trouver une description convenable pour vos besoins et votre contexte personnel, c’est-à-dire pas celui de quelqu’un d’autre. Toyota n’a pas copié une seule entreprise ou une seule technique lorsqu’ils ont construit leur « système ». Leur situation exigeait des améliorations, notamment de la rentabilité, de la qualité et de la productivité, et ils prirent la décision d’y aller ensemble pour remplir ces objectifs. La discipline rigoureuse, qui consiste à se concentrer sur un certain nombre de choses qui posent problème et à les améliorer, est celle qui aidera le plus la plupart des gens et des organisations. Une fois que vous aurez accompli quelque chose de significatif, comme Toyota l’a fait en 1973, vous pourrez alors débattre (et continuer à débattre) sur la façon dont il faut l’appeler.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Innovation games : créer des produits novateurs grâce aux jeux collaboratifs

[((/dotclear/public/lectures/.innovationgames_t.jpg|Innovation Games de Luke Hohmann|L|Innovation Games de Luke Hohmann))|/dotclear/public/lectures/innovationgames.jpg]Cela faisait plusieurs mois que Philippe Launay nous mettait en avant ce ++[livre de Luke Hohmann|http://innovationgames.com/resources/innovation-games-book/|en]++. Il en a d’ailleurs profité plusieurs fois pour nous faire pratiquer quelques techniques sorties du livre lors des différents ++[Scrum User Group Bordelais|http://sites.google.com/site/sugbordeaux/]++ dont il est le dynamique animateur. Finalement j’ai commandé le livre sur Amazon et je l’ai reçu moins d’un mois après. Je n’ai pas été déçu ! Cette semaine j’en ai profité pour faire un atelier « __Product Box__ » avec mon client, qui s’est révélé très productif. Merci Philippe !%%% %%% Coïncidence, Alexandre Boutin (Agilex) vient tout juste de débuter une série de billets pour présenter l’approche de Luke Hohmann :%%% * ++[Jouer avec les clients pour innover #1|http://www.agilex.fr/2010/11/jouer-avec-les-clients-pour-innover/]++%%% * ++[Jouer avec les clients pour innover #2|http://www.agilex.fr/2010/11/jouer-avec-les-clients-pour-innover-2/]++%%% * ++[Jouer avec les clients pour innover #3|http://www.agilex.fr/2010/12/jouer-avec-les-clients-pour-innover-3/]++%%% * ++[Jouer avec les clients pour innover #4|http://www.agilex.fr/2010/12/jouer-avec-les-clients-pour-innover-4/]++%%% * ++[Jouer avec les clients pour innover #5|http://www.agilex.fr/2010/12/jouer-avec-les-clients-pour-innover-5/]++%%% %%%

Fin de mission

[((/dotclear/public/whisky/.201011126-corbeille_t.jpg|Ma jolie corbeille : Miyagikyo 12 ans|L|Ma jolie corbeille : Miyagikyo 12 ans))|/dotclear/public/whisky/201011126-corbeille.jpg]Aujourd’hui, nous avons officiellement fêté ma fin de mission (18 mois) avec un repas collégiale et une corbeille bien pourvue : quelques terrines, un beau verre et un superbe ++[Miyagikyo 12 ans|http://www.whisky.fr/produit-634-miyagikyo-12-ans-45-embouteillage-officiel-12-yo.html]++ !%%% %%% J’en profite donc pour remercier plus particulièrement le plateau du projet : Hélène (la tête pensante), Laurence (ou pas), Marie-Christine (la douce), Fabrice (2h58!), François (118…), Frédéric (le gourmet), Frédéric (euhhhhhhhhhh), Gary (le nouveau marié), Nadir (chouchou), Nathalie (c’est pas passé loin), Paco (el ++M++ejor de los ++4++), Teddy (…218), Thierry (l’hippopotame)… et tous les autres. Une belle page qui se tourne.

60 secondes d’agilité : le ROTI d’une réunion

((/dotclear/public/photos/.photo-Hamlet-Darcy_t.jpg|Hamlet D’Arcy|L|Hamlet D’Arcy))J’ai traduit ce billet de Hamlet D’Arcy : ++[« 60 Second Agility: ROTI Meetings »|http://java.dzone.com/articles/60-second-agility-roti|en]++.%%% > Constamment en train d’essayer de minimiser la durée d’une cérémonie, ma dernière équipe a « découvert » une pratique agile très utile qui prend 60 secondes en tout : le ROTI d’une réunion. Après chaque réunion, sur le chemin qui mène à la sortie, tracez une ligne diagonale sur la tableau blanc avec les étiquettes 0, 2 et 4.%%% > %%% > ((/dotclear/public/traductions/roti.png|ROTI||ROTI))%%% > %%% > Chacun à son tour donne une certaine note sur la façon dont la réunion s’est passée en qualifiant le « Retour sur le Temps Investi »$$NdT : Return On Time Invested$$ ; la personne pointe alors sa notation avec un marqueur. Voici l’échelle de notation que nous avons utilisé :%%% > %%% > 0 = « J’aurais mieux fait d’aller boire un café. J’ai carrément perdu mon temps »%%% > 1 = « Vous auriez dû me laisser à mon bureau en train de coder »%%% > 2 = « Ce fut une bonne réunion. Autant de valeur ajoutée que si j’avais écrit du code »%%% > 3 = « De façon surprenante, ça m’a apporté plus de valeur que si j’avais écrit du code »%%% > 4 = « Super, cette réunion m’a permis de gagner énormément de temps. Dieu merci, je ne suis pas allé écrire du code à la place »%%% > %%% > Puis chaque personne répond à la même question : « Qu’est-ce qui pourrait être fait pour augmenter d’un point votre note ? »%%% > %%% > Pour réaliser cet exercice en 60 secondes, cela signifie qu’il n’y a pas de discussion. Le retour est ce qu’il est; pas de débat, pas de tentative de résolution d’un problème et pas de préjudice moral.%%% > %%% > Le ROTI d’une réunion aide à créer un comportement implicite qui peut, à l’avenir, être adopté par tous les membres de l’équipe. Il conduit l’équipe à mener de moins en moins de réunions (ce qui est presque toujours une bonne chose), il pousse les membres de l’équipe à être plus respectueux du temps et de l’expertise des autres, il influence les organisateurs de réunion à être plus succinct sur le sujet abordé et améliore significativement la qualité des réunions. Il ne prend que 60 secondes de sorte que vous pouvez aussi bien l’essayer à de multiples reprises !%%% > %%% > … et maintenant quelques détails historiques.%%% > %%% > Le ROTI est bien décrit dans le magnifique livre de Esther Derby ++[« Agile Retrospectives »|http://pragprog.com/titles/dlret/agile-retrospectives|en]++. La pratique du ROTI dans le cadre des rétrospectives d’itérations prend plus de temps, de 5 à 10 minutes. Notre équipe a trouvé le ROTI si efficace lors des rétrospectives que nous l’avons raccourci et nous l’utilisons à chaque fin de réunion.%%% > %%% > L’échelle réelle du ROTI est un peu plus formelle que ce que nous avons créé :%%% > %%% > 0 – Aucun bénéfice retiré du temps investi (perte de temps)%%% > 1 – %%% > 2 – Bénéfice retiré équivalent au temps investi (seuil de rentabilité atteint)%%% > 3 – %%% > 4 – Bénéfice retiré supérieur au temps investi (retour sur investissement élevé)%%% > %%% > Pour finir, je précise que le ROTI est aussi abordé en détail sur ++[quelques|http://www.ayeconference.com/the-roti-method-of-gauging-meeting-effectiveness/|en]++ ++[autres|http://www.energizedwork.com/weblog/2006/09/retrospectives-action-begets-action.html|en]++ ++[sites|http://www.bencoombs.com/bens_blog/2008/08/agile-retrospec.html|en]++. Pour un investissement de seulement 60 secondes, cette pratique vaut la peine d’être essayée par votre équipe.%%% > %%% >  »Tiré du blog ++[http://hamletdarcy.blogspot.com|http://hamletdarcy.blogspot.com|en]++ »%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

La Vision du Produit

((/dotclear/public/photos/.photo-Roman-Pichler_sq.jpg|Roman Pichler|L|Roman Pichler))Vous posez des questions autour de vous sur le projet en cours… on vous montre des slides intéressants mais obsolètes, des cahiers dé(s )charges ou des spécifications de plusieurs centaines de page, mais personne pour vous donner les enjeux du client et du projet… ou en tout cas pas de façon claire et unanime. Beaucoup de réunionite et peu de visionite :-(%%% %%% Et hop, j’en ai profité pour traduire ce billet intéressant de __Roman Pichler__ : ++[« The Product Vision »|http://www.scrumalliance.org/articles/115-the-product-vision|en]++.%%% > __Le Nord du Nord__%%% > Avez-vous déjà travaillé sur un projet Scrum, où l’objectif global n’était pas clair ? où vous disposiez d’un backlog du produit, mais où les personnes impliquées dans l’effort de développement ne comprenaient que vaguement le but de la release ? Cela arrive plus souvent qu’on le souhaiterait, même sur des projets de plusieurs millions d’euros ! Souvent, on interprète à tort l’idée que Scrum se concentre sur le fait de « terminer le travail » et donc qu’il s’agit d’une course au développement sans avoir préalablement suffisamment réfléchi à l’endroit où le projet devrait aller. Ne faites pas cette erreur. Tout projet Scrum a besoin d’une vision produit pour montrer la vraie direction du projet « le nord du nord », orienter et guider l’équipe Scrum. C’est l’objectif primordial que tout le monde doit partager : le Product Owner, le ScrumMaster, l’équipe, le management, les clients et les autres intervenants. Comme Ken Schwaber l’a dit : « Le plan minimum nécessaire pour démarrer un projet Scrum contient une vision et un backlog de produit. La vision explique pourquoi le projet est en cours et quel est l’état final recherché. » __(1)__%%% > %%% > __Cinq questions__%%% > « La vision, c’est l’art de voir les choses invisibles », a noté l’écrivain anglais Jonathan Swift. La vision du produit dépeint une image de l’avenir qui attire les gens. Elle décrit qui sont les clients, ce dont les clients ont besoin, et comment ces besoins seront satisfaits. Elle saisit l’essence même du produit : les informations essentielles/critiques que nous devons connaître pour élaborer et lancer un produit gagnant. Développer une efficace vision du produit implique de bien répondre aux questions suivantes :%%% > %%% > 1. Qui va acheter le produit ? Quelle est la clientèle ciblée ?%%% > 2. A quels besoins du client le produit répond-il ?%%% > 3. Quelles caractéristiques du produit sont essentielles pour satisfaire les besoins identifiés, et donc pour le succès du produit ?%%% > 4. Comment se compare le produit aux autres produits existants, vis-à-vis des concurrents et dans l’entreprise même ? Quels sont les points de vente du produit ?%%% > 5. Quels sont le calendrier et le budget cibles pour développer et lancer le produit ?%%% > %%% > Répondre à ces cinq questions nous donne aussi les informations nécessaires pour analyser la rentabilité. Cela nous permet de décider si et comment le projet devrait se poursuivre.%%% > %%% > __Créer la Vision du Produit__%%% > Puisque le Product Owner est responsable de la réussite du produit et du retour sur investissement (ROI), il ou elle devra diriger les activités de création de cette vision grâce à une collaboration étroite avec l’équipe __(2)__. Pour les projets innovants, cette équipe peut inclure des profils métier et techniques; par exemple, des gens du marketing, des concepteurs du produit et des interfaces utilisateurs ainsi que des développeurs. Plus le produit est innovant et complexe, plus la vision est importante, et plus les efforts nécessaires seront importants pour la créer. Pour des projets de développement de nouveaux produits et des versions majeures de produits, des études de marché et des activités de prototypage sont généralement menées. Comme cela peut prendre plusieurs semaines voire plusieurs mois pour compiler les informations pertinentes, exécuter un ou plusieurs sprints est la meilleure façon d’effectuer le boulot nécessaire. Comparez cela avec la version mineure d’un produit où la création de la vision concernée ne prendra que quelques heures ou quelques jours.%%% > %%% > __Le cœur de la Vision du Produit__%%% > Au cœur de la vision du produit, on trouve la description des besoins clients identifiés et les caractéristiques nécessaires du produit qui y répondent. Pour atteindre ce niveau de vision, nous avons d’abord sélectionner notre clientèle cible, puis les besoins pertinents pour ces clients, décidant ainsi quel marché ou segment de marché nous allons aborder. Puis, nous identifions les caractéristiques du produit – autrement dit les exigences critiques de haut niveau – que le produit devra remplir pour satisfaire ces besoins.%%% > %%% > Les caractéristiques du produit comprennent généralement à la fois des exigences fonctionnelles et non fonctionnelles. Les exigences non fonctionnelles incluent des exigences de performance, de robustesse et de facilité d’utilisation. Les exigences fonctionnelles décrivent des fonctionnalités particulières du produit, par exemple effectuer un appel ou envoyer un email. Les caractéristiques du produit servent de guide pour l’équipe, elles limitent le périmètre de solution, l’ensemble des solutions possibles.%%% > %%% > Décrire les caractéristiques du produit au bon niveau de détail est un équilibre qui exige une collaboration étroite entre le Product Owner et l’équipe. Sous-spécifier ces caractéristiques peut produire une direction floue. Sur-spécifier les caractéristiques du produit peut se traduire par une prise de décision plus tôt que nécessaire et des répercussions négatives sur la créativité de l’équipe. Les techniques utiles pour décrire les caractéristiques du produit comprennent des personas, des scénarios, des cas d’utilisation et des user stories.%%% > %%% > __Qualités souhaitables__%%% > Comme tout objectif important, une bonne vision recours également à notre intelligence et nos émotions. Il convient de motiver et d’inspirer les gens. La vision du produit doit être claire et stable, globale et mobilisatrice, concise et pure.%%% > %%% > ++Claire et stable++%%% > La vision du produit doit être claire et facile à comprendre pour s’aligner sur un but commun, et pour éviter toute mauvaise interprétation et de la confusion __(3)(2)__. Le terme anglais « vision » est dérivé du latin « visio », qui se traduit par « voir, vue, notion, idée ». La vision du produit devrait donc nous permettre de voir le futur produit. La vision ne doit pas être floue ou troublée.%%% > %%% > Des changements dans la vision, en particulier en ce qui concerne les besoins des clients et les caractéristiques essentielles, peuvent causer de la confusion, de la dé-motivation, et l’échec du projet. De petits ajustements sont habituellement logiques et acceptables tant que la proposition de valeur du produit reste la même.%%% > %%% > ++Globale et mobilisatrice++%%% > La vision du produit doit décrire un objectif global et mobilisateur : un objectif qui guide l’effort de développement, tout en laissant suffisamment de place pour la créativité; un objectif qui mobilise et inspire les gens, encourage la créativité et le soutien.%%% > %%% > ++Concise et pure++%%% > La vision du produit doit être brève et concise __(2)__. Elle ne doit contenir que des informations essentielles à la réussite du produit. Par exemple, les visions communiquées sur les produits phares traités par Lynn & Reilly __(3)__ ne disposent pas de plus de six caractéristiques. La vision du produit n’est, par conséquent, pas une liste de fonctionnalités et ne doit pas fournir de détails inutiles.%%% > %%% > ++Le test de l’ascenseur++%%% > La manière classique pour valider la vision du produit est de répondre au test de l’ascenseur : « Pouvez-vous expliquer votre produit dans le temps qu’il faut pour monter dans un ascenseur ? » __(4)__. Passer ce test permet de vérifier que votre vision du produit est claire, engageante et concise (en supposant que nous montons au bon étage du bâtiment et qu’on ne va pas rester coincé dans l’ascenseur). Notez que le test de l’ascenseur ne nous dit pas si nous avons sélectionné de façon pertinente les bons besoins clients et les bonnes caractéristiques du produit; seuls de rapides retours clients peuvent le faire.%%% > %%% > __Les projets de tous les jours__%%% > Même nos projets courants devraient être guidés par une vision du produit. Par exemple, je gère mes activités de marketing à l’aide de Scrum. Je remplis mon backlog de marketing avec de nouveaux items régulièrement, aussi fréquemment que possible. Il serait inutile de procéder à des études de marché et des activités de prototypage avant de me décider sur quoi travailler. Je me fixe plutôt une vision marketing qui guide mon travail et concentre mes efforts. Ma vision est, de par sa conception, moins importante que la vision d’un projet de développement d’un nouveau produit mais il est quand même important que j’en ai une.%%% > %%% > __Résumé__%%% > Une vision produit efficace guide l’équipe Scrum et coordonne les parties prenantes et les clients. Passer du temps et de l’argent sur la création d’une vision est un investissement rentable. Comme l’a noté Robert G. Cooper : « Trop de projets de nouveaux produits passent directement du niveau idée au niveau développement avec peu ou pas de travail amont. Les résultats de cette approche « prêt, feu, touché » sont généralement désastreux. Une solide phase avant développement augmente les taux de réussite des nouveaux produits de manière significative et est fortement liée à la performance financière » __(5)__. Cela ne signifie pas de tergiverser au début du développement, en utilisant un processus waterfall en amont pour créer un concept produit formidable ou de passer par un projet distinct. L’astuce consiste à passer le moins de temps possible mais autant que de besoin, d’utiliser Scrum pour créer la vision et de faire en sorte que le plus grand nombre possible de membres de l’équipe – impliqués dans la création de cette vision – participent également à sa transformation en un produit réel.%%% > %%% > __Références__%%% > __(1)__ Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. 2004.%%% > __(2)__ Roman Pichler. Scrum – Agile Projektmanagement richtig einsetzen. dpunkt.verlag. 2008.%%% > __(3)__ Gary S. Lynn & R. Reilly Richard. Blockbusters. The Five Keys to Developing Great New Products. HarperCollins. 2002.%%% > __(4)__ Geoffrey A. Moore, Crossing the Chasm. Marketing and Selling Disruptive Products to Mainstream Customers. Revised edition. Collins Business Essentials. 2006.%%% > __(5)__ Robert G. Cooper. Doing it Right. Winning with New Products. ++[Ivey Business Journal|http://www.iveybusinessjournal.com/article.asp?intArticle_ID=235]++. July/August 2000.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Respecter les personnes

((/dotclear/public/photos/.photo_art_smalley_sq.jpg|Art Smalley|L|Art Smalley))J’avais été un peu à court d’arguments pour développer ce sujet précis lors de ma dernière présentation sur le ++[Lean Software Development|/dotclear/index.php?post/2010/10/12/Lean-Software-Development]++. Comment ne pas tomber dans le cliché ou la banalité alors qu’il y a tant de non-dit dans les entreprises dans lesquelles nous travaillons (SSII ou autres d’ailleurs)… Certains pensent même que cela va de soi ! Un des seuls à me fournir un peu de matériel (et d’espoir) sur le sujet est Thierry Cros (++[Etre Agile|http://etreagile.thierrycros.net]++). Et là, je tombe sur cet article récent de Art Smalley : ++[« Respect for People »|http://theleanedge.org/?p=1821|en]++, du pain-bénit que j’ai traduit avec un grand plaisir.%%% > Il y a environ une dizaine d’années, Toyota a simplifié sa philosophie concernant les deux piliers amélioration continue et respect des personnes. Il est vrai que vous ne trouverez pas beaucoup de choses écrites sur « le respect des personnes », mais il n’en reste pas moins que Toyota a déployé des efforts évidents sur ce sujet. Les racines de ce concept au sein de Toyota remontent au minimum aux préceptes fondateurs de Sakichi Toyoda dans les années 1930 voire même plus tôt selon les versions.%%% > %%% > ((/dotclear/public/traductions/TheToyotaPrecepts.gif|Les préceptes de Toyota||Les préceptes de Toyota))%%% >  »__Les Préceptes de Toyota :__ »%%% >  »1. Contribuez au développement et au bien-être du pays en travaillant ensemble, quelle que soit votre position hiérarchique, en remplissant fidèlement vos fonctions. »%%% >  »2. Soyez en avance sur votre temps en étant en permanence créatif, curieux et en amélioration constante. »%%% >  »3. Ayez le sens pratique et évitez la futilité. »%%% >  »4. Soyez gentil et généreux; faites des efforts pour créer une ambiance familière et chaleureuse. »%%% >  »5. Soyez respectueux et montrez de la gratitude envers des choses grandes et petites respectivement dans la pensée et l’action. »%%% > %%% > Je pense qu’il est important de souligner que la formation TWI$$NdT : Training Within Industry = La formation au sein de l’industrie$$ que Toyota mit en œuvre dans le début des années 1950 – en provenance des États-Unis après la Seconde Guerre mondiale – comprenait également quelques conseils pratiques à la fois sur l’importance du respect des personnes et sur les compétences à développer pour gérer les personnes et les problèmes au travail.%%% > %%% > [((/dotclear/public/traductions/.ToTheWarProductionTrainer_m.jpg|Aux formateurs de l’industrie militaire||Aux formateurs de l’industrie militaire))|/dotclear/public/traductions/ToTheWarProductionTrainer.gif]%%% >  »__Aux Formateurs de l’Industrie Militaire :__ »%%% >  »Les relations professionnelles que vous entretenez dans votre travail peuvent avoir, pour votre usine et l’effort de production militaire, une influence déterminante, peut-être même jamais experimentée auparavant. Vous avez la rare ++opportunité++ de pouvoir influencer les encadrants pour qu’ils améliorent leurs relations professionnelles quotidiennes. »%%% >  »Donner uniquement aux employés des compétences techniques ne suffit pas. Les encadrants doivent influencer tout homme et toute femme qui travaille pour créer la collaboration et l’esprit d’équipe. Vous pouvez aider les encadrants à acquérir cette compétence à travailler avec les gens – c’est votre ++devoir++ de bien leur souligner son importance. »%%% > %%% > Il y a aussi des aspects culturels importants sur le « respect des personnes » que je pense inhérents à la culture japonaise sur la façon dont les groupes interagissent entre eux et qui ont influencé la pensée de Toyota sur ce sujet.%%% > %%% > Indépendamment de ces diverses influences, voici quelques petites choses auxquelles j’ai pensé quant au respect des personnes et la façon dont cela a été mis en pratique chez Toyota. En réalité, il n’y avait pas de manuel pour faire ce genre de chose et cette liste reflète donc juste mes expériences et interprétations personnelles.%%% > %%% > __1.__ La première partie de l’équation concernant le respect des personnes signifie fournir un environnement de travail sécurisé. Toyota était sur une très bonne piste en ce qui concerne la sécurité des travailleurs au Japon et dans d’autres pays que j’ai visités. Un accent très important a été mis sur le fait de sécuriser les processus pour les travailleurs et cela a été compris par tous les employés. Toyota n’est pas parfait à cet égard mais il a fait beaucoup de bonnes choses dans cette direction.%%% > %%% > __2.__ La deuxième partie de l’équation était la création d’un environnement de travail propre et cela nécessitait une certaine discipline à la fois de la part des employés et de la direction. Je ne m’étendrai pas sur la pratique des 5S$$NdT : voir ++[mon billet|/dotclear/index.php?post/2008/11/27/5S]++ sur le sujet$$, mais adhérer aux principes de ce processus a contribué à créer une situation où les choses ont été organisées et entretenues correctement. Les personnes préfèrent travailler dans un lieu de travail propre et bien organisé et Toyota s’est donné beaucoup de mal pour mettre en oeuvre cette discipline.%%% > %%% > __3.__ La troisième partie de l’équation se rapporte à la qualité. Permettre aux employés de faire des pièces défectueuses ou de les forcer à trier et à retravailler les articles défectueux est un gaspillage et détruit le moral. Résoudre les problèmes de qualité à leur origine première et prévenir leurs apparitions récurrentes est une façon de prendre soin du client et de respecter les employés.%%% > %%% > __4.__ Le quatrième point sur ma liste peut sembler polémique car il traite de la productivité et de l’utilisation des ressources. Au début, cela peut ressembler à une recette pour « faire travailler plus » les personnes et vous devez vous prémunir contre ce que Toyota appelle Muri ou charges de travail excessives imposées aux personnes. Cependant le vrai danger est dans l’utilisation des personnes. C’est là que des dommages tout aussi graves se sont produits. Toyota s’efforce de faire en sorte que, pour un takt time$$NdT : provient du mot allemand Taktzeit, temps de cycle$$ de 60 secondes, l’employé produit presque 60 secondes de travail. De même, dans un bureau, un membre du personnel avec huit heures de temps aura produit l’équivalent de presque huit heures de travail$$NdT : je ne peux pas m’empêcher de penser aux jours idéaux$$. Les seniors auront généralement de plus grandes charges de travail qui leur sont imposées en raison de leurs capacités et expérience. Dans les deux cas, une perte de temps pour l’employé implique un manque de respect et une mauvaise planification par toutes les parties concernées.%%% > %%% > __5.__ Le cinquième point de ma liste porte sur le développement des talents des employés au fil du temps. Respecter les personnes signifie développer leurs compétences latentes à la fois sur le tas et par la formation professionnelle. Il est facile d’investir de l’argent dans les nouvelles technologies, le logiciel ou le matériel. Il faut du temps, des efforts et de la planification pour investir dans le développement des compétences des employés. Des programmes de formation en kit et des présentations Powerpoint sont loin d’être suffisants.%%% > %%% > __6.__ Le respect des personnes, c’est aussi avoir un dialogue constructif au cours des entretiens de performance des employés. Une discussion approfondie et franche concernant les points forts et les points à améliorer montre l’honnêteté, la sincérité et le respect des personnes.%%% > %%% > __7.__ Pour finir, demander aux gens d’améliorer leur travail et leur donner les outils pour le faire (par exemple, Kaizen) démontre la forme ultime du respect à mon avis. En d’autres termes, la direction nous manifeste sa confiance et attend de nous une participation active à l’amélioration des choses afin d’assurer notre survie. Le message implicite c’est la confiance et le respect mutuels.%%% > %%% > Je pourrais ajouter d’autres choses à la liste, mais ce sont les premiers points de ma liste personnelle. Je ne pense pas qu’il y ait quelque chose d’unique ou même d’original sur cette liste. En réalité, la difficulté n’est pas d’énoncer ces points l’un après l’autre, mais de les mettre en pratique en communiquant sur le sens de ces pratiques.%%% > %%% > Je pense aussi que si Toyota pratique « le respect des personnes », c’est parce que c’est un concept à double sens. En respectant les employés, Toyota s’assure également que le salarié respecte en retour l’entreprise ainsi que le client. Le système n’est pas parfait par certains côtés, mais il il va plus souvent dans la bonne direction que dans la mauvaise.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Backlog de Noël v2

L’année dernière, j’avais eu l’occasion de préparer le Noël d’une manière originale grâce à __Jean Claude Grosjean__ (cf. ++[Christmas Backlog|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/11/16/Christmas-Backlog]++).%%% %%% Une fois de plus, c’est son dernier billet ++[« SCRUM, Backlog et Père Noël… Acte 3″|http://www.qualitystreet.fr/2010/11/11/scrum-backlog-et-pere-noel-acte-3/]++ qui m’a permis de lancer les opérations ce samedi après-midi. Cette fois mes deux filles et ma femme étaient de la partie et ont respecté la recette à la lettre… au Père Noël :-)%%% %%% ((/dotclear/public/./.2010-Noel-Backlog_m.jpg|Backlog Noël 2010||Backlog Noël 2010))

Estimation traditionnelle et Responsabilité individuelle

((/dotclear/public/photos/.mike-cottmeyer_sq.jpg|Mike Cottmeyer|L|Mike Cottmeyer))J’ai traduit ce billet intéressant de Mike Cottmeyer : ++[« Traditional Estimating and Individual Accountability »|http://www.leadingagile.com/2010/11/traditional-estimating-and-individual-accountability/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+LeadingAgile+(LeadingAgile)|en]++.%%% %%% > L’une des raisons pour lesquelles certaines personnes luttent avec le concept d’estimation relative, c’est qu’elles veulent conserver un moyen de responsabiliser les gens pour faire ce qu’ils ont dit qu’ils allaient faire. Vous avez dit que cela vous prendrait 40 heures, je vous ai donné une semaine pour le faire, pourquoi est-ce-que ce n’est pas encore fini ? Pourtant cela semblait raisonnable … pas vrai ?%%% > %%% > De plus, si tout le monde a fourni des estimations sur sa part de travail, et que nous nous sommes assurés que nous avions suffisamment de personnes pour couvrir l’ensemble des estimations, cela veut dire que nous avons un planning crédible, et que nous devrions être en mesure de livrer dans les délais requis, c’est bien ça, non ? Encore une fois, cela semble assez raisonnable.%%% > %%% > Ecoutez-moi bien… non seulement nous pensons que nous allons responsabiliser les individus pour faire ce qu’ils ont dit qu’ils allaient faire, mais nous pensons également les responsabiliser sur la précision de leurs estimations… et peut-être même pensons-nous que nous allons recueillir certaines données pour obtenir de meilleures estimations pour le prochain projet… et en prime, si ces personnes ne font pas ce qu’elles ont dit qu’elles feraient, et bien, ce ne sera même pas de notre faute, puisque ce sont elles qui ont fourni ces estimations. C’est parfait, bravo !%%% > %%% > Où se situe le problème ? Et si cet engagement individuel n’était pas du meilleur intérêt pour garantir la livraison du produit ? Que se passerait-il si aider quelqu’un d’autre dans l’équipe était le comportement que nous souhaiterions vraiment avoir ? mais que notre responsabilité à l’égard des estimations nous contraigne plutôt à respecter uniquement nos propres engagements ?%%% > %%% > Par exemple, disons que Bob et Sue estiment tous les deux leurs tâches individuelles pour le prochain sprint. Très tôt dans le sprint il s’avère que les tâches de Bob vont prendre beaucoup plus de temps que ce qu’il a prévu. Sue, de son côté, respecte ses estimations et est déjà passée à l’étape suivante.%%% > %%% > Le truc c’est que c’est à la fois le travail de Bob et de Sue qui est nécessaire pour livrer une réelle valeur ajoutée au client. Ce n’est pas si important que Sue livre son travail en respectant scrupuleusement ses estimations… si Bob a du mal à terminer, elle doit aller l’aider. Responsabiliser Sue sur sa partie n’aide pas à obtenir plus rapidement la livraison du produit.%%% > %%% > C’est pourquoi l’Agile ne se soucie pas d’estimer en heures, et pourtant parvient à responsabiliser l’équipe entière sur les livrables de l’itération. Nous voulons inciter tout le monde dans l’équipe à rechercher le meilleur intérêt pour le produit. Nous voulons que tout le monde dans l’équipe travaille ensemble pour construire un incrément du produit avant la fin du sprint. Les estimations individuelles et les responsabilités individuelles vont souvent à l’encontre de cet objectif.%%% > %%% > Mais attention, voici le marché. L’équipe et son encadrement doivent être vigilants pour s’assurer que les stars de l’équipe ne sont pas constamment en train de porter à bout de bras les mêmes personnes systématiquement sous-performantes. Si Bob est toujours en difficulté pour respecter ses délais de livraisons, nous avons peut-être un problème de performance à gérer.%%% > %%% > Il y a d’autres façons de traiter avec des gens qui sont en difficulté, autres que d’exiger des estimations individuelles et la responsabilité individuelle sur ces estimations. Se concentrer sur le rythme avec lequel l’équipe produit de la valeur métier est la seule mesure réelle de succès.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.