Flight Levels in Action de Klaus Leopold

La quatrième conférence de la première Agile100 nous invitait à prendre notre envol. Klaus Leopold a montré avec « Flight Levels in Action » comment améliorer une organisation à différents niveaux.

Le modèle des Flight Levels comprend trois niveaux qui s'occupent des thèmes suivants :

• Flight Level 1 : Niveau opérationnel
• Flight Level 2 : Coordination
• Flight Level 3 : Gestion stratégique du portefeuille

Klaus l'explique plus en détail dans ses slides, disponibles dans le Recap de mai de l'Agile100. De plus, la conférence intégrée ci-dessous montre bien comment les Flight Levels fonctionnent en action.

Flight Levels in Action de Klaus Leopold

Plus sur Klaus Leopold

Dr. Klaus Leopold est informaticien, pionnier du Kanban et inventeur du Flight Levels Model. Il possède une longue expérience en tant que consultant pour le top management, avec environ 1000 participants à ses ateliers chaque année. Il conseille des entreprises du monde entier sur la façon d'agir de manière agile sur le marché. Klaus est l'auteur du bestseller Rethinking Agile, Practical Kanban et co-auteur de l'ouvrage de référence Kanban Change Leadership.
Il est cofondateur de la Flight Levels Academy et partage ses réflexions et expériences actuelles dans le monde des Flight Levels et du développement organisationnel sur son blog www.LEANability.com et son compte Twitter : https://twitter.com/klausleopold.

« La théorie sans pratique est inutile. La pratique sans théorie coûte cher. »

Flight Levels en action (Transcription)

Si tu ne veux pas regarder la vidéo en entier, nous avons préparé pour toi une transcription complète de la conférence de Klaus Leopold. Bonne lecture !

Sohrab :

Bon retour parmi nous. C'est formidable d'avoir Klaus Leopold avec nous aujourd'hui. Klaus et moi ne nous sommes en fait jamais rencontrés en personne, mais nous avons beaucoup de gens qui ont suivi ses formations et les miennes. Et dans mes formations, ils parlaient toujours de Kanban-Klaus, et peut-être que dans ses formations, ils parlaient de Scrum-Sohrab, je ne sais pas, peut-être que Klaus pourra nous en dire plus. Mais je suis vraiment très content d'avoir Klaus parmi nous.

C'est l'un des auteurs que je suis depuis un bon moment. J'ai particulièrement apprécié son dernier livre "Rethinking Agile", dans lequel il parle des Flight Levels. Je suis sûr qu'il abordera certains de ces sujets avec nous aujourd'hui. Et si tu veux en savoir plus, passe au stand de son entreprise après sa présentation, pas pendant, et échange avec certains de ses collègues, je crois que Catherine et Cliff seront là. Klaus, la scène est à toi.

Klaus :

Parfait. Cool. Merci beaucoup, Sohrab, pour cette aimable introduction. Oui, alors, "Rethinking Agile", c'est le titre de mon livre, et c'est aussi le titre de ma présentation d'aujourd'hui. Et je pense que le sous-titre résume assez bien le message que j'essaie de faire passer : pourquoi les équipes agiles n'ont rien à voir avec l'agilité business. De quoi s'agit-il donc ? Eh bien, j'aimerais raconter une histoire. Je veux raconter l'histoire d'une organisation. Et cette organisation avait quelques problèmes. Le problème principal, c'est qu'ils voulaient améliorer leur délai de mise sur le marché. Ils se sont dit : "OK, nos projets prennent beaucoup trop de temps à aboutir. Nous devons vraiment raccourcir notre délai jusqu'au marché."

Et, bon, ce genre de souhaits, je l'entends assez souvent : "Nous voulons améliorer notre time-to-market." Mais d'un point de vue business, il y a bien plus derrière cette réduction du délai de mise sur le marché. Dans cette entreprise en particulier, il s'agissait beaucoup d'être proactif sur le marché. Autrefois, ils étaient leaders du marché, mais maintenant ils essayaient juste de suivre la concurrence. Ce n'est pas une sensation agréable. Et ils se sont dit : "OK, nous voulons redevenir proactifs, nous voulons saisir les opportunités." Je veux dire, ils savent ce qui se passe sur les marchés. Et ils ont dit : "OK, le problème, c'est que quand nous essayons de monter l'un de nos projets, l'opportunité est déjà passée." Donc, pas terrible.

Et bien sûr, ils voulaient être préparés au changement discontinu qui est en cours, n'est-ce pas ? Nous connaissons tous ces nouveaux modèles économiques qui émergent, nous ne faisons plus de projets, nous faisons des produits, nous ne faisons plus de produits, nous faisons des solutions, nous faisons des services, nous faisons je ne sais quoi. Il y a la blockchain, l'intelligence artificielle et ainsi de suite. Et ils ont dit : "Eh bien, l'avenir va très probablement arriver. Mais si nous continuons comme aujourd'hui, alors très probablement sans nous." Et ils ont dit : "OK, nous devons changer fondamentalement ce que nous faisons ici." Et bon, quand tu entends quelque chose comme ça, que fais-tu ? La réponse est simple, non ? Nous devenons agiles, n'est-ce pas ? Avec l'agilité, nous pouvons facilement aborder tous ces sujets. Eh bien, c'est essentiellement ce qu'ils ont essayé de faire. Ils ont donc lancé une transformation agile.

Qu'est-ce qui faisait partie de la transformation agile ? Eh bien, comme dans tous les manuels sur l'agilité, on sait qu'il faut combattre les silos fonctionnels. Les silos, c'est mal, c'est le diable, donc il faut créer des équipes transversales. Ils ont dit : "Réorganisez-vous en équipes transversales." Quoi d'autre ? Ils sont même allés plus loin en disant : "OK, il nous faut des équipes produit. On veut des équipes produit transversales." Autrement dit, une équipe ne travaille que sur un seul produit à la fois. Une bonne chose quand on y réfléchit. Ce qu'on fait ainsi, c'est qu'on réduit les dépendances d'une certaine manière, pour pouvoir livrer directement au marché, et ça raccourcit évidemment notre time-to-market. Personnellement, j'aime bien cette approche.

Ils ont dit : "Ne soyons pas trop dogmatiques sur la méthode agile que les équipes utilisent. Elles peuvent choisir leur méthode agile, leur méthode agile préférée, il y a juste quelques exigences à respecter. Chaque équipe doit avoir une visualisation, sur un tableau. On veut voir ce qui se passe dans les équipes." L'idée, c'était que si je vois ce que font toutes les équipes, je peux simplement aller vers une équipe, entamer une conversation sur leur travail et discuter de leurs problèmes. Chaque équipe doit donc avoir ce tableau, on veut voir ce qui se passe dans les équipes. Une autre exigence, c'était des réunions standard. Chaque équipe a besoin d'un outil de feedback rapide qui leur permet de s'adapter aux choses qui surgissent rapidement, donc des stand-ups, pour chaque équipe.

