Klaus Leopold

Alors bonjour à tous.
Bonjour.
Comment allez-vous ? Bien. Bien. Alors, je m'appelle Klaus et j'ai un accent très allemand, mais je ne le suis pas. Je viens d'Autriche et si vous parlez à un Autrichien, ça fait une différence, vous savez ? Ça en fait vraiment une. Oui. Et aujourd'hui, je veux parler de l'agilité métier lean. Quel titre, n'est-ce pas ? Tout y est. Nous parlons de lean. Business et agilité, ce sont tous les mots à la mode qu'il faut connaître aujourd'hui. Vous pouvez même les combiner. Nous parlons d'agilité métier, nous parlons de business lean, et nous parlons de lean et d'agile. Donc rien ne peut mal tourner ici, d'accord ? Peut-être devons-nous ajouter l'IoT. Mais alors, c'est complet, non ? 4.0. Oui. Alors, mais qu'est-ce que cela signifie ? En fait, j'ai réfléchi à ce titre. Le but est que je veux juste vous raconter une histoire. Une histoire sur une entreprise, et cette entreprise voulait améliorer son délai de mise sur le marché. D'accord ? Si je... Mets ceci, alors celui-là fonctionne. Regardez ça.
Donc je veux parler de l'entreprise, et cette entreprise voulait améliorer le délai de mise sur le marché pour le projet. pour le projet. Je pense que tout le monde connaît ce désir, n'est-ce pas ? Nous sommes beaucoup trop lents, nous ne pouvons pas réagir aux clients à temps, et en fin de compte, nous devons être plus rapides dans la livraison de nos projets. D'accord, bien. Et leur solution était bien sûr, adoptons l'agilité. Avec l'agilité, le délai de mise sur le marché, pas de problème, n'est-ce pas ? Donc ils étaient comme, oui, nous avons 600 personnes ici. Alors faisons une de ces transitions agiles pour toutes ces 600 personnes. Et ils se disaient, d'accord, comment faisons-nous cela ? Ils y ont réfléchi et puis ils ont dit, d'accord, qu'est-ce qui est important quand il s'agit de devenir agile ? Bien sûr, une chose est que nous devons avoir des équipes pluridisciplinaires. Vous en avez entendu parler ? La pluridisciplinarité ? Oui, bien sûr. Beaucoup de hochements de tête. Donc, oui, nous devons avoir toutes les connaissances à bord pour pouvoir livrer rapidement sans dépendances. Ensuite, ils se disaient, d'accord, nous devons organiser nos équipes par produit. Cela signifie qu'une équipe travaille sur un produit et non sur plusieurs produits. Encore une fois, c'est une bonne chose à faire parce que vous éliminez les dépendances. Ensuite, ils se disaient, d'accord, nous ne voulons pas être trop dogmatiques. Trop dogmatiques. Donc les équipes, elles peuvent choisir leur méthode agile préférée. Peu importe si elles font du Scrum ou du Kanban, peu importe. Il y a juste quelques exigences minimales que ces équipes doivent respecter. Et les exigences minimales sont qu'elles doivent avoir une visualisation. Donc l'idée de la direction était que vous allez voir une équipe, vous voyez quelque part un mur où toutes les tâches sur lesquelles l'équipe travaille sont affichées. Nous voyons tous les problèmes et nous voyons simplement ce qui se passe au sein de cette équipe. Donc elles doivent avoir une visualisation. Quoi d'autre ? Elles doivent faire une réunion quotidienne debout. Donc chaque équipe doit avoir une sorte de coordination quotidienne devant le tableau. Et la troisième chose était qu'elles doivent avoir une boucle d'amélioration, des rétrospectives. Je pense que tout le monde connaît les rétrospectives dans cette salle, n'est-ce pas ? Donc l'idée est que nous arrêtons de travailler et réfléchissons à, d'accord, que pouvons-nous réellement améliorer ? Donc, c'est en fait l'aperçu de cette transition agile. Et si vous êtes l'un de ces évangélistes agiles, je suis sûr que vous pensez quelque chose comme, c'est génial ! Vous savez, ils font tout correctement. Donc ils investissent vraiment beaucoup d'argent. Je veux dire, nous parlons de 600 personnes ici. La pluridisciplinarité, toute cette réorganisation, ils le font, n'est-ce pas ? Et ils ne sont pas trop dogmatiques. Donc qu'est-ce qui peut mal tourner ici ? Très bien. C'était le plan initial de cette entreprise. Et puis ils ont commencé cette transition. Ils ont commencé par une formation agile de base. Donc, vous savez, l'agilité, c'est beaucoup une question de mentalité. Vous en avez entendu parler, n'est-ce pas ? C'est une question de mentalité. Donc cette entreprise se disait, d'accord, faisons une formation d'une journée sur la mentalité agile. Donc toutes ces 600 personnes ont suivi une formation d'une journée sur la mentalité agile et la case mentalité était cochée. La mentalité agile était établie, en quelque sorte.
Ou peut-être, oui. Mais c'était la première case. D'accord, donc une compréhension de base de l'Agile, c'est bien. Ensuite, ils se disaient, d'accord, faisons cette réorganisation. Donc ils ont redistribué les personnes et oui, ils ont structuré toute l'organisation en équipes produit, pluridisciplinarité, et ainsi de suite. Ensuite, ils n'étaient pas trop dogmatiques. Donc les gens pouvaient choisir d'utiliser Scrum ou Kanban ou autre chose. Et puis, bien sûr, ces équipes ont reçu plus de formation. Pour les équipes Scrum, ils ont fait cette formation Scrum Master et product owner. Pour les équipes Kanban, ils ont mis en place la conception de système. Donc ils ont organisé des ateliers de conception de système de deux jours. Et oui, donc c'est beaucoup à faire si on regarde cela. Donc en fin de compte, nous parlons de 600 personnes. Oui, c'est un peu d'argent. Peut-être devez-vous investir. Donc la phase initiale a été soutenue par 16 coachs externes.
Bien sûr, pas comme ça, 16 puis zéro, mais il y avait une phase de montée en puissance et une phase de réduction. Mais au pic, Il y avait 16 coachs externes. Et si vous jetez un œil à ce programme, ils en ont besoin. Je veux dire, ils ont besoin de former toutes ces personnes. Ensuite, ils doivent faciliter les réunions quotidiennes de stand-up, les rétrospectives au début. Donc, un investissement assez énorme. Ensuite... Ils ont également développé des connaissances internes, 11 coachs agiles internes, ce qui est en fait une bonne chose à faire, n'est-ce pas ? Parce que nous voulons conserver les connaissances dans l'entreprise. Vous avez probablement de l'expérience à ce sujet, donc quand les consultants externes partent, alors le personnel est comme, d'accord, maintenant nous pouvons revenir à la normale. Ce n'est pas ce que nous voulons voir, n'est-ce pas ? Donc, nous voulons rendre le changement en quelque sorte durable, pour développer une capacité interne. Donc, si vous regardez cela, c'est un programme exigeant, n'est-ce pas ? Mais au final, c'est vraiment tiré d'un manuel agile. C'est très bien. Donc, au final, c'est génial parce qu'ils investissent de l'argent, donc ils le pensent vraiment. Nous voulons devenir agiles ici. Après un peu plus de huit mois, ils se sont dit, d'accord, voyons ce qui s'est passé. Et cela semblait en fait assez bien. Donc, les équipes travaillaient avec ces tableaux, vous aviez vraiment cette visualisation. Donc, chaque fois que vous allez voir une équipe, vous voyez sur quoi cette équipe travaille. Quoi d'autre ? Les rétrospectives étaient faites. Donc, au final, c'était un peu correct.
Mais ensuite, ils se sont dit, D'accord, c'est une sorte de sentiment subjectif. Mais nous sommes intelligents. Il y a des métriques. Donc, ils ont fait des mesures. Et je vais juste vous montrer trois mesures ici. C'était une mesure. Oh, ceci est en fait vert, ceci a été livré. Mais vous pouvez... Imaginez la couleur. Oui. Donc, ceci est une sorte de graphique de sprint, un graphique de vélocité. Oui. Donc, ce que vous voyez ici est une équipe sur l'axe des x. Vous voyez les sprints. Et ici, vous voyez le... Peu importe la couleur, ce gris représente combien de points d'histoire ils se sont engagés à faire, et cela signifie combien ils en ont livré. Donc, au début, ils étaient assez bons pour s'engager, pas si bons pour livrer, mais oui, ils ont progressé. Et à partir d'ici, oui, la performance est un peu meilleure. Mais ce que vous pouvez voir, c'est que c'est en fait l'exception qu'ils atteignent leur objectif de sprint. Donc, ce n'est que deux ou trois fois qu'ils ont vraiment livré ce à quoi ils s'étaient engagés. Et au final, ce n'est pas l'explosion de fusée que cette entreprise voulait voir en ce qui concerne l'introduction de l'Agile. C'est plus comme, d'accord, c'est clair. Au début, tout est nouveau, n'est-ce pas ? Mais ensuite, oui, c'est un peu correct, peut-être. Un autre graphique qui concerne une équipe différente maintenant. C'est une équipe de camp. Mais vous Ce que vous voyez ici est un nuage de points. Un nuage de points du délai d'exécution de leurs user stories. Donc, oui, et c'est la ligne de tendance. Donc, ce que vous pouvez voir, c'est qu'avec un peu d'imagination, ils deviennent plus rapides. Mais peut-être que ce n'est pas parce qu'ils font du Kanban. Peut-être que c'est bien qu'ils fassent du Kanban. Je ne sais pas. Parce que, je veux dire, ce n'est définitivement pas ce que vous lisez dans toutes ces études de cas. Comme le délai d'exécution est réduit d'un facteur de 2, 4, 6, 8, peu importe. Le délai d'exécution diminue un peu. Donc, ce sont deux métriques d'équipe. Le problème avec les métriques d'équipe, c'est que, comme ils ont fait cette réorganisation, nous ne pouvons pas les comparer à d'autres données parce que toutes les équipes étaient en fait nouvelles. Mais il y avait une métrique, et celle-ci est en fait assez intéressante. C'est le délai d'exécution de leurs projets. Et cette entreprise réalisait des projets avant d'être agile et après être devenue agile. Ou quand ils étaient agiles. Les projets n'étaient plus appelés projets alors, parce que ce n'est pas très tendance. Ils les appelaient initiatives. Mais au final, ça sonne beaucoup plus agile, bien sûr, n'est-ce pas ? Mais au final, c'est la même chose. Et nous pouvons comparer les données ici. Donc, vers 40, la transition agile a commencé. Et ce que vous pouvez voir, c'est la ligne de tendance. Donc, la tendance du délai d'exécution des projets est en hausse. Donc, ils livrent les projets plus lentement qu'avant.
Et ils se sont dit, mais qu'est-ce qui se passe ici ? Je veux dire, nous sommes agiles, et agile signifie que le temps de mise sur le marché des projets diminue, mais rien ne se passe ici. C'est à ce moment-là qu'ils m'ont essentiellement appelé, et ils m'avaient entendu parler de l'optimisation locale par rapport à l'optimisation globale. Et des choses comme ça. Ils m'ont dit, viens, s'il te plaît, rends-nous visite et jette un œil à ce qui se passe ici dans notre organisation. J'ai dit, bien sûr, nous pouvons faire cela. La bonne chose, c'est que dans cette entreprise, ils ont vraiment beaucoup investi dans la visualisation. Donc, je pouvais simplement aller voir une de ces équipes, avoir une conversation avec eux sur le tableau, et parler de leur façon de travailler. C'est bien. Et c'est exactement ce que j'ai fait au début. Donc, je suis allé voir les équipes, et je leur ai dit, d'accord, montrez-moi votre tableau. Comment travaillez-vous ? Et ceci est un... Version très simplifiée de l'un de ces tableaux d'équipe. Donc, vous avez essentiellement quelque chose comme un backlog, c'est ce que nous devons faire, c'est ce que nous allons expédier ensuite. Ici, nous avons quelque chose comme développer, peut-être avez-vous plusieurs colonnes ici, et ensuite nous avons terminé. Cela correspond assez bien aussi pour les équipes Scrum. En Scrum, vous avez quelque chose comme le product backlog. Ensuite, vous avez le sprint backlog ici. Ensuite, vous avez le sprint et puis vous avez terminé.
Donc, c'est une version simplifiée de leurs tableaux au niveau de l'équipe.
Il y avait une chose que j'ai remarquée. Ce champ, en attente d'externe, attente externe. Attente externe. Cela signifie que cette équipe ne peut plus avancer dans son travail parce qu'elle doit attendre une autre équipe. Connaissez-vous des situations comme celle-ci ? Bien sûr, oui. Alors, qu'est-ce que cela signifie ? Nous parlons donc d'une entreprise où chaque équipe a un tableau. Cela signifie qu'il doit y avoir un deuxième tableau quelque part dans cette organisation. Et chaque fois que ces gars sont bloqués ici, cela signifie qu'il y a une demande pour une autre équipe. Cette équipe travaille sur ces choses. Et quand ils ont terminé, l'autre équipe, l'équipe une, peut continuer. Voilà ce qui se passe quand on parle de dépendances. Alors j'ai pensé, d'accord, dessinons une sorte de graphe de dépendances. Je suis donc allé voir les équipes et je leur ai demandé, d'accord, à quelle fréquence avez-vous des dépendances avec d'autres équipes ? Et le graphe de dépendances ressemblait à quelque chose comme ceci.
Il y a donc pas mal de dépendances, n'est-ce pas ? Et nous ne parlons que de huit équipes ici. Donc 600 personnes, c'est un peu plus que huit équipes. Mais la question est, pourquoi y a-t-il des dépendances ? Parce qu'ils travaillent en équipes pluridisciplinaires. Et ils constituent des équipes pluridisciplinaires précisément pour éliminer les dépendances. Et ils travaillent avec des équipes produit. Donc une équipe travaille sur un seul produit, pas sur plusieurs produits. Encore une fois, ils l'ont fait parce qu'ils voulaient éliminer les dépendances. Mais il y a encore tellement de dépendances. Quelle en est la raison ? Eh bien, une chose est que plusieurs équipes travaillent sur un seul produit. Il est vrai qu'une seule équipe travaille sur un produit, mais vous avez plusieurs équipes travaillant sur un seul produit. Donc si ces trois équipes travaillent sur un seul produit, bien sûr, ces gars-là ont des dépendances, n'est-ce pas ? Quoi d'autre ? Les produits ne sont pas complètement indépendants. Je pense que tout le monde le sait. Si vous faites quelque chose dans ce produit, vous devez changer quelque chose dans ce produit-là, et un peu dans ce produit-ci, et un peu dans ce produit-là. Donc les produits, il y avait des dépendances. Et au final, nous parlons de 600 personnes. Je n'ai jamais vu une entreprise de plus de 50 personnes sans aucune dépendance, n'est-ce pas ? Donc chaque fois que nous parlons de dépendances, cela fait apparaître une image dans mon esprit. Une image d'un clavier. Supposons que notre entreprise soit un clavier et que nous soyons dans le métier de l'écriture. Donc ce que nous faisons, c'est écrire des lettres. Organisons donc notre entreprise. ne sont pas complètement indépendants. Je pense que tout le monde le sait. Si vous faites quelque chose dans ce produit, vous devez changer quelque chose dans ce produit-là, et un peu dans ce produit-ci, et un peu dans ce produit-là. Donc les produits, ils avaient des dépendances. Et au final, nous parlons de 600 personnes. Je n'ai jamais vu une entreprise de plus de 50 personnes sans aucune dépendance, n'est-ce pas ? Donc, chaque fois que nous parlons de dépendances, cela fait apparaître une image dans mon esprit. Une image d'un clavier. Supposons que notre entreprise soit un clavier et que nous soyons dans le métier de l'écriture. Donc ce que nous faisons, c'est que nous écrivons des lettres. Organisons donc notre entreprise. Équipe 1, 2, 3, 4.
L'équipe 1 ne frappe que les touches numériques, l'équipe 2 s'occupe de Q, W, E, R, et ainsi de suite. Et maintenant, il y a ce client et il veut que nous écrivions une lettre d'amour. Nous devons donc réfléchir à la manière dont nous pouvons envoyer cette lettre d'amour, n'est-ce pas ? Dans un monde avec 600 équipes, pardon, personnes, vous n'avez pas quatre équipes. Votre réalité ressemble plus à ceci.
Pour chaque fichue touche de ce clavier, vous avez une équipe qui l'appuie. Vous avez une équipe H et une équipe G. Bien sûr, chaque organisation a besoin d'une équipe A. Sans équipe A, vous êtes fondamentalement dans la panade. Et maintenant, optimisons ces équipes. Et supposons que cela fonctionne. Vous avez la meilleure équipe H de cette planète. Quand ils commencent à appuyer sur la touche H, de la fumée sort du clavier.
À quel point pouvons-nous livrer notre lettre plus rapidement ?
Pas tellement, n'est-ce pas ? Donc le point est, quand il s'agit d'écrire une lettre ou d'utiliser un clavier, ce n'est pas si important que je puisse appuyer sur chaque touche très rapidement. C'est beaucoup plus important que j'appuie sur la bonne touche au bon moment. Cela pourrait même être un peu plus lent, mais appuyer sur la bonne touche au bon moment. Donc si nous transférons cette logique à notre organisation, alors le point est qu'il n'est pas si important que nous ayons des équipes performantes, que chaque équipe travaille très, très vite. La performance, c'est de s'assurer que la bonne équipe travaille sur les bonnes choses au bon moment. Il y a bien plus de performance là-dedans que de simplement travailler vite au niveau de l'équipe. Et il y a un gars appelé Russell Eckhoff qui dit essentiellement cela. Il dit que la performance d'un système n'est pas la somme de ses parties. C'est le produit de ses interactions. Le produit de ses interactions. Cela signifie que nous devons nous assurer que la bonne équipe travaille sur les bonnes choses au bon moment. Et si vous transposez cette citation aux organisations agiles, nous pouvons dire quelque chose. Comme ceci. L'agilité d'une organisation ne consiste pas à avoir beaucoup d'équipes agiles. Il s'agit d'avoir des interactions agiles entre ces équipes. Ce sont les interactions qui comptent. Et le point est qu'ils ne parlaient pas du tout des interactions.
C'était, disons, ma première découverte. Ils optimisaient simplement localement toutes les équipes, mais ils n'optimisaient pas les interactions entre ces équipes. Ma première découverte dans cette entreprise. Je vais donc rester en mode problème et ensuite je viendrai aux solutions. Alors quoi d'autre ? C'est un autre tableau d'équipe typique. Et je demandais à ces gars, d'accord, donc vous développez et quand vous avez fini ici ou quand vous terminez le développement, alors vous avez terminé. Ils répondaient, oui, bien sûr. Je veux dire, sauf, bien sûr, qu'il y a une intégration en cours. Ah, d'accord. C'est bon à savoir. Ajoutons donc une colonne comme celle-ci, en attente d'intégration. Mais ensuite, si tout est intégré, vous avez terminé. Enfin, en quelque sorte. Bien sûr, il y a un test d'acceptation en cours. D'accord, c'est bon à savoir. Écrivons donc test d'acceptation sur notre tableau. Ensuite, je leur disais, d'accord, et après le test d'acceptation, vous êtes prêts. Pas vraiment. Bien sûr, nous devons le publier. Ah, c'est une bonne information à avoir, en fait. Ensuite, je demandais, d'accord, combien de temps cela prend-il ?
Voilà le résultat. Donc sur une base mensuelle, ils faisaient l'intégration, et trimestriellement, le test d'acceptation et l'attente de la publication. Réfléchissons donc à ce que ces gars veulent faire. Nous voulons améliorer le temps de mise sur le marché. Donc il y a une certaine influence en ce qui concerne le temps de mise sur le marché, n'est-ce pas ? Alors je leur disais, d'accord, et ici ? Donc c'est le backlog et vous commencez simplement à travailler. Ils répondaient, non, ce n'est pas aussi simple que ça parce que c'est le backlog de développement, bien sûr. Ah, bien. Donc s'il y a quelque chose comme un backlog de développement, il y a peut-être aussi un autre backlog ? Eh bien, oui, bien sûr, parce qu'avant de commencer à développer, nous devons bien sûr faire un peu de travail d'analyse. D'accord, c'est une bonne information à avoir, mais avant l'analyse, rien ne se passe. Ils répondaient, en fait, un petit peu. Donc notre processus est en fait plus comme ceci.
Nous avons un réservoir de nouvelles idées. Ensuite, nous faisons une sorte de tri. Ensuite, nous écrivons un concept grossier. Ensuite, nous attendons le comité de pilotage. Le comité de pilotage décide quel concept grossier passe au concept détaillé. Ensuite, nous écrivons ce concept détaillé. Et ensuite, nous attendons l'approbation. C'est vraiment une bonne information à avoir. Parce que si vous prenez du recul, votre processus ressemble à ceci. Et maintenant, nous pouvons demander à nouveau, quelle est la cadence derrière tout cela ? Il attend, attend, attend Godot. Donc, le tri sur une base mensuelle, le comité de pilotage sur une base trimestrielle, et deux fois par an, ces gars approuvent les concepts détaillés.
Nous voulons à nouveau améliorer le temps de mise sur le marché pour nos projets. D'accord ? Initiatives. Leur idée était, voici développer.
Mettons un peu d'agile là-dedans. Et alors nous serons tellement agiles et ce sera génial.
Non, vous ne l'êtes pas. Vous n'êtes définitivement pas agiles. Peut-être que ceci est le développement logiciel agile. D'accord, c'est juste. Mais cette organisation est aussi nulle qu'avant sur le marché. Donc, il y a vraiment une différence entre le développement logiciel agile et l'agilité métier. Et cela n'a rien à voir avec l'agilité métier. C'était en fait ma deuxième découverte là-bas. Donc encore une fois, une optimisation locale et aucune idée de comment fonctionne le processus de bout en bout. Donc, ils n'ont fait que zoomer et aucune gestion de toute la chaîne de création de valeur. Deuxième découverte.
Juste une chose de plus que je dois partager avec vous. Donc, ce que vous pouvez voir ici, ce sont des chiffres sur le tableau. Celles-ci fonctionnent. limites de processus ou limites de travail en cours. Avez-vous entendu parler des limites de travail en cours ? Oui, elles sont tout simplement géniales. Oui, donc avec les limites de travail en cours, vous pouvez réellement accomplir beaucoup. Donc, l'idée est d'arrêter de commencer et de commencer à finir. Oui, donc nous ne commençons pas beaucoup de travail. Nous ne commençons qu'une certaine quantité de travail. Et ensuite, seulement quand le travail est terminé, nous commençons un nouveau travail. C'est l'idée derrière cela. Et à peu près la même chose que ces limites de travail en cours, toutes les équipes Scrum avaient des limites pour deux semaines. Vous savez, il y a le sprint. Et pendant deux semaines dans le sprint, nous ne commençons que cette quantité de travail. Et ensuite, nous devons le terminer. Et ensuite, nous commençons un nouveau travail. Donc, il y avait cette limitation en place dans cette organisation. Et si vous connaissez un peu les limites de travail en cours, c'est la meilleure chose que vous puissiez faire. Donc, surtout, je veux dire, nous ne pouvons pas tout couvrir, mais il y a des maths derrière cela. C'est mathématiquement prouvé que cela fonctionne. Et il y a exactement une chose, le temps de mise sur le marché s'améliore. Vous utilisez des limites de travail en cours. Ces gars-là utilisaient des limites de travail en cours. Le temps de mise sur le marché augmentait. Comment est-ce possible ? Encore une fois.
Eh bien, en ce qui concerne les limites de travail en cours, il y a une petite clause. Et je pense que 99 % de toutes ces organisations ne connaissent pas la petite clause des limites de travail en cours. Donc, voici la petite clause.
Vous devez limiter cette entité dans votre organisation où vous voulez voir les avantages des limites de travail en cours. C'est peut-être la phrase la plus importante que je dis aujourd'hui. Donc, vous devez vraiment limiter ces éléments ou entités dans votre organisation où vous voulez voir les avantages des limites de travail en cours. Qu'est-ce que cela signifie ? Regardons cette entreprise. Ces gars travaillaient sur des initiatives ou des projets. Bien sûr, parce qu'ils sont agiles, ils ont divisé ces éléments. Ils les ont divisés en épopées. Ensuite, ils ont divisé l'épopée en histoires et les histoires en tâches. Je pense que tout le monde connaît quelque chose comme ça. Oui ? D'accord, bien. Donc, nous devons limiter cette entité où nous voulons voir l'amélioration. Donc, ils voulaient améliorer le temps de mise sur le marché des projets. Donc, que devons-nous limiter ?
Ce gars ici. Nous devons limiter les initiatives et les projets dans notre organisation. Qu'ont-ils fait ? Ils ont commencé au niveau de l'équipe. Puis-je, en tant qu'équipe, décider combien de projets sont en cours dans toute l'organisation ? Peut-être pas. Donc, quand il s'agit de limiter ce à quoi j'ai accès,
je peux peut-être limiter les histoires et je peux limiter les tâches. Et c'est tout. N'est-ce pas ? Donc, c'est le problème ici. Ces gars limitaient les histoires et les tâches, mais ils travaillaient encore sur mille projets en parallèle. Donc, surprise, surprise, vous ne terminerez pas les projets plus vite si vous limitez la mauvaise entité dans votre organisation. Est-ce que cela a du sens ? Limitez donc cette entité où vous voulez voir les avantages des limites de travail en cours. La grande question est, qui peut limiter cette entité dans l'organisation ?
La direction. La haute direction, en fait. Ils doivent bouger. Oui. Donc, la haute direction doit faire cela, et c'est en fait la chose de la gestion stratégique de portefeuille. Limitez, oui, alignez tout le travail en fonction de votre stratégie et limitez les projets et initiatives dans votre organisation. Cela ne peut être fait qu'au niveau de la haute direction. Et il est très important que nous ayons quelque chose comme la gestion stratégique de portefeuille, et ce n'était pas en place dans cette organisation. Pourquoi est-ce si important ? Eh bien... J'aime bien cette illustration de Reinventing Organizations, de Frederick Laloux, car elle correspond totalement à ce que je vois tout le temps. Supposons que vous êtes membre du conseil d'administration. Et lundi, quelqu'un vient vous voir et présente une idée. Et ce gars s'est préparé pendant une semaine pour cette présentation. Vous avez une demi-heure de temps. Il présente cette idée et vous pensez, oui, c'est génial. Nous devons faire cela parce que c'est pour l'avenir de notre entreprise. Le lendemain, un autre vient vous voir. 15 minutes. Il s'est préparé pendant deux semaines pour cette présentation. Et cela a juste du sens. Nous devons lancer cette initiative. Nous devons faire cette initiative parce que sinon, notre avenir est vraiment en jeu. Devinez ce qui se passe mercredi ? Un autre vient, n'est-ce pas ? Et présente une idée. Et chacune de ces idées, elles sont bonnes. Mais le problème est que ce que vous avez fait, c'est prendre trois décisions isolées.
Et chacune de ces décisions, elles sont bien sûr bonnes, mais sont-elles bonnes si vous voyez l'ensemble du tableau ? Et c'est exactement là que la gestion stratégique de portefeuille intervient. Rendez plus ou moins visible tout ce que fait votre entreprise et ne prenez pas de décisions isolées. Et cela n'est possible qu'au niveau stratégique du portefeuille. Ce sont essentiellement mes trois constats dans cette organisation. Bien sûr, il y avait plus, mais ce sont, disons, les trois principaux sujets que j'ai découverts. Voilà donc les problèmes. Aucune gestion des interactions entre les équipes, aucune gestion de bout en bout de la création de valeur, et aucune gestion stratégique du portefeuille. Passons maintenant au mode solution. Qu'avons-nous fait dans cette organisation ? Premier sujet, la gestion des interactions entre les équipes. Rappelez-vous, c'était cette image. Beaucoup de dépendances ici au niveau de l'équipe. Et encore une fois, le problème était que plusieurs équipes travaillaient sur un seul produit. Donc, ce que nous avons essentiellement fait, c'est identifier quelle équipe travaille sur quel produit, ce qui est en fait assez simple. Nous pouvons découvrir cela dans une organisation.
Ce que nous avons fait, c'est que nous avons créé des tableaux de produits à la fin. Donc, ce que nous avons fait, si ces trois équipes, disons, travaillent sur un seul produit, elles devaient créer un tableau sur la manière dont elles livrent réellement le produit. Une autre chose, je pense, très importante est de ne pas agiliser ou optimiser les structures organisationnelles. Ce n'est pas le but. Une équipe est une structure organisationnelle. Aucun client ne vous paie pour des équipes. Je paie pour la livraison de valeur. Donc, chaque fois qu'il s'agit de faire quelque chose d'agile, optimisez la livraison de valeur et non les structures organisationnelles. C'est essentiellement ce que nous avons fait ici. Et souvent, c'est vraiment simple comme ça. Vous prenez ces trois équipes, vous les enfermez dans une pièce pour une journée, et elles ont pour tâche de déterminer comment ces personnes travaillent ensemble. Et le résultat était quelque chose comme ceci. Un tableau. Donc, il y avait un tableau sur la manière dont ces trois équipes travaillent ensemble. Et lorsque nous voyons un poids externe ici, ce sont des dépendances en dehors du produit. Ainsi, toutes les dépendances entre les équipes sont gérées sur ce tableau de produit.
C'est un tableau. Un tableau est un tableau et pas une interaction. Nous devions donc mettre en place des interactions ici. Qu'avons-nous fait ? Eh bien, essentiellement, des boucles de rétroaction. Une boucle de rétroaction était les réunions debout. Nous avons donc établi... des réunions debout pour le produit. Chaque équipe envoyait des délégués à une réunion debout. Ils se coordonnaient devant le tableau de produit, puis retournaient à leurs équipes et tenaient une réunion debout au niveau de l'équipe. un tableau. Donc, il y avait un tableau montrant comment ces trois équipes travaillent réellement ensemble. Et lorsque nous voyons une pondération externe ici, ce sont des dépendances en dehors du produit. Ainsi, toutes les dépendances entre équipes sont gérées sur ce tableau produit.
C'est un tableau. Un tableau est un tableau et aucune interaction. Nous devions donc mettre en place des interactions ici. Qu'avons-nous fait ? Eh bien, essentiellement, des boucles de rétroaction. Une boucle de rétroaction était les réunions debout (stand-up). Nous avons donc établi des réunions debout pour le produit. Chaque équipe envoyait des délégués à une réunion debout. Ils coordonnaient devant le tableau produit. Ensuite, ils retournaient dans leurs équipes et tenaient une réunion debout au niveau de l'équipe.
Les boucles de rétroaction, très importantes. Beaucoup de dépendances ont simplement été supprimées lors de cette réunion debout. Une autre chose, ce sont les rétrospectives. Chaque fois qu'il s'agit de faire des rétrospectives, beaucoup d'entreprises ne les font qu'au niveau de l'équipe. Ainsi, chaque équipe s'améliore. Mais ce n'est pas le but. Nous voulons améliorer la livraison du service. Nous devons donc faire des rétrospectives au niveau du produit dans ce cas. Et c'est exactement ce que nous avons fait. Encore une fois, des représentants des différentes équipes envoyaient des délégués à une rétrospective. Ils s'amélioraient. Et puis, oui, nous avons essentiellement amélioré la livraison de... Le produit.
Quel a été le résultat ? Le résultat était que le nombre de dépendances, bien sûr, diminuait. Toutes ces dépendances, les dépendances entre équipes, étaient déjà gérées, mais il reste encore des dépendances. Ce sont les dépendances du produit. Donc, c'était le fait qu'un produit, si vous changez quelque chose ici, vous devez changer quelque chose là. Alors, comment avons-nous géré ces dépendances inter-produits ? Eh bien, souvent c'est assez simple.
Nous avons établi, on pourrait dire, une gestion de portefeuille opérationnelle, mais en fin de compte, c'était beaucoup plus simple. Nous avons essentiellement identifié quels produits avaient beaucoup de dépendances, et ce que nous avons fait, c'est que nous avons pris ces tableaux, les avons mis dans une seule pièce,
Et ensuite, nous avions une sorte de vue d'ensemble de toutes les dépendances entre les produits. Et encore une fois, nous avons établi des boucles de rétroaction. Donc maintenant, vous voyez le produit un, deux, trois, il y a beaucoup de dépendances. Et maintenant, encore une fois, des délégués des différents produits parlaient devant le tableau et supprimaient ces dépendances. Lorsque nous parlons de dépendances externes ici, elles sont externes au développement de produit. Donc, c'est vraiment en dehors de la zone de développement de produit. Oui, et encore une fois, l'important est de mettre en place les boucles de rétroaction. Donc, le tableau seul n'est qu'un objet inanimé. Les gens doivent parler devant le tableau. Oui, un stand-up de portefeuille et aussi des rétrospectives. C'était la première chose. Oui, donc.
Gestion des interactions entre les équipes. Et ensuite ? Gestion de bout en bout de toute la chaîne de création de valeur. Eh bien,
En fin de compte, d'un point de vue technique, c'est très simple. C'est très simple. Il suffit de zoomer en amont, d'impliquer les affaires,
Peut-être est-il intelligent de ne pas avoir trop d'étapes devant. Donc, rendez-le un peu plus petit. Et c'est exactement ce que nous avons fait ici. Donc, cette attente d'approbation n'était faite que sur une base bi-hebdomadaire. C'était quatre mois auparavant. Et c'est terminé.
D'un point de vue technique, pour établir quelque chose comme cela, cela nous a pris un an. Parce qu'ici, nous parlons des gens. Et les gens, c'est du changement. C'est un pur changement que vous devez faire ici. Vous ne pouvez pas imposer cela aux affaires et dire que vous devez coordonner avec ces personnes. Vous devez le rendre attrayant pour eux. Et cela nous a pris presque un an pour impliquer les affaires et coordonner tout au long de la chaîne de création de valeur. D'un point de vue technique, c'est facile. Mais ici, vous êtes dans la gestion du changement. Vous devez convaincre les gens et c'est la chose difficile. Dessiner quelques colonnes est la chose facile. Donc, oui, ce fut la deuxième étape. Nous avons simplifié l'amont et nous avons étendu aux affaires. Cela ne nous a pris qu'un an.
Deuxième point. Troisième point, en fin de compte, également assez simple, et je trouve le troisième point, la gestion stratégique du portefeuille, bien plus facile que de gérer toute la chaîne de création de valeur, car ici, vous n'avez besoin de convaincre que quelques personnes. Et il s'agit de la haute direction. La haute direction doit proposer un tableau, un tableau de portefeuille stratégique. Et c'est exactement ce que nous avons fait ici. Donc, dans un premier temps, nous avons posé la question, d'accord, qu'est-ce qui nous occupe ? Et dans leur monde, c'étaient des initiatives, ce qui est le projet.
Des investissements, vous savez, c'est le genre de choses que nous devons faire, mais il n'y a pas beaucoup de valeur client, mais nous devons le faire. Et des changements. Les changements, c'est aussi assez bien. Par changements, j'entends vraiment des changements organisationnels. Comme McKinsey qui est là et fait une sorte d'initiative lean, puis il y a des gens agiles qui font des trucs agiles là, la responsabilité client, peu importe, des initiatives de navire, homme, bla bla. Et il y a généralement beaucoup de choses qui se passent dans ces organisations, et cela n'accélère pas la livraison de valeur à la fin, n'est-ce pas ? Donc, oui, nous avons découvert ces choses, et ensuite nous nous sommes dit, d'accord, et comment travaillons-nous sur ces choses ? Et voici une sorte d'esquisse du tableau de portefeuille stratégique. Ce n'est pas le tableau de portefeuille stratégique correct. C'est juste ce qu'ils ont pensé. Nous pourrions essayer. Oui.
Oui. Et encore une fois, l'important n'est pas le tableau. L'important, ce sont les boucles de rétroaction. Ici, la haute direction se tenait devant ce tableau sur une base hebdomadaire. Au début, ils ont dit, d'accord, nous ferons cette réunion debout tous les deux mois. Alors j'ai dit, d'accord, commençons. Et après la première réunion, ils étaient comme, d'accord. Nous devons faire cela chaque semaine. Et ces gars-là, vraiment, ils restent devant ce tableau chaque semaine pendant environ 50 minutes, 10 minutes. Et les responsables produit, les représentants des responsables produit sont également devant le tableau. Et ils prennent des décisions en contexte. Pas de décisions isolées. Et l'important, c'est qu'ils limitent le travail dans toute l'organisation ici. Cela signifie qu'ils appliquent des limites de travail en cours ici. Et cela signifie que maintenant nous parlons d'améliorer le temps de mise sur le marché. Et c'est la chose importante. Donc, c'était la troisième étape. Nous avons établi cette gestion stratégique de portefeuille. Donc, c'étaient les trois choses. Donc, quand j'ai essayé de résumer cela, je pense qu'une chose était vraiment très claire pour moi : l'agilité métier n'est définitivement pas un sport d'équipe. Quand il s'agit d'agilité métier, c'est un sport d'entreprise. Donc, vous devez faire bouger toute l'organisation vers un autre endroit. Sinon, vous faites un tas d'optimisations locales. Vous dépensez beaucoup d'argent, c'est bon pour l'industrie du conseil, pas si bon pour vous en tant qu'entreprise, mais vous ne verrez pas beaucoup d'améliorations à la fin. Je veux dire, vous énervez certaines personnes, comme vous le faites avec chaque changement, mais c'est tout ce que vous accomplissez.
Donc, quand je dis que c'est un sport d'entreprise, quand je dis que c'est un sport d'entreprise, qu'est-ce que cela signifie ? Donc, si nous pouvons faire de l'agile dans l'entreprise, où pouvons-nous réellement le faire ? Et il y a un modèle que j'aime utiliser comme modèle de communication, que j'appelle les niveaux de vol. Le niveau de vol est un terme de l'aviation. Plus vous volez haut, plus vous voyez, mais vous ne voyez pas beaucoup de détails. Et si vous volez très bas, vous voyez beaucoup de détails, mais vous ne voyez pas grand-chose. Et c'est l'idée des niveaux de vol, où vous pouvez avoir une conversation sur l'endroit dans votre organisation où vous pouvez réellement devenir agile. Bien sûr, ce que je pense que tout le monde connaît, c'est le niveau de vol un. Niveau de vol un, le niveau opérationnel, où les gens travaillent. Équipes Scrum, équipes Kanban, peu importe. Nous pouvons, bien sûr, faire des améliorations au niveau de l'équipe. C'est le niveau de vol un. Habituellement, beaucoup d'entreprises ont plus d'une seule équipe, donc vous trouverez plusieurs systèmes de niveau de vol un dans votre organisation.
Si ce sont les touches individuelles de votre clavier, nous devons nous assurer que nous appuyons sur la bonne touche au bon moment, vous vous souvenez ? Et c'est ce que nous faisons au niveau de vol deux. Le niveau de vol deux est la coordination de bout en bout. Espérons que vous avez quelque chose comme de l'idée à l'impact. Votre chaîne de création de valeur et vous vous assurez que la bonne équipe travaille sur les bonnes choses au bon moment. Cela signifie que vous pouvez connecter ces tableaux ensemble. Et bien sûr, vous devez mettre en place une boucle de rétroaction parce que, encore une fois, il s'agit de la boucle de rétroaction et non des tableaux. Le tableau est juste ce dont vous parlez, mais vous devez parler. Donc, niveau de vol deux, de l'idée à l'impact, espérons-le, et vous vous assurez que la bonne équipe travaille sur les bonnes choses au bon moment. Coordination de bout en bout. Souvent, vous avez plus d'une seule chaîne de création de valeur dans votre organisation. Vous avez peut-être plusieurs produits, plusieurs projets. Donc, nous voyons plusieurs systèmes de niveau de vol 2 dans notre organisation, bien sûr.
Et souvent, il est le cas que nous avons des dépendances entre ces produits. Donc, nous pouvons simplement les mettre dans la même pièce, et c'est ce que j'appellerais la gestion opérationnelle de portefeuille. Ici, vous gérez les dépendances entre plusieurs flux, entre plusieurs produits, plusieurs chaînes de création de valeur. Niveau de vol deux. Nous pouvons voler encore un niveau de vol plus haut, niveau de vol trois, c'est la gestion stratégique de portefeuille. Qu'est-ce qui occupe toute l'organisation et le travail dans l'organisation est-il aligné sur la stratégie ? C'est ce que vous allez répondre au niveau de vol trois. Dans les grandes entreprises, nous voyons Plusieurs niveaux de vol 3. systèmes qui sont en quelque sorte connectés ensemble. Donc, ce sont les niveaux de vol et maintenant nous pouvons avoir une conversation. Donc pour moi, ce n'est pas un modèle de maturité, c'est très important. C'est vraiment un modèle de communication. Nous pouvons déterminer où dans une organisation se trouve le bon levier à actionner pour que nous voyions ce type d'amélioration que nous voulons voir. Donc, il ne s'agit pas de mieux ou de pire. C'est aussi très important. Donc, vous pouvez construire, car à chaque niveau de vol, il y a différentes tâches principales que vous devez établir. Par exemple, au niveau de vol un, la tâche principale est de livrer.
Ainsi, vous pouvez prendre les meilleures décisions stratégiques. Si vous n'êtes pas capable de livrer, c'est assez difficile. Cela n'a aucun sens. Donc, il ne s'agit pas de mieux ou de pire. Mais l'autre chose est également vraie. Si vous voulez améliorer notre temps de mise sur le marché pour les projets, nous pouvons mettre de l'Agile ici au niveau de l'équipe. Comme un fou, mais les projets seront toujours terminés très, très lentement. Donc, le levier est là-haut. Et c'est à cela que servent les niveaux de vol. Il ne s'agit pas de mettre en œuvre les niveaux de vol. Personne ne veut mettre en œuvre une affiche. Il s'agit d'avoir une conversation qui a du sens. D'accord ? Il me reste quatre minutes, et je pense que je vais conclure maintenant.
Je vous ai montré une situation où une transition agile était déjà en cours et je me suis joint à cette transition agile et oui, nous avons fait quelque chose de différent. Mais je pense qu'une question est : comment commenceriez-vous à partir de zéro ? Donc, s'il n'y a rien en cours ou pas grand-chose dans votre organisation, comment deviendriez-vous agile ? Je pense qu'il y a deux approches. La première approche est lorsque vous êtes une société de conseil et que vous voulez maximiser vos revenus en tant que société de conseil et que vous ne vous souciez pas trop de voir des améliorations dans l'organisation. Cela semble un peu bizarre, mais je connais beaucoup d'organisations qui sont comme, d'accord, devenons un peu agiles, mais ne changeons pas trop de choses. Vous connaissez cela ? Oui. Donc, bien sûr, s'il y a une demande, il y a une solution. Donc, formez toute l'organisation aux méthodes agiles. Il est très important de former l'état d'esprit car tout est une question d'état d'esprit. Vous devez vraiment former l'état d'esprit. C'est très important. Cela fonctionne totalement. Commencez au niveau de l'équipe, c'est très important, et ne cessez pas de sous-optimiser.
Ne montez jamais à un modèle stratégique ou quelque chose de ce genre.
Ce qui est également très important, Suivez une recette.
C'est très important. Parce que c'est un moyen très, très sûr de brûler des tonnes d'argent. Oh, je pense qu'il y a une faute de frappe sur la diapositive. Désolé pour cela.
C'est de ma faute. Ouais. Donc, voici la première approche. La deuxième approche s'adresse à vous si vous êtes une organisation à l'esprit économique et que vous voulez vraiment voir quelque chose se passer dans votre organisation, que vous voulez voir du changement, alors c'est en fait assez simple. Au début, vous n'avez besoin que d'une seule équipe agile et c'est la haute direction. C'est la haute direction. Impliquez votre haute direction, rendez votre haute direction agile, puis descendez les niveaux hiérarchiques. Mais faites-le en mode traction. Laissez les équipes tirer le changement. Commencez par la gestion stratégique du portefeuille, alignez tout le travail de votre organisation sur cette stratégie. Et puis, à la fin, peut-être que vous rendrez également certaines équipes agiles. Il y a une autre chose qui, je pense, est particulièrement importante pour moi. Éliminez toutes ces méthodes et cadres agiles. Prenez-les comme source d'inspiration, mais vous avez le droit de réfléchir. Il y a un cerveau là-dedans. Appliquez. Une solution sur mesure pour votre demande. Vous devez savoir ce que vous faites et vous n'avez pas besoin de... déployer une affiche ou des choses comme ça. Je veux dire, c'est bon pour les sociétés de conseil, bien sûr, parce que c'est le marché. Mais pour vous en tant qu'organisation, ce n'est pas ce que vous voulez faire. Parce qu'en fin de compte, vous n'avez besoin que d'une seule chose en place. Vous devez être le meilleur pour vous améliorer. Et cela, vous ne pouvez pas l'atteindre en déployant quelques affiches. Soyez le meilleur pour vous améliorer. C'est tout ce que je voulais dire. Merci.

Transcription (Traduit)