Product Management for Continuous Delivery - Elizabeth Ayer at FlowCon France 2019

[00:00:00] Et quelques couleurs vives pour vous donner de l'énergie ce matin. Merci beaucoup d'avoir réussi à venir à Flokhon ce matin. Hum, je veux parler de la gestion de produit pour la livraison continue, mais avant cela, je dois absolument vous parler de mon musée préféré. Nous sommes à Paris, mais ce n'est pas le Louvre. Ce n'est pas non plus, euh, le musée des Arts et Métiers, que j'ai visité hier, et c'était incroyable. Si vous n'y êtes pas allé, vous devez absolument y aller et découvrir l'incroyable histoire de la technologie qui y est présente. Mais le musée que j'aime le plus, je l'ai découvert pour la première fois sur Twitter, quand j'ai vu une photo de ceci et quelqu'un a dit, Est-ce que quelqu'un sait ce qu'est ce bâtiment à Londres ? Et j'ai pensé, ooh, des faits, pas des opinions, hein. Je peux adhérer à ça. Mais en plus, j'ai trouvé qu'il y avait quelque chose de très, euh, très drôle là-dedans, parce que, euh, celui qui a écrit ça a clairement des opinions. Donc, pour tout ce qu'il dit sur les faits et non les opinions, il a des points de vue. Et, euh, alors je suis allée et j'ai découvert un peu plus sur ce musée et j'ai trouvé que c'était l'atelier d'un homme appelé David Carkadi, qui est un super-héros victorien. Un homme incroyable dont vous n'avez jamais entendu parler auparavant. Et je défendrai cette position qu'il est un super-héros, ainsi. Carkadi a empêché les ponts de s'effondrer. C'est un comportement de super-héros, oui. Ainsi, par exemple, à l'époque où Carkadi travaillait, les catastrophes de ponts étaient incroyablement fréquentes. Voici un cas où le pont de Great Yarmouth s'est effondré, 70 enfants sont morts. Mais ce genre de choses arrivait année après année, il y avait des défaillances technologiques comme celle-ci. Carkadi a empêché les trains de dérailler. Ainsi, par exemple, la catastrophe ferroviaire de Versailles en 1840 fut l'une des six catastrophes ferroviaires, des événements catastrophiques. Et celle-ci fut causée par la rupture d'un essieu, une fissure. Et Carkadi a fait cela en testant des matériaux et des composants. Tester les matériaux et les composants. Donc à cette époque, euh, de nombreux nouveaux matériaux étaient développés. Il y avait de nouveaux types de fer, de nouveaux types d'acier. Et les gens les utilisaient directement pour des usages industriels, en grande partie. Je veux dire, ils essayaient de tester, mais n'étaient pas très systématiques à ce sujet. Et il a donc introduit des tests systématiques et matures pour ces nouveaux matériaux et composants. Et cela a provoqué un changement de mentalité dans la façon dont les gens abordaient la technologie de l'époque. Avant, quand quelque chose n'allait pas, on faisait appel à des experts qui témoignaient, eh bien, je pense que c'était à cause de ces choses. Et un autre expert disait, Eh bien, je pense que c'était à cause de cela. Et finalement, ils blâmaient un contremaître ivre ou quelque chose comme ça. Quelqu'un de bas statut et tout le monde partait et continuait à faire la même chose encore et encore, causant une sécurité terrible et une infrastructure vraiment médiocre à cette époque. Alors quand je suis finalement arrivée dans ce studio, le lieu des faits et non des opinions, ce que j'y ai trouvé, c'était ça. C'était une machine appelée machine d'essai universelle. Et c'est une machine de 15 mètres de long, magnifiquement conçue avec une grande précision, qui, pour son époque, était capable d'obtenir la spirale parfaite pour que vous puissiez faire cela. Une ingénierie incroyable. Elle était alimentée par la vapeur, donc par le réseau de vapeur du métro de Londres, super cool. Hum, et, et donc cette machine est toujours en service aujourd'hui dans ce musée, ainsi qu'un tas d'autres machines de test là-bas. Hum, et il est ouvert un jour par mois. Donc si vous voulez un jour y aller et le voir par vous-même, vous devez planifier à l'avance, mais cela en vaut absolument la peine, et c'est un incroyable, euh, témoignage du travail de quelqu'un qui a apporté une maturité à une discipline qui n'était pas encore mature. Et son travail est toujours visible. Il a testé le pont de Blackfriars, il a testé des matériaux pour un tas d'autres choses qui sont encore utilisées aujourd'hui. Et il pouvait ainsi savoir si quelque chose avait des défauts en quelques semaines, cela prenait tout ce temps pour faire ce genre de test plutôt que des années. Il pouvait prendre une poutre en acier qui allait dans un pont et la tester. Il pouvait voir à quoi ressemblait le motif lorsque vous pliez quelque chose sous des forces incroyables, afin que vous puissiez savoir pourquoi quelque chose échouait plus tard. Vous sauriez à quoi ressemblait ce motif de fracture. Et cela a conduit à une livraison plus rapide, car vous n'introduisiez pas de mauvais composants dans votre ingénierie. Cela a réduit les coûts de maintenance et a conduit à une bien meilleure sécurité. Cela vous semble-t-il familier à quelqu'un ? Peut-être, éventuellement. Alors, à propos de la livraison continue, euh, ce sont beaucoup des mêmes avantages que nous obtenions, mais c'est un précurseur très précoce, vous savez, avant le mouvement lean, avant Agile, avant tout cela, 100 ans avant cela, vous aviez quelqu'un qui commençait à appliquer ces principes et à obtenir certains de ces premiers avantages. Et comme la livraison continue offre désormais une livraison plus rapide, un coût de maintenance réduit, la sécurité, la fiabilité, tous ces avantages que nous tirons de cette technologie. Hum, juste une mise à niveau avant d'aborder les aspects produits, pour nous assurer que nous parlons tous de la même chose avec la livraison continue. Hum, cela a été codifié initialement par Jez Humble et Dave Farley dans ce livre, Continuous Delivery, si vous ne l'avez pas lu, c'est l'un des véritables classiques. Et il s'agit de livrer des logiciels utiles aux utilisateurs rapidement, en toute sécurité et de manière durable, selon les propres mots de Jez. Et le concept central ici est celui d'un pipeline de développement. Vous avez donc un groupe de... une équipe pluridisciplinaire qui travaille ensemble maintenant. Nous avons donc transféré autant de compétences que possible à cette équipe de développement initiale. Et il y a certains principes intégrés ici, comme le fait que tout doit être sous contrôle de version. Tout passe ensuite par l'intégration, de préférence un développement basé sur la branche principale. Tout passe par l'intégration, construit des artefacts, puis est automatiquement propagé aux environnements en aval, offrant une fiabilité grâce à cette infrastructure que nous n'avions pas à l'époque. Hum, et de la capacité ensuite à voir très rapidement si quelque chose n'allait pas réellement fonctionner une fois potentiellement mis en production. Donc, il a toutes ces boucles de rétroaction intégrées. Il y a celle initiale avec un développeur sur sa machine. Il y en a une légèrement plus grande avec l'intégration continue et des tests supplémentaires à ce niveau. Et puis, évidemment, dans ces environnements en aval, nous avons davantage de retours d'information pour ces objectifs spécifiques. Maintenant, ce n'est pas la même chose que le déploiement continu. Juste pour clarifier, cela ne signifie pas que tous les changements sont directement mis en production sans intervention humaine. Cela signifie que tout est déployable, il est donc possible de déployer en production, si c'est ce que l'entreprise juge approprié. Voilà donc la livraison continue.
[00:06:57] Hum, et la livraison continue présente ces incroyables opportunités aux chefs de produit. Et c'était quelque chose que moi, en tant que chef de produit, je n'avais pas vu au début. J'ai beaucoup lutté contre cela. On aurait dit que c'était plus de la masturbation intellectuelle de développeur, essayant de faire de la technologie sans, vous savez, ne pas garder un œil sur le coût et le bénéfice que nous allions finalement en retirer. C'était à l'époque où les gens changeaient très fréquemment de contrôle de version et, vous savez, je veux dire, évidemment ces développeurs veulent juste. J'avais complètement tort, complètement tort à ce sujet. Et je regarde en arrière et d'accord, je lève les mains. Hum, cela a vraiment tenu ses promesses en termes de vitesse, de rapidité de livraison et d'améliorations de la qualité, bien au-delà de ce que les développeurs avaient jamais promis. Et cela signifiait que nous avions toutes sortes d'effets positifs en cascade, comme nous n'avions plus autant de reprises, nous n'avions plus de clients qui nous appelaient furieux. Nous avions une bien meilleure confiance au sein de l'organisation parce que le développement était tout simplement meilleur. Ça s'est juste mieux passé. Et encore une fois, les chefs de produit peuvent se battre contre cela. Mais maintenant que nous l'avons adopté, maintenant qu'il est ancré dans la communauté technique, il a des pratiques techniques très solides. Et les chefs de produit ne rejettent généralement plus cela, comme je le faisais. Hum, mais nous n'embrassons toujours pas les avantages que cela nous procure réellement. Et pour comprendre pourquoi, j'aimerais revenir un peu sur l'histoire de la raison pour laquelle cela pèse lourdement sur la mentalité du produit. Et pour cela, je veux le faire avec l'aide de mon ami, Stephen Hawking, qui a écrit une suite à Une brève histoire du temps, que personne ne connaît. Euh, la brève histoire des produits du Big Bang aux trous noirs.
[00:08:46] Et combien de personnes ici se souviennent de ce que c'était de publier annuellement ? Oui, pas mal. Combien de personnes ici publient encore annuellement ? Oh, un seul. Donc, à l'époque, pour ceux d'entre vous qui s'en souviennent, nous devons raconter à ces jeunes ce que c'était. Hum, nous avions ces grosses sorties "big bang" une fois par an environ, et nous avons essayé parce que nous n'avions qu'une seule chance. Nous avons mis tout ce que nous pouvions dans la version. Nous avons entassé toutes les fonctionnalités, toutes les corrections, et cela a conduit à une qualité vraiment terrible, ce qui signifiait que les clients ne voulaient pas déployer la version que nous venions de publier. Ils voulaient le tester pendant des mois ou attendre la sortie de la version corrigée ou autre, ce qui a conduit à tout ce genre de travail à faible valeur ajoutée, ça n'aurait pas dû arriver. C'est ce que c'était à l'époque. Et nous avons décrit ce que cette valeur serait avec des spécifications qui ressemblent à ceci. Et je ne sais pas si vous pouvez réellement le lire là-haut, mais une spécification comme celle-ci vous dit exactement où mettre les boutons, mais avec des mots. Et nous avons fait cela, et les spécifications étaient vraiment instrumentalisées à cette époque. Vous auriez quelqu'un avec un dossier commercial disant, eh bien, je vais gagner 100 millions de dollars si vous investissez dans le mien. Eh bien, je vais gagner 200 millions de dollars si vous investissez dans le mien. Et tout était complètement inventé. Je veux dire, nous avons essayé d'être professionnels en matière d'ingénierie des exigences, mais honnêtement, quand je repense à cette mauvaise époque, c'était la base pour offrir une très, très faible valeur client. Mais ensuite, nous avons eu Agile. Hourra, nous avions une équipe de développement livrant du logiciel au chef de produit, qui livrait des carnets de commandes à l'équipe. Et tout, vous savez, les cycles ont diminué, ça s'est un peu amélioré. Mais bon, du Big Bang au trou noir. La partie trou noir, c'est que nous avons eu des méthodes de travail plus agiles au sein de l'équipe, mais qu'est-ce qui s'est passé quand quelque chose est sorti vers les vrais utilisateurs ? C'était à peu près tout. C'est sorti par la porte, et puis nous avons dit au revoir et n'y avons plus jamais pensé. Et c'est ce que j'appellerais l'Agile trou noir. Et malheureusement, beaucoup d'entre nous en font encore l'expérience aujourd'hui. Hum, et donc c'est, c'est, vous savez, déverser ce que nous faisons. Et si vous voulez savoir si c'est vous, les signes de l'Agile trou noir sont des choses comme « fait » signifie codé ou testé ou livré, mais cela ne signifie pas validé. Dans ce genre de monde, avec l'Agile trou noir, la mise en production est le point de célébration. Hou, le jeter dans le trou noir. Mais le succès de l'utilisateur n'est pas ce qui est célébré. Vous remarquez dans l'Agile trou noir qu'aucune fonctionnalité n'échoue jamais. Jamais. Non. Parce que vous ne le sauriez jamais. Ça pourrait sortir et ne jamais tenir la promesse commerciale. Mais qui le saurait car nous n'avons pas ces mécanismes de validation en place. Et la planification commence souvent par des idées de fonctionnalités. Vous dites, d'accord, quelle est la liste des choses que tout le monde a en tête et que nous pensons vraiment devoir faire ? Qui, quelqu'un reconnaît ça comme étant comment ils, ouais. Oui. Euh, malheureusement, il est encore extrêmement courant pour nous tous de travailler de cette manière. Et je pense que nous pouvons retracer ce comportement jusqu'à l'époque où nous avions ces spécifications de version. Et nous avions cette attitude de jeter les choses aux utilisateurs et de les oublier. Et nous faisons toujours cela avec beaucoup de développement Agile aujourd'hui. Alors, qu'y a-t-il au-delà du trou noir ? Eh bien, boucler la boucle. Je veux dire, dans ce diagramme pour la livraison continue, nous avions des choses qui allaient aux utilisateurs, et cette flèche n'était tout simplement pas là. Alors, qu'allons-nous faire ? Nous allons essayer de récupérer ces informations auprès des utilisateurs. Nous allons ajouter cette boucle métier à notre livraison continue, de sorte que nous ne fassions pas seulement des boucles techniques de développement, mais que nous fassions aussi des boucles de production qui testent cette hypothèse métier de la même manière que le développement teste une hypothèse technique. Et bien sûr, c'est facile. Vous décrivez le résultat que vous voulez. Vous livrez un logiciel et vous le mesurez, n'est-ce pas ? Lol.
[00:13:13] Littéralement, quiconque a essayé cela sait que ce n'est pas facile du tout. C'est vraiment, vraiment difficile. En fait, euh, Nicole Forsgren a traité, a tweeté récemment, c'est la femme qui a écrit Accelerate avec Jez Humble, un livre merveilleux, vous devriez aussi le lire. Hum, et c'était dans le sens du mème d'un tweet que tout le monde dans votre industrie connaît, mais dont personne ne parle. Et elle était là à dire que mesurer les choses est vraiment important, mais vraiment difficile, et aucun d'entre nous ne le fait.
[00:13:46] L'Agile du trou noir. C'est ce que nous voyons. C'est ce que nous vivons encore. Et donc vous voyez une prolifération de cadres de définition d'objectifs, essayant d'aider à boucler la boucle sur l'Agile, essayant de spécifier quels sont les résultats que vous recherchez et de les réintégrer, assurez-vous de vérifier cela. Euh, la plupart des gens parleront d'objectifs et de résultats clés. Il y a tellement de saveurs différentes de cela maintenant. Je ne peux presque pas, ce n'est presque pas une chose. C'est toute une famille de choses, de façons d'exprimer l'intention, puis de vérifier cette intention. Il y en a tout un tas d'autres. J'aime bien ce que je vois. Je ne l'ai pas essayé, mais j'aime ce que je vois dans les quatre disciplines de l'exécution. Hum, j'aime ce que je vois dans le processus de mesure de la performance, qui est quelque chose que Stacy Barr, qui est une experte en mesure de la performance, a fait un travail merveilleux. Le cadre North Star vient de sortir d'Amplitude, qui est une entreprise qui produit des logiciels pour suivre ces résultats. Il y a beaucoup, beaucoup de ces cadres qui apparaissent pour nous aider à résoudre ces problèmes. Juste pour vous donner un exemple au cas où vous n'auriez jamais travaillé avec un OKR auparavant. Un exemple pourrait être quelque chose comme ça. Comme je l'ai dit, il y a beaucoup de saveurs différentes, mais voici un exemple. Et c'est une chose que, euh, j'ai pensé que je ferais une faveur à mes organisateurs de conférence. J'ai fait un peu de recherche compétitive et j'ai découvert ce qu'ils utilisaient lors d'une très grande conférence sur les produits. J'ai pensé, conférence produit, ils doivent réellement faire des mesures, n'est-ce pas ? Il s'avère que oui. Hum, et ils avaient décomposé la satisfaction des participants en catégories très simples : l'inscription s'est-elle déroulée sans problème ? Quelle était la qualité des intervenants ? Et la nourriture était-elle bonne ? Pour être juste, je pense que cela résume bien la situation. Hum, et donc ils avaient, euh, des objectifs d'année en année. Ainsi, pendant un an, ils ont eu une très mauvaise expérience avec des gens faisant la queue devant la porte, certains manquant la conférence d'ouverture. Et donc ils avaient un objectif en place pour maintenir la satisfaction des utilisateurs, la satisfaction des participants élevée, euh, et particulièrement autour de l'inscription. Et la façon dont ils se vérifiaient à ce sujet était : pourrions-nous faire entrer 90% des inscrits dans la salle avant la première session ? Hum, ils ont généralement obtenu un taux de participation de, euh, 97%, et ils pensaient que 90, 94 serait tout juste atteignable pour faire entrer autant de personnes dans la session. Hum, et donc ce que cela fait, c'est que cela exprime clairement l'intention et exprime exactement comment ils vont se juger là-dessus. Hum, et l'une des choses merveilleuses à ce sujet est que cela ne dit pas nécessairement comment le faire. Il y a donc de nombreuses façons d'aborder cela. Ils pourraient ajouter des bénévoles à l'inscription pour accélérer le processus. Ils pourraient déplacer l'heure de début du discours d'ouverture. Ils ont beaucoup, beaucoup d'options parce qu'ils n'ont pas dit exactement ce qu'ils allaient faire. Ils étaient tous alignés autour de cet objectif, ce qui leur permettait, même sur le moment, de travailler à la réalisation de cet objectif, à savoir faire entrer les participants avant le début de la conférence principale. C'est donc un exemple de, euh, OKR sur leur utilisation, sur la façon de s'aligner sur l'intention, ce qui nous amène au premier point de la gestion de produit pour la livraison continue : s'aligner au niveau de l'intention, non pas au niveau de la fonctionnalité, mais au niveau de ce que l'on essaie d'atteindre. Maintenant, pour être juste, les bons chefs de produit font cela depuis toujours. Ils s'efforcent de s'assurer que des équipes entières et eux-mêmes sont alignés sur ce qui est à atteindre pour obtenir de bonnes contributions de ces équipes sur ce qu'elles essaient de faire. Donc ce n'est pas tout, ce n'est pas seulement s'aligner sur le niveau d'intention, mais c'est aussi vérifier et changer de cap. Si à ce moment précis, vous découvrez quelque chose, vous êtes sur une trajectoire qui n'est pas la meilleure pour atteindre cet objectif, vous avez besoin de la liberté de la changer. Vous devez faire cette vérification constante et changer de cap.
[00:17:31] C'est une question que je me pose maintenant, euh, je forme des chefs de produit dans certaines grandes organisations. Hum, et on se dit, bon, c'est probablement bon si on ne mesure pas, non ? C'est bon. Hum, et la réponse à cela est que c'est bien jusqu'à ce que ça ne le soit plus. Alors, en ce moment, je travaille pour le gouvernement des États-Unis, et ils ont, euh, des logiciels qui sont vraiment mauvais. Genre vraiment, vraiment, vraiment, vraiment, vraiment, vraiment mauvais. Hum, je suis d'avis que si vous voulez faire évoluer un système, vous partez de là où vous êtes, et vous l'étranglez, ou vous le découpez, vous faites certaines choses de là où vous êtes, vous le faites évoluer. Il n'y a rien à sauver de beaucoup de ces systèmes. C'est une perte totale. La logique métier est défaillante, l'expérience utilisateur est presque inexistante. La quantité de contournements autour du logiciel est agonisante pour quiconque se soucie de l'expérience des utilisateurs. Hum, et donc vous dites que nous allons, peut-être, essayer de mettre en place un nouveau système d'authentification. Vous savez, nous allons simplement essayer d'utiliser quelque chose de plus sécurisé et qui utilise des flux de travail modernes, des modèles de développement modernes pour le faire. Et il n'y a aucun doute dans nos esprits que cela va tenir la promesse d'une meilleure sécurité et d'une meilleure expérience utilisateur. Aucune, aucune du tout. Nous serions absolument stupéfaits si cela ne tenait pas ses promesses. Et en partant de là où nous en sommes, avec un logiciel aussi mauvais, honnêtement, vous pouvez être intuitif sur ce que vous faites. Et maintenant, vous pouvez cueillir les fruits les plus accessibles. Vous pouvez faire les choses évidentes. Et donc la mesure à ces premiers stades ne délivre pas réellement de valeur, et les gens commencent à penser, eh bien, c'est inutile. Pourquoi je mesure ça ? On le savait déjà. Le problème, c'est qu'à un moment donné, cela changera, surtout avec les équipes de livraison continue. Elles sont là, agiles et itératives, livrant de la valeur très rapidement. Cela va changer. Ils vont passer par toutes les choses évidentes et intuitives, et à ce moment-là, les choses cesseront de fonctionner. Elles cesseront de réellement, vous savez, de délivrer évidemment la valeur, et ils ne sauront plus quoi faire. L'équipe n'a pas de mécanisme pour travailler dans cet environnement. Et ce qui fonctionnait avant ne fonctionne plus. Alors, c'est probablement bon si on ne mesure pas. Non. Non, ce n'est pas bon car à un moment donné, nous devons avoir cela avec une équipe de livraison continue. quand les gens commencent à penser, c'est inutile. Pourquoi je mesure ça? On le savait. Le problème, c'est qu'à un moment donné, cela changera, surtout avec les équipes de livraison continue. Elles sont là, sympas et itératives, livrant de la valeur très rapidement. Cela changera. Ils passeront par toutes les choses évidentes et intuitives et à ce moment-là, les choses cesseront de fonctionner. Elles cesseront d'apporter, évidemment, de la valeur. Et ils ne savent pas quoi faire. L'équipe n'a pas de mécanisme pour travailler dans cet environnement. Et ce qui fonctionnait avant ne fonctionne plus. Alors, c'est probablement OK si on ne mesure pas? Non, non, ce n'est pas bon parce qu'à un moment donné, nous devons l'avoir avec une équipe de livraison continue. Donc juste pour donner des preuves à ce sujet, cela doit arriver, cela arrive toujours. Euh c'était un article que Microsoft a écrit et dans lequel ils ont décidé de tester si leurs fonctionnalités apportaient la valeur qu'ils recherchaient de la part des fonctionnalités. Et donc ils ont effectué un très vaste test sur les capacités fournies par leurs applications et ont constaté que seulement 30% d'entre elles apportaient réellement la valeur commerciale qu'ils attendaient. Seulement 30%. 60% n'ont eu aucun changement ou ont eu un effet néfaste sur la chose qu'ils surveillaient. Donc, c'était après quelques années à essayer de faire des choses évidentes mais sans avoir une culture de la mesure, et soudain, ils se retrouvent dans une position où leurs meilleures estimations ne sont pas bonnes. 30% n'est pas bon. Et il s'avère que c'est une statistique très courante. Si vous regardez un tas d'autres entreprises, ce chiffre de 20 à 30% est ce qu'elles citent toutes comme étant le moment où vous commencez à mesurer. Après avoir fait les choses vraiment évidentes pendant un certain temps, vous commencez à mesurer et vous vous dites, oh, seulement 20 à 30% de nos capacités apportent la valeur commerciale que nous pensions qu'elles allaient apporter. Et à ce moment-là, ces entreprises commencent à s'améliorer, elles commencent à suivre leur taux de succès avec ces fonctionnalités. Et à ce moment-là, elles peuvent commencer à comprendre ce qui fait avancer les choses et ce qui ne les fait pas avancer. Et c'est cet apprentissage qui est absolument essentiel pour un produit réussi allant au-delà de ce stade. Il devrait être intuitif pour nous que la valeur puisse augmenter aussi bien que diminuer lorsqu'une fonctionnalité est ajoutée. En fait, si nous y réfléchissons, c'est assez évident, car sinon nous n'aurions jamais d'interfaces comme celle-ci. Nous n'aurions jamais pu y arriver, mais quelqu'un a pensé que chacune de ces capacités, chacun de ces dialogues était précieux, mais à un moment donné, c'est devenu un grand désordre avec lequel les gens ne pouvaient pas travailler. Et nous l'avons peut-être vu dans certains logiciels d'entreprise que nous utilisons tous aujourd'hui. Nous savons qu'une fonctionnalité n'ajoute pas nécessairement de la valeur. Et c'est l'un de mes griefs avec le mot fonctionnalité. C'est tellement incontestablement positif. Mais ce n'est pas réellement et nécessairement une chose positive. Si seulement 30% de ces choses répondent à l'intention commerciale, ce n'est pas une fonctionnalité, c'est simplement un logiciel que vous avez livré.
[00:22:20] nous trouvons que les entreprises, probablement les vôtres, mesurent beaucoup de choses, donc ce n'est pas par manque de mesure réelle. Je pense que cette situation est ce que je vois beaucoup. Cette citation vient en fait de quelqu'un de Microsoft bien après la publication de ce rapport. Nous avons beaucoup de métriques, mais cela ne change rien. Ce qui signifie que la mesure a lieu, mais qu'elle ne s'aligne pas pour diriger le comportement de l'utilisateur. et pour stimuler le comportement. Et la différence entre les entreprises qui se contentent de mesurer et celles qui utilisent réellement la mesure se trouve dans la culture. Ce n'est pas dans les outils qu'elles utilisent, ce n'est pas dans le cadre, c'est dans la culture de la mesure de ces entreprises. Donc, quelqu'un comme Amazon a une culture profondément ancrée de la mesure, de la cascade, des objectifs et de tout cela. C'est partout dans leur comportement autour du produit. Alors, qu'est-ce que j'entends par culture ? Je ne parle pas de l'opéra et le ballet, je parle de la culture comme un ensemble d'hypothèses qui a suffisamment bien fonctionné pour être considéré comme valide. Donc, des choses que nous avons faites et pour lesquelles il n'y avait pas nécessairement de base, mais c'était bien. Elles ont fonctionné. Et donc nous continuons à les utiliser. Cet homme, Edgar Shine, a écrit d'excellents livres sur la culture organisationnelle et, avec cette définition des hypothèses de base partagées sur ce qui fonctionne suffisamment bien, nous pouvons considérer la mesure. Et tout cela, c'est probablement bien si on ne mesure pas, est une question culturelle. C'est quelque chose qui est ancré non seulement dans la culture organisationnelle, mais aussi dans la culture professionnelle de la gestion de produits. Et pour moi, je pense que cela remonte à l'époque des spécifications où nous nous contentions de jeter les choses par-dessus le mur et où tous ces chefs de produit ont eu des carrières réussies. J'ai eu une carrière réussie en faisant cela chez Siemens, ai-je fait de bons logiciels? Non, mais j'ai quand même eu des augmentations et des promotions et des choses comme ça. Et donc, au sens culturel, cela a suffisamment bien fonctionné pour être considéré comme valide. C'est ainsi que cela s'est ancré dans la culture de la gestion de produits. Et si vous regardez les personnes qui embauchent, les personnes qui forment, elles peuvent parler de mesure. Mais je pense que nous constatons toujours que, profondément ancré dans notre culture, ce n'est pas là. Nous ne mettons pas en pratique ce que nous prêchons. Donc, le produit gagne quand nous étendons cette culture DevOps, tout comme nous étendons ces boucles de rétroaction. Et nous devons y ajouter cette culture de validation, cette culture de mesure, pour l'ancrer dans nos comportements et pas seulement dans nos intentions. Je vais parler un peu de la culture DevOps. Euh, il y a de nombreuses façons de l'aborder. J'ai tiré celle-ci du blog de Martin Fowler. De nombreuses façons de l'aborder, mais en gros, nous pouvons considérer la culture Devops comme une culture du feedback, une culture de l'automatisation, et une culture de l'intégration de la qualité dès le départ. Et toutes ces choses tournent autour d'un sens de responsabilité partagée avec ces équipes interfonctionnelles, Dev et Ops. Et c'est ça la culture d'équipe, qui est construite sur les fondations de la culture organisationnelle. Ce qui signifie pas de silos, les démanteler, et des équipes autonomes, en essayant de s'assurer qu'il y a suffisamment de capacité dans ces équipes.
[00:25:40] qu'ils peuvent agir sans avoir à consulter des personnes de partout ailleurs dans l'organisation, qu'ils peuvent avancer et accomplir leur mission. Donc c'est ça la culture DevOps, plus ou moins, en résumé. Si nous voulons ajouter un produit, eh bien, vous pourriez soutenir que le feedback est déjà là. Mais ce feedback n'est pas la même chose que cette tranche qui va jusqu'aux utilisateurs de production. Je vais donc le mentionner séparément comme étant une chose sur laquelle nous devons travailler. est la partie validation de la culture produit. Et donc, comment changer la culture ? Comment changer la culture ? Eh bien, heureusement, notre ami M. Shine a des conseils à nous donner dans ce livre sur le changement de la culture organisationnelle. Et il dit qu'il existe des mécanismes primaires pour ancrer la culture. Et la principale, la chose numéro un, c'est à quoi faites-vous attention ? Et cela vient surtout du leadership, pour les personnes qui sont considérées comme des leaders. À quoi font-ils attention? De quoi parlent-ils? Qu'est-ce qu'ils mettent en avant? À quoi passent-ils leur temps? Euh d'autres mécanismes incluent les réactions aux grands événements. Donc cette chose du moment fait partie d'une autre façon d'ancrer la culture, c'est-à-dire comment ces leaders ou d'autres personnes réagissent.
[00:26:51] quand de grands événements se produisent. Euh la façon dont les ressources sont allouées, le temps, l'argent. Si nous disons que nous valorisons l'autonomie de l'équipe, mettons-nous réellement des ressources derrière pour que cela se produise, y compris de l'argent souvent nécessaire dans ces cas pour s'assurer que cela arrive.
[00:27:09] Et les récompenses, donc les gens qui reçoivent des primes, des promotions, tout ça, d'où ça vient ? Si ça devait être les moyens par lesquels nous signalons. ce que nous valorisons dans une organisation. Et enfin, le mentorat, l'enseignement, le coaching, toutes ces choses plus traditionnelles, mais des choses que les gens sont parfois trop timides pour faire quand il s'agit d'une valeur, pas d'une compétence pure et dure. Ce sont donc les mécanismes primaires. J'ai un peu condensé sa liste, mais ce sont les mécanismes primaires pour ancrer la culture. Et c'est ainsi que, personnellement, j'aime faire les choses comme ça. Je suis une grande fan des tableaux de bord. Je suis une grande fan des tableaux de bord avec quelque chose de vraiment grand en haut pour rappeler aux gens quel est l'objectif. Ce qui est ma principale plainte concernant de nombreux logiciels de gestion de projet, c'est que vous ne pouvez pas réellement personnaliser cela pour en faire votre propagande dont vous avez besoin. Euh mais j'aime personnaliser un espace, voici une équipe avec laquelle j'ai travaillé, ils avaient leur ils n'ont pas l'air de l'utiliser, ils l'ont réellement utilisé. Leurs tableaux de bord, il y en avait plusieurs qui traînaient dans le bureau aussi. Donc attirer l'attention sur cela, s'assurer que c'est présent et en parler, s'assurer que si vous êtes en stand-up, vous vous y référez, que vous le vérifiez, que lorsque vous planifiez, vous y revenez. Donc, certaines des choses que, encore une fois, j'aime faire pour promouvoir une culture de boucle fermée avec les équipes sont tout d'abord, rendre cet objectif et ces résultats vraiment visibles, partout, à tous les niveaux, le chanter, de haut en bas. Euh, normaliser le travail par petits lots. C'est presque une valeur en soi. C'est tellement important. Et je trouve que mes équipes ont universellement été trop embarrassées pour livrer quelque chose de vraiment, vraiment minuscule, mais c'est la taille dont nous avons besoin pour pouvoir le valider. Donc, promouvoir cette culture et essayer de normaliser le travail formidable par petits lots, aller jusqu'au bout de la boucle est ce qui compte. Ce genre de renforcement a été vraiment nécessaire pour mon expérience. Euh, prendre le temps, il s'agit de l'allocation des ressources, juste prendre le temps. Et en tant que professionnels du produit, nous avons évidemment beaucoup d'influence sur la façon dont ces équipes passent leur temps, nous nous assurons que nous avons le temps, les tâches pour collecter et analyser ces résultats, nous-mêmes, les autres, partout, que nous faisons ce travail, que nous rendons ce travail visible, que nous l'incluons dans notre planification. et agir sur ce que nous apprenons. C'est là que ça a tendance à se casser. Nous pouvons donc regarder tout ce que nous voulons, et c'est la culture de la mesure que les gens disent, mais cela n'affecte pas vraiment ce que nous faisons. C'est agir là-dessus et encore une fois, pour moi, cela variera selon les personnes, je pense que différentes choses fonctionneront pour différentes personnes. Mais pour moi, j'aime commencer la planification en nettoyant le backlog, je veux dire vous pouvez le garder là si vous voulez vraiment, mais en partant d'une feuille vierge de ce que vous voyez en ce moment dans ce que vous mesurez et ce que vous avez appris. et essayer de faire avancer cela. Alors, ce sont mes techniques personnelles. Je suis sûr que vous en avez beaucoup plus. J'ai hâte de les entendre. Euh Et c'est la validation, c'est ce qui, vous savez, est un composant clé essentiel pour nous de faire progresser la gestion de produits et la livraison continue. Et cela nous donne l'opportunité d'apprendre et d'essayer d'améliorer nos pratiques de produits. Mais nous avons aussi des défis à relever avec cela. Et j'ai senti que je ne pouvais pas parler de ce sujet sans évoquer certains des défis qui rendent cela très difficile avec les équipes qui adoptent cette cadence de livraison rapide en essayant de les gérer comme des produits en utilisant des techniques à l'ancienne.
[00:30:35] Donc, une fois que nous ajoutons cette boucle de rétroaction, euh je vais simplifier un peu ce diagramme. Euh, nous pouvons considérer ces éléments comme des cycles. Donc, en enlevant l'encombrement, cela ressemble à ceci. Vous avez vos boucles de développement internes, j'en ai supprimé quelques-unes. Et puis vous avez une boucle de production externe. Ce qui est cette boucle d'hypothèses commerciales. Euh mais ceux-ci deviennent plus courts et plus rapides et plus fiables et ceux-ci se resserrent. Et ce que j'ai pu constater, c'est que cela crée un goulot d'étranglement ailleurs. Avant, le goulot d'étranglement était la livraison, à l'époque où l'on expédiait des logiciels dans le trou noir. Euh, le goulot d'étranglement était la livraison, surtout, vous savez, bien avant que nous ayons l'agile aussi. Euh, mais soudain, nous avons eu un goulot d'étranglement dans la prise de décision produit. Nous avions tellement de petites micro-décisions à prendre qu'un chef de produit ne pouvait pas être là pour les prendre toutes, même s'il était directement intégré à l'équipe. Afin d'avoir les informations pour fournir ces décisions, cette personne ne pouvait pas être constamment au courant de absolument tout ce qu'une équipe de développement faisait. Et donc nous avons constaté que cela créait un très grand goulot d'étranglement ailleurs dans ce processus de décision. Euh, je vais parler d'un exemple, je ne travaille plus pour ces gens donc je peux parler d'eux avec gentillesse et sans ménagement. Euh et nous avons vécu cela lorsque nos équipes de développement avaient ancré ces merveilleuses pratiques, mais nous avons également constaté qu'à mesure qu'elles devenaient très bonnes dans ces choses, l'engagement commençait à diminuer et nous avons également constaté que l'efficacité, la prise de décision, en fait, c'était comme si tout était vraiment difficile à réaliser dans l'organisation.
[00:32:16] Et nous avons remonté cela aux goulots d'étranglement de la prise de décision produit. Les chefs de produit gardaient ces décisions très secrètes. et en gardant le contrôle de ces décisions. Et il s'est avéré que les équipes de développement étaient en quelque sorte prêtes à en prendre certaines en charge, mais ces chefs de produit les retenaient trop, ils ne les laissaient pas partir. Et nous n'avions pas non plus assez de chefs de produit.
[00:32:38] Donc, tout cela, encore une fois, a mené à ce sentiment que les choses n'allaient pas. Euh et donc malgré ces meilleures pratiques de développement, encore une fois, les gens se sentaient découragés et ça ne faisait pas du bien. Et donc nous avons essayé une restructuration de l'entreprise. Euh et nous avons essayé de dire que nous créons des équipes autonomes maintenant, vous êtes maintenant autonomes. Euh et donc, vous savez, le prochain conseil est de donner les moyens aux équipes d'éviter d'être un goulot d'étranglement sur les décisions produit. Je peux vous dire ce que c'est de faire ça naïvement et comment le faire mal. Je me considère comme une sorte d'expert mondial en matière de déresponsabilisation tout en essayant de responsabiliser. Euh ce n'est pas juste un mot vide de sens, l'autonomisation signifie vraiment quelque chose de spécifique. Cela signifie qu'une personne se sent habilitée ou qu'une équipe se sent habilitée à prendre ces décisions. Euh et en fait, j'ai tellement mal fait ça, j'ai donné une conférence ailleurs sur ce sujet, sur le mot A autonomie et comment je l'ai brisé. Euh En bref, la rupture a été de dire : vous êtes autonomes, voici votre backlog, bonne chance, au revoir. Ce n'est pas la façon de promouvoir l'autonomie. Vous ne donnez pas simplement le contrôle de quelque chose à quelqu'un. Euh, cela a été résolu par une application plus approfondie de "Turn the Ship Around" de David Marquet. Euh si vous n'avez pas lu ceci, c'est un autre merveilleux livre pour comprendre ces choses. Euh et à partir de cela, nous pouvons établir que les principes d'autonomisation sont quelque peu différents de ce que nous pensions. Il ne s'agit pas simplement de contrôle, voici votre contrôle. Ce n'est pas responsabilisant. Ce qui est habilitant a deux piliers. Je ne sais pas si vous pouvez les lire. J'espère que vous pouvez les lire.
[00:34:15] Euh l'une d'entre elles est la compétence technique et ce n'est pas seulement technique au sens de euh, vous savez, la compétence informatique, mais c'est toutes les techniques nécessaires pour faire cela et les informations pour remplir le rôle particulier. Et l'autre partie est la clarté organisationnelle. Donc, de l'organisation, vous avez besoin de clarté sur la mission de cette équipe et sur ce que cette équipe essaie d'accomplir. Il faut donc un cadre agréable, clair et confortable pour travailler. Et cette équipe a besoin de compétences, et c'est surtout sur le développement de ces compétences que nous avons vraiment échoué au départ. Et ce que nous avons découvert que nous devions faire pour donner le contrôle, c'était de former au produit, nous devions nous former à ces techniques de gestion du périmètre, de commande, de planification, je ne dis pas de priorisation car dans un monde basé sur les objectifs, cela semble un peu différent. Mais quand même, en pensant aux techniques, vous savez, comprendre des choses comme le coût du retard, nous devions former nos équipes à certaines de ces techniques pour pouvoir prendre de bonnes décisions produit.
[00:35:11] Et enfin, en pensant commercialement, nous avions besoin qu'ils progressent. Et en fait, nous avons constaté que beaucoup d'entre eux étaient prêts. Ils posaient déjà des questions qui indiquaient une volonté d'aller dans cette direction. Mais nous devions leur fournir des informations, de la formation, et ce qui était connu dans d'autres parties de l'entreprise pour les intégrer délibérément dans l'équipe et fournir à l'équipe tout le contexte dont elle avait besoin, sans dire de manière agressive.
[00:35:42] Donc si nous revenons à cette culture DevOps, c'est l'autre pièce que nous avons trouvé manquante, l'autre pièce qui, pour une culture produit, un produit autonome, une culture produit réussie dans le monde de la livraison continue, nous avions besoin de cette pièce d'autonomisation également.
[00:36:00] Ce n'est donc pas facile. Nous en avons parlé. Je veux dire, le changement de culture n'est jamais facile. Euh mais l'un des points clés du changement de culture est que vous ne pouvez pas le résoudre avec des pratiques techniques. Vous devez d'abord reconnaître que le problème est un problème de culture. Et c'est ce que je pense que nous faisons. Je pense que c'est là que notre discipline est allée, c'est de commencer à reconnaître les problèmes de culture autour de la validation et de l'autonomisation et de les reconnaître pour ce qu'ils sont. Donc, en fait, je suis en quelque sorte encouragé par cela. Donc, si nous reconnaissons le type de défi qu'il représente, nous pouvons nous réunir en tant que discipline dans des endroits comme celui-ci et discuter des moyens de le résoudre et commencer à progresser de manière à niveler tout le terrain de jeu. Au lieu de simplement, vous savez, une pratique technique ici, une pratique technique là et une entreprise qui le fait bien, nous pouvons faire avancer tout le monde en partageant ces défis. Je suis donc encouragé, je suis enthousiasmé, je suis enthousiasmé par ce que je vais voir aujourd'hui lors du reste de cette conférence. Euh et je suis ravi de pouvoir apporter des faits et non des opinions dans ces discussions. Évidemment, nous avons toujours besoin de notre jugement, nous avons toujours besoin de nos opinions, mais nous pouvons vraiment augmenter le niveau de faits que nous utilisons dans cette prise de décision. Et juste pour euh pour conclure cette conversation sur ce qu'il faudra pour faire de cela la norme dans notre discipline. Euh je veux parler de ce que Kakoti a réellement vécu en essayant de faire du test la norme en science des matériaux. Euh il a constaté que pendant longtemps, donc quand il a construit cette machine pour la première fois, il a dû la financer avec son propre argent. Il a dû financer cette gigantesque machine de 15 mètres parce que personne d'autre que lui ne pensait que c'était assez important à faire. Et donc il l'a construit. Il a découvert qu'il pouvait obtenir quelques clients à travers le monde pour lui expédier des matériaux. Principalement en Europe, je pense que les Britanniques ne se souciaient pas autant de tuer des gens. Euh et donc les gens, vous savez, il a travaillé comme consultant indépendant et au fil du temps, les gens ont commencé à parler. Et ils sont devenus un signe de qualité, oh, mes matériaux ont été testés par Kakoti. Ils ne le faisaient toujours pas pour eux-mêmes, mais ils parlaient au moins de, oui, eh bien, c'est bien. Nous voulons le faire. Oui. Euh et puis cela a persisté comme ça et il est devenu énormément frustré par cette situation. où les gens parlaient encore, mais ne vivaient pas vraiment cette mentalité de test. Euh jusqu'à ce que, soudainement, vers la fin du 19ème siècle, ça bascule. Et nous avons regardé autour de lui et tout le monde faisait les tests, tout le monde, toutes les différentes entreprises avaient leurs propres départements pour faire cela, il y avait des machines concurrentes aux siennes. Cela a soudainement basculé. Il a constaté que, comme avoir toutes ces personnes différentes dans tous ces endroits différents, soudain, tout s'est mis en place et toute l'attitude de cette industrie a changé. Cela a semblé se faire du jour au lendemain, mais en fait, ce fut une lente progression tout au long de ce siècle. Donc je pense que nous allons voir ça. Je pense que nous le voyons maintenant, car nous sommes tous d'accord, la mesure est importante, nous sommes tous d'accord, la validation est importante, nous développons tous ces outils et techniques. Nous recherchons donc ce changement que nous verrons peut-être, euh, peut-être pas cette semaine. Peut-être pas cette année, mais j'espère assez tôt pour que nous puissions en profiter. Juste pour citer les livres sur lesquels j'ai basé ma réflexion en plus de l'expérience, les choses qui m'ont aidé à construire mes modèles mentaux à ce sujet. Euh évidemment la livraison continue, euh accélère le livre que j'ai mentionné, le travail de Nicole Forgren, qui explique comment ces mécanismes de livraison continue fonctionnent ensemble pour générer une meilleure culture, un meilleur environnement, euh plus de satisfaction des développeurs, toutes ces choses. Euh pour la fixation d'objectifs. J'aime particulièrement le focus radical. Mais j'aime aussi ce livre appelé "Thinking in Bets", auquel John Cutler consacre beaucoup de temps. J'ai aussi beaucoup de temps pour une façon de conceptualiser notre travail, en particulier le travail risqué, comme une séquence de paris sur ce qui motive quoi. Et ce que vous pouvez faire pour réellement affecter le comportement externe, qui est souvent un enchaînement d'hypothèses et de paris que vous faites en cours de route. Je pense que c'est énormément utile pour essayer de faire passer quelque chose d'une intention et d'un objectif de haut niveau jusqu'à ce que nous allons réellement mesurer sur le terrain dans une boucle étroite. Et enfin, concernant la culture et l'autonomisation, le livre d'Edgar Schein que j'ai mentionné, qui contient de nombreux conseils pour ajuster la culture, pour faire avancer la culture dans des directions saines. Et David Marquet pour "Turn the Ship Around". Ce qui est un ouvrage si important sur l'autonomisation, sur la capacité des équipes à prendre davantage de décisions concernant nos produits, dans notre cas. Euh, je veux juste remercier encore une fois les sponsors qui ont rendu possible notre présence ici. Et merci de me rejoindre aujourd'hui. D'accord. Merci.

Transcription (Traduit)