Chaque équipe doit faire des rétrospectives, ce qui est en gros une machine à amélioration, ce qui fait pas mal de sens, non ? On veut donc s'améliorer. Devenir agile, ce n'est pas juste une amélioration ponctuelle, on veut s'améliorer en continu. Et dernière chose, et ça aussi j'aime bien, ils ont dit : "On veut voir quelques mesures." Tu sais, une chose c'est de sentir que ça va bien, une autre c'est de savoir quel est le résultat concret de ce qu'on fait ici. Le temps de cycle avec l'équipe doit donc diminuer, et le débit doit augmenter, d'accord ? C'étaient les deux métriques. Et bon, quand tu regardes tout ça, et que tu viens de lire un manuel sur l'agilité, tu te dis probablement : "Génial. Je veux dire, ils comprennent vraiment ce qu'il faut faire, non ? C'est exactement ce qu'il faut faire. Rien ne peut mal tourner."

Eh bien, c'est ce qu'ils ont essayé de faire. Et comment ont-ils abordé cette transformation ? Eh bien, tout d'abord, ils ont lancé un projet de transformation d'un an et demi. Tu sens quelque chose ? C'est un peu mon genre d'humour, tu vois ? On veut devenir agile, et la toute première chose qui nous vient à l'esprit, c'est de définir en mode cascade comment on va devenir agile. Je ne suis pas sûr que ce soit la meilleure façon de faire. Mais bon, OK, c'est comme ça qu'ils ont fait. Donc un plan de projet d'un an et demi pour devenir agile. Et l'une des toutes premières choses dans ce plan de projet, c'était, on parle ici de 600 personnes, donc pas énorme, mais quand même 600 personnes, c'est pas mal de monde. Ils ont dit : "Tous ces gens, eh bien, ils doivent recevoir une sorte de formation agile de base."

Je pense que tout le monde ici en a entendu parler, l'agilité, ce n'est pas tellement les pratiques. L'agilité, c'est bien plus l'état d'esprit. Tu y réfléchis ? C'est une question d'état d'esprit. Si seulement les gens ont le bon mindset, tout va bien. Donc ce n'est pas une question de pratiques. C'est une question d'état d'esprit. Et c'est ce qu'ils ont fait. Ils ont donc lancé ce programme d'une journée sur le mindset agile, où les 600 personnes sont passées en gros, et ensuite ils pouvaient cocher la case dans le plan projet "mindset agile établi". Bon, on peut se demander si ça marche comme ça, mais peut-être qu'il faut une formation de deux jours, non ? Donc voilà, c'est un truc de mindset. Quoi d'autre ? La réorganisation a été faite. Et qu'est-ce que ça veut dire ? Les gens ont été en gros jetés en l'air, ils ont atterri ailleurs dans l'organisation dans ces équipes produit transversales, et ensuite on a commencé en gros à implémenter l'agile équipe par équipe.

Donc les équipes Scrum ont eu leur formation Scrum, leur formation Product Owner, et les équipes Kanban, elles ont mis en place des systèmes et tout ça. Et bon, au début, tout ce processus était soutenu par 16 coaches externes, ce qui est cool quand tu diriges un cabinet de conseil. Je veux dire, tu peux vendre pas mal de jours comme ça. Mais quand tu regardes ce qui se passe ici, je veux dire, on parle de 600 personnes. Donc c'est vraiment... quand tu réfléchis à combien de formation et tout est nécessaire ici, tu as probablement vraiment besoin des 16 formateurs externes.

Quoi d'autre ? J'aime bien ça. Ils ont dit : "On doit développer des capacités internes." Donc ils ont formé 11 coaches internes, et l'idée c'était : "OK, on doit garder le savoir dans notre organisation", parce que, je veux dire, je l'ai vu tellement de fois, tant que les consultants externes sont là, tout va plus ou moins bien. Et quand les coaches et consultants externes s'en vont, beaucoup de gens pensent : "Enfin on peut revenir à la normale." Donc, bon, tu ne veux probablement pas revenir à la normale quand tu as investi autant d'argent qu'ils l'ont fait ici. Donc voilà, c'était le plan, plus ou moins. C'était quoi le rapport de statut ? Le rapport de statut après environ un an, ils ont rapporté que 80 % des équipes étaient complètement transformées. J'aime bien cette formulation, non ? Elles étaient complètement transformées. Donc qu'est-ce que ça veut dire que 80 % des équipes étaient complètement transformées ?

Eh bien, tu pourrais faire tout un tas de ces vérifications dans ta rétrospective de plan projet. On les a vues, leur support, bien sûr, les réunions standard, check, check, check. Il y avait une case appelée métriques. Et ils ont dit : "Oui, les équipes font des métriques, mais... OK, on coche la case, mais regardons les métriques. Je veux dire, c'est pour ça qu'on les a." Donc maintenant ça devient un peu intéressant. Voici donc ce qu'on appelle un graphique de vélocité de Sprint Scrum. Je vais te montrer ces graphiques de vélocité et de Lead Time un peu plus tard, et ce que tu vois ici, ce sont des tendances d'équipe. C'est donc un graphique de tendance et pas d'une seule équipe, mais de plusieurs équipes. Et l'idée c'est qu'on veut voir en général si on s'améliore ou pas. C'est une mesure du débit de la philosophie. En gros, ça veut dire combien une équipe livre.

Nous voyons donc l'axe du temps sur l'axe X, et sur l'axe Y nous voyons les points de story fictifs, je crois qu'on les appelle comme ça, de Scrum. C'est la vélocité. Et la tendance, c'est ce qu'ils s'attendaient à voir. Ils voulaient voir la vélocité augmenter naturellement. Au début, il n'y a peut-être pas beaucoup de vélocité, parce que tout est nouveau, tu sais, les équipes, elles doivent en quelque sorte apprendre comment tout ça fonctionne, mais ensuite ça doit définitivement monter. Super. C'est le résultat attendu. Le résultat réel ressemblait à ça. Donc, oui, ça s'est un peu amélioré, mais ensuite c'est redescendu. Ils se demandaient : "Qu'est-ce qui se passe ici ? Je ne suis pas sûr. Je veux dire, ce n'est pas ce qu'on attendait." Et bon, les premières voix, tu pouvais entendre les premières voix dans cette organisation, et elles disaient : "Eh bien, tu sais, on t'a toujours dit que Scrum ne fonctionne pas. C'est la preuve, non ? Kanban est bien meilleur que Scrum, non ?"

