Henrik Kniberg
Transcription (Traduit)
Je suis vraiment heureux d'être ici à Paris. Et ceci est une conférence vraiment cool et un endroit cool, avec beaucoup de gens cool, alors applaudissez-vous, je pense.
Oui, je vais parler un peu de cette chose appelée alignement. Et ce que je veux dire par là, c'est comme des équipes qui ne courent pas dans 15 directions différentes. D'accord ? Cela semble être un énorme défi pour de nombreuses entreprises. Combien d'entre vous sont dans un contexte multi-équipes ? Vous avez plusieurs équipes qui doivent travailler ensemble d'une manière ou d'une autre. Donc, eh bien, c'est à peu près la plupart d'entre vous, n'est-ce pas ? Super.
Ceci est une seule équipe faisant quelque chose, de manière Agile, Kanban, Scrum, je ne sais pas. Ce n'est pas de la science-fiction, nous avons en quelque sorte compris comment faire. Vous pouvez prendre à peu près n'importe quel livre sur un cadre Agile ou Lean et faire simplement ce qu'il dit et vous vous en sortirez plutôt bien. Ce n'est pas comme si c'était une solution miracle, mais vous vous en sortirez plutôt bien. Vous livrerez quelque chose. Donc, je ne vais pas parler de ceci, mais quand vous avez plusieurs de ces choses, d'accord, c'est un peu plus délicat, non ? Il faut un peu de communication transversale, un peu de synchronisation. Mais c'est de cela que je veux parler, non ? Parce que quand vous avez cela, ce qui se passe souvent, c'est que, non ? Combien d'entre vous reconnaissent cette image ? On dirait que, ouais, c'est nous, non ? C'est un défi. Et malheureusement, je n'ai pas de réponses pour vous. Mais merci beaucoup quand même. Et j'espère que vous passerez une bonne conférence.
Je n'ai pas de réponses, mais j'ai quelques exemples. Et certains de ces exemples pourraient avoir du sens dans votre contexte ou non. Mais nous verrons.
Mais c'est ce avec quoi j'ai traité pendant plusieurs années. Et je suis toujours à la recherche de petits conseils, astuces et idées. Et j'en ai trouvé quelques-uns qui pourraient être utiles.
Parce que cela ne s'adapte pas à grande échelle. D'accord, je cherchais depuis longtemps une bonne métaphore pour le problème qui se pose, et je l'ai enfin trouvée il y a quelques mois. Donc voici la métaphore. Voici une équipe qui essaie de résoudre un problème. Le problème qu'ils essaient de résoudre est que nous devons traverser cette rivière, n'est-ce pas ? Et puis ils construisent un pont parce qu'ils sont une équipe autonome. On leur a confié la tâche de résoudre ce problème. Donc ils ont trouvé cette solution brillante. Ce qu'ils ne savent pas, cependant, c'est qu'ailleurs dans le même bâtiment, une autre équipe essaie également de résoudre le même problème. Donc ils sont alignés, non ? Ils essaient de résoudre le même problème. Sauf que l'autre équipe fait cela. N'est-ce pas ? Et ils essaient très joyeusement de résoudre le même problème. Et puis quand ils se découvrent, ils sont comme, quoi ? Que faites-vous les gars ? Attendez, nous construisons un tunnel. Nous construisons un pont. Attendez. Et puis vous obtenez de la confusion. N'est-ce pas ? C'est donc mon modèle mental de sous-optimisation. Et cela se produit lorsque vous allez trop loin avec l'autonomie. N'est-ce pas ? Nous, dans la communauté Agile et Lean, sommes très attachés à la décentralisation, n'est-ce pas ? C'est comme, ah, la décentralisation, c'est bien. Mais quand vous poussez les choses trop loin, vous obtenez ces équipes qui semblent prendre de bonnes décisions. localement, mais ensuite cela ne s'emboîte tout simplement pas vraiment. Alors que faisons-nous à ce sujet ? Eh bien, voici la réponse, non ?
C'est une réaction courante, cependant, non ? Réaction courante, ouais, je vous avais dit que cette connerie d'autonomie ne marchait pas, non ? Il faut que quelqu'un prenne les choses en main, non ? Rappelons les managers. Mais ceci est basé sur ce que je considère comme une hypothèse erronée.
Et c'est la notion que l'alignement et l'autonomie sont comme en opposition l'un avec l'autre. Vous devez en quelque sorte choisir où vous voulez vous situer sur l'échelle. Donc soit le manager décide, soit les équipes décident, et vous devez choisir, en quelque sorte, où sur cette échelle.
Je trouve plus utile de penser à cela comme une échelle à deux dimensions. Et je dois être honnête, je n'ai pas inventé cela, mais je ne me souviens pas de qui je l'ai volé. Donc je m'excuse auprès de la personne à qui j'ai volé cette métaphore, d'accord ? Et si vous savez qui c'est, faites-le-moi savoir. Mais de toute façon, c'est un excellent modèle, en regardant ces dimensions séparément. Faible alignement, faible autonomie, microgestion. Une faible autonomie signifie que les équipes ne peuvent pas décider quoi faire ou comment le faire. On leur dit simplement quoi faire. Et on ne leur dit pas pourquoi ils le font. Donc il n'y a pas d'alignement. Très ennuyeux. En haut à gauche, c'est plus comme si nous avions une sorte de but de haut niveau. Les gens comprennent pourquoi ils sont là. Nous sommes ici pour traverser la rivière à cause de X, n'est-ce pas ? Mais ensuite, on leur dit aussi comment résoudre le problème. Construisez un pont. Alignement élevé, mais toujours faible autonomie. Un peu mieux, peut-être. Un peu plus motivant. Nous pouvons utiliser un peu plus la créativité des gens. Mais le bon quadrant est en haut à droite, non ? Nous devons traverser la rivière. Les managers, les leaders sont bons pour décrire le pourquoi, pourquoi nous sommes ici, le contexte. Et ensuite, ils laissent les équipes trouver le comment. Donc vous, les gars, trouvez le comment. Maintenant, nous libérons la créativité, non ? Nous libérons l'innovation. Beaucoup de bonnes choses se produisent.
En bas à droite, haute autonomie, faible alignement. Eh bien, c'est quand vous avez toutes ces équipes qui font juste ce qu'elles veulent, ce qui semble avoir du sens de leur point de vue. Et puis vous obtenez comme le pauvre manager, le leader disant, j'espère que quelqu'un travaille sur le problème de la rivière, mais je n'en ai aucune idée. Et c'est à ce moment-là que vous obtenez des choses comme le problème du pont-tunnel, etc. Par simple curiosité, je me rends compte que cela pourrait être une question sensible, mais si vous êtes d'accord pour en parler ici, combien d'entre vous estiment que cet environnement, ici en bas à gauche, est celui qui vous semble le plus familier, celui dans lequel vous vivez en ce moment, cet environnement, levez la main.
Quelques-uns, nous en avons deux, peut-être trois. Combien d'entre vous estiment que c'est principalement ce qui décrit ce que je vois ?
Bon, regardez autour de vous, d'accord ? Cela représente peut-être 20 % de la salle. Et ici ? Vous vivez principalement dans ce monde.
J'étais étonnamment peu nombreux. J'en ai vu comme deux et demi.
Je ne veux pas dire une demi-personne, je veux dire une demi-main.
Et ici en bas, le genre de problème de chaos général ? Combien d'entre vous vivent ici ? D'accord, donc très mélangé, n'est-ce pas ? Groupe très mélangé. Et environ la moitié d'entre vous n'ont même pas levé la main, donc je ne sais pas où vous vivez.
Peut-être que cela varie. Pour moi, il s'agit vraiment de savoir comment trouver cet endroit ? Comment y arrivons-nous ? Et l'alignement est quelque chose qui permet l'autonomie. Plus vous êtes bon en tant que leader, à créer de la clarté. Pourquoi sommes-nous ici ? Quel problème essayons-nous de résoudre ? Et en créant du contexte pour que les gens puissent voir ce qui se passe. Mieux vous êtes à faire cela, plus vous pouvez donner d'autonomie, et les équipes utiliseront cette autonomie de manière positive. Est-ce que cela a du sens ? Donc l'alignement permet l'autonomie. Ce n'est pas l'un ou l'autre.
J'appelle cela l'autonomie alignée. Je sais que c'est un peu compliqué à dire, mais je ne trouve pas de meilleur terme. Bref, je vais utiliser la métaphore de la cuisine, d'accord ? Parce que nous sommes en France après tout. La nourriture. La cuisine pour décrire ce que je considère comme certains ingrédients qui augmentent la probabilité d'obtenir un alignement entre plusieurs équipes agiles. Mon hypothèse maintenant est que vous avez des équipes agiles de quelque sorte, n'est-ce pas ? Kanban, Scrum, une combinaison, je ne sais pas. Mais en gros, vous faites du lean agile au niveau de l'équipe, bien. Comment créons-nous l'alignement, n'est-ce pas ? Quelques ingrédients clés. Et le premier que j'ai déjà évoqué, c'est un sens de la finalité. Une compréhension claire de, pourquoi est-ce que je transporte cela ? Reste là.
Finalité partagée.
Et oui, vous le savez probablement déjà, mais je veux insister dessus parce que c'est vraiment important et que nous l'oublions parfois. Je vais donner quelques exemples de deux entreprises pendant cette présentation, Spotify et Lego, non pas parce qu'elles le font nécessairement de manière parfaite. Elles sont comme n'importe quelle autre entreprise. Elles ont des bons et des mauvais côtés. Je les mentionne simplement parce que ce sont les entreprises avec lesquelles j'ai le plus d'expérience directe. C'est juste pour avoir des exemples concrets. Et ce que je trouve inspirant, s'il y a une chose que ces deux entreprises font vraiment bien, c'est la finalité. Parce que dans ces organisations, surtout si vous écoutez quelqu'un comme Daniel Ek ou Jørgen Vig Knudstorp de Lego, ils insistent toujours sur la finalité. Ils ne parlent pas tant du produit. Ils insistent sur la manière dont le produit est utilisé, qui l'utilise, quels problèmes nous essayons de résoudre. Et cette passion résonne. Vous remarquez que les gens en parlent beaucoup. Les équipes en parlent, les développeurs, les chefs de projet. Cela semble être une préoccupation constante, parler du problème que nous essayons de résoudre, qui sont les utilisateurs. Chez Lego, il y a des enfants qui courent dans le bureau deux fois par semaine. Il y a des gens dans les équipes qui vont visiter des écoles. C'est incroyable de voir cette concentration sur la finalité. Et cela motive les équipes, mais cela les aide aussi à prendre de meilleures décisions. Donc, la finalité.
Et il y a un moyen de tester cela. Demandez simplement à vos collègues ou à une équipe, par exemple, sur quoi travaillez-vous en ce moment ? Et pourquoi ? Et vous obtiendrez des types de réponses intéressants. Donc, si la réponse est, eh bien, nous travaillons sur X parce que Sam dit que c'est vraiment important. Comme, euh, vous savez. Eh bien, peut-être que ce n'est pas génial.
Oh, et nous avons terminé quand Sam est d'accord avec ça, n'est-ce pas ? Cela ne ressemble pas à une organisation guidée par la finalité, selon moi. Si la réponse est plus comme, eh bien, nous travaillons sur X parce que nous pensons que cela aura l'impact Y, et cela compte pour l'entreprise et nos parties prenantes à cause de Z, oh, cela commence à sembler plus impressionnant, n'est-ce pas ? Et nous avons terminé quand les métriques ont bougé, donc ils le mesurent même. C'est bien, cool. Maintenant, cela commence à devenir intéressant. Vous commencez à voir des tableaux de bord et des choses comme ça. C'est une façon de tester, en quelque sorte. Donc, c'est un ingrédient.
Un autre ingrédient clé est la transparence.
Et cela ne sera pas une nouveauté pour vous non plus, mais je vais vous donner quelques exemples. Parce que, encore une fois, vous pouvez avoir ces deux équipes qui ont la même finalité partagée, mais elles sous-optimiseront encore parce qu'elles ne voient pas ce qui se passe. Donc, la transparence. Beaucoup d'entreprises que je rencontre ressemblent un peu à ceci.
Que voyez-vous ici ? Rien.
Donc, le pauvre développeur ou le pauvre designer est assis dans une pièce en se demandant, hmm, je me demande ce sur quoi les autres travaillent.
Je ne sais pas, je vais juste continuer à travailler sur ce ticket qui est apparu dans mon flux Jira ou mon tableau Kanban ou autre, n'est-ce pas ? Et si vous avez toute une organisation comme ça, alors vous n'avez pas de transparence.
Vous aurez beaucoup de mauvaises choses cachées dans l'ombre, n'est-ce pas ? Donc, allumez les lumières. Ce que je trouve intéressant, c'est qu'il semble assez courant de nos jours que les équipes aient ces tableaux, n'est-ce pas ?
Des tableaux visuels de toutes sortes. Ce que je trouve intéressant chez Spotify, c'est qu'en fait, chez Spotify, nous avons eu le problème de, maintenant nous avons environ 100 équipes, et nous voyons ce problème de sous-optimisation, n'est-ce pas ? Et nous avons essayé de faire quelque chose à ce sujet. Et un modèle qui nous a réellement aidés est d'aller à l'extrême avec la transparence, surtout en ce qui concerne les grandes initiatives sur lesquelles l'entreprise veut travailler. Donc, c'est, je suppose, assez typique. Comme la plupart des entreprises ont ce concept de quelles sont les croyances de l'entreprise, où voulons-nous aller et pourquoi ? La plupart des entreprises ont ce concept de quelles sont les croyances de l'entreprise, où voulons-nous aller et pourquoi ? Quels seraient quelques jalons clés en cours de route ? Par exemple, atteindre X nombre d'utilisateurs actifs ou être un employeur de classe mondiale selon n'importe quel critère. C'est un type de réflexion stratégique assez typique. Mais ce que je trouve intéressant, c'est que Ils ont fait un effort très marqué pour clarifier ce que nous appelons des paris. Un pari, c'est un peu l'équivalent Spotify d'un projet ou d'un flux de travail. Juste une sorte d'effort coordonné, généralement plutôt important. Les petites choses, les petites améliorations continues, celles-là fonctionnent simplement comme elles fonctionnent. C'est très bien. Le défi pour nous, ce sont les choses plus importantes où nous avons besoin de plus d'alignement. Donc nous appelons celles-ci des paris et nous les rendons très, très, très visibles. Donc, ils se trouvent en fait dans... Eh bien, ils servent de point d'alignement. Ainsi, si ces trois équipes savent toutes que nous travaillons sur l'intégration de la PlayStation de Sony, c'est notre objectif actuel. Nous appelons cela un pari. Si toutes les équipes savent sur quoi travaillent les autres équipes, elles seront plus susceptibles de collaborer et de se parler.
Mais de toute façon, ces paris, nous avons une solution très peu technologique, c'est juste une feuille de calcul Google. C'est une feuille de calcul Google appelée le tableau des paris de l'entreprise. Voici à quoi cela ressemblait en juin ou quelque chose comme ça cette année. Ça ressemble un peu à un truc Kanban, non ? Et c'est à peu près ce que c'est. C'est une sorte de système Kanban au niveau de l'entreprise. Et ce n'est pas strictement limité en travail en cours (WIP), mais implicitement limité en WIP, car lorsque nous l'avons commencé, nous avions trop de choses, et cela a été progressivement réduit. Et maintenant, voici le nombre d'initiatives inter-entreprises en cours. Approximativement. Nous ajustons les noms des colonnes, mais pendant une période, nous utilisions maintenant, ensuite, plus tard, ce qui est une approche simple et agréable.
Mais ce que je trouve intéressant, c'est que ceci est visible par tout le monde. N'importe qui dans l'entreprise peut, en un clic, voir sur quoi diable nous travaillons.
Et si vous cliquez sur l'un de ceux-ci, vous arrivez à ce brief. C'est un Google Doc. N'importe qui peut simplement le voir. Et il contient des éléments assez standards comme qui est le sponsor de ceci ? Quels sont les indicateurs de succès ? Comment saurions-nous si ce pari a bien fonctionné ? À quoi ressembleraient les chiffres ? Dans certains cas, des choses comme le coût du retard, tout ce qui est pertinent pour ce pari. Mais la deuxième page est ce que je trouve intéressant, un peu différent. Je n'ai pas vu cela dans beaucoup d'autres entreprises. C'est quelque chose que nous appelons un DIBB, D-I-B-B, Données, Insight, Croyance, Pari. Et cela montre le raisonnement logique derrière pourquoi nous faisons cela. Alors, remontons quelques années en arrière. Il y a quelques années, Spotify avait le problème suivant :
Les données montraient que l'utilisation du bureau. Le lecteur de musique Spotify était un produit de bureau, et l'utilisation du bureau diminuait, tandis que l'utilisation mobile augmentait, n'est-ce pas ? Données très claires. Et comment sommes-nous staffés, n'est-ce pas ? Oups, autant de personnes sur le bureau et si peu sur le mobile. Ce sont des données. Donc c'est ce que signifie la colonne de gauche. Ce sont juste des données. Et ensuite, quelle insight ces données nous donnent-elles ? Eh bien, elles nous donnent l'insight que le mobile dépasse le bureau et que nous avons un problème, n'est-ce pas ?
Et qu'est-ce que cela ? Cela nous dit quelle est notre croyance sur la place de notre entreprise dans le monde à cause de cela. Eh bien, notre place dans le monde est que nous devons vraiment devenir mobile first. C'est la croyance. Et alors, d'accord, que allons-nous faire alors ? Donc les paris sont en quelque sorte les projets ou les épopées, les choses que nous allons faire. Eh bien, nous ferions mieux d'embaucher un tas de développeurs mobiles, de former un tas de développeurs de bureau en développeurs mobiles, et d'investir beaucoup dans l'infrastructure pour la livraison continue sur mobile et juste beaucoup de choses, n'est-ce pas ? Ce que je trouve intéressant, cependant, c'est que nous voyons ici le pourquoi. Pourquoi construisons-nous cette infrastructure ? Eh bien, à cause de cette croyance qui est venue de cette insight, qui est venue de ces données. Et n'importe laquelle de celles-ci peut être fausse, n'est-ce pas ? Donc nous les mettons là pour qu'elles puissent être critiquées et discutées. Nous considérons cela comme un cadre de discussion. Et au fur et à mesure que nous mettons en œuvre les paris, nous obtenons plus de données, n'est-ce pas ? Et ces données nous donnent de nouvelles insights. C'est juste une façon de rendre la conversation un peu plus ciblée. Donc ce n'est pas comme si je travaillais sur X parce que Sam l'a dit. Est-ce que cela a du sens ? les projets ou les épopées, les choses que nous allons faire. Eh bien, nous ferions mieux d'embaucher un tas de développeurs mobiles, former un tas de développeurs desktop en développeurs mobiles, et investir beaucoup dans l'infrastructure pour la livraison continue sur mobile et juste beaucoup de choses, n'est-ce pas ? Ce que je trouve intéressant, cependant, c'est que ici nous voyons le pourquoi. Pourquoi construisons-nous cette infrastructure ? Eh bien, à cause de cette croyance, qui est venue de cette intuition, qui est venue de ces données. Et n'importe laquelle de celles-ci peut être fausse, n'est-ce pas ? Donc nous les mettons là pour qu'elles puissent être critiquées et discutées. Donc nous considérons cela comme un cadre de discussion. Et au fur et à mesure que nous mettons en œuvre les paris, nous obtenons plus de données, n'est-ce pas ? Et ces données nous donnent de nouvelles intuitions. Donc, ce n'est qu'une façon de rendre la conversation un peu plus ciblée. Donc ce n'est pas comme si je travaillais sur X parce que Sam l'a dit, n'est-ce pas ? Est-ce que cela a du sens ?
Donc peu clair, mais assez utile.
Et vous ne pouvez pas, autant que je sache, vous ne pouvez pas vraiment éviter cela. C'est le prix à payer lorsque vous permettez aux équipes de travailler de manière autonome. Il y a tellement d'avantages à l'autonomie et à la décentralisation. L'inconvénient, c'est cela. Mais ce que vous pouvez faire, c'est le détecter. Et si vous le détectez tôt, ce n'est pas un gros problème, n'est-ce pas ? Si vous remarquez que cela se produit à la phase de plan, lorsque vous parliez simplement de ce qu'il faut faire, alors cela ne posera aucun problème. Donc, la détection précoce des désalignements est vraiment ce dont il s'agit, pas rendre l'alignement impossible. Un désalignement va parfois se produire.
D'accord, alors à quelle vitesse pouvons-nous détecter un désalignement ? Et la transparence aide. Passons maintenant à Lego.
Différentes entreprises juste pour le contraste, n'est-ce pas ?
Ce dont je vais parler ici, ce sont quelques outils pour détecter et résoudre les dépendances. Certains d'entre vous reconnaîtront peut-être ceci. Qu'est-ce que c'est ?
En fait, cela pourrait être n'importe quoi, ce ne sont que des post-its sur un mur.
En fait, cela vient du cadre Safe Scaled Agile, c'est ce qu'on appelle un tableau de programme.
Mais si vous le considérez simplement comme n'importe quel outil, c'est une visualisation. Je l'appelle un tableau de dépendances. Et ce qui est intéressant à ce sujet, ce sont les équipes. Nous avons 20 équipes différentes au sein de la partie solutions numériques de LEGO, qui sont les personnes qui construisent toutes les choses numériques, site web, outils de design, etc. Et ils avaient beaucoup de problèmes de dépendances entre ces équipes. Donc tout cela fait, c'est visualiser cela. Donc 20 équipes et puis quatre sprints à venir. Et simplement qui a besoin de quoi de qui et quand, approximativement, n'est-ce pas ? Cela aide à résoudre les problèmes.
Le fil rouge montre simplement, la flèche va du post-it jaune au post-it rose, c'est tout. Donc ces trois équipes ont besoin de cette chose de cette équipe en premier. En visualisant cela, ces équipes sont plus susceptibles de se parler, n'est-ce pas ? Ce qui est intéressant, cependant, c'est qu'en regardant ce tableau, vous voyez des motifs, n'est-ce pas ? Quel est le motif ? Je sais que c'est un fouillis, mais quel est le motif ?
Quelque chose doit vous sauter aux yeux, non ?
Oui, quelqu'un a fait cela, n'est-ce pas ?
C'est une colonne pleine de post-its roses. Il y a écrit informatique d'entreprise là-haut. N'est-ce pas ? Il s'est avéré que, en fait, les plus grandes dépendances que nous avions n'étaient pas entre ces équipes. Les plus grandes dépendances étaient envers une toute autre partie de l'organisation appelée informatique d'entreprise. Donc nous avons ajouté une colonne pour cela afin de le visualiser. Et cela a généré ce moment collectif de prise de conscience. Comme tout le monde savait cela, mais maintenant cela est devenu très clair. Et ce qui a commencé à se passer, c'est que personne ne possède ce document. Personne ne essaie de le maintenir. C'est juste un marché pour déclencher un comportement décentralisé. Les gens le voient, ils se parlent, et ils commencent à optimiser la contrainte. Au lieu de s'énerver contre la CAT, vous idiots, vous nous ralentissez, ils réalisent que c'est une véritable situation de goulot d'étranglement. Nous devons réfléchir à la manière de l'utiliser le plus efficacement possible, n'est-ce pas ? Mais aussi réfléchir à la manière de réduire le facteur de goulot d'étranglement pour l'avenir. Donc ces deux choses ont commencé à se produire. Et maintenant, c'est en fait beaucoup mieux parce qu'ils ont beaucoup investi dans des choses comme l'infrastructure cloud afin que les équipes puissent se procurer leurs propres environnements de test au lieu d'attendre la CIT, des choses comme ça. Donc visualisez les dépendances pour pouvoir les optimiser, mais aussi pour pouvoir commencer à les supprimer au fil du temps grâce à la technologie, à la réorganisation, à la culture, etc.
Cela est utilisé dans le travail quotidien au bureau. C'est le siège social à Billund, où les équipes en parlent pour faire un suivi des dépendances, des choses comme ça. Parce que lorsqu'il s'agit de mise à l'échelle et d'alignement, tout repose vraiment sur les dépendances. C'est ce qui va informer la vitesse de votre projet. C'est simplement dans quelle mesure pouvons-nous éviter de rester bloqués en attendant les uns après les autres, n'est-ce pas ?
Donc, retour à Spotify, juste pour le contraste, Spotify n'a pas tendance à utiliser ce genre de chose. Ils n'ont pas autant de situations où 20 équipes sont totalement dépendantes les unes des autres. Mais parfois, il y a de plus grandes initiatives où les équipes doivent se synchroniser. Donc une version plus typique de Spotify de ceci est une synchronisation des dépendances au quotidien. Donc toutes les équipes qui se trouvent être dépendantes en ce moment se rencontrent généralement tous les jours devant un outil léger, juste un tableau comme celui-là. Et chaque colonne est une équipe et chaque post-it rose est quelque chose que quelqu'un a besoin de quelqu'un d'autre en ce moment. Donc c'est plus une dépendance en temps réel. Qui a besoin de quoi de qui maintenant ? Et ensuite, ils utilisent la synchronisation quotidienne comme une sorte de marché pour résoudre qui doit parler à qui, comme un centre de compensation. Mais la visualisation des dépendances est l'une de ces choses clés de transparence dont je pense que vous avez besoin si vous voulez obtenir l'alignement. Idéalement, vous n'avez pas de dépendances, mais probablement vous en avez, alors pourquoi ne pas les visualiser ?
Donc c'est l'ingrédient numéro deux.
Prêt pour le numéro trois ? Oui ? Ou peut-être que deux suffisent.
Encore un, d'accord. Nous en ferons trois. Boucles de rétroaction.
Il ne suffit pas de voir ce qui se passe. Vous avez également besoin d'un moyen de voir quelle est la conséquence de mes actions, n'est-ce pas ?
Maintenant, si vous prenez n'importe quelle méthode agile typique et que vous faites simplement ce qu'elle dit, vous obtiendrez une série de boucles de rétroaction. Vous obtenez des choses comme les tests unitaires de XP, les stand-ups quotidiens de presque n'importe quelle méthode, les rétrospectives, l'intégration continue. Si vous faites des sprints, vous avez des revues de sprint. Il y a toutes ces boucles de rétroaction qui viennent avec un package, ce qui est génial. C'est, je pense, l'un des facteurs de succès pour lesquels ces méthodes se répandent si rapidement.
Avec plusieurs équipes, vous devez simplement en ajouter quelques-unes de plus.
Vous devez ajouter des choses comme la synchronisation inter-équipes, où nous parlons les uns aux autres.
Vous avez besoin de choses comme des rétrospectives ensemble entre plusieurs équipes pour parler de la manière dont nous allons collaborer efficacement entre équipes. Et vous avez besoin de choses comme l'examen complet du produit. Nous examinons l'ensemble, comment tout s'assemble, et nous obtenons des retours sur le client, etc. Alors ajoutez-en juste quelques-uns de plus.
Je dirais que le schéma le plus fort que j'ai observé, le schéma le plus constant pour les grands efforts, est la notion de cadence d'intégration. Et je trouve cela vraiment puissant parce que cela vous aide, peu importe quel est votre processus de développement. Donc peut-être que cette équipe ici fait du Scrum et ils font des sprints d'une semaine. Peut-être qu'ils font des sprints de deux semaines. Nous avons une équipe ici qui fait du Kanban. Nous avons une équipe là-bas qui fait Dieu sait quoi, n'est-ce pas ? Peu importe comment nous travaillons, nous pouvons décider qu'il y aura une intégration toutes les deux semaines, point final. Et tout va se rassembler et nous allons l'examiner. Vraiment puissant parce que cela devient comme une fonction forçant la collaboration. Maintenant, les équipes doivent se parler parce qu'elles savent qu'elles vont se retrouver ensemble dans deux semaines et ce sera un peu embarrassant si nos choses ne fonctionnent pas ensemble. Un exemple de cela, chez Spotify, nous le faisons normalement chaque vendredi pour les plus grandes initiatives. Dans le projet d'intégration de la PlayStation de Sony, nous nous sommes intégrés avec Sony, il y avait du matériel, des contrats, des logiciels, toutes ces choses. La démonstration du vendredi était vraiment utile parce que quelqu'un de la finance présentait la dernière version, le dernier projet de contrat. Un designer présentait le dernier projet de conception, et ils remarquaient que, oh, ce n'est pas tout à fait aligné, n'est-ce pas ? Les choses qui sont dans le contrat ne correspondent pas à ce que nous concevons ici. Nous devrions en parler. Donc les problèmes ne sont pas résolus lors de cette démonstration, mais ils sont révélés. Et c'est la chose clé, n'est-ce pas ? Vous remarquez un problème tôt, alors vous pouvez le résoudre avant qu'il ne soit trop tard. C'est vraiment puissant, est-ce que c'est toutes les semaines ? Est-ce que c'est tous les mois ? Est-ce que c'est tous les trimestres ? Eh bien, cela va dépendre de votre contexte, n'est-ce pas ? À quelle vitesse évolue votre environnement ? Mais une sorte de cadence d'intégration est super précieuse. Plus votre projet devient complexe, plus cela devient important. Combien d'entre vous ont quelque chose comme cela dans votre environnement ?
Levez la main, je suis juste curieux.
C'était étonnamment peu. Combien d'entre vous sont dans un contexte de développement multi-équipes à nouveau ? D'accord, vous pourriez envisager cela, n'est-ce pas ? Encore une fois, il n'y a pas de solution miracle. Il n'existe pas de meilleure pratique. Mais ceci est l'une de ces pratiques généralement assez bonnes. D'accord. Retour aux Lego, boucle de rétroaction, n'est-ce pas ? Nous faisons cette chose tous les deux mois, cette planification en grande salle. Et je pense à cela comme un alignement en tant qu'événement social. Et c'est en fait étonnamment puissant. Parce que dans le passé, nous avions cette armée de propriétaires de produits et de développeurs de produits et de chefs de projet qui passaient tout leur temps à courir pour synchroniser. Ils géraient des feuilles de calcul et envoyaient des e-mails et organisaient des réunions, juste pour essayer de créer de la synchronisation. Eh bien, cela a en quelque sorte disparu. Les gens sont toujours là, ils utilisent simplement leur temps pour des choses plus intéressantes que de simplement synchroniser les gens. Alors, comment cela s'est-il produit ? Eh bien, la solution était vraiment la planification en grande salle. Réunissez tout le monde. Dans notre cas, c'est un événement d'une journée complète, qui a lieu tous les deux mois, et il y a environ 150 personnes. Environ 30 d'entre elles sont simplement des invités d'autres parties de LEGO qui sont vraiment fascinés par cette chose. Donc ils viennent pour regarder, et ensuite ils sont inspirés. Mais de toute façon, c'est Ça commence par une démonstration.
Oh, le son. Pouvez-vous allumer le son ?
Le son a disparu.
C'est juste un peu d'inspiration. Oh, c'est juste une courte vidéo.
Juste pour donner aux gens une idée de ce que nous avons livré au cours des deux derniers mois chez LEGO. Ceci est le matériel numérique sur le site web, d'autres outils, etc. Cela rappelle aux gens pourquoi nous sommes ici. Cela ne remplace pas des choses comme les revues d'équipe, les revues au niveau de l'équipe, cela donne simplement une vue d'ensemble. Mais la majeure partie de la journée consiste vraiment en des sessions en petits groupes. Ce sont simplement des équipes qui font de la planification, un peu de planification à long terme, pas seulement un sprint ou une semaine ou un cycle. Ils regardent un peu plus loin. Quelles sont les grandes choses qui doivent se produire ? Et comment cela impacte-t-il ces gars-là ? Et à qui dois-je parler pour synchroniser cela ? Donc c'est un point de synchronisation. Cette planification aurait dû avoir lieu de toute façon, nous avons simplement choisi de la faire dans la même pièce en même temps. Et vous utilisez des techniques de visualisation simples. Voici les gens de LEGO Friends et leur tableau de planification. Et ce qui apparaît là, ce sont des choses comme, en fait c'est un autre thème, mais c'est un tableau de planification. Et il montre essentiellement quel problème nous allons résoudre au cours des prochains mois, quel est notre objectif. Donc dans ce cas, ils veulent permettre aux RH d'entreprise de promouvoir des emplois chez Lego sur la nouvelle expérience web Lego Careers, bla bla bla. Ou permettre à la Lego House d'administrer les visites Lego Inside. Mais il s'agit surtout des parties prenantes, des utilisateurs, et non des livraisons. J'appelle cela des objectifs basés sur l'impact. Et puis quelques objectifs ambitieux, car évidemment nous ne savons pas combien nous pouvons finir en quelques mois, donc nous ne faisons que deviner. Mais cela donne une idée, comme, l'équipe croit que ceci est réaliste, ce qui est un bon point de départ. Et nous avons mesuré cela, et nous avons appris qu'environ 90 % des choses auxquelles les équipes s'engagent sont effectivement réalisées, ce qui est vraiment, vraiment bien comparé à la façon dont c'était avant. Donc maintenant, les gens sont beaucoup plus détendus concernant les engagements, n'est-ce pas ? Ce n'est pas une promesse. Ce n'est pas 100 %. C'est 90 %. Mais cela donne au moins une idée de qui va livrer quoi, quand, n'est-ce pas ?
approximativement. Nous parlons des risques et nous parlons des livraisons. Donc c'est comme un plan très provisoire pour quelques semaines à venir, mais c'est provisoire, cela va changer.
Et puis nous avons des tours de présentation, donc les équipes se présentent mutuellement, montrant voici ce que nous prévoyons de faire, que prévoyez-vous de faire, et oh merde, si vous allez faire cela, nous ferions mieux de faire ceci en premier. Et ensuite, ils vont au tableau des dépendances pour synchroniser cela. Donc c'est juste de la synchronisation. Et ce que j'ai remarqué, c'est que bien que les développeurs aient tendance à détester les réunions, ils aiment beaucoup cela, parce que ce qui se passe, c'est qu'ils résolvent des problèmes qui les auraient frappés plus tard. Donc ils aiment vraiment ces moments. Les développeurs ne considèrent pas cela comme une réunion. Ils considèrent cela comme du travail.
D'accord, donc gardez simplement à l'esprit que ce n'est pas une chose de publication par lots de deux mois. C'est juste un point de synchronisation. Donc la publication se fait quand elle doit se faire, ce qui dépend du type de travail qu'ils font. Mais l'alignement se fait sur le rythme et la cadence.
Donc, pour ceux qui détestent vraiment le cadre SAFe, sachez que vous pouvez faire ces choses sans SAFe. Vous n'avez pas besoin de ce gros monstre de framework pour pouvoir choisir les pratiques qui s'adaptent à votre environnement, n'est-ce pas ?
Bref, c'était quelques exemples de boucles de rétroaction, n'est-ce pas ? Nous ne faisons qu'effleurer certains sujets.
Le quatrième ingrédient que j'aimerais ajouter à la soupe, ce sont des priorités claires.
Et
Ce que je veux dire par là, c'est que si vous prenez n'importe quelle organisation et que vous demandez à l'équipe de direction, quels sont tous les grands projets et initiatives en cours, n'est-ce pas ? Et demandez-leur simplement de vous dire toutes les grandes choses en cours. Et normalement, vous obtenez quelque chose comme, vous savez, juste un tas de choses, n'est-ce pas ? Voici toutes les choses en cours. Et ensuite, il leur a demandé, est-ce qu'elles ont toutes la même importance ? Ont-elles toutes la même urgence ? Ils vont probablement dire non, n'est-ce pas ? Alors vous dites, eh bien, lesquelles, vous savez, pouvez-vous prioriser cette liste ? Et ce qu'ils feront généralement, c'est dire, oui, oui, bien sûr que nous priorisons. Nous avons des priorités élevées, moyennes et basses, n'est-ce pas ? Exact. Voilà, c'est fait.
Est-ce que quelqu'un reconnaît cela ? N'est-ce pas ? Très familier, n'est-ce pas ?
C'est aussi comme ça que nous faisions les choses chez Spotify jusqu'à ce que nous organisions cet atelier, quand nous en avons finalement eu assez. Comme les managers regardaient cela, ils se disaient, ça n'a pas de sens, essayons quelque chose de différent. Alors nous avons essayé quelque chose de différent et ça a tellement mieux fonctionné que nous avons continué à le faire. Cela fait maintenant quelques années. Et la chose que nous avons essayée, qui était différente, était un concept vraiment merveilleux appelé une liste. Avez-vous déjà entendu parler de ces choses ? Une liste ?
N'est-ce pas ? Alors, qu'est-ce qui est vraiment cool avec une liste ?
Oui, une liste, c'est comme, c'est vertical. Oui, il n'y a qu'une seule chose qui peut être en haut. C'est assez brillant. Je pense que celui qui a inventé la liste devrait recevoir le prix Nobel, n'est-ce pas ?
Que se passe-t-il si vous voulez prendre celui-ci et le mettre en haut ? Que se passe-t-il ? Comment nous faisions les choses chez Spotify jusqu'à ce que nous organisions cet atelier quand nous en avons eu, vous savez, finalement assez. Comme les managers regardaient ça, ils se disaient, ça n'a pas de sens, essayons quelque chose de différent. Alors nous avons essayé quelque chose de différent et ça a tellement mieux fonctionné que nous avons continué à faire ça. Donc ça fait quelques années maintenant. Et la chose que nous avons essayée qui était différente était un concept vraiment merveilleux appelé une liste. Avez-vous entendu parler de ces choses ? Une liste ? N'est-ce pas ? Alors qu'est-ce qui est vraiment cool avec une liste ?
Oui, une liste, il y a comme, c'est vertical.
Quand on se tourne vers son nom.
Oui, il n'y a qu'une seule chose qui peut être en haut. C'est assez brillant. Je pense que celui qui a inventé la liste devrait recevoir le prix Nobel, non ?
Alors que se passe-t-il si vous voulez prendre cette chose et la déplacer en haut ? Que se passe-t-il ?
Alors celle-ci n'est plus en haut, n'est-ce pas ? C'est génial. Donc c'est ce que nous avons fait. Nous avons simplement introduit un classement unique des initiatives transversales de l'entreprise. Ce ne sont que les grandes choses, n'est-ce pas ? Les équipes itèrent sur leurs missions entre-temps, donc cela ne couvre pas tout ce qui se passe, mais cela couvre les grandes choses qui concernent différentes parties de l'organisation. Et vous pourriez argumenter que, mais certaines de celles-ci sont indépendantes. Comme celle-ci est principalement RH, et celle-ci est principalement finance, n'est-ce pas ? Pourquoi devons-nous les classer de force ? Mais il s'avère qu'il y aura toujours des contraintes quelque part, une dépendance, un budget limité ou l'accès à une ressource, quelque chose. Et si tout le monde sait que ceci est plus important que cela en ce moment, cela facilite la prise de décision. Voilà comment ça marche. Et la question directrice est, si nous ne pouvons faire qu'une seule de ces deux choses, laquelle serait-ce ? Celle-ci ou celle-là ? Si l'une de celles-ci devait être retardée d'un mois, laquelle préférerions-nous retarder d'un mois ? Si nous devions choisir, n'est-ce pas ? C'est une sorte de réflexion sur le coût du retard. J'aimerais pouvoir dire que nous étions super structurés et que nous avions vraiment fait les calculs et que nous avions le coût du retard pour ces choses. Non. Beaucoup de cela repose simplement sur l'intuition et les discussions. Mais c'est toujours très utile. Et ce qui aide beaucoup, c'est que, encore une fois, les croyances de l'entreprise, les objectifs de l'étoile polaire, rappellent à tout le monde que c'est là que nous voulons aller à long terme. Donc pour y arriver, vous savez, laquelle de celles-ci préférerions-nous ? Être en haut de la liste, laquelle devrait avancer le plus vite, n'est-ce pas ?
Exactement, elles sont classées par ordre d'importance. Tout est strictement classé par ordre d'importance. Et ce que nous avons remarqué, c'est que cela s'est répandu. Donc cela a commencé au niveau de la direction, mais ensuite cela a commencé à se propager parce que d'autres parties de l'organisation, comme la tribu infrastructure, se sont dit, oh, c'est intéressant. Si cette initiative est la plus importante pour toute l'entreprise,
Que pouvons-nous faire pour la soutenir ? Quelle serait notre contribution la plus importante à cela ? Parce que nos affaires ne sont pas sur cette liste, car cette liste ne contient que des choses vraiment grandes et larges, n'est-ce pas ? Donc peut-être des choses comme nous allons investir dans le cloud. Nous allons déplacer toutes nos affaires vers le cloud, ce qui est un exemple réel, en fait. Et cela va être en haut de notre liste, car c'est ainsi que nous pouvons soutenir la vision à long terme de l'entreprise. Donc ce serait leur version. Et le marketing, un peu la même chose. Donc nous ne forçons pas tout à s'aligner, mais en le rendant visible, nous augmentons au moins les chances.
Donc c'est vraiment juste un outil de conversation.
Mais ce que j'aime, c'est le fait que ce n'était pas imposé, ce n'était pas poussé, c'était plus comme si d'autres parties de l'organisation s'étaient inspirées, elles se sont dit, hé, ça a du sens, nous allons faire quelque chose de similaire. Et maintenant, cela est devenu presque comme une norme de facto.
Et l'idée ici, et c'est un exemple que n'importe quel outil peut être mal utilisé. Vous pouvez utiliser un outil comme celui-ci pour tuer l'autonomie, n'est-ce pas ? Comme tout le monde doit travailler sur cette histoire en haut, alors au diable l'autonomie, n'est-ce pas ? Maintenant, il s'agit davantage de donner du contexte. Donc disons que vous êtes dans ceci, disons que nous avons ces trois équipes. Travaillant sur une intégration avec la PlayStation de Sony. Nous avons ces deux-là qui travaillent sur l'expérience de course, essayant de comprendre comment Spotify peut être une bonne chose pour quand vous courez. Les deux sont des exemples réels. Celle-ci est numéro un, celle-là est numéro deux, mais nous allons quand même faire les deux. C'est juste que quand il faut choisir, si l'une doit être plus lente, alors nous préférerions que ce soit celle de la course qui soit plus lente. Bref, ici nous avons cette équipe d'outils et d'infrastructure, et ils essaient de déterminer sur quoi nous allons travailler aujourd'hui. Eh bien, maintenant cela devient plus facile pour eux parce qu'ils ont toutes ces personnes qui les sollicitent, mais maintenant ils commenceront par demander aux gens de la PlayStation de Sony, vous savez, qu'est-ce qui vous ralentit ? Comment pouvons-nous vous aider ? Et ils se concentreront sur eux tout en soutenant les autres, n'est-ce pas ? Donc c'est juste un outil. Ce n'est pas parfait. Ce n'est pas aussi propre et joli que cela en a l'air sur une image. Les choses vont toujours devenir un peu plus désordonnées. Mais cela a certainement aidé comme outil de communication.
Voici une équipe ou un squad comme nous aimons les appeler. Et il y a un autre squad qui dit, hé, nous avons besoin de votre aide, n'est-ce pas ? Et nous avons quelqu'un là-bas qui dit, vous devez passer à ce nouveau serveur de build. Et nous avons notre backlog et nous avons des tickets Jira qui arrivent et nos propres idées folles. Nous avons nos données de tests utilisateurs. Nous avons des trucs de tests A-B. Nous avons toutes ces données qui arrivent, n'est-ce pas ? Toutes ces impulsions. En tant que squad, vous êtes toujours responsable de déterminer comment utiliser au mieux votre temps.
Ce que font les tableaux de paris, c'est qu'ils vous donnent du contexte pour que vous puissiez prendre une meilleure décision. Parce que nous ne voulons pas en arriver au point où c'est à un manager de prendre cette décision parce qu'ils ne savent pas non plus. Nous voulons que les équipes prennent des décisions, mais leur donner autant de contexte que possible pour qu'elles puissent prendre une meilleure décision. Et je suppose aussi pour visualiser le fait qu'elles ont pris cette décision afin que les autres squads le sachent. Donc ce ne sera jamais parfait. Il y aura toujours des désalignements, mais cela nous aide au moins à les réduire un peu, et cela nous aide à les détecter plus tôt lorsqu'ils se produisent. D'accord ? Est-ce que cela a du sens ? Principalement, oui ? Bien.
Retour aux Lego. Je vous avais dit que je sauterais d'un sujet à l'autre, n'est-ce pas ? Retour aux Lego. Nous sommes à cet événement de planification, n'est-ce pas ? C'est un groupe de représentants de plusieurs équipes qui font principalement du travail d'infrastructure. Leur travail consiste donc à rendre les autres équipes plus rapides afin que ces équipes puissent ravir le client. D'accord ? Et la question est : que devons-nous faire pour rendre les autres équipes plus rapides ? Eh bien, il y a un tas de choses que nous pourrions faire. Dans le passé, chaque équipe avait son propre backlog. Nous avions l'équipe de recherche avec son backlog de recherche, l'équipe de surveillance avec son backlog de surveillance, l'équipe d'infrastructure de test avec son backlog d'infrastructure de test, etc. Ce qui n'a pas vraiment de sens, car que se passe-t-il si la surveillance est vraiment, vraiment importante en ce moment et que l'infrastructure de test ne l'est pas tellement ? Nous avons ce dont nous avons besoin. Il serait préférable que nous aidions ces gars, non ? Donc, pour permettre cela, nous avons maintenant un seul backlog en entrée de cet événement d'alignement. Fondamentalement, tous les propriétaires de produits et les principales parties prenantes se réunissent avant l'événement de planification, et ils ont simplement toutes les discussions. Et ils décident que, d'accord, la séquence la plus sensée ici est celle-ci d'abord, puis celle-là, puis celle-là. Et c'est l'entrée de l'événement d'alignement. Ainsi, lorsque toutes les équipes se rencontrent, les priorités ont déjà été convenues, et la question porte davantage sur la tactique. Qui va faire quoi et dans quel ordre ? Il y a donc des argumentations. Nous ferons ces trois-là, et nous ferons ceux-là, nous ferons cela, et attendez une seconde, personne ne fait celui-là parce que c'est ennuyeux, mais quelqu'un doit le faire, alors parlons-en, et ensuite vous en discutez, n'est-ce pas ?
Donc, c'est du pull. À partir d'un seul backlog.
Certaines équipes préfèrent le faire numériquement, donc ceci est une version numérique de cela. Un seul backlog, priorisé. Voici toutes les équipes travaillant sur cette partie du système, ou travaillant sur l'infrastructure dans ce cas. Et vous prenez littéralement une tâche ici et vous la tirez comme ça. Et cette barre montre votre charge de travail, n'est-ce pas, basée sur la météo d'hier et la vélocité. Cela vous donne simplement une idée de si nous nous surengageons totalement ou si nous avons beaucoup de marge dans le système, n'est-ce pas ?
Certains problèmes ne sont cependant pas résolus. Parfois, il y a des problèmes qui sont juste, oh mon Dieu, nous ne pouvons pas résoudre cela. Donc, pendant la journée, nous avons cette revue de gestion où tous les managers se réunissent et doivent essentiellement traiter les choses qui n'ont pas été résolues. Nous avons une contrainte de priorisation vraiment importante. Nous ne pouvons pas faire ces deux choses. L'une doit disparaître. Laquelle est-ce ? Ils doivent donc prendre les décisions difficiles, faire les choix difficiles et aider. Il y a certains risques qui échappent au contrôle de l'équipe. Et un manager devra s'engager et dire, hé, je vais aider à trouver comment nous pouvons accéder au serveur de licences ou peu importe ce dont nous avons besoin. Donc, en ayant tout le monde dans la même pièce et une contrainte claire que nous avons cette seule journée et qu'après cela, nous avons terminé, n'est-ce pas ? Bien sûr, nous aurons des réunions et des alignements au fur et à mesure, mais le grand événement d'alignement a lieu pour eux tous les deux mois. Un peu rarement, pourriez-vous penser. Nous pourrions le faire plus souvent à l'avenir. Je ne sais pas, n'est-ce pas ? Mais de toute façon, il est très utile de pouvoir régler les problèmes maintenant et non pas simplement déclencher une réunion plus tard, n'est-ce pas ?
C'était donc un exemple de quelques exemples de priorités claires. Cela aide beaucoup à vraiment forcer les choses dans une seule liste. Cela peut changer. Ce n'est pas permanent, n'est-ce pas ? Mais cela aide vraiment beaucoup.
Donc, dernier ingrédient. Vous êtes toujours réveillé ? Vous voulez un dernier ingrédient, n'est-ce pas ? Et après cela, vous pourrez ajouter vos propres ingrédients, selon vos goûts.
Le dernier ingrédient est le flux, qui devrait vous être cher compte tenu du nom de cette conférence.
Et je vais l'illustrer en utilisant une petite démonstration que certains d'entre vous ont peut-être déjà vue parce que je l'utilise assez souvent. Mais je vais l'utiliser quand même parce que c'est important.
Je vais illustrer ce que je veux dire par flux et non-flux.
Et pour cela, j'ai besoin d'aide, donc je vais avoir besoin d'une Madame Jenny, qui va jouer le rôle de cliente. Applaudissez-la. Madame Jenny, super.
Et j'ai besoin de cinq volontaires pour monter ici et nous tenir compagnie. Donc cinq volontaires. Je ne vais rien vous faire de terrible. Ne vous inquiétez pas. Nous en avons un.
Youpi.
Vous pourriez penser que je suis sponsorisé par Lego, mais non.
D'accord, donc la façon dont cela fonctionne, c'est que vous représentez une sorte d'équipe, et vous allez livrer des briques Lego à Madame Jenny, parce qu'elle veut du Lego, n'est-ce pas ? Elle n'en a pas ici en ce moment. Elle veut du Lego là-bas. C'est notre environnement de production, n'est-ce pas ? Oui. Et vous avez tous des compétences différentes, donc nous allons simuler cela en faisant passer une brique Lego à travers les dix mains. Donc, je dois la faire passer à travers les dix mains, et quand elle a passé toutes les dix mains, elle est considérée comme terminée. Et ensuite, vous la livrez, n'est-ce pas ? Et elle la mettra en production. D'accord ? Donc, je commence ici. Faites-la simplement passer à travers les dix mains. D'accord. Regardez-les travailler, n'est-ce pas ? C'est un travail difficile. Oui. Cool. Et déployer. Nous allons nous arrêter là pour l'instant, n'est-ce pas ? Faites-en juste une. Cool. Applaudissez-les. Ils ont publié, n'est-ce pas ? Oui. Cool.
Oui. Maintenant, ils sont tous heureux parce qu'ils ne savent pas ce que je vais faire ensuite, n'est-ce pas ? Je vais dire, voici, construisez celui-ci.
Oh mon Dieu, comment diable ? C'est vraiment, ça doit passer par les 10 mains. Vous devez choisir, vous savez, oui, y compris celle de gauche dans votre poche.
Là, oh, je l'ai. Cool, d'accord. Super, donc maintenant ils sont échauffés, n'est-ce pas ? Ils savent comment livrer, super, cool.
Cette fois, je veux que vous comptiez parce que la plupart d'entre vous sont des geeks lean, donc nous devons mesurer le temps de cycle ici, n'est-ce pas ? Donc je veux que tu comptes combien de secondes cela prend. Fort. D'accord ? Prêt ? Compte.
Sept secondes et un bug. Toutes les dix mains ne l'ont pas touché, n'est-ce pas ? Donc celui-là est un peu buggé, non ? Rappelez-vous, toutes les dix mains doivent le toucher, y compris votre main gauche. Mais maintenant, nous avons établi une référence pour le processus, n'est-ce pas ? Sept secondes, cool.
Cette fois, je vais faire une pause au milieu. Donc quand je dis pause, vous vous figez simplement. D'accord ? D'accord.
Pause. Pause. Vous ne comptez pas quand ils sont en pause. Ils sont en pause, n'est-ce pas ? D'accord. Maintenant, ils sont en pause. Et c'est ce que Monsieur David, le manager, voit lorsqu'il passe par hasard. C'est juste son instantané, n'est-ce pas, de ce qu'il voit par hasard, non ?
Et puis il... Et puis il part en réunion, n'est-ce pas ? Donc ce n'est qu'un instantané. D'accord, et puis ils, vous savez, jouent, n'est-ce pas ? Continuez à travailler, d'accord ? Et puis pause. Monsieur David revient. Il ouvre la porte. Voilà ce qu'il voit. Que pensez-vous qu'il pense ?
Oui, qu'est-ce que vous en dites ? Attendez, laissez-moi vous donner un micro. Nous voulons entendre ses commentaires ici. Monsieur David.
D'accord.
Des gens paresseux. Oui.
Quoi ? Seuls deux travaillent. Seuls deux travaillent, n'est-ce pas ? Pourquoi les payons-nous ? Donc nous devrions faire quelque chose à ce sujet, n'est-ce pas ? Oui.
Je connais ce consultant. Oui, je connais un consultant. Il s'appelle Dave. Dois-je l'appeler ? D'accord, je vais l'appeler. Alors Dave, oui, tu es consultant, n'est-ce pas ? Tu sais comment vraiment utiliser les ressources efficacement, n'est-ce pas ? Oui, peux-tu venir ici et voir ? J'ai ce problème. Je vais te montrer. Je vais te montrer. Entre juste et je vais te montrer. Dave, oui, super. Merci. Cool. Tu vois ?
Je vois le problème.
Du gaspillage, n'est-ce pas ? Oui. Donc nous allons régler ça, d'accord ? Donc réinitialisons l'exercice. Merci. D'accord.
D'accord, nous're allons avoir besoin de son dans un instant, d'accord ? Juste une seconde. Une fois que tu es Dave, il va maintenant s'assurer que tout le monde reste occupé. Nous voulons utiliser nos ressources efficacement pour obtenir un retour sur l'argent que nous payons, n'est-ce pas ? Prêt ?
D'accord, garde-le occupé, c'est super. Nous avons beaucoup à faire, nous devons nous mettre au travail, faites-le circuler, oui. Cool, c'est super. Oh, il y a une ressource disponible. Là, là, d'accord. En voici une. Oh Dave, il y en a une, il y en a une, oui. C'est cool, d'accord. D'accord, nous en avons un là, d'accord. Cool. D'accord.
Pause, pause, figez, figez. Cool, d'accord, nous gelons. Maintenant Dave, attends, oh attends, Dave, je suis désolé, je vois deux mains avec les mains vides. Nous ne pouvons pas avoir de mains vides, oui, c'est super, super, d'accord. Cool, alors Monsieur David, reviens ici. Ce type, Dave, il est incroyable, regarde ce qu'il a fait. Monsieur David, oui, viens ici, je vais te montrer. C'est vraiment cool, n'est-ce pas ?
Qu'est-ce que tu vois ?
C'est super, n'est-ce pas ? Nous avons résolu le problème.
Efficacité maximale.
Efficacité maximale, oui. Utilisation à 100%. C'est tout simplement génial.
Je n'ai eu aucune pause. C'est quoi ce bordel ? Attends, laisse-moi voir ça. Aucun ? Pas un seul ? C'est quoi ce bordel ? Pause, pause, figez, figez. Cool, okay, on fige. Maintenant Dave, attends, oh attends, Dave, désolé, je vois deux mains avec les mains vides. On ne peut pas avoir les mains vides, ouais, c'est super, super, okay. Cool, alors Monsieur David, revenez ici. Ce gars, Dave, il est incroyable, regarde ce qu'il a fait. Monsieur David, ouais, viens ici, je vais te montrer. C'est vraiment cool, non ?
Qu'est-ce que tu vois ?
C'est super, non ? On a résolu le problème.
Efficacité maximale.
Efficacité maximale, ouais. Utilisation à 100%. C'est juste super.
Je n'ai pas eu de pauses.
Quoi ? Attends, laisse-moi voir ça. Aucune ? Pas une seule ? Quoi ? D'accord. Vous avez déjà vu ça arriver, non ? Combien d'entre vous ont vu ce problème ? Non ? Tout le monde ! C'est un problème très courant. Désolé, je vais continuer à vous utiliser. Ça va ? Oui, d'accord. Ouais, c'est un problème très courant. Et je pense que la raison est qu'à première vue, ça a l'air très bien, non ? Sauf que les choses avancent très lentement. Puis-je vous demander de venir ici ? Parce que je vais montrer une image. Donc si vous vous tenez ici. Et Jenny aussi. Ouais, tenez-vous juste ici. Et je sais que c'est une vieille métaphore qui est surutilisée, mais c'est toujours une très bonne métaphore que lorsque vous avez un système de trafic qui ressemble à ça, non ? Utilisé à 100%. Celui qui a payé pour cette route, non ? Quelqu'un a payé pour ça. Peut-être que c'est comme, ouais, vous savez, c'était une route chère. Et je suis vraiment content de voir qu'elle est pleinement utilisée. Non ? Route chère pleinement utilisée. Sauf que le but de la route n'est pas d'être utilisée, non ? Le but de la route est d'aider les gens à aller de A à B. Et on ne va pas de A à B si la route est pleinement utilisée. On va de A à B s'il y a du Et c'est à cause de la théorie des files d'attente. On ne peut pas vraiment y échapper. Et en réalité, c'est en fait pire parce que ça va probablement ressembler plus à ça, non ? Et ce qui est intéressant, c'est que si c'est votre problème, vous avez trop de travail dans le système, vous avez des gens pleinement utilisés, alors l'alignement ne va pas se produire. L'alignement n'est pas votre problème. Il faut commencer ici. Il faut permettre le flux. Maintenant, il y a cette astuce sympa, non, que nous utilisons beaucoup dans cette communauté et qui traite ce problème. Et quelle est l'astuce ?
Limites de travail en cours, ouais ? Est-il possible d'y parvenir sans limites de travail en cours ?
La limite de travail en cours est une façon, non ? L'astuce, c'est le tirage. Vous en avez entendu parler ? Tirage, non ? Alors transformons ceci en un système de tirage. Alors pouvons-nous rassembler toutes les briques ici ?
Voilà.
D'accord, maintenant transformons-le en un système de pool. Donc au lieu que je lance juste des briques,
Je fais juste comme ça. Donc prends-en une et passe-la, puis prends-en une autre, comme tu voulais le faire avant, non ?
Qu'est-ce qui se passe maintenant ? Qu'est-ce que vous voyez ?
Vous voyez le flux, non ? On a, si on fait juste une pause, une pause une seconde. D'accord, quelle est l'utilisation des ressources en ce moment, approximativement ?
Quatre mains sur dix, approximativement. Et le point clé est que je me fiche de l'utilisation des ressources parce que c'est juste ce qu'il faut. C'est juste assez. Et restez figés. On a Alex Say ici. Il n'a rien à faire en ce moment, non ? Ce n'est pas du gaspillage, non ? Cela signifie juste qu'il est prêt. Donc quand celui-là vert arrive, il l'a, non ? Ça va continuer à couler. Mais si tout le monde est occupé, alors quand la prochaine brique arrive, elle devra attendre. Donc on paie le prix d'avoir des gens apparemment inactifs, mais cela signifie que le travail lui-même n'est jamais inactif. Il continue simplement à couler, non ? Bon, alors oui, continuez à avancer, d'accord ? Je vais ajouter une dimension supplémentaire à cela. Continuez à tirer. Et si je vous disais que les rouges valent 10 fois plus que les autres ? Regardez ce qui se passe. Regardez-moi ça. Les mêmes personnes faisant le même travail, mais c'est 10 fois plus précieux. Plutôt cool, non ? Autrement connu sous le nom d'agile. Vous pouvez changer les priorités. Alors, oui, merci beaucoup. Applaudissons-le pour avoir été contrarié.
Merci.
Bien joué.
Des accessoires humains pour les exercices. Merci beaucoup d'être venus. D'accord.
Donc je me rends compte que c'est prêcher des convertis, n'est-ce pas ? Lean Kanban France, c'est une conférence lean, la plupart d'entre vous connaissent ces choses, mais je veux encore insister parce que si vous ne réglez pas ça, oubliez l'alignement, d'accord ? Donc, il faut commencer par là.
D'accord, donc c'est l'ingrédient numéro cinq, le flux.
Nous avons terminé.
Pute.
Mais attendez, de quoi n'avons-nous pas parlé ? Qu'est-ce qui est vraiment important et dont nous n'avons pas parlé pour que tout cela fonctionne ?
La valeur est un aspect important, oui. C'en est un autre. La question est vraiment, mais attendez, attendez, attendez, attendez, attendez, attendez. Qui met les ingrédients, hein ? Est-ce qu'ils apparaissent comme par magie, hein ?
Le cuisinier. Le leader.
N'est-ce pas ? Nous avons besoin de leaders.
Expérimentez avec les ingrédients, voyez ce qui fonctionne, d'accord ? Parfois, les choses se passent bien, parfois pas tout à fait, d'accord ?
Des leaders.
Voyez-vous, j'ai remarqué que dans notre communauté, dans la communauté Agile Lean, nous sommes très attachés à la décentralisation. Nous aimons parfois croire que les leaders ne sont pas nécessaires, n'est-ce pas ? Je vais m'en débarrasser pour que nous puissions faire le vrai travail à la place. Je trouve cela, moi-même je le croyais autrefois, mais j'ai remarqué, surtout chez Spotify, j'ai facilité beaucoup des grandes rétrospectives lorsque nous avons fait quelque chose de grand et que nous voulions faire un suivi sur ce que nous en avons appris. Nous faisons des rétrospectives au fur et à mesure, mais ensuite nous en faisons une à la fin. Et le thème commun est que nous nous sommes améliorés dans les grands projets. Nous étions nuls à ça avant. Nous nous sommes améliorés. Et la principale différence est le leadership. Surprise, n'est-ce pas ? Alors parlons-en un peu. Donc nous sommes tellement auto-organisés. Ouais, mec, qui a besoin de leaders ? J'ai trouvé que souvent dans les efforts réussis, il y a un leader quelque part, mais parfois ils se cachent, n'est-ce pas ? Parfois ils s'appellent autrement. Oh, non, je ne suis pas un leader. Je suis juste un coach. D'accord. Mais vous vous assurez que tout le monde comprend où nous allons et pourquoi, n'est-ce pas ? Oh, oui, bien sûr. D'accord. Donc si nous regardons, il y a cette tendance à croire que les leaders sont tous mauvais et méchants. J'appelle ça la phobie des leaders, une peur irrationnelle des leaders et du leadership. La croyance erronée que tous les leaders sont méchants et que tout leadership est mauvais, n'est-ce pas ? Quelqu'un veut-il avouer cette phobie ? J'ai l'arachnophobie. J'ai peur des araignées, d'accord ? J'ai peur des leaders.
Il y a certaines entreprises qui sont souvent citées comme modèles d'auto-organisation. Des entreprises qui disent, eh bien, elles n'ont pas de leaders. Elles n'ont pas besoin de leaders parce qu'elles sont complètement auto-organisées. Semco, Valve, Zappos, ce sont souvent celles qui sont citées. Vous lisez des articles à leur sujet et ils insistent souvent sur l'absence de patron, n'est-ce pas ? Mais si vous regardez en coulisses, soigneusement derrière les coulisses, que voyez-vous ?
Hmm.
N'est-ce pas ? Qui se cache derrière les buissons ? Eh bien, il y a des gens qui se cachent derrière les buissons. N'est-ce pas ? Il y a un gars qui se cache derrière les buissons chez Valve. Il y a un gars qui se cache derrière les buissons chez Zappos. N'est-ce pas ? Qui a permis à cette auto-organisation de se produire en premier lieu ? Qui prend les décisions chez Valve ? C'est Gabe. C'est son entreprise. C'est lui qui a permis cela. C'est grâce à sa bénédiction que les équipes peuvent être auto-organisées et ne pas avoir de managers. Donc c'est le paradoxe intéressant du manager qui dit, vous n'avez pas besoin de managers. J'utilise mon autorité pour dire que vous n'avez pas besoin de mon autorité, ce qui est plutôt intéressant.
Et si nous reconnaissons ces leaders, je pense que la vie devient un peu plus facile, nous avons une communication plus honnête. De plus, je pense que cela vaut la peine, ne serait-ce que pour des raisons éthiques, de reconnaître les personnes qui font du bon travail. Comment appelons-nous ces leaders ? Eh bien, cela va dépendre. Certains les appellent un chief product owner, certains un chef de projet, ou un road manager, un grand manitou, un chef manitou, un dictateur bienveillant en chef, je ne sais pas. Appelez ça comme vous voulez, d'accord ?
Pour de petits efforts, une ou deux équipes, probablement pas nécessaire, mais pour quelque chose de grand, Encore une fois, complexe ? Oui, ce sera nécessaire. Mais leur travail est différent de celui du leadership traditionnel, plus hiérarchique et descendant. Je pense à cela comme une personne qui détient la vision, qui détient l'image de là où nous allons et pourquoi. Donc ici, nous avons un groupe d'équipes construisant différentes parties de cette maison. Le leader leur rappelle comment tout cela va s'assembler, qui va emménager et ce qu'ils vont en faire. De plus, le leader met en place toutes ces choses dont j'ai parlé, n'est-ce pas ? La transparence, les boucles de rétroaction, s'assurer que tout est en place pour qu'ils puissent prendre du recul.
Donc, ce n'est pas le cou unique qu'on peut tordre, ce n'est pas la seule personne à qui on veut pouvoir couper la tête si les choses tournent mal. C'est plutôt la personne qui est capable de créer un sens partagé de la responsabilité.
Je crée un environnement où les gens sont réellement motivés à se soucier du produit et ensuite du résultat.
Et c'est difficile. C'est pourquoi ces personnes sont nécessaires. Ce n'est pas moi qui aligne les équipes. Ce n'est pas moi qui cours pour synchroniser. C'est plutôt moi qui mets en place le tableau des dépendances ou qui trouve des personnes qui connaissent ce genre de choses, ou qui crée des forums de communication comme la planification en grande salle afin que les équipes puissent s'auto-aligner parce que c'est tout simplement plus efficace.
Ce n'est pas moi qui prends les décisions. Chaque fois que je dois prendre une décision, c'est un signal d'alerte. Pourquoi a-t-il fallu que cela arrive à ma table ? Au lieu de cela, je crée un environnement où les équipes sont capables de prendre des décisions par elles-mêmes, où elles ont le contexte dont elles ont besoin, le courage nécessaire, un environnement où l'échec est acceptable, etc.
Et enfin, comme je l'ai illustré dans l'exercice, ce n'est définitivement pas mon travail de courir pour m'assurer que les gens restent occupés. Mon travail est de créer un environnement où les gens réalisent que s'occuper n'est pas une bonne idée, c'est une mauvaise idée. Et nous voulons une sorte de moyen de nous concentrer sur le flux plutôt. Donc, je regarderais des choses comme mettre en place des contraintes de fouet, des systèmes de tirage, rendre le travail visible, etc. Voilà ce que je considère comme une sorte de bon leader dans un contexte d'autonomie alignée. Et cela ne doit pas nécessairement être une seule personne. Cela peut être un binôme travaillant ensemble. Cela peut être un trio. Chez Spotify, nous utilisons presque toujours ce genre de combinaison avec quelqu'un d'un point de vue technique, quelqu'un avec une perspective produit, quelqu'un avec une perspective design, parce qu'ils vont voir le monde de différentes manières, et nous voulons ces trois perspectives. Donc, comme une mini-équipe de direction. Pas dans tous les cas, mais typiquement pour les plus grandes initiatives.
Donc, oui, pour conclure, voici quelques ingrédients. Ce n'est évidemment pas une recette complète pour l'alignement. C'est une chose délicate. C'est difficile. Mais je considérerais ceux-ci comme les bases. Une sorte de but partagé. Une sorte de transparence. Plus il y en a, mieux c'est.
Des boucles de rétroaction à tous les niveaux.
Des priorités claires, et ensuite un sens du flux.
Oui. Merci.