Matthias Patzak - Portofolio Kanban, The Art of Being Loosely Coupled and Highly Aligned

[00:00:03] Bonjour à tous. Je suis Matthias Patzak. Je suis stratège d'entreprise chez AWS. Personne ne sait vraiment ce qu'est un stratège d'entreprise.
[00:00:10] Nous sommes d'anciens clients et nous partageons avec les clients actuels notre expérience en matière de transformation lean, agile et cloud. J'étais CTO d'Auto Scout 24. Je suis aussi un coach d'entreprise. Parfois, dans ma carrière, j'ai obtenu cette certification, également un formateur certifié au niveau du vol.
[00:00:32] pour ce que ça vaut. Mais en fait, aujourd'hui, je parle de portefeuille Kanban lâchement couplé et hautement aligné.
[00:00:41] Et j'utilise le mot portefeuille Kanban tel qu'il est utilisé dans Kanban, mais en fait, je ne partage pas la ligne directrice officielle. Je partage mon expérience en tant que CTO d'une place de marché européenne allemande de taille moyenne, comment nous gérons toute l'entreprise avec Kanban au niveau de l'entreprise.
[00:01:04] Et nous l'avons fait parce que nous avons commencé à adopter l'agilité en 2008. Et ce que je constate chez de nombreux clients AWS, mais aussi chez des personnes et des entreprises de la communauté, c'est que parfois ils ne savent pas clairement pourquoi ils introduisent certaines techniques et certaines méthodes. Et c'est pourquoi je voulais commencer par 'pourquoi'.
[00:01:27] Et pourquoi avoir un portefeuille Kanban, pourquoi avoir du lean, de l'agile, du DevOps, du cloud dans votre organisation. Et de mon point de vue, je veux citer le manifeste Agile. Notre priorité absolue est de satisfaire le client par la livraison précoce et continue de logiciels de valeur.
[00:01:49] Ou pour le dire plus simplement, et ce qui est également énoncé dans le manifeste Agile, la mesure principale du progrès est un logiciel fonctionnel. C'était vrai il y a 20 ans. De mon point de vue, la mesure principale du succès pour toute organisation de développement de logiciels de produits est la satisfaction des clients. Et si vous voulez introduire une méthodologie ou une technologie dans votre organisation et que vous voulez convaincre votre direction ou vos leaders, aucun fondateur, aucun investisseur, aucun PDG ne voudra jamais parler d'un mot de passe technique Lean Agile. Ils ne sont pas intéressés par Dynamo DB. Ils ne sont pas intéressés par le serverless. Ils ne sont pas intéressés par Kanban. Alors, quel est leur langage ?
[00:02:37] Quelle est la principale préoccupation de tout CXO ? La première chose est le résultat. Ce n'est pas le rendement, combien de fonctionnalités vous livrez. C'est le résultat, en fait, c'est la valeur commerciale. La deuxième chose est la vitesse. À quelle vitesse votre organisation technologique livre-t-elle ces résultats à vos clients ? La troisième chose est la qualité. En fait, la plupart du temps, la qualité n'est intéressante que lorsqu'elle fait défaut. Alors, travaillez avec soin pour que la qualité ne manque pas. Ils sont également intéressés par l'attraction et la rétention des talents, donc la motivation est très importante dans votre organisation, et ils sont toujours importants pour la croissance. Quand j'ai obtenu mon premier poste de CTO, le PDG m'a dit : ce que je veux de vous – et j'étais, c'était une startup allemande – je veux de la scalabilité. La scalabilité pour mon entreprise, la scalabilité pour mon organisation.
[00:03:33] Ainsi, en tant que CTO, en tant que leader dans n'importe quelle organisation, et de mon point de vue, toute personne qui veut impulser le changement est un leader. Vous devez combiner les personnes, les processus et la technologie pour livrer de la valeur commerciale. C'est toujours interconnecté. Il ne s'agit pas seulement des personnes et de la culture, il ne s'agit pas seulement des méthodes de travail, il ne s'agit pas seulement de la technologie. Et pour offrir de la valeur commerciale, la communauté technologique s'est manifestée.
[00:04:00] Je voulais juste dire il y a 20 ans, mais ce n'est pas vrai. J'ai commencé à lire des livres sur l'effet, même si c'était agile dans les années 90, avec les livres de Tom De Marco par exemple, 'Peopleware' ou ses autres livres. Mais l'ingrédient secret de plus que tout pour livrer rapidement et de manière fiable est l'autonomie. Nous avons donc poussé l'autonomie comme ingrédient secret dans notre modèle opérationnel pour devenir plus rapides.
[00:04:32] Et en fait, nous parlons de l'autonomie des équipes. Et de mon point de vue, d'après mon expérience, et j'aurais adoré en discuter avec vous en personne, la plus petite cellule de votre organisation, ce sont vos équipes. Et chez Amazon, nous les appelons les équipes de deux pizzas. Et l'équipe de deux pizzas est notre indicateur de taille parce que nous disons qu'aucune équipe ne devrait être plus grande que ce que vous pouvez nourrir avec deux pizzas de taille américaine. Et j'ai ajouté mes définitions, mes caractéristiques à cette plus petite cellule, à cette équipe, à cette charge. Ce qui est important, c'est d'avoir des membres d'équipe dédiés.
[00:05:14] Aucun membre de l'équipe ne travaille sur quoi que ce soit en dehors de l'équipe. Ils sont uniquement dédiés à l'équipe et cette équipe a une responsabilité dédiée pour un certain domaine de votre chaîne de valeur de votre produit.
[00:05:28] La deuxième chose, les membres de l'équipe possèdent toutes les compétences transfonctionnelles nécessaires pour livrer un résultat de l'idée à l'impact. Non pas que notre équipe s'est engagée à faire quelque chose dans notre backlog et l'a ensuite livré à l'assurance qualité. C'est de l'idée à l'impact. Du point de vue de la taille, les topologies d'équipe recommandent 5 à 9 personnes, d'après mon expérience, 5 à 11 peuvent aussi fonctionner. Et je préférerais avoir une équipe plus grande mais ne pas avoir tous les rôles dans l'équipe dont vous avez vraiment besoin pour livrer de l'idée à l'impact. Les personnes que vous avez dans votre équipe doivent être en forme de T. Elles doivent donc avoir une expérience très approfondie dans une certaine compétence. Mais ils devraient également être capables de travailler sur tout ce qui est nécessaire dans votre équipe et ce qui est actuellement la priorité absolue de votre backlog. Parce que – et c'est le point numéro huit – l'efficacité, travailler sur les bonnes choses est bien plus important que l'efficience. Et avec des personnes en forme de T, vous pouvez tout mettre, avec le dicton 'tous sur le pont', sur l'élément le plus important de votre backlog. Les équipes sont auto-organisées et autonomes, bien sûr, dans les limites des compétences qu'elles possèdent actuellement et des limites de l'organisation plus large. Par exemple, votre micro-architecture et votre stack technologique.
[00:06:54] Une telle équipe devrait également avoir un équilibre sain entre les développeurs internes et externes. Chez Auto Scout, nous avions une répartition de 70/30. Nous disions que 70% du personnel devrait être interne, 30% externe.
[00:07:09] Vous pouvez avoir des équipes 100% internes, cela fonctionne assez bien avec des avantages et des inconvénients. Nous avons également géré certaines parties de l'organisation pendant un certain temps avec une répartition 50/50 car nous n'étions pas en mesure d'embaucher aussi rapidement que nous avions besoin de personnel. C'est un peu plus risqué, mais c'est également faisable. Vous avez également besoin d'un équilibre sain entre les juniors et les seniors. Toutes les organisations avec lesquelles je parle manquent de compétences. Et que font certaines organisations ? Elles vont dans les universités et embauchent des juniors. Mais qui devrait former les juniors ? Donc, avoir trop de juniors dans votre équipe n'est pas vraiment sain.
[00:07:46] Les équipes d'Auto Scout et des organisations modernes ont également appliqué la version la plus avancée de Kanban, qui est 'you build it, you run it'. Donc l'équipe, cette équipe cross-fonctionnelle, construit et gère les produits.
[00:08:01] Ce qui est également important, c'est que ces équipes mesurent certains critères : leur résultat, leur vitesse, à savoir le temps de cycle, le débit, leur qualité, leur motivation. Ils observent ce qui se passe dans le reste de l'organisation et ils réfléchissent à leur comportement, à leurs méthodes de travail et au résultat. Et ensuite, ils optimisent. Et ma méthode de travail préférée est Kanban pour faire bouger les choses.
[00:08:28] Nous avons donc une équipe de deux pizzas et cette équipe de deux pizzas est autonome.
[00:08:33] Mais en fait, de nombreuses cellules constituent une organisation.
[00:08:38] Et donc, dans cet exemple, nous avons l'équipe de paiement. C'est une organisation de commerce électronique, ils ont un site web et une application mobile pour acheter des vêtements ou des voitures. Mais chaque site web ou chaque organisation de commerce électronique a aussi un back-office, une organisation de traitement des commandes ou une organisation de vente au détail, l'organisation qui achète des matériaux, qui vend des matériaux, qui gère le stock, qui gère les retours. Vous aurez également des équipes dédiées à votre informatique d'entreprise, gérant vos ordinateurs portables, votre réseau de bureau, tous les autres systèmes que vous avez. L'organisation a également une petite organisation de données et une organisation pour l'infrastructure. Et bien sûr, nous avons un département marketing, un département juridique, un département financier, et nous avons la direction. Et la direction, dans mon exemple, a défini une étoile polaire.
[00:09:32] La direction, une vision et un objectif pour l'organisation, ce qui est important.
[00:09:38] Et maintenant, nous avons notre équipe de paiement autonome. Et l'équipe de paiement doit travailler sur une épopée. Et nous sommes une organisation de produits avancée et c'est juste leur épopée. Mais en fait, dans la plupart des organisations, même les plus agiles, ce n'est pas aussi facile que cela. Parce que l'équipe de paiement a besoin d'une autre équipe web.
[00:10:01] L'équipe web doit s'aligner et obtenir des fonctionnalités de l'équipe marketing, et comme le marketing n'est qu'un groupe de 27 personnes, ce n'est pas vraiment avec une structure et 157 outils de service logiciel, c'est plus compliqué d'interagir avec eux.
[00:10:16] L'équipe de paiement a également besoin de deux équipes de l'organisation de vente au détail et d'exécution des commandes. Une équipe de l'équipe de vente au détail a également besoin de conseils juridiques car nous modifions quelque chose dans les conditions générales. Et les autres équipes de vente au détail ont besoin d'une équipe de données. Cette équipe de données a besoin d'une autre équipe de données et parce qu'ils doivent changer quelque chose dans l'infrastructure, ils ont besoin d'une équipe d'infrastructure. Donc, juste pour cette seule épopée, nous avons une dépendance envers neuf autres équipes.
[00:10:45] Et les autres équipes, elles ont aussi leurs épopées. Et comme elles sont autonomes, chaque propriétaire de produit de ces équipes gère et maintient son propre backlog de produit, priorisé et probablement aligné avec le chef de produit ou même le PDG.
[00:11:11] Et en tant qu'organisation, vous devez trouver l'équilibre entre l'autonomie locale et la performance locale et la performance organisationnelle globale. Avec une autonomie croissante, la performance des équipes augmente, augmente, augmente et augmente. Et la performance de l'organisation fait de même. Donc, avec l'autonomie croissante des équipes et la performance des équipes, la performance de l'organisation augmente également. Mais il y a un certain point, il y a un juste milieu dans toute organisation où, avec une autonomie croissante – et nous pourrions alors parler d'anarchie – des équipes locales, la performance de l'organisation diminue. Et en tant qu'organisation, vous devez trouver le juste milieu entre l'intérêt individuel des cellules des équipes de votre organisation. Et c'est là et pourquoi nous appliquons le Kanban de portefeuille.
[00:12:09] Mais il s'agit aussi de – je voulais juste dire chaque organisation, mais la plupart des organisations ont un défi majeur qu'elles doivent relever et maîtriser pour vraiment avoir une croissance non linéaire.
[00:12:29] Beaucoup d'organisations n'ont pas vraiment ce défi majeur, alors il s'agit juste d'opérations continues, mais si vous voulez vraiment croître de manière exceptionnelle, vous devez surmonter un défi majeur. Et vous ne pouvez pas surmonter votre défi stratégique majeur si vous n'êtes pas capable de concentrer et d'aligner tout le monde dans la bonne direction. Et donc, pour faire de grandes choses dans votre organisation, vous devez d'une manière ou d'une autre aligner, orchestrer et coordonner le travail, pas le travailleur en fait, mais vous devez coordonner le travailleur.
[00:13:10] Et c'est un très vieux diagramme que j'ai tiré d'une discussion sur le modèle Spotify, mais il explique très bien ce que nous voulons atteindre. Et c'est une matrice deux par deux, sur un axe nous avons l'autonomie et sur l'autre nous avons l'alignement. Et j'ai vu de nombreuses organisations, en particulier les entreprises traditionnelles qui sont passées à l'agile, elles ont beaucoup misé sur l'autonomie. Mais avec l'autonomie sans alignement, vos équipes sont rapides, mais elles courent dans toutes les directions.
[00:13:41] D'un autre côté, les organisations traditionnelles ont très souvent une faible autonomie dans leur modèle opérationnel, mais un alignement élevé avec beaucoup de règles et beaucoup de gouvernance. Ils courent dans la même direction, ce qui est bien, mais ils sont super lents. Donc, en fait, ils ne vont nulle part. Ce que nous voulons atteindre, c'est que tout le monde coure dans la même direction du point de vue de l'exécution de la stratégie.
[00:14:07] Et donc nous devons offrir de l'autonomie en même temps, mais nous devons offrir de l'alignement. Et un faible alignement et une faible autonomie, c'est ce que personne ne veut.
[00:14:17] Et si je devais fournir un visuel pour 'lâchement couplé et hautement aligné', ce serait cela. J'aurais aimé trouver une visualisation avec une photo avec juste des vedettes rapides et non des pétroliers, mais ce sont des pétroliers rapides. Et ils sont alignés, mais néanmoins chacun de ces pétroliers est autorisé à choisir sa propre route et son propre parcours et à embaucher ses propres talents. mais néanmoins, ils sont alignés.
[00:14:48] Alors, comment créez-vous cet alignement dans une organisation ?
[00:14:53] Et le logiciel, c'est de l'ingénierie humaine. Tout tourne autour des gens. Et comment rassembler les gens dans une organisation ? Le feu de camp rassemble les gens. Vous rassemblez les gens dans un lieu commun et vous offrez un endroit où ces personnes peuvent co-créer, communiquer et collaborer.
[00:15:12] Que sont les feux de camp dans une organisation agile ?
[00:15:17] Les meilleurs feux de camp que j'ai vus sont des tableaux Kanban physiques. Et ceci est un brouillon dont je parlerai plus tard, à propos du tableau Kanban que nous avons utilisé chez Auto Scout pendant une longue période pour vraiment diriger notre organisation.
[00:15:39] Donc, je parlais de Kanban et ce que Klaus Leopold a fait – et je partagerai un lien vers son livre plus tard – c'est qu'il a appliqué le Kanban d'un point de vue théorique et méthodologique au contexte plus large de l'organisation. Et il parle de trois niveaux de vol. Et le niveau de vol numéro un, c'est là où la plupart d'entre nous appliquent des pratiques Lean, Agile, Scrum, Kanban depuis plusieurs années. C'est le niveau de l'équipe opérationnelle où les équipes de livraison gèrent leur travail quotidien. Et dans les niveaux de vol, en fait, peu importe si les équipes font du Scrum, du Kanban ou du Waterfall. Et c'est également vrai chez Amazon.
[00:16:19] Alors, quand j'ai rejoint Amazon il y a quatre ans, j'étais vraiment curieux de savoir quel était le processus réel de développement logiciel d'Amazon. Et puis j'ai essayé de le trouver. Et il n'y en a pas un seul.
[00:16:31] Quelle que soit la méthodologie que vous trouvez, une équipe chez Amazon l'utilise. Plus probablement 57 ou 157 autres méthodologies qu'ils ont inventées eux-mêmes. Donc au niveau du vol, il est tout à fait acceptable d'avoir toutes les méthodes qui fonctionnent pour l'équipe.
[00:16:49] Le niveau de vol deux, c'est la coordination. C'est là que les organisations coordonnent les équipes de l'idée à l'impact. Il s'agit simplement de gérer leurs dépendances. Nous avons des dépendances. Nous devons réduire les dépendances autant que possible, mais nous ne pouvons pas arriver à zéro dépendance. Nous devons donc coordonner et aligner.
[00:17:10] Le niveau de vol trois est le portefeuille stratégique. C'est la vue d'ensemble depuis l'espace sur la Terre où vous voyez votre paysage stratégique avec une carte. C'est là que le mapping peut aider. Et c'est là que les équipes de direction concrétisent la stratégie.
[00:17:27] Élaborer une stratégie est super facile, vous engagez simplement un McKinsey ou vous partez en séminaire et vous revenez avec 150 diapositives PowerPoint. Mais exécuter la stratégie dans une grande organisation, c'est vraiment difficile.
[00:17:42] J'ai donc présenté cette organisation exemple, et c'est une organisation assez simple, c'est juste 30 équipes, probablement 200 et 300 personnes. Et la question est de savoir qui doit participer au feu de camp ?
[00:17:59] Et donc, tout le monde ne peut pas participer, ils doivent donc envoyer des délégués. Je préférerais avoir des délégués transfonctionnels. Très souvent, quand je demande aux organisations qui seraient les délégués, la première réponse est 'les gens du business'. Oui, mais que se passe-t-il si vous voulez discuter de problèmes techniques ? Vous devez donc avoir des délégués transfonctionnels. Ils doivent avoir une vue d'ensemble généraliste. Ils doivent être expérimentés, donc des seniors, des experts en la matière ou des leaders seniors dans votre organisation. Et vous devez avoir une perspective diverse chez les personnes qui participent au feu de camp. Parce que vous voulez avoir des discussions saines et des conflits sains pour vraiment exécuter rapidement votre stratégie. et des délégués. Je préférerais avoir des délégués transfonctionnels. Très souvent, quand je demande aux organisations qui seraient les délégués, la première réponse est : les gens du métier. Oui, mais si nous voulons discuter de questions techniques ? Donc, vous devez avoir des délégués transfonctionnels. Ils doivent avoir une vue d'ensemble généraliste. Ils doivent être expérimentés, donc des experts seniors dans leur domaine ou des leaders seniors dans votre organisation, et vous devez avoir une perspective diverse. parmi les personnes qui assistent au feu de camp, parce que vous voulez avoir des discussions saines et des conflits sains pour vraiment exécuter rapidement votre stratégie.
[00:18:48] Et comme je l'ai dit, le cœur de toute stratégie est de relever des défis à enjeux élevés. Et c'est pourquoi il est important que vous ayez les bonnes personnes autour de ce feu de camp et que ces personnes soient capables de prendre des décisions. Donc, la variante numéro un est d'envoyer un délégué de chaque équipe. Dans mon organisation ou dans l'exemple d'organisation, nous aurions 30 à 40 personnes présentes à une réunion de contrôle hebdomadaire ou à une réunion stratégique trimestrielle. 30 à 40 personnes sur une organisation de 200 à 300 personnes, c'est faisable, mais très inefficace.
[00:19:29] Donc, la variante deux serait d'envoyer des délégués de chaque domaine ou de chaque secteur. Cela ferait alors 30 personnes. Et avons-nous vraiment besoin de gens du marketing, du juridique, des finances ? Bien sûr, nous avons besoin de gens du leadership, mais de l'infrastructure et des autres, probablement pas. Ainsi, comme vous avez dans votre conception axée sur le domaine, un domaine principal et des domaines secondaires, il est tout à fait valable que vous disiez, lorsque vous amenez des gens au camp, que nous avons des domaines principaux et que ce sont des personnes qui doivent vraiment être présentes. avec des responsabilités et des autorités de décision, tandis que d'autres personnes autour de ce feu de camp sont juste là pour, oui, pour leur information. À notre scout, nous voulions avoir des délégués de chaque domaine. Et c'était probablement 20 personnes et nous étions une organisation plus grande, mais en fait, à cette réunion, 44 personnes se sont présentées.
[00:20:26] En moyenne, c'était un grand espace, car c'était l'endroit où nous prenions des décisions, où nous avions des discussions et où nous décidions ensuite. Ainsi, de nombreuses autres organisations étaient présentes, par exemple, le juridique et les finances, car elles disaient : oui, c'est là que vous prenez des décisions. Si nous voulons savoir ce que vous avez décidé concernant le changement de budget, l'échange de budget, c'est ici que nous le saurions. Donc, envoyer des délégués est une bonne, bonne idée, mais un délégué de chaque domaine n'est pas vraiment transfonctionnel. Donc, une autre variante serait d'envoyer des personnes de l'IT et du produit. Donc, vous envoyez toujours quelques personnes de vos domaines principaux. Cela ferait alors 18 personnes. Et tous n'auraient pas vraiment un rôle actif.
[00:21:12] Parce que seuls vos domaines principaux décideraient, débattraient et discuteraient, tandis que les domaines non principaux se contenteraient d'écouter. Et cette seconde variante pourrait également entraîner un Kanban de sous-portefeuille de niveau de vol deux, car les délégués que vous envoyez, ils doivent avoir les informations. Donc, vous vous retrouveriez avec un tableau Kanban au niveau de l'entreprise, que j'ai déjà montré et dans lequel je plongerai plus profondément dans quelques minutes. Mais pour obtenir de véritables informations sur ce qui se passe, les domaines principaux, le web, le commerce de détail, les autres, les données, l'infrastructure, ils gèrent leurs efforts avec des tableaux Kanban de niveau de vol deux.
[00:21:55] Lorsque vous introduisez un tel tableau Kanban et que vous commencez à en discuter, ne vous noyez pas dans un verre d'eau. Faites face à l'incertitude, ce n'est pas clair. Vous rassemblez les gens autour du feu de camp pour s'aligner et discuter. Mais observez, orientez, décidez et agissez dans la bonne direction, mais décidez vite et vous pouvez changer la direction que vous avez prise lors de ce feu de camp. Ce qui est important, c'est d'avoir une cadence. C'est comme le time boxing ou le sprint en Scrum. Mais vous avez une certaine cadence où vous avez une révision de stratégie. Parce que nous parlons de l'exécution de votre stratégie, vous devez donc revoir où vous en êtes dans l'exécution de votre stratégie. À notre scout, c'était un atelier de réunion d'un ou même deux jours tous les trimestres. Donc, nous y avons investi beaucoup de temps, mais pour nous, il est très important de discuter : où mettons-nous nos efforts pour exécuter la stratégie ? Et puis nous agissions juste dans la bonne direction. Mais pendant cette cadence trimestrielle, nous avions fait ce que nous appelions une revue des opérations. C'est ce qui, dans notre, dans une équipe Scrum ou une équipe Agile serait un quotidien, nous le faisions une fois par semaine, le mardi matin pendant une heure, les délégués du domaine se réunissaient et ils avaient leur revue des opérations. Et ainsi nous exécutions au niveau de l'entreprise sur une cadence hebdomadaire avec chaque décideur présent dans la salle.
[00:23:27] Ce que beaucoup d'organisations oublient, c'est ce que j'ai mentionné plusieurs fois : vous devez observer, décider et agir, elles manquent la réflexion. Donc, avant de commencer votre prochaine revue stratégique et d'agir dans la bonne direction, vous devez mener une rétrospective. Dans ces réunions, il est très important que ce ne soit pas seulement du partage de connaissances, ce n'est pas seulement discuter et nous, nous, quelqu'un décidera plus tard.
[00:24:00] Là, vous visualisez, vous décidez, vous agissez et le plus important est toujours dans le contexte du portefeuille global de votre travail. Si vous ne faites pas cela, qu'est-ce qui arrive régulièrement ? Donc, je me souviens très bien de l'époque avant que nous ayons ce Kanban de portefeuille, nous avions une réunion de direction le lundi et quelqu'un de l'organisation venait, avait 15 ou 30 minutes et proposait un nouveau projet. Et ils préparaient cette proposition pendant six semaines, ils avaient des diapositives très brillantes, très nettes et claires. Et en tant que manager, quand vous aviez cette présentation, vous n'aviez qu'à dire oui, c'est une excellente idée, nous allons le faire. Que se passe-t-il le mardi ? La personne suivante vient avec une idée. Fait sa présentation. Et en tant que manager, alors, quand c'est un cas valable, vous recommencez un nouveau travail. Avec Kanban et les niveaux de vol aux niveaux de l'entreprise et juste en prenant des décisions lors de cette réunion de revue stratégique, vous décidez toujours dans le contexte de votre portefeuille global. Et toutes les autres personnes qui ont un intérêt dans l'exécution de la stratégie sont également présentes. Donc, la personne qui veut présenter un projet et faire une présentation, ce n'est pas si facile de faire une présentation quand tout le monde est là. Et vous savez que si vous promettiez quelque chose qui n'est pas vraiment vrai, quelqu'un lèverait la main et dirait : oh, j'ai une préoccupation, je veux dire quelque chose. Et c'est pourquoi avoir cette réunion stratégique où vous décidez et où vous partagez dans le contexte du portefeuille est très important et cela réduit cette prise de décision rapide, réduit le temps de cycle au niveau stratégique. La question est : quel est le travail que vous gérez là-bas ? En fait, c'est à vous de voir.
[00:25:59] Vous pouvez décider quel type d'éléments de travail vous allez gérer là-bas. Vous voulez, absolument, gérer vos initiatives, les choses stratégiques vraiment importantes qui doivent se produire pour surmonter le défi à enjeux élevés. Donc, les initiatives et les épopées sont généralement des éléments de travail que vous voyez sur le tableau Kanban. Certaines organisations gèrent ou utilisent également ces tableaux Kanban pour les incidents majeurs, je préfère avoir un tableau d'incidents dédié dans une salle de guerre juste pour gérer les incidents. Ce que je recommande, mais c'est à vous de voir, c'est de gérer le développement de votre organisation et les grands changements qui nécessitent la capacité des équipes de direction ou ce que vous savez va ralentir toutes les autres initiatives, vous pourriez les gérer aussi dans une ligne dédiée. Ce que vous ne devriez pas gérer, ce sont les histoires, les parcs et les tâches. Si vous commencez à gérer ces petits éléments, ce serait excessif.
[00:27:00] La beauté des niveaux de vol et de Kanban au niveau de l'entreprise est que ce qui a fonctionné pour vos équipes pendant plus d'une décennie fonctionnera très probablement aussi pour l'entreprise. Et c'est pourquoi ce que j'ai aimé et ce qui était si facile pour nous, même si nous avions des défis avec les membres de l'équipe de direction qui n'étaient pas si impliqués dans notre façon de travailler auparavant. Mais ce que nous avons appris d'une perspective mécanique, d'une perspective de méthode, mais aussi d'une perspective psychologique et comment faciliter les réunions, comment diriger les réunions, comment convaincre les gens, tout cela a très bien fonctionné aussi au niveau de l'entreprise. Alors, prenez simplement votre guide Kanban, prenez vos apprentissages Kanban, prenez vos coachs Kanban et appliquez avec prudence l'apprentissage que nous avons fait en tant que communauté pendant plus d'une décennie au niveau de l'entreprise.
[00:28:00] Donc, maintenant je vais approfondir le tableau Kanban d'entreprise que j'ai proposé. Alors, il y avait juste cinq colonnes que nous utilisions.
[00:28:12] Je fais régulièrement des revues avec d'autres organisations et j'ai eu une revue avec une banque et ils m'ont amené dans une pièce et c'était un mur de six mètres et ils avaient probablement 27, 27 colonnes allant de l'idée, au cas d'affaires, à l'architecture de solution, à la budgétisation, beaucoup de colonnes et d'étapes qui étaient nécessaires dans l'organisation. Nous avions un processus très simple et en aval, il commençait par l'idéation. Donc, quelqu'un essayant vraiment de comprendre l'idée, puis ayant une évaluation pour trouver l'adéquation produit-marché, puis cela est passé au développement. Et puis c'est quelque chose que nous avons proposé dans notre organisation et j'ai vu de plus en plus d'entreprises adopter qu'après le développement, la colonne suivante n'est pas
[00:28:58] Et c'est ce que vous voyez régulièrement, nous avons terminé, nous l'avons mis en production, nous l'avons livré à un client, et imaginez, nous l'avons livré. Oui, nous avons poussé, nous avons poussé une fonctionnalité à un client et nous ne nous soucions vraiment pas si le client peut l'utiliser. Donc, dans notre organisation et nous l'avons appris à la dure. en 2011, 2012, nous étions capables de publier 12 fois par jour sur notre base de données Oracle et notre centre de données sur site. Et nous venions d'une publication mensuelle, mais nos KPI n'ont pas changé. Donc, nous livrions des fonctionnalités, mais nous ne livrions pas de valeur. Et c'est, c'était aussi l'époque où le livre Lean Startup est sorti, où nous avons appliqué cette pensée de construire, mesurer, apprendre. Et donc, nous avons dit, non, non, après le développement, nous devons mesurer et nous devons nous adapter. Donc, nous avions tout testé A/B et ensuite nous avons adapté et optimisé en production. Et nous avions terminé quand nous avons dit, d'accord, nous avons atteint l'impact. Et nous avons appris que probablement seulement un tiers des fonctionnalités que nous avions soigneusement prototypées et imaginées apportaient réellement de la valeur commerciale. L'autre tiers n'a rien changé et l'autre tiers nuisait à d'autres KPIs.
[00:30:10] Et puis vous pouvez visualiser dans votre processus vos éléments de travail actuels et même avec cette visualisation, comme vous pouvez le faire avec une équipe Scrum ou avec une équipe Kanban. Juste en passant ce tableau Kanban d'entreprise, très souvent vous pouvez voir des problèmes dans votre, dans votre flux de travail.
[00:30:28] Ainsi, comme élément additionnel, nous avions que chaque colonne était une initiative stratégique. Et ces colonnes, chaque ligne était une initiative stratégique. Et ces lignes n'étaient pas ordonnées par ordre alphabétique ou par date, elles étaient ordonnées ou même classées par priorité. Ainsi, l'initiative la plus importante d'un point de vue stratégique était en haut et la moins importante était à la fin. Et cela a eu plusieurs effets, le plus important étant si quelqu'un attendait quelqu'un d'autre. Et cela arrive tout le temps, c'était un exercice assez facile. Nous sommes allés devant le tableau et avons demandé, d'accord, où est votre initiative et les gens montraient la ligne 14. Et puis j'ai dit, d'accord, et vous dépendez de quelle équipe, quelle initiative et puis ils ont pointé le numéro trois. Et j'ai dit, d'accord, c'est assez facile. Vous êtes 14, ils sont trois, donc vous attendez.
[00:31:22] Ce que vous pouvez aussi voir dans l'exemple que j'ai montré ici.
[00:31:29] Vous voyez que les priorités ici en bas, elles sont plus avancées que les initiatives les plus importantes ici. Ainsi, l'initiative prioritaire la plus importante de l'entreprise est juste en développement tandis que le numéro quatre est déjà en mesure et en adaptation et la même chose est vraie pour les autres. Et ce sont là quelques-uns des effets visuels que nous avons observés en utilisant ce tableau Kanban physique ; d'après mon expérience, la plupart des tableaux numériques cachent simplement cet effet.
[00:32:04] Ce que nous avions aussi sur nos tableaux était la stratégie de domaine. J'ai dit que chaque trimestre nous réfléchirions à la stratégie actuelle du domaine et si nous étions dans la bonne direction. Nous avions donc un document d'une page sur la stratégie de ce tableau, car dans certaines discussions, il était très facile d'aller à la diapositive PowerPoint de la stratégie de domaine et de dire : mais en fait, nous voulions atteindre ceci et cela, alors s'il vous plaît, arrêtez la discussion car nous avons décidé que c'était la stratégie. Et bien sûr, nous avions également des rapports de KPI et d'OKR sur le tableau.
[00:32:44] Si vous voulez diriger votre organisation dans une direction commune, il est important que vous fixiez un objectif audacieux de haut en bas qui inspire et force l'organisation à avancer plus vite qu'elle ne l'aurait fait organiquement. Et si vous demandez aux équipes de direction, elles diraient, bien sûr, nous avons de tels objectifs top-down et nous nous menons les organisations dans le domaine du véritable avantage concurrentiel. En fait, c'est très souvent faux. Et nous l'avons de nouveau appris à la dure, nous avons fait une fois un exercice de cartographie avec tous les éléments de notre portefeuille stratégique et nous avons hiérarchisé et cela a changé la façon dont nous hiérarchisions selon deux critères. L'un des critères avec lequel de nombreuses organisations hiérarchisent est la valeur commerciale, et nous l'avons appelé valeur stratégique potentielle, potentiel, mais une dimension est la valeur commerciale. Et l'autre n'est pas le coût, beaucoup d'organisations décident de la valeur et du coût. Nous avons dit, non, non, la deuxième dimension est la probabilité de succès. Et puis nous avons commencé à cartographier nos éléments dans ce deux par deux.
[00:33:57] Et ce que vous verrez alors, c'est que vous avez certains éléments qui ont une forte probabilité de succès, mais une faible valeur stratégique potentielle. C'est là que vous devez adopter une attitude de grande pensée. Vous devez essayer de trouver des moyens d'augmenter la valeur stratégique de cette organisation par une stratégie de prix différente, par une stratégie de déploiement différente, peu importe. Vous trouverez également dans votre organisation des initiatives qui ont une forte valeur stratégique, mais une faible probabilité de succès. Vous ne commencez pas à exécuter et à mettre en œuvre ces initiatives. Ce que vous devez faire, c'est de l'idéation et de l'expérimentation pour augmenter la probabilité que vos clients adoptent cette initiative.
[00:34:41] Si vous avez des éléments avec une faible probabilité et une faible valeur, oui, vous le supprimez, vous le supprimez simplement. Et ce que nous voulons avoir, mais ils sont très rares, ce sont des initiatives qui ont une forte probabilité et une forte valeur stratégique. Lorsque nous avons fait l'exercice dans notre organisation, et c'est ce que l'on voit dans de nombreuses organisations, c'est que elles ont beaucoup, beaucoup d'initiatives avec une forte probabilité, mais une faible valeur commerciale, car tout le monde prend un pari sûr et c'est bien, il suffit de livrer des fonctionnalités à temps, dans le budget et la qualité. Mais cela n'aide pas vraiment.
[00:35:16] Ce que nous voulons en fait, c'est le bon mélange, le bon portefeuille de initiatives à forte probabilité de succès, peut-être à faible valeur commerciale, ce sont des fonctionnalités de base, ce ne sont que des fonctionnalités de maintenance, mais nous devons aussi avoir de grands paris dans l'organisation. Le défi à enjeux élevés avec lequel vous pouvez vraiment créer un avantage concurrentiel.
[00:35:42] De nombreuses organisations affirment qu'elles sont lentes. Et si vous voulez être deux fois plus rapide, deux fois plus rapide et c'est possible. Il existe des études de cas, parfois même vieilles de plus de 10 ans, il est très facile de devenir deux fois plus rapide, même au niveau stratégique. Tout ce que vous avez à faire, c'est de limiter le travail en cours. Et l'effet sera que vous aurez le même débit, mais votre temps de cycle peut être réduit de plus de 50%. Et si nous parlons d'initiatives stratégiques, nous ne parlons pas de semaines, nous parlons de mois ou d'années que cela prend généralement pour mettre en œuvre et exécuter une telle initiative stratégique. Mais comment limiter le travail en cours sur un tel tableau Kanban au niveau de l'entreprise ? Et il y a deux façons.
[00:36:36] L'une est la manière très traditionnelle d'avoir une limite de travail en cours sur chaque colonne, donc six éléments devraient être en évaluation. Nous avons appliqué la deuxième méthode, une méthode contrainte, une limite de WIP sur les ressources, donc certaines ressources, certaines équipes auraient certains éléments de capacité, donc des aimants. Et puis nous avons commencé quand nous avons fait la planification trimestrielle, je voulais dire, en fait ce n'était pas une planification, c'était plus une réflexion en scénarios, mais nous avons commencé par l'élément le plus important, et nous avons demandé à tous les domaines et à l'équipe ce qui devait se passer pour que cette initiative se réalise.
[00:37:18] Et puis ils ont mis les aimants sur les épopées réelles de leurs éléments et nous avons progressé vers le numéro deux, le numéro trois et le numéro quatre. Et parfois, même l'initiative stratégique numéro deux, nous avions un problème car certaines équipes n'étaient plus en mesure d'y ajouter des aimants de capacité. Et ce qui se passe dans beaucoup d'organisations, vous faites un compromis, vous retirez des ressources le vendredi après-midi, s'il vous plaît, pourriez-vous travailler sur cette initiative stratégique. Nous ne l'avons pas fait, nous n'avons alors tout simplement pas commencé l'initiative stratégique numéro deux, mais nous avons ajouté et continué avec les numéros trois, quatre.
[00:37:55] Ce que vous faites dans une telle organisation, c'est déléguer beaucoup en tant qu'équipe de direction au niveau du domaine et au niveau du middle management. Et puis la question est : oui, mais quelles sont les responsabilités des leaders, de la haute direction ? Et il y a quatre responsabilités clés, la première est d'attirer et de développer les talents. La seconde est de définir et de piloter, et je dirais même de faire respecter votre culture.
[00:38:25] Troisièmement, vous donnez la direction. Créer l'alignement. Et la quatrième et la plus importante chose est que vous devez co-créer une stratégie avec vos équipes de domaine et ensuite en piloter l'exécution.
[00:38:39] Lorsque vous introduisez une nouvelle méthodologie, soyez clair sur ce dont vous avez besoin, ce que vos équipes doivent apprendre, ce qu'elles doivent désapprendre, mais aussi ce qu'il faut conserver. Très souvent, les personnes en charge du changement ne savent pas vraiment ce qu'elles doivent appliquer, ce qui va vous ralentir et même nuire à votre organisation. Et prenez soin de vos gens. Apprendre de nouvelles choses, et même si ces choses comme Kanban sont juste appliquées d'une manière différente, pourrait faire en sorte que certains d'entre eux se sentent incertains, inexpérimentés et vulnérables. Alors, écoutez vos collaborateurs.
[00:39:14] Et n'oubliez jamais, n'oubliez jamais, notre plus haute priorité est de satisfaire le client par la livraison précoce et continue de logiciels de valeur. Si vous voulez approfondir ce sujet, je recommande trois livres : 'Team Topologies', 'Sooner Safer Happier', et 'Rethinking Agile' de Klaus Leopold, qui a en fait inventé les niveaux de vol. J'aurais aimé avoir une session de questions-réponses en direct pendant cette présentation. Nous aurons, nous aurons une session de questions-réponses. Génial. Mais si vous voulez discuter avec moi et obtenir d'autres informations, n'hésitez pas à me contacter sur LinkedIn, voici mon identifiant, vous pouvez me trouver très facilement. Je suis également disponible pour des engagements dans votre organisation si vous êtes un client AWS. Alors, merci beaucoup.
[00:40:07] Merci, Matthias. Je pense que nous aurons des questions.
[00:40:11] Ah, nous faisons des questions-réponses maintenant. Ok, super.
[00:40:17] Alors, euh, oui, nous avons quelques questions. La première concerne la feuille de route, vous avez dit que ce n'était pas vraiment de la planification, mais que c'est une sorte de prévision, et combien de temps prévoyez-vous ou planifiez-vous des feuilles de route dans votre système ?
[00:40:40] Cela dépend de ce dont vous avez besoin, donc nous avions toujours un plan ou une intention sur une base trimestrielle. Alors, quel est le prochain trimestre, mais nous pensions aussi, en termes de déploiement, de marketing, à ce que cela implique réellement. Donc, nous pensions à une sorte de scénarios, non pas sur le tableau Kanban, mais sur d'autres tableaux à feuilles mobiles et des papiers bruns pour réfléchir à des scénarios, à ce qui pourrait arriver et comment nous réagirions d'un point de vue ressources, d'un point de vue budget, d'un point de vue capacité et si nous devions agir sur certains aspects, où devrions-nous faire des compromis. Et parfois, cela aurait pu être 18 mois. Oui, entrer sur un nouveau marché, donc nous opérons dans 18 pays européens et si vous vouliez aller en Russie, autre devise, autre langue, autres polices, des marchés totalement différents, cela demandait beaucoup d'efforts et nous pensions même plus loin.
[00:41:42] Bien. Qu'est-ce qui ne fonctionne pas au niveau de l'entreprise ?
[00:41:47] Tout, tout peut échouer, tout échoue tout le temps. En fait, au début ce qui ne marchait pas, mes pairs de l'équipe de direction n'étaient pas enclins à faire des post-it sur un mur sur une base hebdomadaire. Et je n'ai pas eu l'idée de dire, hé, faisons du Kanban de niveau de vol au niveau de l'entreprise, mais ils me posaient constamment des questions et me mettaient au défi concernant la capacité des équipes de développement logiciel. Et c'est pourquoi ou comment j'ai introduit Kanban au niveau de l'entreprise en mode guérilla, j'ai visualisé nos initiatives actuelles et j'ai visualisé la capacité, donc les aimants des équipes, et ensuite nous nous sommes réunis une fois par semaine et avons discuté de la capacité.
[00:42:33] Et c'est ce que nous avons fait pendant plusieurs semaines, puis nous avons ajusté le tableau et l'avons optimisé, et après deux trimestres, j'ai invité Klaus Leopold et nous l'avons fait correctement, mais ils ont été accrochés par leur question. Euh, oui, c'était l'un des problèmes les plus importants, comment commencer et comment convaincre.
[00:42:57] Merci, Matthias. Et de nos jours, nous pouvons voir que la plupart des entreprises de logiciels ont des politiques de télétravail. Alors, ma question est : comment le Kanban
[00:43:20] Je ne suis pas un grand fan d'avoir ces feux de camp en ligne. De mon point de vue, il existe trois types de travail dans une organisation et ces trois types de travail nécessitent trois environnements différents. La première chose est le travail de concentration. Et le travail de concentration fonctionne très rarement dans les locaux de votre entreprise, donc avoir du travail de concentration, avoir un contributeur individuel qui réfléchit vraiment en profondeur à quelque chose, pourquoi ne pas laisser ces personnes le faire chez elles.
[00:43:53] Si ce contributeur individuel pense que c'est mieux fait à la maison. Si ce contributeur individuel veut faire de la programmation en binôme au bureau, alors pourquoi pas ? Mais le deuxième type de travail est le travail créatif collaboratif. Et c'est, de mon point de vue, l'exécution de la stratégie, un tableau Kanban est très important, c'est un travail créatif, où vous devez voir les nuances de comportement, dans les visages, dans leur communication. Et cela vaut la peine de demander aux gens de venir au bureau une fois par semaine, une fois par trimestre pour une journée entière afin de réaliser cette co-création créative en groupe. Donc, vous devez trouver des méthodes de travail où ils peuvent avoir leur propre temps, s'auto-organiser, mais où aussi un groupe se réunit pour une prise de décision rapide. Et le troisième type de travail que je perçois n'est pas vraiment du travail, mais de la socialisation. Ainsi, les organisations doivent disposer d'espaces de travail pour le travail de concentration, pour la cocréation, mais elles doivent également fournir des espaces de bureau qui ressemblent à un café danois ou français, ou à un salon où les gens peuvent simplement socialiser.
[00:45:01] Alors, merci, Matthias. Euh, nous allons prendre d'autres questions. Et nous vous les enverrons et, euh, nous pourrons avoir un échange là-dessus. Donc ce serait vraiment, euh, vraiment bien. Et, euh, merci pour la présentation et à bientôt.
[00:45:16] Oui, merci beaucoup. Ce fut un plaisir.

Transcription (Traduit)