Donc, d'accord, si Kanban est meilleur que Scrum, alors jetons un coup d'œil aux diagrammes Kanban. C'est le diagramme de temps de cycle Kanban. Bon, le temps de cycle c'est essentiellement la vitesse, à quelle vitesse on livre ? C'est encore un diagramme de tendance de plusieurs équipes. On voit la tendance sur l'axe X, et sur l'axe Y la vitesse, à quelle vitesse ils sont. Et naturellement ils voulaient voir le temps de cycle baisser, non ? Et, eh bien, le résultat attendu, le résultat réel ressemblait à ça. Ils ont dit : "Bon, c'est un peu de la fantaisie. On peut dire que ça ne s'aggrave pas. Mais, bon, c'est assez difficile de dire que c'est bien meilleur." Donc ils étaient un peu agités. Ils se disaient : "D'accord, on ne sait pas ce qui se passe ici." C'est le problème avec ces diagrammes.

Le problème c'est qu'il est assez difficile de créer un diagramme quand c'est écrit, pas d'amélioration, parce qu'on parle de diagrammes d'équipes et on parle de diagrammes après une réorganisation. C'est-à-dire que ces équipes, elles n'existaient pas avant. Donc, d'accord, il y a eu cette réorganisation, maintenant tout est différent, en gros. Et je ne peux pas comparer, parce que les équipes n'existaient pas avant. Mais il y avait un diagramme qui existait en gros avant qu'ils deviennent agiles, et après qu'ils soient devenus agiles. Et c'est le time-to-market de leurs initiatives. Tu te souviens, c'est la raison pour laquelle ils ont tout fait, parce que le délai de mise sur le marché avait augmenté. Et ils ont mené des initiatives avant de devenir agiles. Et ils menaient ou mènent encore des initiatives après être devenus agiles.

Dépendances et interactions agiles

Le temps de mise sur le marché s'allongeait donc de plus en plus, et ils ont dit : "OK, on doit changer ça. On doit faire baisser cette courbe." C'était le résultat attendu. Mais le résultat réel ressemblait plutôt à ça. Et là, ça fait vraiment mal, parce que ce qu'on voit ici, ce n'est pas qu'on ne voit pas d'amélioration. C'est plutôt que ça empire. Donc ils ne sont pas devenus agiles, et ça leur prenait encore plus de temps pour arriver sur le marché. Et ils se sont demandé : "C'est quoi ce phénomène qui se passe ici ?" Je veux dire, ça n'avait aucun sens pour eux, pas vrai ? Et bon, ils m'ont entendu parler à la conférence quand j'abordais l'optimisation locale versus l'optimisation globale et ce genre de choses. Et ils ont dit : "Eh bien, peut-être que ça a un rapport avec ce dont tu parles."

Donc en gros, ils m'ont appelé et ont dit : "OK, tu peux venir jeter un œil ? On ne voit aucune amélioration ici. Peut-être que ça a un lien avec ce dont tu as parlé dans ta présentation à la conférence." J'ai dit : "Bien sûr. Je peux regarder ça." Ce que j'ai fait en gros, c'est que je suis allé chez eux et j'ai passé, je dirais, un jour et demi, presque deux jours avec eux. Et oui, j'étais en quelque sorte à la recherche des causes profondes. Et c'était plutôt cool parce que, tu sais, toutes les équipes, elles étaient agiles. Et ça veut dire... ou elles utilisaient une de ces méthodes supplémentaires. Et ça veut dire qu'il y avait beaucoup de visibilité. Donc en gros, je suis allé voir les équipes, parce que c'est là que l'agilité se passait dans cette organisation. Je suis allé vers les équipes et j'ai simplement engagé la conversation avec elles.

Et au début, j'ai parlé des dépendances et des interactions agiles. Donc quand j'ai discuté avec les équipes, voici la visualisation simplifiée que j'ai toujours vue ici, quelque chose comme les choses qu'on doit faire, comme le backlog. Colonne suivante, les trucs qu'on a déjà engagés. Développer, c'est on travaille dessus en ce moment. Et puis il y a la colonne done, une vue simplifiée d'un des tableaux d'équipe. Il y avait juste une chose, chaque équipe avait quelque chose comme ça sur son tableau, attente externe. Ça veut dire que cette équipe ne peut plus travailler sur cet élément de travail ici, parce qu'une autre équipe dans cette organisation doit travailler dessus. Donc c'est bloqué de cette perspective, et une autre équipe doit le débloquer. Donc, une dépendance, pas vrai ? Ce qui est intéressant, c'est que chaque équipe dans cette organisation, et vraiment à 100 %, chaque équipe avait ce problème d'attente externe. Et je me suis dit : "OK, qu'est-ce que ça veut dire ?"

Supposons vraiment que chaque équipe dans cette organisation ait une visualisation comme ça, ça voudrait dire qu'il y a quelque part un deuxième tableau dans cette organisation. Et si l'équipe numéro un rencontre cette dépendance ici, comme l'attente externe, ça veut dire que ça déclenche en quelque sorte une demande chez l'équipe numéro deux. Ils font une sorte de, je sais pas, planification magique, peu importe, et arrivent à la conclusion : "OK, commençons à travailler sur cet élément, et quand ils auront fini, ça veut dire qu'on a fini et l'équipe là-haut peut libérer cet élément." Donc c'est en gros ce qui se passe quand on voit ce problème d'attente externe. J'ai donc demandé aux équipes à quelle fréquence ça arrive. Et sur qui attendez-vous ? Pas juste une fois dans la vie, mais plutôt sur une base fréquente.

Et ce que j'ai fait, j'ai dessiné quelque chose comme un diagramme de dépendances, et ça ressemblait à ça. Il y a vraiment beaucoup de dépendances. Et je me suis dit : "C'est intéressant." Et tu vois, il n'y a que huit équipes ici. Donc dans la vraie vie, 600 personnes, tu peux imaginer que c'est énorme quand tu regardes ce diagramme de dépendances. La question est : pourquoi y a-t-il autant de dépendances ? Je veux dire, ils ont fait énormément de choses pour réduire ces dépendances. Rappelle-toi, ils forment des équipes pluridisciplinaires. Ils construisent des équipes pluridisciplinaires parce qu'on veut éliminer les dépendances. L'autre chose, c'est même d'avoir des équipes produit. C'est-à-dire qu'une équipe ne travaille que sur un seul produit. Ils ont donc fait énormément pour éliminer les dépendances, mais malgré tout, ils se retrouvent dans une situation comme celle-ci. La question est : pourquoi ?

