Bonjour, je vous propose de visionner la conférence (je l’ai visionné en x1.5, bien réveillé.e ça passe) et d’échanger ici sur vos ressentis, les éléments vertueux que vous y voyez, les risques / biais…
3 « J'aime »
Merci pour le partage. Le discours du monsieur me parle complètement et me permet par la même occasion de clarifier la vision du lean, qui n’était pas si claire pour moi.
Je pense que pas mal de choses qu’il évoque dans cette conférence pourrait s’appliquer à mon actuel contexte d’entreprise.
Merci pour ton message. Quels en seraient les gains et quels seraient les biais ou les risques d’après toi ?
Pour être plus spécifique, Régis Médina nous rappelle que le monde de la tech, et en particulier celui du développement, c’est avant tout un art délicat. Il utilise le terme de « craft » que je trouve judicieux car permettant de s’affranchir de la connotation un peu péjorative chez nous d’artisanat.
Cela a son importance car une part significative de la satisfaction d’un développeur est celle du travail bien fait, de qualité.
Or, souvent, on considère antinomique la qualité et le « time to market » que nous impose le monde actuel de concurrence acharnée et de diktat de la productivité. Il faut livrer des features, de la valeur, à l’arrache s’il le faut. La non-qualité étant un mal nécessaire qu’on rectifiera plus tard, quand on aura le temps. Ce qui n’arrive que très rarement. Le développeur se sent donc tiraillé entre son souhait de qualité et les impératifs métier de son entreprise, qui souvent n’y comprend absolument rien à l’informatique (en dehors de l’utilisation de Word et Excel).
Cette conférence nous rappelle que ce n’est pas une fatalité et qu’on peut à la fois faire de la qualité de manière productive. Mais pour cela il faut développer les compétences du développeur. Ce qui a pour corolaire de ne plus considérer qu’un développeur est interchangeable avec un autre. Tous les développeurs ne se valent pas. D’où la nécessité de redonner une place centrale à la notion de compétence.
La démarche que propose l’intervenant est à la fois simple, pleine de bon sens mais en décalage avec la vision indifférenciée qu’on certains (beaucoup) dirigeants d’un développeur. Ce n’est pas juste une ressource, mais un individu que le manager se doit de faire progresser, avec méthode pour que cela soit efficace.
Plutôt que d’installer un baby-foot, je crois beaucoup plus qu’un collaborateur sera davantage enclin à rester dans une boite s’il a le sentiment qu’il peut progresser.
Et pour répondre à ta question, la mise en place d’une culture de ce type peut apporter des gains considérables sur le moyen-long terme. Il faut cependant que l’entreprise, et donc le dirigeant ait ce souhait conscient de vouloir faire progresser leurs collaborateurs dans leur art, en faire des « Avengers » pour reprendre l’image de la conférence, ce qui sera bénéfique pour tout le monde.
Les obstacles à cette vision, c’est la culture en général des entreprises françaises (hors start-up) qui sont encore restés coincées dans les années 80 en matière de management des développeurs. Et ce qui explique aussi à mon goût une reconnaissance médiocre de ce métier chez nous, comparativement à ce que je peux constater dans le monde anglo-saxon.
La séniorité n’est pas non plus perçue à sa juste valeur chez nous. C’est avant tout un (trop) gros salaire qu’il serait judicieux de se débarrasser. Il y a tant de jeunes diplômés qui pourrait remplacer le vieux Gérard pour beaucoup moins cher… Alors que des développeurs seniors sont justement un atout considérable en tant que mentor, et utilisés comme tel pourraient faire exploser les compétences de développeurs moins expérimentés.
Voilà. J’espère que cela répond à tes attentes. 
Je viens enfin de regarder la vidéo 
Orienter différemment le kanban en centrant sur le développeur et non l’état d’avancement du process m’a « retourné le cerveau ». Tenter de sortir de la vision tayloriste du kanban de cette manière semble être un vrai levier pour faciliter l’apprentissage comme il l’explique, mais ça doit être hyper bien coaché pour les dev ne voient pas ça comme du flicage.
Si je comprends bien, finalement, au lieu de détecter les blocages d’un sujet à une étape du process, on préfère focaliser sur qui est bloqué pour amener le tech lead à aider ce développeur bloqué dans son apprentissage de la résolution de problèmes.
Je vais y réfléchir ça semble très interessant
1 « J'aime »
Oui, @nicobiot, ça retourne la tête 
Il est important de garder en tête que tout le système Lean / Toyota Production System est un système apprenant permettant de développer les personnes au travers de la résolution des problèmes.
On sort de la vision tayloriste avec le Kanban Lean quand il est piloté par la demande client et quand l’équipe calcule elle-même sa productivité. Il est absolument important que la résolution de problème soit mise en place AVEC le kanban… sinon, c’est le drame. Pourquoi ? Parce qu’avec la résolution de problème, l’équipe progresse jour après jour et atteint des performances parfois incroyables. Elle devient fière de son travail et n’a plus de problème avec les indicateurs de performances. Par contre, il faut vraiment éviter de calculer la productivité à la personne.
Le système TPS est prévu pour rendre visibles les problèmes aux endroits où ils apparaissent (l’étape). On utilise soit l’arrêt automatique, soit on tire l’andon (appel à l’aide). C’est au manageur / responsable d’équipe de venir aider le collaborateur en difficulté pour réussir sa tâche. Si ce n’est pas possible, la pièce est sortie du flux.
Dans tous les cas, il y aura une résolution de problème pour comprendre la cause racine qui peut être d’ordre technique, de formation… Prenons la formation : l’analyse des causes racines permettra de mettre en lumière l’écart entre ce que sait l’opérateur et ce qu’il devrait savoir pour réussir sa tâche. C’est là que la formation au poste de travail (principe Lean) prend ensuite toute sa valeur (dans l’IT : pair programming, par exemple).
Au plaisir de compléter l’échange si besoin.