Pawel Brodzinski
Transcription (Traduit)
ce qui me laisse un énorme fossé à apprendre et probablement un énorme potentiel de frustration d'ici demain. De toute façon, je finirai peut-être par le faire en anglais, je suppose. Quoi qu'il en soit, pour cette session, je veux aborder le sujet de la gestion de portefeuille. Et assez intéressamment, récemment, c'est une sorte de thème récurrent pour moi. Lorsque je parle avec différentes organisations et qu'elles m'abordent, hey, Paweł, peux-tu nous aider à améliorer notre façon de travailler ? Et elles commencent à parler des problèmes de leurs équipes, équipes d'ingénierie, équipes de projet. Et nous orientons rapidement la discussion vers ce qu'elles ont réellement dans leurs portefeuilles, leurs portefeuilles de produits ou de projets. Et nous finissons par y trouver des problèmes majeurs. Donc, assez intéressamment, peu importe par où nous commençons, très fréquemment nous finissons par parler du niveau portefeuille. Et c'est de cela que cette session va traiter. Pour ceux qui ne me connaissent pas, je m'appelle Paweł Brudzinski. Et mon travail quotidien consiste à diriger une entreprise, Lunar Logic. Lunar Logic est une entreprise de développement web à Cracovie, en Pologne. Et c'est une entreprise de développement web très inhabituelle. Nous sommes un cas d'autogestion extrême. Il n'y a pas de managers dans l'entreprise.
En plus des projets web que nous développons, l'organisation interne elle-même est structurée d'une manière très, très différente. Donc si vous... vouliez avoir une idée de ce que c'est que de travailler avec une telle organisation, vous pouvez toujours nous engager. Nous sommes toujours à la recherche de nouveaux projets intéressants à réaliser pour nos clients. Je tiens également un blog, que vous pouvez trouver à bradzinski.com, où je couvre des sujets qui m'intéressent d'un point de vue professionnel. Vous y trouverez des sujets comme la gestion de portefeuille, vous trouverez des sujets comme la gestion du changement, qui est le thème de ma session de demain. Vous y trouverez beaucoup de choses sur le lean, le Kanban, mais aussi des sujets comme la conception des organisations, le leadership. Donc ce sont des thèmes que vous pouvez trouver sur le blog. Enfin, mon identifiant Twitter est Pavel Brudzinski. Je serais vraiment ravi de recevoir vos retours là-bas.
Alors, laissez-moi commencer par répondre à une question : pourquoi le portefeuille ? Typiquement, lorsque nous sommes à des événements Lean et Agile, nous discutons des équipes, comment améliorer nos équipes, comment améliorer nos équipes d'ingénierie, nos équipes de projet. Récemment, il y a quelques années, nous avons également commencé à parler de la mise à l'échelle de tout cela. Donc nous avons des équipes et nous voulons étendre cette approche. Ce sont des thèmes courants que j'entends lors des événements internationaux. En même temps, mon focus est beaucoup plus restreint. Je dis, regardons la gestion de portefeuille. Pourquoi donc ? Eh bien, si nous nous concentrons uniquement sur les équipes, même si nous choisissons une approche à grande échelle, nous finirions par améliorer l'efficacité de seulement certaines parties de l'organisation. Et comme Eli Goldratt l'a dit de manière célèbre, un système d'optimums locaux n'est pas du tout un système optimal. Donc, si nous améliorons nos équipes et que nous ne prêtons pas attention au travail qui est effectué, aux types de projets ou de produits que nous développons, nous pourrions finir par faire efficacement ce qui ne devrait pas être fait du tout.
C'est une sorte de gaspillage ultime, comme le formule Peter Drucker. Et Stephen Parry le formule un peu différemment. Il dit que livrer du gaspillage plus efficacement, c'est essentiellement du gaspillage moins cher, plus propre et plus rapide. Pas vraiment quelque chose que nous aimerions faire. Maintenant, je me demande pourquoi nous voyons autant de problèmes lorsque nous examinons les portefeuilles de différentes entreprises. Donc, pourquoi je finis par parler avec différentes organisations, je finis généralement par examiner leurs portefeuilles et y trouver des problèmes. Et une partie de la réponse est ce que Dan Kahneman a défini comme ce que vous voyez est tout ce qu'il y a. Donc notre cerveau fonctionne de telle manière que lorsque nous sommes sur le point de prendre une décision et que nous avons certaines données disponibles, nous utiliserions ces données et prendrions une décision. Même si nous pourrions facilement chercher un peu plus de données et améliorer significativement notre décision. Donc notre cerveau est quelque peu paresseux, si vous voulez. Et c'est ainsi que notre cerveau fonctionne en général. Et au fait, si vous n'avez pas lu le livre de Dan Kahneman, Penser vite, penser lentement, allez le lire.
C'est probablement le meilleur livre que vous puissiez lire si vous ne l'avez pas encore fait. Et surtout ce principe de ce que vous voyez est tout ce qu'il y a, et les outils que nous avons lorsque nous gérons un portefeuille, nous finissons par prendre de très nombreuses mauvaises décisions. Parce que quels types d'outils avons-nous lorsque nous examinons nos PMO ?
Eh bien, nous avons généralement quelque chose que j'appelle la frénésie d'Excel. Ces immenses feuilles de calcul remplies de chiffres. Et ne vous méprenez pas, je n'ai rien contre les feuilles de calcul. Je suis un pervers, j'adore les feuilles de calcul. Le problème, c'est que c'est le mauvais outil pour nous aider à gérer un portefeuille. Non seulement l'outil est mauvais, et nous y reviendrons dans quelques minutes, mais aussi le contenu de ces feuilles de calcul est trompeur. Parce que quel type de données avons-nous dans ces feuilles de calcul ? Imaginez simplement ce qui se passe lorsqu'un nouveau projet, lorsque vous voulez démarrer un nouveau projet dans votre organisation, ou que vous commencez à développer un nouveau projet, produit. Typiquement, la première chose que nous vérifions est que nous voulons avoir une idée du coût attendu. Donc nous irions voir nos équipes de développement et leur demander une estimation. Et je ne veux pas commencer une discussion sur la manière dont nous estimons, c'est une toute autre discussion, mais elles finiraient par fournir un nombre ou une fourchette de nombres.
Voici donc ce que nous prévoyons qu'il en coûtera pour construire cette chose. Maintenant, si nous parlons d'un projet, nous voulons probablement que ce projet soit rentable. Donc nous voulons avoir certaines hypothèses sur les revenus. Donc nous prendrions le nombre de nos développeurs, disons un million de dollars, et nous dirions, oh, donc nous voulons être rentables. Alors vendons-le pour, proposons-le à notre client pour 1,5 million. Et ce avec quoi nous finissons, c'est un projet très attrayant à mener. Je veux dire, en fin de compte, il est rentable. Je veux dire, c'est ce que nous attendons. Alors pourquoi ne pas commencer cela ? Il existe une autre version qui est plus populaire dans les organisations de développement de produits, qui est, oh, donc nous voulons construire ce produit ou cet ensemble de fonctionnalités pour notre produit. Donc encore une fois, nous allons voir nos équipes d'ingénierie, nous leur demandons, d'accord, combien cela nous coûterait-il de construire cela ? Et elles reviendraient avec un nombre à nouveau. Et ensuite, le côté bénéfice de l'équation serait, nous en avons besoin parce que nos concurrents l'ont. Donc encore une fois, d'une certaine manière, c'est un produit attrayant à construire. Je veux dire, nous ne discutons même pas de la partie bénéfice, mais nous disons, oui, nous devons le construire. Je veux dire, comme, nous devons l'avoir. Donc, il n'est pas étonnant que nous finissions avec des portefeuilles gonflés faisant beaucoup trop de choses. L'autre problème avec ce type de processus de prise de décision dans le contexte de la gestion de portefeuille est ce qui motive réellement nos décisions. Donc si vous repassez par ces exemples, vous finiriez par réaliser que nous parlons beaucoup Désolé. Nous parlons beaucoup des coûts.
Donc nous commençons par le coût.
En fait, dans l'histoire du projet, la partie bénéfice est dérivée du coût estimé. Et notez, ce n'est même pas un coût réel, car nous ne le saurons qu'après avoir terminé le projet. C'est une estimation du coût. Donc nous basons beaucoup de nos décisions sur l'estimation et nous savons en quelque sorte que nous ne sommes pas très bons en matière d'estimation. Et au fait, comme le souligne Johanna Rothman, si nous choisissons l'estimation comme moyen d'évaluer nos projets dans notre portefeuille, nous sommes littéralement condamnés à échouer.
Il y a une autre perspective à cela, offerte par Tom DeMarco et Tim Lister. Ils disent que nous sommes assez bons pour tenir les gens responsables de la partie coût de l'équation.
Mais nous ne sommes pas aussi rigoureux lorsqu'il s'agit de tenir les gens responsables de la partie bénéfice de l'équation. Donc nous commençons avec cette idée, oh, nous allons construire ce produit et il s'avérera super rentable. Et ensuite, nous parlons d'être dans les temps et dans le budget, tout le temps. Vous avez entendu ça, n'est-ce pas ? Et puis nous parlons d'être dans les temps et dans le budget, tout le temps. Vous avez déjà entendu ça, non ? Mais nous ne sommes pas du tout aussi rigides lorsqu'il s'agit de valider si les avantages promis ont été délivrés après tout. Et ceci, soit dit en passant, est le résultat de notre approche quant à la manière dont nous gérons notre portefeuille.
Voici Klaus Leopold, mon ami et collègue consultant Lean. Ainsi, Klaus travaille avec différentes organisations.
Et il travaille dans différents contextes avec ces organisations, très fréquemment en les aidant à travers le conseil d'administration, y compris ce qui se passe dans leurs portefeuilles. Donc, il y a une histoire de Klaus. Il commence à travailler avec l'un de ses nouveaux clients. Ils l'ont engagé. Pour les aider, vous savez, à livrer quelque chose, à les aider à améliorer le flux de travail. Et alors qu'ils discutent de leurs problèmes, ils regardent soudain le tableau et réalisent que dans cette organisation, 25 développeurs travaillent sur 113 projets simultanément.
À quel point cela est-il sensé ?
Je veux dire, aucune personne saine d'esprit sur la planète Terre ne penserait que cela puisse être une manière efficace de travailler.
Et je parie que les gars dans cette organisation ont commencé chacun de ces projets avec de bonnes intentions. Ils pensaient que c'était un projet attrayant à mener. En fin de compte, je ne pense pas qu'ils voulaient simplement rendre la vie de leurs ingénieurs plus misérable. Je ne pense pas cela. Ils pensaient que chacun de ces projets avait du sens. Donc, ils l'ont commencé. Et cela signifie qu'il y a presque cinq projets par personne dans l'organisation.
Et il y a une histoire intéressante pour étayer cela. Il y a quelques années, j'ai participé au Kanban Leadership Retreat, et la gestion de portefeuille était un thème récurrent. Alors j'ai commencé à poser des questions à différentes personnes comme, chaque fois que le sujet surgissait, je demandais : combien d'ingénieurs avez-vous dans votre organisation ? Les gens répondaient 100. Et combien de projets en cours avez-vous ? Et ils répondaient 200. Donc, ce que j'ai réalisé, c'est que ce ratio, le nombre de projets par rapport au nombre d'ingénieurs, était compris entre un et six. Et notez que ce n'étaient pas simplement des personnes aléatoires des bureaux de gestion de projet. C'étaient des consultants Lean supposés être à la pointe. Et leurs clients. Donc la situation est vraiment, vraiment triste. Nous sommes surchargés par le nombre de choses que nous essayons de mener de front. Et ceci était aussi mon histoire personnelle. Il y a plusieurs années, j'étais avec une organisation, je dirigeais une équipe de 150 ingénieurs, et j'avais ce pressentiment que nous essayions de faire trop de choses en même temps. Alors j'ai pensé que puisque Kanban fonctionnait si bien pour moi dans le contexte des équipes, il pourrait donner des résultats similaires dans le contexte du portefeuille. C'est ainsi que mon histoire avec le Kanban de portefeuille a commencé. Donc, pour cadrer ce que j'appelle Kanban de portefeuille, j'utilise généralement la méthode Kanban telle que définie par David Anderson comme point de référence. Voici donc les six pratiques de base et les quatre principes de la méthode Kanban. Et je serais ravi d'avoir une longue discussion sur la manière dont vous appliqueriez toutes ces pratiques dans le contexte de la gestion de portefeuille. Mais la partie importante est la suivante.
La partie importante est qu'il y a deux principes qui en disent long sur la mentalité. Commencez avec ce que vous avez. Ne réinventez pas votre portefeuille. Vous ne pouvez pas, d'ailleurs, parce que tous les engagements en cours acceptent simplement d'évoluer à partir des situations épouvantables dans lesquelles vous vous trouvez actuellement. Et il y a deux pratiques de base qui sont essentielles pour un changement. Donc, la visualisation, je dis souvent que la gestion visuelle en tant que pratique distincte est cet outil qui nous permet de récolter les fruits faciles à atteindre. Et cela est vrai dans ce cas également. Et enfin, limiter le travail en cours, ce qui alimente le mécanisme d'évolution de Kanban. Alors laissez-moi commencer par la visualisation. Quand j'ai commencé avec le Kanban de portefeuille, j'ai évidemment commencé par la visualisation basée sur ce que nous verrions dans les équipes. Donc, une sorte de tableau basé sur le flux. Donc, au lieu d'éléments de travail comme des fonctionnalités, des user stories, peu importe, ici nous avons des projets ou des produits ou des MVP ou des ensembles de fonctionnalités, peu importe. Le problème avec cette approche était que j'ai effectivement trouvé qu'il y avait très peu de sens de flux. Parce que soudain, un élément de travail, une carte sur ce tableau, n'est pas quelque chose que nous terminons en quelques heures ou jours. C'est quelque chose qui prend des mois ou des trimestres, voire des années à terminer. Portfolio Kanban, j'ai évidemment commencé par la visualisation qui est basée sur ce que nous verrions dans les équipes. Donc une sorte de tableau basé sur le flux. Donc au lieu d'éléments de travail comme des fonctionnalités, des user stories, ou autres, ici nous avons des projets ou des produits ou des MVP ou des ensembles de fonctionnalités, ou autres. Le problème avec cette approche était que j'ai effectivement constaté qu'il y avait très peu de sens du flux.
Parce que soudain, un élément de travail, une carte sur ce tableau, n'est pas quelque chose que nous terminons en quelques heures ou jours. C'est quelque chose qui prend des mois ou des trimestres, voire des années à terminer.
Donc il y a peu de sens du flux, nous ne voyons pas de changement sur le tableau, alors soudain nous cessons de prêter attention au tableau, nous cessons de le mettre à jour, et à ce moment-là, il devient inutile. Ce n'est pas la meilleure conception que j'ai vue, mais c'était comme la première expérience que j'ai menée.
Mais ma frustration a atteint son paroxysme lorsque j'essayais de me défendre, moi et mon équipe, contre le démarrage d'un nouveau produit, et je n'arrivais pas à trouver un moyen sur ce tableau de justifier un refus.
Alors, dans ma frustration, j'ai décidé de jeter toutes les notes autocollantes, d'effacer le tableau, et de recommencer à zéro. Et voici ce à quoi j'ai abouti, ce qui est une conception de tableau très différente. Ici, vous voyez deux dimensions. La dimension verticale représente les capacités, dans ce cas, les équipes. La dimension horizontale est le calendrier. Et ce qui est au milieu, ce sont tous les engagements. Et ce qui est important dans le contexte de la gestion de portefeuille, c'est que les engagements se produisent au fil du temps et qu'ils changent au fil du temps. Donc nous avons des projets ou des produits que nous menons puis nous arrêtons de les développer. Et tout l'espace blanc sur ce tableau représente les capacités disponibles qui nous donnent des informations sur ce que, en plus de ce que nous avons déjà dans notre portefeuille, nous pouvons commencer d'autre. Et puis il y a le côté gauche du tableau où nous avons toutes les choses potentielles sur lesquelles nous pouvons travailler. Dans ce cas, ceci est... Une des premières versions est très simple, mais la partie en amont peut aussi être très sophistiquée et comporter plusieurs étapes. J'ai validé cette approche avec quelques entreprises et j'ai pensé, oh, nous pourrions avoir quelque chose comme une visualisation standard du portefeuille.
Sauf que, peu de temps après, j'ai commencé à voir des conceptions de tableaux comme celui-ci. Par exemple, voici une organisation où les délais sont vraiment importants. Les délais sont vraiment importants. Ou comme le dirait Lee Skiog, des lignes tristes. Parce que, vous savez, Personne ne va mourir si on rate la date. Ce n'est que quelqu'un qui va être triste. Donc voici une organisation dirigée par des lignes tristes, et ils veulent vraiment prêter attention. Ils ont donc conçu leur tableau pour voir littéralement s'ils sont à la date prévue ou en retard. Ici, les colonnes représentent des semaines, donc encore une fois le calendrier, et les projets sont placés dans une partie spécifique du tableau pour représenter la date limite.
Et nous avons une sorte de fenêtre mobile du présent. Donc tout ce qui est à gauche du présent est déjà passé la date limite. Tout ce qui est à droite du présent est dû dans les prochaines semaines. Donc c'est très différent... En voici un autre, c'est un tableau de portefeuille à deux niveaux, assez populaire dans les organisations de développement de produits, où elles contrôlent la taille des morceaux de travail sur lesquels elles travaillent. Donc chacune des grandes notes autocollantes est essentiellement un ensemble de fonctionnalités ou une épopée ou un MVP, et ensuite elle atterrit dans une voie, et chaque voie est essentiellement un tableau en soi, où le flux se produit dans les voies. Donc c'est une autre approche. Et enfin, l'un de mes préférés, voici un tableau d'une organisation où la visualisation du flux était très importante. Le problème était que le flux était non homogène. En d'autres termes, pour chaque projet, ils avaient un flux de travail différent. Donc ils ne pouvaient pas concevoir un tableau unique basé sur le flux autre que à faire, en cours, terminé.
Ils ont donc décidé d'opter pour quelque chose de très différent. Donc le flux est décrit par ces décorateurs, ces petites notes autocollantes attachées aux grandes fiches.
Et elles montrent non seulement que le flux est différent pour chaque projet, mais aussi le statut des étapes spécifiques. La leçon à tirer de cela est qu'il n'existe pas de conception universelle de tableau Kanban pour le portefeuille. En fait, selon l'organisation, cela aboutirait à des conceptions différentes. Et pourquoi la visualisation est-elle si importante alors ? Alors laissez-moi faire une petite expérience avec vous. Voici le portefeuille d'une petite entreprise. Il y a sept projets menés par cette entreprise, dont trois sont de nouveaux projets, quatre sont des projets de maintenance où il y a un travail continu, et il y a un produit géré par cette entreprise.
Et vous avez quelques chiffres. Vous avez le coût estimé de la construction du produit, vous avez le revenu attendu, vous avez le profit estimé, vous avez même la rentabilité, et c'est encore mieux parce que vous avez aussi des informations sur l'achèvement des personnes. Donc quelle grande partie du projet est déjà terminée. Nous sommes le 1er janvier, nous avons aussi des délais, tout ce que vous devez savoir sur le portefeuille de cette petite entreprise. Et vous avez un nouveau projet potentiel. Coût estimé, vous êtes allé demander aux développeurs et ils ont estimé le temps, vous l'avez multiplié par le coût et le coût estimé du projet est de 400 000 euros. Ce qui est un projet assez régulier et important pour une organisation Zet, n'est-ce pas ? Nous avons au moins deux projets de cette taille. Le profit attendu est plutôt bon, 250 000. Meilleur que tout ce que nous avons sur le tableau. Il y a un risque majeur, il y a un délai serré. Nous n'avons que trois mois pour réaliser ce projet. La question est, devrais-je... l'organisation accepter ce projet.
Est-ce que cela semble attrayant ?
Bon sang, oui.
Rien de comparablement attrayant dans le portefeuille existant.
Grâce à ce que vous voyez est tout ce qu'il y a, si vous regardez quelque chose comme ça, j'aimerais dire, essayons cela. Essayons totalement cela. Il y a de l'argent facile sur la table. Alors maintenant, laissez-moi présenter exactement les mêmes données d'une manière légèrement différente. C'est exactement le même portefeuille visualisé dans ce en utilisant ce modèle où nous présentons les capacités disponibles et nous essayons d'équilibrer les capacités disponibles par rapport à la demande.
Donc maintenant, nous voyons que nous pouvons à peine caser quoi que ce soit dans les trois prochains mois. Donc accepter ce projet se terminerait probablement par un énorme raté dans ce nouveau projet, ou une série de ratés dans les engagements existants, ou très probablement les deux.
Et notez, cela ne se termine pas, lorsque vous vous retrouvez dans une situation où il y a des ratés majeurs parce que vous vous êtes engagé à trop de choses, ce n'est pas seulement que le travail
glisse dans le temps, mais aussi que se remettre de ces ratés prend du temps supplémentaire. De la même manière qu'un embouteillage se produit, il ne suffit pas d'enlever l'obstacle qui ralentit la circulation. Il faut du temps pour revenir à la vitesse normale de conduite.
C'est exactement pourquoi la visualisation est si importante et pourquoi elle nous permet de mieux comprendre le travail que nous faisons. Maintenant, j'ai déjà mentionné qu'il existe des approches très différentes de la visualisation. Donc maintenant, je peux vous donner quelques conseils sur la façon de choisir celle qui conviendrait à un contexte donné. Et le conseil que je peux partager est de penser à l'évaluation des risques. Donc lorsque nous réfléchissons à l'évaluation des risques dans le contexte du portefeuille, à la gestion de projets ou à la gestion de produits, nous pensons généralement à l'évaluation dans le contexte individuel de ce projet spécifique, de ce produit spécifique. Nous disons, oh, ici il y a un lien avec l'équipe, ici il y a un lien avec la technologie, ici il y a un lien avec le financement.
Maintenant, lorsque je parle de concevoir un tableau de portefeuille, je pense davantage aux dimensions de risque qui sont pertinentes non pas pour un seul projet, mais pour tous les projets du portefeuille. Donc je pense, oh, nous avons tendance à trop nous engager. Donc nous devons nous concentrer sur la manière dont nous équilibrons la demande par rapport aux capacités. Ou nous ratons les délais. Nous devrions nous concentrer sur la ponctualité. De nos projets. Oh, nous avons des difficultés à gérer les dépendances entre nos initiatives, nous devrions nous concentrer sur cela. Donc ce sont des dimensions de risque intéressantes. Et plus tôt cette année, lors du Kanban Leadership Retreat, j'ai animé un long atelier sur le Portfolio Kanban, et une des choses que nous avons faites pendant l'atelier était de discuter des différentes dimensions de risque auxquelles nous sommes confrontés dans nos organisations. Et un gagnant clair, sans surprise pour moi, un gagnant clair était la gestion des capacités par rapport à la demande. Et le résultat, c'est que si nous échouons à cela, nous nous engageons trop et nous finissons par voir ces portefeuilles de projets gonflés et surchargés. Un second était la gestion des dépendances. Entre les projets, puis nous avons eu la gestion de différents types de travail. Donc du travail planifié par rapport au travail non planifié. Pensez aux classes de service dans le contexte de la gestion de portefeuille. Il y en avait d'autres. Ceci est essentiellement le résultat de la session. Il y avait quelques conceptions vraiment folles de tableaux Kanban, des conceptions de tableaux de portefeuille. Donc, il y a quelques exemples. Et dans ces exemples, nous nous concentrons consciemment sur des dimensions de risque moins populaires. Il est donc possible de définir, de concevoir différents tableaux pour se concentrer sur une dimension de risque spécifique qui est la plus importante ou la plus douloureuse pour nous. Et c'est exactement le modèle de tableau de portefeuille que nous devrions examiner.
Quelle que soit la dimension de risque la plus douloureuse ou la plus importante pour nous, elle devrait être visualisée comme la structure du tableau.
Et nous ne devrions pas nous concentrer sur plus d'un seul contexte. Donc, si nous essayons de mettre trop de choses dans la conception du tableau, nous finirons par obtenir une visualisation incompréhensible. Et si c'est incompréhensible, cela va être inutile parce que nous ne l'utiliserons pas pour obtenir les informations dont nous avons besoin lorsque nous prenons des décisions. Rappelez-vous, Ce que vous voyez est tout ce qu'il y a. Si vous regardez le tableau et que vous ne comprenez pas ce qui s'y trouve, vous cessez d'utiliser les informations présentes sur ce tableau. Et un contexte s'applique également à une autre chose, à savoir que nous devrions nous concentrer sur une seule granularité de travail. Donc, si vous pensez à de grandes organisations où le portefeuille peut être organisé en différentes couches de travail, pensez que vous avez des ensembles de fonctionnalités, les ensembles de fonctionnalités sont organisés en projets, les projets sont organisés en programmes, les programmes sont organisés en lignes de produits. Vous avez différentes couches de travail. Si vous travaillez dans un tel contexte, vous devriez vous concentrer sur une seule couche de travail sur un seul tableau. Donc, n'essayez pas d'y mettre trop de choses à la fois. Si vous traitez différentes couches de travail, ajoutez simplement un tableau supplémentaire. Ce qui, soit dit en passant, peut signifier que lorsque vous regardez un tableau de programme, donc une sorte de tableau avec des programmes, vous pouvez finir par réaliser qu'une dimension de risque différente serait plus pertinente dans ce contexte, que la dimension de risque serait pertinente dans le contexte d'un projet au sein d'un seul programme. Vous pouvez donc finir par concevoir différents tableaux pour différentes couches de travail.
Et que faire des autres dimensions de risque que nous avons ? Je veux dire, en fin de compte, nous ne voulons pas nous concentrer uniquement sur l'équilibrage de la demande par rapport aux capacités. Et simplement nous moquer des délais, n'est-ce pas ?
Nous voulons obtenir ceci et cela. Donc, pour d'autres dimensions de risque, nous pouvons utiliser des fiches. Il y a beaucoup de choses que nous pouvons coder en utilisant des décorateurs, en utilisant des données supplémentaires sur les fiches, etc., etc., etc. Donc, mettez sur la visualisation tout ce qui est important pour le processus de prise de décision, mais du point de vue de la conception du tableau, concentrez-vous sur la dimension de risque la plus douloureuse à laquelle vous êtes confronté. Donc, la visualisation est cette pratique qui nous permet de récolter ces fruits à portée de main, qui nous aide à comprendre où nous en sommes, quels types de problèmes nous rencontrons, et possiblement nous donne un indice sur l'endroit où nous échouons principalement. Maintenant, il y a aussi la limitation du travail en cours. qui est ce mécanisme qui nous aide à améliorer. Le problème avec la limitation du travail en cours, outre le fait que de nombreuses équipes résistent à limiter le travail en cours dans un contexte donné, est qu'au niveau du portefeuille, nous traitons une énorme variabilité de taille. Mon expérience courante est que la plus petite initiative menée par une organisation sera 200 fois plus petite que la plus grande. Cela n'est en aucun cas une recherche appropriée. C'est juste un thème commun que je vois. Donc, pensez à une organisation de développement de projets, le plus petit projet qu'ils mènent, une paire de développeurs qui travaillent pendant quelques semaines. Ils appelleraient cela un projet. Le plus grand projet qu'ils ont dans leur portefeuille serait 15 personnes travaillant pendant deux ans. Nous parlons d'une énorme variabilité de taille. Maintenant, si nous essayons d'appliquer cette sorte de méthode naïve de limitation du travail en cours, en disant que nous ne voulons pas avoir plus de huit projets en cours, nous ne voulons pas avoir plus de quatre MVP en cours, nous finirions par échanger l'une de ces grandes initiatives contre une des petites. Cela n'a pas de sens. Parce qu'une fois que nous avons terminé ce grand projet qui a nécessité l'attention de 15 ou 20 personnes, nous pouvons en mener plusieurs petits.
Et une fois que nous avons terminé le petit, nous ne pouvons pas vraiment commencer le grand, n'est-ce pas ? Donc, à cause de cela, il ne fait vraiment pas sens d'utiliser ce genre de limite stricte de travail en cours en tant que nombre.
Comment pouvons-nous alors aborder la limitation du travail en cours ? Eh bien, il existe cette belle technique appelée Limites de Fouet par la Conversation. C'est comme super léger, très simple.
Il faut un peu de temps pour vraiment se familiariser avec cela et en tirer plus de valeur. Mais c'est vraiment facile de commencer à expérimenter avec cela. Donc, la technique est très, très simple. Chaque fois que vous êtes sur le point de commencer quelque chose, chaque fois que vous êtes sur le point de vous engager, à travailler sur un nouveau projet, à travailler sur un nouveau produit, vous commencez une conversation, vous commencez à poser des questions. Quelles capacités avons-nous besoin d'avoir pour construire cela ?
D'ailleurs, au moment où vous répondez à ces deux questions,
la plupart du temps la réponse sera : oh, nous ne pouvons pas commencer cela. Et vous avez terminé. Mais si par hasard vous répondez que, eh bien, nous avons besoin de telles et telles capacités, et que nous les avons disponibles, vous allez plus loin. Alors, comment le démarrage de ce nouveau projet affecterait-il tous les autres engagements que nous avons déjà dans notre portefeuille ? Ici, nous parlons de dépendances.
Et ensuite, vous commencez à discuter, d'accord, donc nous pouvons démarrer toutes sortes de choses, pas seulement cette chose-là, laquelle de ces choses devrions-nous commencer ?
Et parfois, vous vous retrouverez dans une situation où la réponse sera : oh, nous n'avons pas les capacités disponibles pour démarrer cette nouvelle initiative. Mais alors, ce ne sera pas à vous de prendre la décision. Ce sera comme : oh, c'est le plus grand projet de l'histoire de l'entreprise, et c'est notre meilleur client de tous les temps, et il n'y a aucun moyen de dire non. Et alors, la conversation que vous avez porte sur ce que nous pouvons faire. Donc, si nous lançons ce projet, quelque chose doit être abandonné.
quels engagements nous voulons honorer.
Et encore une fois, c'est une façon de prioriser. Quels sont nos engagements en cours qui sont les plus précieux pour une organisation et lesquels le sont moins pour notre organisation. Donc, tout se résume vraiment à la priorisation, à prioriser certains projets par rapport à d'autres, certains produits par rapport à d'autres.
Donc, quand nous en sommes à la priorisation, il y a un monsieur que vous devez rencontrer.
Qui est familier avec les travaux de Don Reinertsen ?
Vous, monsieur, ne connaissez rien des travaux de Don Reinertsen. J'avais l'habitude de dire qu'il y a deux types de personnes dans le monde. Ceux qui sont familiers avec les travaux de Don Reinertsen et ceux qui devraient l'être.
L'une des choses que Don a introduites dans le monde est le coût du retard, qui est un excellent mécanisme pour nous aider à déterminer comment prioriser les choses.
Donc maintenant, je suis stressé parce que si je fais une erreur,
je veux dire, quelqu'un appellerait cela une erreur. Donc, ce sont des profils d'urgence pour différents produits. Donc, ce que vous voyez ici, ce sont des graphiques. La ligne verticale représente les bénéfices au fil du temps. La ligne horizontale représente le temps. La ligne rouge est ce que nous nous attendons à obtenir en livrant un produit. La ligne bleue est ce que nous nous attendons à ce qu'il se passe lorsque nous livrons en retard. Donc à gauche, et la partie orange représente essentiellement une différence de bénéfices. Donc, si nous livrons en retard, nous obtenons essentiellement moins de bénéfices. Donc à gauche, le graphique de gauche est pour un produit qui a un cycle de vie court. Donc, si nous livrons en retard, le pic est affecté, il est plus bas, et le déclin est plus rapide, ce qui est assez évident. Le marché commence à décliner, décliner, et donc les ventes de notre produit déclinent également. Donc, nous gagnons essentiellement moins d'argent. Les graphiques de droite concernent les produits avec un long cycle de vie. Le premier est celui où être en retard sur le marché n'affecte pas le pic. Pensez à Google Search. Je veux dire, ils ont encore gagné leur part de marché malgré le fait qu'ils n'étaient pas en avance. Le graphique du bas est pour le produit où être en retard affecte le pic. Pensez à Windows Mobile.
Je veux dire, le jeu était terminé avant même que Microsoft sache qu'il y avait un jeu.
Mais de toute façon, le fait est que lorsque nous essayons d'évaluer la valeur économique de nos décisions, nous devrions regarder à quel point la zone orange est grande. Plus elle est grande, plus nous perdons de bénéfices potentiels. Et d'ailleurs, le coût du retard est une sorte de tour astucieux que Don a joué aux gens parce que ce n'est pas vraiment un coût, c'est une question de valeur. Cela s'appelle le coût du retard. Donc dans ce cas, c'est comme une sorte de valeur perdue.
Mais la raison est que si nous voulons déterminer quelle initiative, quel produit est le plus précieux, nous pouvons faire cette évaluation et essayer de déterminer dans quel cas la zone orange serait la plus grande. Il y a une prise de conscience intéressante lorsque vous travaillez dans un projet. organisation ouverte, c'est que vous verriez des courbes de coût de retard comme celles-ci.
Le fait est que si vous n'avez pas les capacités pour commencer à travailler sur un projet, vos clients attendront très rarement. Ils diront : d'accord, vous ne pouvez pas commencer ce projet, alors nous choisirons un autre fournisseur. Donc, vous pouvez réaliser qu'il y a un coût de retard à être en retard. C'est ne pas faire du tout un projet. Mais la règle générale reste la même.
Plus la zone orange est grande, plus nous perdons de bénéfices. Donc, vous pouvez utiliser cette technique pour prioriser les choses que vous avez dans le backlog. Il y a une autre figure qui est vraiment importante pour la communauté Lean Kanban et c'est Stephen Bungay. Et en plus de tout ce qu'il nous apprend sur le leadership, il y a une contribution à la communauté Lean Kanban qui s'appelle la question des Puits d'Épices. Qui est : dis-moi ce que tu veux, ce que tu veux vraiment, vraiment.
Et c'est une façon de formuler une question, quel est l'objectif stratégique de l'organisation ? Quel est l'objectif numéro un que nous essayons d'atteindre ici ? Pourquoi répondre à cette question est-il important ? Parce que nous pouvons consciemment décider que nous voulons mener des initiatives qui sont alignées avec la réalisation de notre objectif stratégique, même si économiquement il y a d'autres types d'initiatives non liées qui pourraient potentiellement rapporter un plus grand résultat financier. Donc, comprendre ces deux aspects, premièrement, l'équation économique, et deuxièmement, quels sont les objectifs stratégiques et quel est l'alignement des initiatives spécifiques avec les objectifs stratégiques dans une organisation peut nous aider à prioriser les choses. Et ensuite, nous pouvons choisir judicieusement sur quoi nous travaillons et sur quoi nous ne travaillons pas. Maintenant, dans la plupart des organisations que je connais,
même si nous faisions bien la priorisation, nous finirions avec beaucoup trop de choses sur lesquelles travailler.
Il existe donc une technique intéressante qui peut nous aider à y voir plus clair.
Il s'agit de la planification de la capacité, quelque chose qui est proposé par Chris Matz.
Et je pense que ce n'est pas encore le nom définitif. C'est une sorte de titre de travail, donc il pourrait changer. Et c'est essentiellement une approche pour planifier le travail une fois que nous avons priorisé le travail. Donc, une fois que nous avons fait notre devoir et que nous savons quels produits ou MVP ou ensembles de fonctionnalités sont plus importants que d'autres, quels projets sont plus importants que d'autres, la planification de la capacité peut nous aider à déterminer combien nous pouvons gérer. Nous commençons donc par la liste priorisée de nos initiatives. Ensuite, nous faisons une estimation très approximative, quelque chose que Chris Matz appelle une estimation SWAG.
SWAG vient de 'Sweet Wild Ass Guess' (une supposition très approximative). Et c'est volontairement très approximatif. Donc, essentiellement, Chris Matz a demandé, donc l'exercice que les propriétaires de produits ou les gestionnaires de produits doivent faire est de déterminer quelles équipes travailleront à la construction de ces initiatives.
Une fois qu'ils savent quelles équipes travailleront sur ces initiatives, ils doivent aller voir ces équipes et déterminer combien de semaines, en semaines d'équipe, ils pensent qu'il leur faudra pour construire cela. Et ils mettent cela sur une liste. Donc ici, nous avons toutes ces estimations SWAG approximatives des équipes. Donc initiative alpha, équipe D, deux semaines, équipe G, trois semaines. Initiative Bravo, équipe B, deux semaines, équipe D, deux semaines, équipe E, quatre semaines, etc.
D'ailleurs, Chris Matz a rapporté que lorsqu'ils ont fait cela pour la première fois chez Skype, et qu'ils ont alloué tout le temps du trimestre parce qu'ils planifiaient trimestriellement, ils n'ont rien livré. Donc le trimestre suivant, ils ont réduit de moitié le temps disponible. Donc pour un trimestre, ils ne planifient que... six semaines.
Donc, une fois qu'ils ont ces estimations, ils commencent à planifier selon un rythme de planification, quel qu'il soit. Chez Skype, c'était un trimestre, quel que soit le rythme dans votre organisation, ce serait ici. Et ils commencent à planifier de cette manière. Donc, la première initiative était alpha et nous avons eu nos invités Swilled by us. estimations, deux semaines et trois semaines. Donc, nous avons mis cela dans un plan. Ensuite, nous passons au suivant, puis au suivant, et soudain, surprise, c'est toujours plus rapide que prévu, nous nous retrouvons dans cette situation. Donc, le prochain projet de la liste ne rentre pas.
Que se passe-t-il alors ?
Nous ne commençons pas du tout celui-là. Nous ne construisons pas des ensembles de fonctionnalités partiels. Il retourne ici. Nous pouvons alors parcourir le backlog et essayer de trouver quelque chose qui s'adapterait à l'espace blanc, qui correspondrait aux capacités disponibles. Le fait est que, la manière dont la plupart des organisations sont structurées est qu'il y a quelques équipes qui tendent à être les équipes centrales. Elles tendent à être impliquées dans presque tout.
Donc, il y a très, très peu de choses que nous pourrons intégrer dans notre tableau de planification des capacités et plus encore. Alors, laissez-moi trier ces équipes par utilisation pour vous. C'est facile. si vous avez cela préparé dans votre présentation, un clic.
Nous avons donc une situation très courante. Encore une fois, Chris Matz rapporte qu'environ 20 % des équipes seront pleinement utilisées après cet exercice. Environ 20 % des équipes ne seraient pas utilisées du tout.
Et les 60 % restants passeraient essentiellement de manière linéaire d'une utilisation à 100 % à une utilisation à 0 %.
Cet exercice consistait essentiellement à commencer par définir le but, puis à déterminer, dans le cadre de ce but, quels sont les projets ou produits les plus pertinents ou qui donnent les meilleurs résultats, et ensuite à planifier en fonction des capacités disponibles.
Nous nous sommes retrouvés avec beaucoup d'espace blanc, beaucoup de marge. Que ferions-nous de cette marge ? Eh bien, la marge nous offre des options. Donc, une chose que nous pouvons faire est de chercher des moyens d'utiliser ces équipes pour aider les autres équipes à travailler vers les objectifs stratégiques. L'autre chose que nous pouvons faire est de chercher les lacunes. Pourquoi nous retrouvons-nous avec des équipes qui sont presque inutilisées ? Quelles capacités leur manquent ? Quelles capacités devrions-nous développer ? De plus, nous pouvons utiliser cette marge comme Un moyen de...
Saisir les opportunités qui se présentent. Je veux dire, nous sommes à un niveau préférentiel, nous ne planifions pas pour la semaine prochaine. Nous planifions pour le prochain trimestre ou le prochain semestre, voire plus longtemps. Il y aura des opportunités en chemin.
Dans tous les cas, nous pouvons utiliser ces options pour introduire des améliorations continues, nous pouvons utiliser ces options pour faire beaucoup de choses différentes. Le fait est que la plupart du temps, si nous décidions d'utiliser ces capacités disponibles pour construire des ensembles de fonctionnalités partiels, des produits partiels, des projets partiels, nous finirions par abandonner ce travail de toute façon, parce que dans un trimestre à partir de maintenant, dans six mois, les priorités auront changé. Nous serions dans une situation différente. Donc, la discussion sur les limites de travail en cours, et soit dit en passant, la partie importante est que nous venons d'utiliser la planification des capacités comme un moyen de limiter le travail en cours également.
Nous avons simplement décidé de ne pas commencer certaines de nos initiatives prioritaires. Ainsi, la discussion sur les limites de travail en cours dans le contexte de la gestion de portefeuille est un moyen de transformer la discussion, passant du coût, du coût estimé et des revenus attendus vers des aspects beaucoup plus importants comme les bénéfices, les risques, l'évaluation des risques et les options que nous avons.
Et c'est ainsi, et cela se produit en disant non. Parce que, comme le Kanban de portefeuille ne consiste pas, essentiellement, à choisir le travail que nous faisons, mais à choisir le travail que nous ne faisons pas. Et d'ailleurs, nous le faisons une décision à la fois.
Nous ne disons pas, réinventons la manière dont nous gérons le portefeuille. C'est simplement dire, oh, nous ne pouvons pas gérer cette chose maintenant.
Et avec cela, merci beaucoup.