Eh bien, il y a plusieurs raisons, trois raisons. Je pense que ce sont les trois principales raisons que j'ai identifiées. Raison numéro un : oui, c'est vrai. Une équipe ne travaille que sur un seul produit. C'est bien. Cependant, plusieurs équipes travaillent sur le même produit. Donc par exemple, cette équipe en haut ne travaille que sur le produit A, mais l'autre équipe et encore une autre équipe, elles travaillent aussi sur le produit A. Et, quelle surprise, il y a des dépendances, pas vrai ? Quoi d'autre ? Un autre problème, c'est que les produits ne sont pas complètement indépendants les uns des autres. C'est-à-dire que si tu changes quelque chose dans le produit A, tu dois aussi changer quelque chose dans le produit B et dans le produit C. On a donc énormément de dépendances au sein des produits ou entre les produits.

Et bon, au final on parle de 600 personnes. Personnellement, je n'ai jamais vu une organisation de plus de 30 personnes sans dépendances dans le travail intellectuel, pas vrai ? C'est donc tout à fait normal qu'on voie des dépendances ici. Et, eh bien, chaque fois que je pense aux dépendances, une image apparaît dans ma tête, une image d'un clavier. Imaginons que notre organisation soit un clavier, et qu'on soit dans le business de l'écriture. Ce qu'on fait, c'est qu'on écrit des lettres pour nos clients. Alors organisons notre organisation : équipe un, deux, trois, quatre, d'accord ? L'équipe un n'appuie que sur les touches numériques, l'équipe deux Q, W, E, R, l'équipe trois A, S, D, F et ainsi de suite. Et maintenant, imaginons que le client veuille qu'on écrive une lettre d'amour. Eh bien, on doit réfléchir à comment livrer cette lettre d'amour. Mais si tu es une organisation de 600 personnes, tu n'as pas que quatre équipes. Ton organisation ressemble probablement à ça.

Pour chaque fichue touche de ton clavier, il y a quelque part une équipe qui appuie sur cette touche. On a une équipe R, on a une équipe T, on a une équipe G, on a une équipe A, chaque organisation a besoin d'une équipe A, évidemment. Sinon, tu es carrément dans la mouise. Et maintenant, imaginons qu'on optimise toutes ces équipes. Et disons que ça marche. On a la meilleure équipe R de cette planète. On a la meilleure équipe V et la meilleure équipe S. Et quand l'équipe D commence à appuyer sur la touche D, de la fumée sort du clavier. Ils sont tout simplement fantastiques. On est la référence internationale quand il s'agit de taper sur le clavier, d'appuyer sur les touches du clavier. La question est : à quelle vitesse en plus peut-on livrer notre lettre d'amour ? Eh bien, peut-être pas tellement, pas vrai ?

La bonne équipe doit travailler sur les bonnes choses au bon moment

Le point est donc que, quand il s'agit d'utiliser le clavier, ce n'est pas si important que vous appuyiez sur chaque touche très rapidement, ce qui est beaucoup plus important, c'est que je m'assure que vous appuyez sur la bonne touche au bon moment. Si j'appuie sur la bonne touche au bon moment, je peux terminer ma lettre beaucoup, beaucoup plus vite. Et c'est pareil pour les organisations. C'est pareil pour les organisations. Ce n'est donc pas si important que chaque équipe travaille très, très vite. Ce qui est beaucoup plus important, c'est que nous nous assurions que la bonne équipe travaille sur les bonnes choses au bon moment. La bonne équipe doit travailler sur les bonnes choses au bon moment. C'est là que réside la performance organisationnelle.

Et maintenant, il y a un gars qui s'appelle Russell Ackoff. Russell Ackoff disait déjà 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 interrelations. Qu'est-ce que ça veut dire ? Eh bien, si on transpose ça dans notre monde actuel, on pourrait dire que l'agilité d'une organisation ne consiste pas à avoir, je ne sais pas, beaucoup d'équipes agiles. Une organisation agile, c'est plutôt qu'il y ait de vraies interactions entre les équipes. Nous devons donc rendre les interactions agiles et pas tellement les équipes, c'est là que se trouve l'agilité organisationnelle. Nous devons nous assurer que la bonne équipe travaille sur les bonnes choses au bon moment. Et c'est quelque chose qui n'était absolument pas sur le radar de cette organisation. Ils disaient : "Le Graal, c'est la cross-fonctionnalité. On doit casser ces silos fonctionnels, et tout ira bien."

Ne me comprenez pas mal. Je suis un grand fan des équipes cross-fonctionnelles. Mais le problème, c'est que ça ne suffit pas de casser les silos, les silos fonctionnels. Donc, ce que cette organisation a fait en gros, oui, ils ont cassé les silos fonctionnels, mais ils ont construit des silos cross-fonctionnels. Le point est donc que ce n'est pas si important de savoir quelle personne est dans quelle équipe. Ce qui est beaucoup plus important, c'est que nous percions des trous d'interaction entre les murs des équipes. Nous devons donc permettre à ces équipes d'interagir de manière agile. Et ça n'a pas du tout été fait dans cette organisation. Voilà donc le constat, numéro un, il n'y avait aucune interaction réelle. J'ai encore deux problèmes pour vous. Et après les problèmes, nous passerons à la phase de solution. Problème numéro un, pas d'interactions agiles. Passons au, disons, deuxième problème, la deuxième découverte.

Comme je l'ai déjà dit, j'ai parlé avec les équipes, et j'ai aussi parlé avec les équipes du flux. Qu'est-ce que ça veut dire ? Eh bien, regardons encore une fois le clavier. Voilà donc à quoi ressemblent ces tableaux. Et je me suis dit : "Okay, c'est intéressant. Donc vous développez, et après le développement, vous avez terminé. Ça veut dire que le client est totalement satisfait, tout est super." Ils ont dit : "Eh bien, ce n'est pas si simple. Après le développement, nous devons bien sûr intégrer ce que nous avons fait." Et moi : "Okay, cool. Pourquoi pas ?" Donc on construit une autre colonne. Je veux dire, on veut le rendre visible. C'est bien le but d'une visualisation, non ? Donc on a créé une colonne qui attend l'intégration. D'accord. Mais ensuite je me suis dit : "Okay, et quand l'intégration est terminée, alors c'est fini. Ça veut dire que le client est totalement satisfait."

