« 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é ? » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (7 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Catégorie: Portail Lean]] | [[Catégorie: Portail Lean]] | ||
[[Category: Gemba]] | |||
[[Category: Jidoka]] | |||
[[Catégorie: Michael Ballé]] | [[Catégorie: Michael Ballé]] | ||
Auteur : Michael Ballé<br/> | Auteur : Michael Ballé<br/> | ||
| Ligne 16 : | Ligne 18 : | ||
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/> | 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/> | <br/> | ||
Si vous avez utilisé des techniques | 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/> | <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/> | ||
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/> | <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/> | 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/> | ||
| Ligne 68 : | Ligne 69 : | ||
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/> | 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/> | <br/> | ||
[[Fichier:Balle agile1.png|300px]]<br/> | [[Fichier:Balle agile1.png|300px|link=]]<br/> | ||
<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/> | 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/> | ||
| Ligne 74 : | Ligne 75 : | ||
En Lean, la production elle-même est la méthode de test de la conception.<br/> | En Lean, la production elle-même est la méthode de test de la conception.<br/> | ||
<br/> | <br/> | ||
[[Fichier:Balle agile2.png|300px]]<br/> | [[Fichier:Balle agile2.png|300px|link=]]<br/> | ||
<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/> | 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/> | ||
| Ligne 80 : | Ligne 81 : | ||
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/> | 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/> | <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 ! | |||
