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

De Wiki Agile
Aller à la navigation Aller à la recherche

Auteur : Michael Ballé
Source : ANY ADVICE FOR A TEAM WITH A NEW BOSS WHO DOESN’T KNOW LEAN BUT WANTS US TO SWITCH TO AGILE INSTEAD?
Date : 08/07/2019

Traducteur : Fabrice Aimetti
Date : 28/07/2019

Traduction :

Cher coach Gemba,

Nous avons un nouveau chef qui ne connaît pas le Lean et qui demande à notre équipe Lean de passer à "l'Agilité". Un conseil ?

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.

Si vous avez utilisé des techniques de Kanban et Lean pour établir un flux d'informations plus rapproché entre les concepteurs et les développeurs, alors l'Agilité vous fera probablement faire un pas en arrière.


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.

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.

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.


Et ça marche ! Ils livrent.

Qu'est-ce que le Lean leur apporterait ?

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 code à livrer et à faire fonctionner ensemble à la fin. Mais il reste un système qui organise l'équipe et s'arrête au codeur individuel et donc - le code. Il y a beaucoup de techniques agiles pour examiner la qualité du code, mais jusqu'à présent, je ne les ai jamais vu aussi bien appliquées.

À l'autre bout du spectre, les clients des équipes agiles sont beaucoup plus heureux parce qu'ils voient la livraison continue de fonctionnalités, mais il n'est pas clair que le produit résultant est mieux aimé ou plus utilisé qu'avec la méthode traditionnelle en cascade.

L'un des problèmes clés de la pensée agile est que - d'après ce que j'ai vu - elle est très basée sur les 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.

Le Lean commence à un point différent - non pas avec l'équipe, mais avec le développeur et le propriétaire du produit ou l'architecte (en termes simples, l'ingénieur en chef).

Avec agilité, l'équipe regarde le tableau d'affichage, en prend un de l'arriéré d'histoires et le pousse dans les files d'attente "à faire", "en cours", "en révision", "fait", "fait" - beaucoup de variations sur ces en-têtes, mais ils font surtout la même chose.

Quand vous regardez le tableau, certains billets avancent, d'autres s'attardent. L'équipe rééchelonne les billets en fonction de ce qui a été réalisé et de ce qui s'est heurté à un barrage routier. La plupart du temps, le gestionnaire est le bris d'égalité et c'est lui qui décide en dernier ressort de ce qui doit être fait et de ce qui sera reporté.

Le Lean commence par le développeur. Le flux de billets doit se faire au poste de travail : voici ce sur quoi vous devez travailler ensuite, et ensuite, et c'est tout - comme un cuisinier dans une cuisine recevant les commandes des tables du restaurant.

L'intérêt d'amener la file d'attente au poste de travail est de rendre la personne autonome : elle n'a pas besoin d'une équipe ou d'un patron pour savoir quoi faire. Ils peuvent travailler seuls ET appeler à l'aide s'ils rencontrent un problème.

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 un deuxième emploi de côté et ainsi de suite. Nous le faisons tous. Certaines difficultés se résolvent facilement - obtenir un élément d'information manquant de quelqu'un. D'autres s'attarderont et s'envenimeront parce qu'ils sont la partie cachée de l'iceberg des problèmes plus profonds.

Qualité intrinsèque

Le Lean ne fonctionne pas sans andon - la hiérarchie 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, la direction 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, un

Récupérée de "https://wikiagile.coach/index.php?title=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%27Agilité_%3F&oldid=11343"