Ils ont dit : "Non, pas tout à fait. Nous devons bien sûr encore faire quelques tests d'acceptation." J'ai dit : "Okay, intéressant. Donc, ajoutons une autre colonne. Donc, on attend les tests d'acceptation. Mais maintenant le client l'a accepté. Donc le client est totalement satisfait maintenant, c'est ça ?" Ils ont dit : "Non, il y a, vous savez, ces fenêtres de release, et ça doit rentrer dans une fenêtre de release, et ainsi de suite. Mais après ça, on a en quelque sorte terminé." J'ai dit : "Okay, c'est une bonne information, non ? On a maintenant un tableau avec quelques colonnes de plus." Donc il ne s'agit pas tellement de la visualisation. Il s'agit plus de ce qu'on peut apprendre de cette visualisation. Et quand je vois une visualisation comme celle-ci, je commence en quelque sorte à poser des questions comme : "Okay, on attend l'intégration ? Combien de temps ça prend ? Combien de temps ça prend ? Combien de temps ça prend ?"

Et, eh bien, dans ce cas particulier, la réponse était que l'intégration était faite mensuellement et les tests d'acceptation quatre fois par an, qui passaient par la release. On veut améliorer le time-to-market de nos projets. Je pense que j'ai quelques idées, non ? Mais bien sûr, je n'étais pas complètement satisfait ici, surtout dans le développement logiciel, on sait assez bien ce qu'on doit faire ici. Donc, il y a l'Intégration Continue, la Livraison Continue, le Déploiement Continu, le Continu Tout. J'ai aussi regardé l'avant du tableau. Je me suis dit : "Okay, voici le backlog. Ça veut donc dire qu'ici tu as ta vision, ton idée de produit, ta super idée de fonctionnalité, et tu commences à développer."

Et ils ont dit : "Non, non, non, ce n'est pas si simple. Vous savez, quand on parle du backlog ici, on parle du backlog de développement. Avant de commencer le développement, nous devons bien sûr faire quelques analyses." Je me suis dit : "Okay, pourquoi pas ? Je veux dire, c'est pour ça qu'on a construit ce tableau, non ? Donc ajoutons une autre colonne, comme les packages produit ici en haut, l'analyse et ensuite on est dans le backlog de développement, et ensuite on peut commencer. Ça veut donc dire qu'ici dans le Product Backlog, on a vraiment notre super idée." Et ils ont dit : "Non, en fait notre processus ressemble assez exactement à ça. On a une sorte de pool de nouvelles idées, et on fait une sorte de triage avec ces idées, puis on écrit un concept grossier. Ce concept grossier attend le comité de pilotage, puis on écrit un business case détaillé, qui à son tour attend l'approbation. Et maintenant on est enfin dans le Product Backlog. Et on peut commencer à analyser."

Je me suis dit : "Okay, intéressant, bien sûr. Et ce qui est cool, c'est que si on dézoome un peu, le processus ressemble à ça." Et j'ai pensé : "Okay, bien." Et encore une fois, comme avant, quand je vois quelque chose comme ça, le point est qu'on peut recommencer à poser des questions. Et la question était la même qu'avant, à quelle fréquence ça a lieu ? Et combien de temps faut-il attendre ? Et la réponse était que le triage est fait mensuellement, ce qui est plutôt rapide. Quatre fois par an, il y avait le comité de pilotage, qui approuvait en quelque sorte les business cases grossiers. Et une fois par an, les business cases détaillés étaient approuvés, une fois par an. On veut améliorer le time-to-market de nos projets. Je crois que j'ai identifié quelques leviers qu'on pourrait actionner. Eh bien, ils ont aussi eu une idée. Ils ont dit : "Développement, problème identifié. On a mis de la poussière de fée agile là-dedans et on est tellement agiles, c'est juste fantastique."

Eh bien, non, désolé de le dire. Je ne crois pas ça. Je veux dire, bien sûr on peut accélérer ça d'une certaine manière, mais au final on n'accomplit pas grand-chose quand il s'agit de livrer plus vite sur le marché. Je veux dire, c'est peut-être le développement logiciel agile. Très bien. Je n'ai pas de problème avec ça. Mais la Business Agility, ça n'a rien à voir avec la Business Agility. Cette entreprise X est sur le marché comme avant, donc il n'y a aucun changement du tout. Et c'est exactement le deuxième problème que j'ai découvert. Il n'y avait pas de capture ni de gestion de la chaîne de valeur.

Passons au troisième problème avant de nous tourner vers les solutions !

Alors, le problème, et j'ai encore un problème avant de passer aux solutions : nous pouvons parler un peu du portefeuille stratégique Agile. Avant de faire cela, revenons aux équipes, d'accord ? C'était donc l'un de ces tableaux d'équipe. Et ce que je pouvais voir sur ces tableaux, c'était quelque chose comme des chiffres dessus, des chiffres comme des limites WIP, je suppose. Vous avez tous déjà entendu parler des limites WIP, comme les limites de travail en cours. Cela signifie qu'ils ne peuvent commencer que deux éléments ici et qu'ils doivent terminer l'un de ces éléments avant de pouvoir en commencer un nouveau. C'est donc pour les équipes Kanban, mais il y avait aussi des équipes Scrum, peut-être que les équipes Scrum n'avaient pas cette limitation explicite. Mais les équipes Scrum, elles ont limité leur travail parce qu'elles travaillent avec des Sprints ou elles font des Sprints. Donc le Sprint est fondamentalement similaire à la limitation du travail en cours, parce que ce que tu fais, c'est simplement dire : "OK, je m'engage à livrer ces éléments dans les deux prochaines semaines. Je ne commence pas plus d'éléments tant que je n'ai pas livré ceux-ci, et ensuite nous pouvons commencer plus d'éléments." C'est donc aussi "arrêter de commencer, commencer à finir".

Je parle donc de créer du focus, parce que créer du focus c'est tout simplement génial. Il y a tellement de théorie derrière. Et il y a même une preuve mathématique, comme la loi de Little, que plus ou moins tout ce que tu peux lire ici est vrai. Donc, le coût de changement de contexte diminue, le temps de cycle diminue, le coût du retard diminue, ton système est stable, ce qui signifie que tu es prévisible. Il y a donc tellement de bonnes choses quand tu crées du focus dans ton organisation. Et, eh bien, il y a même une chose, le temps de cycle diminue et le délai de mise sur le marché diminue. Le point est donc que si tu crées du focus, tu deviens plus rapide, le délai de mise sur le marché raccourcit. Mais ce que nous avons vu maintenant dans cette organisation, c'est que le délai de mise sur le marché a en fait augmenté. Comment est-ce possible ? Je veux dire, il y a des preuves mathématiques que c'est correct.

