Catégories
Start-up et applications

VSM s'adresse aux équipes de développement

La notion de création de flux de valeur pour améliorer l'efficacité organisationnelle et fournir des produits de meilleure qualité résonne certainement au niveau C et au niveau intermédiaire dans les grandes entreprises. Pourtant, l'adoption par les équipes de développement chargées de créer ces produits a été plus lente.

Il y a plusieurs raisons à cela. La première est que la gestion des flux de valeur (VSM) ajoute un autre outil auquel les développeurs doivent prêter attention. Un autre est la crainte que les informations sur l'avancement du projet et les efforts individuels ne dépassent les directeurs de développement pour les cadres supérieurs, et ils ne mesurent peut-être pas les travailleurs et leur travail par rapport aux mesures correctes.

Pour les développeurs, selon Eric Minick, directeur de programme, Gestion des produits de livraison continue et de test continu chez IBM, cela fait peur – en particulier dans une organisation à faible confiance. "Êtes-vous dans une organisation qui tire sur le messager, ou êtes-vous dans une organisation qui fait des autopsies irréprochables et des choses comme ça?" Dit Minick. «Le terme que nous entendons est sécurité psychologique – pouvez-vous dire que mon équipe a un problème ou non? Je pense qu'il y a des contraintes organisationnelles à cela. »

Un autre problème est le décalage entre les équipes de gestion et de développement quant à la façon dont les choses se passent. Par exemple, Minick a déclaré: «Si vous choisissez une pratique DevOps – faites-vous un post-mortem irréprochable, faites-vous une livraison continue, et vous demandez au CIO, vous demandez à la direction et vous demandez aux équipes – vous verrez que 60% des CIO dire oui, 45% des cadres intermédiaires disent oui et environ 35% des équipes de développement disent oui.

"Vous avez ce genre de changement vert clair", at-il poursuivi. «Une partie de la valeur de VSM est d'être honnête à ce sujet et de dire, OK, nous avons quelques outils en place, mais notre délai de livraison du code à la production est toujours de 18 jours. Est-ce une livraison continue ou non? Je ne sais pas, c'est une chose d'interprétation. Mais cela devient honnête, dans la mesure où il aligne en réalité l'équipe de développement et les dirigeants – mais si les dirigeants pensent que vous faites mieux que vous, ce moment est un peu effrayant. Et donc, il incombe vraiment aux dirigeants d'envoyer ce bon message et de dire: Regardez, nous savons qu'il y a différents niveaux de maturité, nous n'allons tirer le marteau sur personne ici; ce que nous voulons simplement voir, c'est que les gens s'améliorent, et cela devrait être fait en examinant plusieurs mesures ensemble. C’est vraiment important pour les équipes. Allez-vous vite, ou allez-vous vite sans qualité. Allez-vous lentement avec la qualité? Ce qui est mieux?"

Alors, où le flux de valeur est-il rentable pour les développeurs? Très souvent, les développeurs ont des ralentissements parce que des facteurs leur sont imposés de l'extérieur de leur équipe. Les organisations demanderont: «Pourquoi la chose la plus prioritaire ne fonctionne-t-elle pas?» Et la réponse pourrait bien être: "Parce que je travaillais sur des projets pour animaux de compagnie pour le patron de mon patron." Le résultat de cela, selon Minick, pourrait être moins de demandes de surprise de la part des dirigeants. Ou peut-être que cet exécutif a dit que ces projets étaient la priorité la plus élevée.

Avoir un flux de valeur en place qui montre d'où vient le travail, et comment il a été livré, et cela en soi est très précieux. Un exemple est les revues de code, généralement effectuées par les développeurs les plus expérimentés de l'équipe. Et chaque fois que vous modifiez l’équipe, vous la brisez de sorte que maintenant les révisions de code persistent pendant une semaine ou plus, et que tout le monde est en colère les uns contre les autres, mais personne ne parle – car ce sont des développeurs.

Donc, ce qui se passe, a déclaré Minick, est le suivant: "Vous entrez dans la rétrospective, et voici les données: les révisions de code ont tendance à prendre 5,6 jours. Maintenant, (avec une communication honnête et irréprochable), vous pouvez avoir une conversation productive qui dit sur quels changements de code un développeur junior peut-il faire un examen? Et maintenant, vous n'attendez pas une semaine pour la révision de votre code, et vous arrivez sur le marché une semaine plus rapidement, et les développeurs seniors arrivent à écrire du code, et tout le monde est plus heureux et moins énervé. Ce sont ces petits moments qui, je pense, ont un très gros avantage pour l'équipe de développement, car ils ont toujours des goulots d'étranglement, et les goulots d'étranglement se déplacent en fonction de ce qui a changé, ou du travail inattendu venant de la direction, ou des autres équipes qui sont occupées leurs propres trucs. Ainsi, la télémétrie devrait être extrêmement précieuse pour eux dans leur travail quotidien. Et si le flux de valeur fonctionne bien, cela va mieux les aligner sur l'entreprise, donc ils vont travailler sur des choses plus importantes, et avoir plus d'impact, et cela se sent vraiment, vraiment bien. "

Vous voulez en savoir plus sur les flux de valeur? S'inscrire à Virtual VSM DevCon, une formation gratuite d'une journée destinée aux équipes de développement, qui se tiendra le 22 juillet 2020.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *