Voir la source de Un conseil pour une équipe avec un nouveau chef qui ne connaît pas le Lean et qui souhaite plutôt nous faire passer à l'Agilité ?

[[Catégorie: Portail Lean]]
[[Catégorie: Michael Ballé]]
Auteur : Michael Ballé<br/>
Source : [https://www.lean.org/balle/DisplayObject.cfm?o=4983 ANY ADVICE FOR A TEAM WITH A NEW BOSS WHO DOESN’T KNOW LEAN BUT WANTS US TO SWITCH TO AGILE INSTEAD?]<br/>
Date : 08/07/2019<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 28/07/2019<br/>
---- 
Traduction :<br/>
<br/>
'''Cher coach Gemba,'''<br/>
<br/>
'''Nous avons un nouveau chef qui ne connaît pas le Lean et qui demande à notre équipe Lean de passer à "l'Agilité". Un conseil ?'''<br/>
<br/>
Dites à votre chef que vous faites déjà de l'Agilité - il n'y a pas vraiment de différence entre l'Agilité et le Lean. Le chef n'a pas toujours raison, mais le chef est toujours le chef. Une règle d'or de la psychologie est que les gens réduisent les problèmes complexes jusqu'à la partie qu'ils pensent pouvoir résoudre. La grande clairvoyance du Lean c'est de pouvoir faire des hypothèses sur la façon dont un site de travail fonctionne (et va fonctionner) en fonction des problèmes que le chef prend en charge, de la façon dont il les définit et de la façon dont il les résout (avec les gens ou en imposant aux gens sa façon de faire), et le type de solutions qu'il préfère.<br/>
<br/>
 Si vous avez utilisé des techniques Lean Kanban pour établir un flux d'informations plus rapproché entre les concepteurs et les développeurs, alors l'Agilité sera probablement un retour en arrière.
<br/>La vraie question est la suivante : que perdez-vous en abandonnant le Lean et en adoptant l'Agilité ? Tout dépend du type de Lean que vous pratiquez. Dans certains cas, vous pourriez passer à l'étape supérieure.<br/>
<br/>
J'étais sur la gemba récemment dans un département informatique et j'ai eu exactement cette discussion avec le manager Agile. Ils ne veulent pas entendre parler de l'approche Lean pour leur entreprise parce qu'ils la trouvent trop rigide - ils ne pensent pas que dans leur environnement complexe et en évolution rapide, les standards et les processus standards s'appliquent à eux - et je ne suis pas nécessairement en désaccord avec eux.<br/>
<br/>
D'un autre côté, ils ont admis qu'ils avaient de longs ''lead times'', un énorme backlog et beaucoup de ''rework'', même s'ils pratiquaient l'Agilité depuis des années, ce qui signifie essentiellement cela :
* Ils définissent le travail à travers des stories : ils définissent les fonctionnalités avec des "personas" utilisateurs, spécifiant ce que cet "utilisateur" aimerait faire pour obtenir cela et le décomposant en petits morceaux de travail - des epics et des stories - à développer.
* Ils travaillent en petits lots : ils livrent le travail une fois par jour ou une fois toutes les deux semaines et essaient de tester le code avant la livraison.
* Ils travaillent en équipe : tous les matins, ils mènent une mêlée quotidienne pour discuter du travail à faire et des problèmes qu'ils rencontrent.
<br/>
Et ça marche ! Ils livrent.<br/>
<br/>
Qu'est-ce que le Lean leur apporterait ?<br/>
<br/>
== Différents points de départ ==
La partie difficile. L'Agilité est une victoire incontestable par rapport à la planification d'un système entier et à des mois de développement de portions de code à livrer et à faire fonctionner ensemble à la fin. Mais il reste un système qui organise l'équipe et s'arrête à l'individu développeur et donc - le code. Il y a beaucoup de techniques Agile pour examiner la qualité du code, mais jusqu'à présent, je ne les ai jamais vu si bien appliquées.<br/>
<br/>
À l'autre bout du spectre, les clients des équipes Agile sont beaucoup plus heureux parce qu'ils voient la livraison continue des fonctionnalités, mais il n'est pas clair que le produit résultant soit mieux apprécié ou plus utilisé qu'avec la méthode traditionnelle en V.<br/>
<br/>
L'un des problèmes clés de la pensée Agile est que - d'après ce que j'ai vu - elle est fortement orientée fonctionnalités. Le logiciel qui en résulte a tendance à être chargé de fonctionnalités, aucune d'entre elles n'est très utile et ne fonctionne pas nécessairement très bien pour les utilisateurs sur les quelques fonctionnalités clés dont ils ont vraiment besoin, sur des problèmes plus profonds tels que la vitesse, les bogues et les problèmes, et la sécurité des données.<br/>
<br/>
<u>Le Lean commence à un point différent</u> - non pas avec l'équipe, mais avec le développeur et le product owner ou l'architecte (en termes lean, l'ingénieur en chef).<br/>
<br/>
Avec l'Agilité, l'équipe regarde le tableau d'affichage des tickets, en prend un du backlog de stories et le pousse dans les files d'attente "à faire", "en cours", "en revue", "fini" - beaucoup de variations sur ces en-têtes, mais ils font principalement la même chose.<br/>
<br/>
Quand vous regardez le tableau, certains tickets avancent, d'autres s'attardent. L'équipe ré-ordonnance les tickets en fonction de ce qui a été réalisé et de ce qui a été bloqué. La plupart du temps, le manager a une vois prépondérante et c'est lui qui décide en dernier ressort de ce qui doit être fait et de ce qui sera reporté.<br/>
<br/>
Le Lean commence par le développeur. Le flux de tickets doit se faire sur le poste de travail : voici ce sur quoi vous devez travailler ensuite, et ensuite, et ensuite c'est tout - comme un cuisinier dans une cuisine recevant les commandes des tables du restaurant.<br/>
<br/>
L'intérêt d'amener la file d'attente jusqu'au poste de travail est de rendre la personne autonome : elle n'a pas besoin d'une équipe ou d'un chef pour savoir quoi faire. Elle peut travailler seule ET appeler à l'aide si elle rencontre un problème.<br/>
<br/>
La raison pour laquelle le travail s'accumule sur les bureaux des gens, c'est que lorsqu'ils rencontrent une difficulté, ils mettent de côté le travail pénible et commencent quelque chose d'autre - ce qui a du sens. S'ils se heurtent à un deuxième problème, ils mettent de côté ce deuxième travail et ainsi de suite. Nous le faisons tous. Certaines difficultés se résolvent facilement - obtenir une information manquante de quelqu'un. D'autres s'attarderont et s'aggraveront parce qu'ils sont la partie cachée de l'iceberg de problèmes plus profonds.<br/>
<br/>

== Construire la Qualité intrinsèque ==
Le Lean ne fonctionne pas sans Andon - la ligne de management est là pour être une chaîne d'aide. Lorsqu'une personne rencontre un problème, au lieu de le mettre de côté et de travailler sur autre chose, le management se présente et résout le problème, plutôt que de passer à une autre tâche. Ce n'est jamais facile, mais c'est ainsi que nous découvrons les vrais problèmes dès le début, et les résolvons.<br/>
<br/>
Cette chose simple mais difficile est la clé de la qualité intrinsèque : en fin de compte, <u>le produit sera beaucoup plus robuste que si nous continuons à travailler, si nous poussons tous les problèmes sur la voie et si nous espérons que l'intégration nous permettra de les résoudre tous ensemble</u> - voyez ce qui se passe lorsque les managers essaient cela avec la conception des avions. Aïe.<br/>
<br/>
Et nous arrivons ici à un malentendu majeur au sujet du Lean. Le Andon ne consiste pas seulement à aider les développeurs et à les former à faire des choses quand nous le pouvons. Le Andon vise à comprendre pourquoi le développeur a le problème en premier lieu et où nous nous sommes trompés dans l'instruction de travail.<br/>
<br/>
L'autre partie de l'équation est l'architecte (en termes Agile, l'ingénieur en chef en Lean), la personne qui garde une vision globale de :<br/>
<br/>
<center>Bénéfices pour les clients : fonctionnalités -- technologies -- intégration dans l'ensemble du système -- coût total.</center>
<br/>
Quelqu'un doit concevoir le travail. En Lean, l'ingénierie conçoit l'ouvrage dans les moindres détails et utilise ensuite les problèmes de production pour affiner cette conception. Dans l'Agilité, le travail est conçu avec un coup de pinceau plus large et les développeurs trouvent un moyen de le faire fonctionner.<br/>
<br/>
Dans le cadre d'une pensée Lean, nous mettons l'accent sur les nouvelles fonctionnalités que nous apportons au marché et nous nous assurons qu'elles ne nuisent pas à la performance globale du produit et qu'elles sont solidement conçues avec des standards afin que les équipes de production savent quoi faire. Les fonctionnalités innovantes ou l'utilisation d'une technologie innovante sont utilisées avec parcimonie, dans des projets qui font l'objet d'une forte surveillance.<br/>
<br/>
Le développement Agile a tendance à être beaucoup moins strict avec la production d'un code qui fasse le travail, et les architectes ont tendance à voir des progrès en termes d'ajout de fonctionnalités pour satisfaire davantage les besoins des utilisateurs (avertissement : généralisation large ici, deux architectes n'ont pas le même point de vue sur cette question). C'est une différence fondamentale qui explique une grande partie des discussions Agile/Lean.<br/>
<br/>
[[Fichier:Balle agile1.png|300px|link=]]<br/>
<br/>
En Lean, le mécanisme de feedback à la conception n'est pas la réaction de l'utilisateur face au produit complet une fois qu'il est mis à l'épreuve sur le terrain, mais le processus même du ''stop-and-fix'' / arrêt-répare (si les concepteurs sont réellement intéressés).<br/>
<br/>
En Lean, la production elle-même est la méthode de test de la conception.<br/>
<br/>
[[Fichier:Balle agile2.png|300px|link=]]<br/>
<br/>
Les ateliers et formations ''kaizen'' sont vraiment intéressants en Lean lorsque nous abordons des problèmes de conception profonds qui peuvent ensuite être expliqués aux ingénieurs. Les explications ne seront utiles que si le concepteur a une connaissance approfondie des bénéfices pour le client, des fonctionnalités et de la technologie nécessaire pour les livrer avec qualité et facilité, à un coût raisonnable. Pas facile.<br/>
<br/>
En fin de compte, les techniques Lean ont pour but d'aider les gens à voir au-delà des frontières de leur travail fonctionnel - l'objectif est une meilleure collaboration tout au long de la chaîne et la suppression des coûts - gaspillage - des lacunes dans la coopération (rien de plus inutile qu'un produit non utilisé par les utilisateurs).<br/>
<br/>
Malheureusement, de nombreux programmes Lean sont exclusivement axés sur l'amélioration de la productivité de chaque équipe et passent complètement à côté de l'objectif global de "vendre un produit, en fabriquer un - pour s'assurer que vous continuez à en vendre un".<br/>
<br/>
Pour répondre à votre question, cela dépend vraiment du type de programme Lean que vous avez exécuté. Si l'accent a été mis sur le travail standardisé et les processus standardisés, comme certains essaient de le faire, l'Agilité sera un pas en avant. Cela détendra l'atmosphère et vous empêchera de forcer les clients et le personnel avec vos processus arbitraires. D'un autre côté, <u>si vous avez utilisé des techniques Lean Kanban pour établir un flux d'informations plus rapproché entre les concepteurs et les développeurs, alors l'Agilité sera probablement un retour en arrière</u>, permettant aux ''middle managers'' de reprendre le contrôle du qui-fait-quoi et de ne plus examiner le code des développeurs.<br/>
<br/>
Les questions clés sont les suivantes : Qu'essayez-vous de faire ? Où cherchez-vous à faire des gains ? Quel type de Lean pratiquez-vous actuellement ? Quel genre d'Agilité votre nouveau chef veut-il que vous fassiez ? Pas de conseil : ça dépend !