Alors, ont-ils simplement falsifié la loi de Little ? Eh bien, non. Laisse-moi le formuler ainsi. Quand il s'agit de créer du focus, il y a, disons, des petits caractères. Et je pense que 99% des organisations n'ont jamais lu ces petits caractères. Voici donc les petits caractères, un peu plus grands. Le point est que ce n'est pas une question de se concentrer sur n'importe quel élément ou n'importe quelle entité dans ton organisation. Ce que tu dois faire, c'est te concentrer, tu dois créer du focus, tu dois limiter ces éléments de travail là où tu veux voir le bénéfice. Tu dois limiter ces éléments de travail là où tu veux voir le bénéfice. Qu'est-ce que ça signifie ? Eh bien, cette organisation travaillait sur des initiatives, d'accord ? Ce qu'ils faisaient, c'était de diviser les initiatives en Epics. Ensuite, ils ont divisé les Epics en stories et les stories non aimées en tâches. C'est comme ça qu'ils ont fait. Eh bien, nous devons nous améliorer.

Ce que nous voulons voir, c'est que nous voulons améliorer le délai de mise sur le marché de nos initiatives. Qu'est-ce que nous devons limiter ? Sur quoi devons-nous nous concentrer dans notre organisation ? Eh bien, comme je l'ai dit, les initiatives, bien sûr, donc nous devons nous assurer que la quantité, le nombre d'initiatives dans notre organisation est en quelque sorte limité. C'est ce que nous devons faire. Qu'ont-ils fait ? Eh bien, l'agilité était une affaire d'équipe. L'agilité n'était donc qu'une équipe et rien d'autre. Moi en tant qu'équipe, dans cette chaîne, qu'est-ce que je peux influencer ? Qu'est-ce que je peux réellement limiter ? Très probablement pas les initiatives. Très probablement pas les Epics. Donc ma sphère d'influence est quelque part ici, je peux probablement limiter les stories, je peux limiter les tâches. Et je pense que c'est exactement le problème. Et c'est exactement le problème que nous avons vu dans cette organisation.

N'attribue pas à la stratégie les choses que tu fais, mais fais uniquement ce que la stratégie te dit !

Le point est donc, ne soyez pas surpris si vous ne voyez pas l'amélioration que vous voulez voir. Vous devez donc vous concentrer sur ces éléments de travail où vous voulez voir l'amélioration. Et ce ne sont clairement pas des stories. Ce sont des initiatives. Et dans cette organisation, ils ont répliqué les équipes, ils ont leurs objectifs de sprint et tout est défendu, mais ils travaillaient toujours sur 1000 initiatives en parallèle. Donc, surprise, surprise, aucune des initiatives n'a été terminée plus rapidement. Ce n'est pas une bonne chose. Où pouvons-nous limiter ces initiatives ? Où pouvons-nous créer un focus sur ces initiatives ? Je dirais, quelque part dans un portfolio stratégique, quelque part là-haut, peu importe ce que là-haut signifie, mais c'est au-delà du niveau de l'équipe, n'est-ce pas ? Quand on parle de la stratégie et du portfolio stratégique, il y avait une autre chose qui était en quelque sorte intéressante dans cette organisation, à savoir le processus de développement de la stratégie.

Dans cette organisation, la stratégie était donc abordée d'une manière un peu intéressante. Disons-le comme ça. Donc, mettons une ligne du temps, d'accord ? Dans cette organisation, les gens travaillaient sur quelque chose. C'est bien. Je veux dire, c'est pour ça qu'ils sont payés. Et puis il y a eu cette annonce de stratégie. La stratégie a donc été en quelque sorte proclamée lors d'une... je ne sais pas, assemblée générale, super nourriture, boissons, tout ça. Et, oui, voilà toute la stratégie. Et la conséquence de l'annonce de la stratégie était que les gens travaillaient sur les mêmes choses. Donc, pas de grande différence, n'est-ce pas ? Et puis, plus tard dans l'année, ils ont en quelque sorte vu le signe de la fin de l'année. Et puis ils se sont dit : "OK, il y avait quelque chose avec la stratégie, quelque part au début de l'année." Et ce que vous pouviez observer dans cette organisation, de plus en plus de gens commençaient à créer de nouveaux documents PowerPoint comme strategyfulfillment.pptx.

Et ce qu'ils faisaient essentiellement, c'est qu'ils essayaient en quelque sorte d'aligner rétrospectivement toutes les choses sur lesquelles ils travaillaient avec la stratégie. Ils se disaient donc : "OK, j'ai travaillé sur ce projet. Ça rentre dans ce panier stratégique. J'ai travaillé là-dessus, ça rentre dans ce domaine stratégique." Ils essaient donc en quelque sorte de planifier à rebours et de justifier ça sur la base du travail stratégique qu'ils ont fait. Mais ce n'est pas le but de la stratégie. L'idée de la stratégie est que la stratégie détermine sur quoi nous travaillons. Ce n'est pas une méthode de justification, n'est-ce pas ? C'est donc une autre chose qui ressortait vraiment dans cette organisation. Et je parlerai un peu plus tard dans la solution de ce que nous avons fait à ce sujet. OK, c'était donc le problème numéro trois, donc pas de véritable gestion de portfolio stratégique dans cette organisation.

Nous avons donc essentiellement parlé de ces trois problèmes, pas d'interactions réelles, la stratégie était bonne, la gestion de la stratégie n'était pas disponible, et pas de gestion de bout en bout du flux de valeur. C'étaient donc essentiellement les trois problèmes que j'ai découverts. Parlons des solutions. Eh bien, au final, les solutions n'étaient pas de la science spatiale. C'est la bonne nouvelle. Néanmoins, il a fallu un certain temps avant d'arriver à ce point où nous pouvions commencer à travailler sur les solutions. Mais quelles étaient les solutions ? Eh bien, premièrement, les interactions réelles entre les équipes. Vous vous souvenez, il y avait ce diagramme où nous avions toutes ces dépendances. Et, oui, qu'avons-nous fait ? Eh bien, ce que nous avons fait, c'est, vous vous souvenez, les dépendances étaient là parce que les équipes travaillaient sur un produit, mais plusieurs équipes travaillaient sur le même produit.

Nous avions donc encore beaucoup de dépendances. Ce que nous avons donc essentiellement fait, c'est partir du niveau de l'équipe et créer des tableaux produit. Qu'est-ce que ça signifie ? Nous avons essentiellement identifié quelle équipe travaille sur quel produit. Disons donc que ces trois équipes travaillent sur un produit. Ce que nous avons donc essentiellement fait, c'est enfermer les trois équipes en quelque sorte dans une salle, et nous aimerions créer une visualisation de la façon dont ils gèrent ensemble leur flux de travail. Et c'est ce que nous avons finalement fait pour tous les produits. Nous avons donc construit des tableaux produit. Le point est donc, nous avons arrêté d'optimiser les structures organisationnelles. Une équipe est une structure organisationnelle, moi en tant que client, je m'en fiche si vous avez des compositions d'équipes ou quoi que ce soit, ça m'est égal, n'est-ce pas ? Donc nous avons arrêté de nous concentrer là-dessus et d'optimiser les structures organisationnelles. Ce que nous avons fait, c'est optimiser la livraison de valeur.

La valeur client se crée au niveau du produit

Le produit est quelque chose dont le client tire un certain bénéfice une fois qu'il est terminé. Et c'est ce que nous avons fait. Nous avons donc construit des tableaux de produit. Et devant les tableaux de produit, et c'est le plus important, les équipes se coordonnaient. Nous avions donc des stand-up meetings et des rétrospectives entre les équipes devant ce tableau. Et je pense que c'est aussi un point très important. L'essentiel, ce n'est pas vraiment le tableau. C'est bien plus le fait que les gens, les bonnes personnes aient la bonne conversation devant le tableau. L'interaction réelle est donc ce qui compte le plus. Et oui, ce que nous avons fait, ce sont des stand-up meetings de produit et des rétrospectives de produit. C'est-à-dire que les équipes envoyaient des représentants au stand-up meeting, à la rétrospective, ils avaient un stand-up meeting pour toutes les équipes, puis ils retournaient dans leur équipe et avaient un stand-up meeting en équipe. Oui, c'est une chose.

Quand on fait ce genre de chose, le nombre de dépendances diminue, n'est-ce pas ? Mais il restait toujours quelques dépendances. Ces dépendances sont donc maintenant gérées au sein du produit. Mais n'oubliez pas, il y avait toujours cette situation où si vous changiez quelque chose dans le produit deux, vous deviez changer quelque chose dans le produit un. Nous avions donc des dépendances entre les produits. Qu'avons-nous fait pour surmonter cela ? Eh bien, nous avons construit ce que j'appellerais aujourd'hui un portfolio opérationnel. Portfolio opérationnel signifie essentiellement que nous avons identifié d'une certaine manière les produits et services où il y a beaucoup de dépendances. Et nous avons regroupé ces tableaux et créé un autre tableau dans lequel nous pouvons gérer ces dépendances à travers les produits.

Voici par exemple juste une illustration. C'est le produit un, produit deux, produit trois, tous ces produits se trouvent sur le même tableau, et maintenant des représentants des différents produits participent à notre stand-up meeting, participent à notre rétrospective, et nous pouvons coordonner le travail à travers les produits. Donc encore une fois, ce n'est pas vraiment le tableau qui compte. C'est plutôt l'interaction qui se passe devant le tableau. Oui, et c'est essentiellement ce que nous avons fait pour surmonter le problème de ces dépendances. Nous nous sommes donc détachés de la structure organisationnelle et nous nous sommes concentrés sur ce qui est intéressant pour le client, à savoir la création de valeur, dans ce cas c'étaient des produits et des tableaux où nous pouvions gérer les dépendances et tout le reste à travers les produits, à travers les équipes, point numéro un.

Qu'avons-nous fait ? Quelle était la solution pour le point numéro deux ? Tu te souviens, c'était ce tableau immense, ce processus gigantesque qui devenait de plus en plus grand. Eh bien, la solution est simple. Quand je te la présente comme ça. Mais au final, nous avons parlé d'un an et demi, presque deux ans de processus de changement pour en arriver là. Donc, la solution ressemble finalement à ceci. Nous avons en quelque sorte simplifié l'upstream. Souviens-toi que nous n'avons pas autant d'étapes ici avant que les gens commencent réellement le travail proprement dit. Nous n'avons donc plus qu'un concept approximatif qui attend la validation. Et, oui, nous pouvons déjà commencer à travailler. Et nous avons embarqué le business. Qu'est-ce que ça signifie quand je dis que nous avons embarqué le business ? Eh bien, c'était une organisation assez traditionnelle, et ils fonctionnaient vraiment en silo, genre, il y a le business et il y a l'IT. Et du point de vue du business, l'IT n'est qu'un centre de coûts.

Donc il vaut mieux ne pas parler à ces gens-là. Le vrai défi était donc de les réunir d'une manière ou d'une autre pour que nous puissions gérer l'ensemble de la chaîne de valeur. Et ce que nous avons aussi fait, tu te souviens, ce processus d'approbation n'était déclenché qu'une fois par an, nous l'avons réduit à toutes les deux semaines, toutes les deux semaines, nous pouvions commencer un nouveau travail. Normalement, commencer un nouveau travail n'est pas un gros problème dans les organisations. Mais le point est que nous avons limité le travail en cours ici. Nous ne pouvions donc commencer un nouveau travail que lorsque le travail en cours était terminé. Et là aussi, nous avons établi de véritables interactions, c'est-à-dire que nous avons organisé des stand-up meetings et des rétrospectives et nous y avons invité le business. Nous n'avons donc pas inventé de nouvelles réunions, les réunions existaient déjà, mais le business en faisait partie.

D'accord, j'ai encore une solution et ensuite j'aurai terminé. Alors, qu'avons-nous fait avec la stratégie ? Eh bien, tu te souviens, c'était ce processus de mapping étrange, orienté vers le passé. Donc, la première étape que nous avons essayé d'établir, un processus de mapping vers l'avant. C'est-à-dire qu'il y avait une stratégie. Et sur la base de la stratégie, ce que nous avons fait, c'est que nous avons dérivé des résultats et des actions de la stratégie. C'est-à-dire que la stratégie déclenchait essentiellement une conversation : Qu'est-ce que nous voulons atteindre ? Et que devons-nous faire pour y arriver, n'est-ce pas ? Cela a donc été dérivé de la stratégie. Ensuite, nous avons mesuré les résultats pour vérifier que nous avions atteint ce que nous voulions atteindre. Et cela a bien sûr déclenché le processus d'apprentissage qui a affiné la stratégie. C'était donc la façon de penser. Et en gros, nous avons en quelque sorte cartographié tout cela sur un tableau. Et c'était notre tableau stratégique. Nous avons donc ces points stratégiques, n'est-ce pas ? Genre, tu sais, sur trois à cinq ans, comme la digitalisation et certains sujets culturels, et ainsi de suite.

Et ce que nous avons fait, nous avons essentiellement défini des résultats, ce que nous voulons atteindre dans l'année. Nous avons donc rétréci l'entonnoir. Ensuite, quand nous avons ces résultats pour une année, nous sommes allés encore plus loin, genre, et qu'est-ce que cela signifie pour les 90 prochains jours ? Nous avons donc des résultats mesurables pour les 90 prochains jours. Nous avons donc créé un focus sur l'axe temporel, 3 à 5 ans, 1 an, 90 jours. Il faut donc vraiment se concentrer là-dessus. C'est assez difficile de prioriser des projets de cinq ans. Ce projet de cinq ans est-il plus important que l'autre ? Eh bien, je ne sais pas. Nous devons tous les terminer d'ici cinq ans. Mais si on resserre un peu, on peut créer un focus. Et si nous avions quelque chose comme ça, nous en dériverions des actions. Et quand je vois quelque chose comme ça, je vois déjà le tableau stratégique. Au final, c'est tout simple. Il suffit d'ajouter quelques lignes et d'en supprimer quelques autres. Et c'était plus ou moins le tableau stratégique avec lequel nous avons commencé à travailler.

Nous avons donc ici nos résultats, les résultats annuels, et nous avons une échelle de 0% à 100% où nous pouvons voir si nous progressons. Et ici nous avons juste une version très simplifiée du tableau, d'un tableau, des actions et c'est ce que nous faisons. Et le point est que nous avons créé le focus ici. Cela signifie donc que nous avons créé le focus en resserrant l'entonnoir temporel, et ensuite nous avons tous besoin des bonnes actions concrètes qui produisent vraiment des résultats dans les 90 prochains jours. C'était le tableau stratégique. Et bien sûr, avec un tel tableau stratégique, nous avons aussi organisé des stand-up meetings. Et nous avons aussi fait des rétrospectives sur ce tableau. C'étaient donc essentiellement les trois problèmes et les solutions que nous avons trouvées. Et nous allons en quelque sorte réfléchir à ce que nous avons fait. Une chose a été... une chose... j'entends des voix, je ne sais pas si c'est le bon moment.

Une chose, si je tire une conclusion, c'est que, eh bien, la Business Agility n'est définitivement pas un sport d'équipe. Quand il s'agit de Business Agility, c'est un sport d'entreprise, il faut vraiment penser à toute l'entreprise. Et Sohrab a déjà parlé des Flight Levels. Et je te donne encore une minute parce que je pense que si nous parlons de sport d'entreprise, qu'est-ce que cela signifie ? Donc où dans une organisation pouvons-nous faire des améliorations ? Où devons-nous devenir agiles ? Et c'est exactement de cela qu'il s'agit avec les Flight Levels. Pour moi, Flight Levels est un modèle de pensée qui m'aide à comprendre où dans une organisation je dois faire quoi pour atteindre ce que je veux atteindre. Flight Levels est donc un terme de l'aviation, on peut voler bas, ou on peut voler très haut. Selon le niveau auquel on vole, on voit des choses différentes. Nous pouvons voler très bas dans une organisation.

Adapte toujours ton niveau de vue d'ensemble !

Quand nous volons bas dans une organisation, nous nous trouvons au Flight Level One, et le Flight Level One est le niveau opérationnel. Les équipes, les équipes qui font vraiment le travail, nous pouvons rendre nos équipes agiles. Normalement, une organisation a plus d'une seule équipe, donc nous voyons plusieurs systèmes Flight Level One dans une organisation. Ce que nous voyons aussi très souvent, c'est qu'une équipe seule n'est pas capable de livrer au marché. Nous avons donc besoin d'une coordination entre plusieurs équipes pour livrer au marché. Cela signifie que nous devons voler un peu plus haut. Quand nous volons un peu plus haut, c'est le Flight Level Two, la coordination de bout en bout. C'est donc le monde des produits, des services, et ainsi de suite. Ce que nous allons faire, ou ce que nous faisons ici, c'est que nous nous assurons que la bonne équipe travaille sur les bonnes choses au bon moment. Ainsi, nous pouvons connecter le Flight Level Two au Flight Level One. Le travail opérationnel se fait au Flight Level One. Et ici, nous coordonnons simplement pour que la bonne équipe travaille sur les bonnes choses au bon moment.

Et ce qui est génial avec ça, c'est que du point de vue du Flight Level Two, peu m'importe quelles méthodes sont utilisées dans les équipes. Donc les équipes pourraient travailler avec, je ne sais pas, avec Scrum ou les équipes pourraient travailler avec Kanban ou les équipes pourraient simplement travailler, ça va aussi, n'est-ce pas ? Assure-toi simplement que la bonne équipe travaille sur les bonnes choses au bon moment. Normalement, une organisation a plus d'un seul produit ou service, donc nous voyons plusieurs systèmes Flight Level Two dans une organisation. Si nous avons des dépendances entre ces systèmes Flight Level Two, nous pouvons construire un portfolio opérationnel. Mais c'est toujours un système Flight Level Two, parce que nous coordonnons le travail à travers plusieurs produits ou services. Et nous pouvons même voler encore un niveau plus haut, et c'est le niveau stratégique.

L'idée du niveau stratégique est d'aligner le travail dans notre organisation sur la stratégie, que nous mettons également en focus ici au niveau stratégique. Bien sûr, nous pouvons connecter le Flight Level Three au Flight Level Two, et aussi le Flight Level Three au Flight Level One. Et la plupart du temps, nous n'avons pas qu'un seul board stratégique dans une organisation, mais nous avons plusieurs boards stratégiques dans une organisation. Oui. Et voilà essentiellement les Flight Levels. Et une chose est importante ici, il ne s'agit pas de mieux ou moins bien. Le Flight Level Three n'est donc pas trois fois meilleur que le Flight Level One, il résout un problème différent, n'est-ce pas ? Si tes équipes ne livrent pas, tu peux prendre les meilleures décisions ici en haut et créer le focus et tout au Flight Level Three, les choses ne seront quand même pas livrées, n'est-ce pas ? Il ne s'agit donc pas de mieux ou moins bien, il s'agit de trouver les bons leviers à actionner dans ton organisation.

Et c'est essentiellement tout. Si tu t'intéresses à plus de choses sur les Flight Levels, nous avons un stand ici, Catherine, Cliff et moi serons là-bas un peu plus tard. Et nous avons bien sûr aussi des workshops auxquels tu peux participer. Si tu vas sur flightlevelsacademy.com, tu verras la liste de tous les workshops ou la liste des workshops. Et ce que nous faisons, c'est que nous parlons essentiellement de ce dont j'ai parlé dans cette présentation. Voilà. Merci de ton attention.

Sociocratie 3.0

=> James Priest & Jeff Cumps parlent de [Sociocratie 3.0](/fr/developpement-organisationnel/sociocracy-3-0-james-priest-jeff-cumps/ "Sociocratie 3.0)

Le ministère agile

=> À quel point les ministères allemands sont-ils agiles ? - Une interview avec Sebnem Andresen.

L'avantage des entreprises qui expérimentent

=> Apprends ce qui se passe quand ton entreprise expérimente !