Mattias Skarin
Transcription (Traduit)
Bienvenue à tous.
Asseyons-nous et lançons ce spectacle. Mettons-nous en route.
Veuillez accueillir. Prenez place devant. Ne soyez pas timides. Je ne mords pas. Du moins, pas encore. Vraiment ? Non.
D'accord, commençons. Je m'appelle Mattias. Je suis un gars dynamique. Je travaille à Stockholm. Et je suis très passionné par la recherche de meilleures façons de faire le développement de produits. Et quelques-unes des méthodes sur lesquelles je suis tombé, bien sûr, c'est le Kanban. Et j'ai appliqué le Kanban dans de nombreux cas et situations différents. Alors j'ai pensé, partageons certaines de ces idées avec vous. Et très récemment, j'ai publié un livre, celui à droite de mon point de vue. Et je ne parlerai pas des détails de chaque cas que vous trouverez dans le livre. Ce que je vais faire, c'est vous parler de certaines choses qui se sont produites à travers ces cas. Que vous pourriez trouver intéressantes.
Des choses comme, d'accord, alors qu'est-ce qui s'est passé ensuite ? D'accord.
Donc, j'ai fait une petite expérience avant d'entrer dans la salle. J'ai créé un Kanban de conférence. Et j'ai effectivement créé quelques tickets là-dessus. Donc, lorsque de nouveaux participants arrivent, ils s'assoient, écoutent attentivement, vraiment très attentivement. Ensuite, ils prennent le téléphone, oh non, j'ai vérifié mon email, posent une question, se lèvent et partent. Mais quoi ? Cela ne vous programme pas ? Quoi ? Personne n'est venu se lever et partir quand j'ai déplacé le ticket sur le tableau ? Quoi ? Pourquoi ?
Eh bien, une raison évidente pourrait être que c'est moi qui ai créé cela et pas vous.
Cela n'a aucun sens pour vous.
C'est une idée importante.
Si avoir un tableau visuel ou les éléments qui s'y trouvent n'a aucune signification pour vous, vous n'allez probablement pas y prêter beaucoup d'attention. C'est une idée importante. Donc, la première chose que vous devez faire en tant que coach qui met en œuvre le Kanban est de valider que les éléments que vous y mettez ont un sens pour les personnes qui y travaillent.
L'entreprise est un bon moyen de construire un comportement partagé. Donc, vous pouvez créer des comportements partagés dans une équipe, vous pouvez le faire à travers une chaîne de valeur, à travers les départements. Ce que cela fait, c'est que lorsque les gens interagissent, ils commencent à se faire confiance. Et ils ressentent un sentiment d'adhésion. Voici ce que nous faisons ensemble. Nous agissons de cette manière. Et cela construit la confiance. Et cette confiance est votre levier pour apporter des améliorations. Donc, la première question à laquelle vous allez être confronté est, bien sûr, du genre, pourquoi diable devrais-je commencer à mettre des post-its sur un mur et les déplacer ? Et si vous ignorez cette question, il est très probable que les gens ignoreront votre tableau. Cela m'est arrivé. Je vous l'accorde. Mais et si cela pouvait signifier que nous pourrions agir en tant qu'unité plutôt qu'en tant qu'individus ? Est-ce que cela aurait un sens pour vous ? Oui. En fait, cela a beaucoup de sens. Donc, je vais vous présenter la Loi de Skarin. Ce n'est pas... Souvent, on a l'occasion de présenter une nouvelle loi, alors j'ai décidé de saisir ma chance. La voici. Elle dit que le nombre d'initiatives d'amélioration que vous verrez dans un système commun est directement proportionnel à la confiance que les membres ont dans le but de ce système.
Donc, s'il n'y a pas de confiance dans ce que vous faites et si vous ne croyez pas que cela ajoute de la valeur pour les personnes qui travaillent dans ce système, elles ne vont probablement pas simplement l'ignorer. Et vous verrez des choses comme un mur où rien ne bouge. Des choses comme ça. Je vais donc partager quelques idées à travers quatre études de cas différentes. Kanban en dehors de l'IT, Kanban utilisé à travers différentes unités de marché et à travers une entreprise, dans la gestion du changement, et une dernière histoire, que se passe-t-il lorsque vous utilisez Kanban et que vous échouez. Que pouvons-nous apprendre de cela ?
Il y a des leçons que nous pouvons tirer. Donc, j'ai pensé partager certaines des idées à travers ces cas. Et je n'entrerai pas dans les détails de chaque cas. Ce dont je vais parler, c'est de la manière dont nous avons introduit Kanban. Quel a été le point de bascule ? Quand est-ce que cela est passé d'être quelque chose d'étranger à quelque chose que nous aimons et dont nous nous soucions ? Qu'est-ce qui s'est passé ensuite ?
Ce sont les types de choses que je vais parcourir. Commençons donc par le premier cas, Kanban en dehors de l'IT. Et pour donner un peu de perspective, il s'agit d'un service de back-office dans une banque. Donc, ces personnes ne développent pas de logiciels, elles ne gèrent même pas de logiciels, elles gèrent des services, des pensions, des paiements, des remboursements, des choses comme ça. La manière dont le Kanban a été introduit était qu'un des managers de cette équipe, une équipe d'environ 20 personnes, a vu le Kanban au département des opérations et elle a dit, eh bien, que se passerait-il si nous l'utilisions ?
Elle avait examiné le Lean dans l'IT et certaines autres pratiques, mais cela lui semblait plus adapté. Donc, elle m'a demandé de venir et de trouver comment introduire le Kanban. Et ce que nous avons fait, c'est que nous avons invité l'équipe, nous avons fait une demi-journée de formation sur les principes derrière le Kanban, pas le tableau, un peu comme, d'accord, quel est le bénéfice que nous essayons d'obtenir ? Nous avons fait une rétrospective, comme, d'accord, quels sont vos défis ? Et ensuite, nous avons dessiné un tableau Kanban ensemble, puis nous avons demandé aux membres de donner un vote de confiance pour savoir s'ils pensaient que cela serait utile. Et nous leur avons demandé de faire un vote à main levée. En quoi cela serait-il utile ? Oui, absolument. Eh bien, peut-être, mais je suis prêt à essayer. Non. Nous avons obtenu les pouces en l'air. D'accord, alors nous avons dit, faisons-le. Maintenant, un peu de perspective. Ce n'est pas une équipe ordinaire.
Ils sont autonomes dès le premier jour.
En fait, ils l'étaient même avant que je les rencontre. Si vous venez les voir avec un problème, ils le résoudront avant que vous ne quittiez la pièce. Et je ne parle pas des managers, je ne parle pas de chaque membre de cette équipe. Je parle de presque chaque membre de cette équipe. Alors, il faut juste commencer à se demander Mais à quoi diable avez-vous besoin de Kanban ? Vous vous auto-organisez, vous avancez par vous-mêmes.
À quoi allez-vous l'utiliser ? J'avais cette question en tête. J'en ai discuté avec le manager, mais nous nous sommes dit, d'accord, nous ne comprenons pas vraiment, mais essayons d'abord avant d'arrêter cette expérience. Alors, nous leur avons donné une certaine marge de manœuvre et nous avons commencé. La première chose que nous avons faite a été d'installer le tableau. Et à ce moment-là, ils ont en fait créé un tableau vraiment bien organisé. Ils avaient beaucoup d'interactions. L'équipe se réunissait devant le tableau chaque semaine, tous les jours. Le manager venait chaque mercredi et demandait quels étaient les problèmes que nous devions résoudre, puis il s'attaquait directement à ce problème.
Bien sûr, une des choses qu'ils ont inventées, c'est que les élans sont de super limites de fouet.
Une chose vraiment cool... que cette équipe a faite, c'est qu'ils ont introduit une manière totalement nouvelle d'aborder et de réaliser des améliorations.
Et je l'appelle les améliorations basées sur le Fika. Et Fika en suédois, c'est un nom pour prendre un café et discuter.
Donc, pour vous donner une idée, cette équipe n'est pas au sommet de la hiérarchie ni de l'importance stratégique de cette entreprise.
Donc, chaque fois qu'ils ont un problème, comme ce logiciel avec lequel je travaille est nul, ou quelqu'un d'autre me critique constamment, ou pourquoi les gens ne font pas ce que je pense qu'ils devraient faire, devraient se comporter ?
Ils ne vont pas voir la haute direction pour demander aux autres de se comporter dans une certaine direction. Ils doivent trouver d'autres moyens d'obtenir de l'aide. Et une des choses vraiment astucieuses qu'ils ont faites, c'est que lorsque les managers ont vu qu'ils voulaient de l'aide d'une autre équipe, comme une équipe front-end, ils commençaient simplement par prendre un café avec les membres de cette équipe pendant trois ou quatre semaines, apprendre à les connaître, et après avoir fait cela, ils demandaient, d'accord, quel type de problèmes voyons-nous ensemble que nous devons résoudre ? Et une fois cela fait, ils allaient le résoudre. Et ces gars-là ont fait des choses incroyables. Ils ont réussi à faire faire par d'autres équipes de l'entreprise les choses qu'ils voulaient. Et ils ont même réussi à obtenir qu'une équipe de développement, qui n'avait jamais de temps pour eux parce qu'ils étaient simplement en train de... Donc, faire entrer des choses dans le backlog de l'équipe de développement signifiait faire... des petites, grandes choses importantes. Ils demandaient de petits changements comme, d'accord, comment pouvons-nous simplement simplifier la saisie de ces informations pour que cela ne prenne pas beaucoup de temps ?
Ils ont obtenu qu'un membre de l'équipe de développement s'assoie à côté d'eux pendant une journée et apporte les modifications en même temps qu'ils travaillaient dans ce système. Donc, vraiment, des façons très cool par lesquelles ils ont effectivement amélioré les choses.
Quel a été le point de bascule ? Eh bien, deux choses, n'est-ce pas ? Ils se souciaient beaucoup de voir l'image complète de ce sur quoi ils travaillaient.
Et ils se souciaient également de s'assurer que les choses importantes, liées à la législation, ne se perdent pas quelque part. Donc, s'ils avaient un ticket et que quelqu'un tombait malade par accident, ce que Kanban les a aidés à faire, c'était que tout le monde dans l'équipe puisse le voir et s'engager pour résoudre ce problème. Donc, quand ils ont remarqué cela, c'est à ce moment-là qu'ils ont dit, en fait, c'est un outil vraiment utile pour nous.
Un apprentissage important que nous avons fait était que si vous leur demandez s'ils utilisent Kanban aujourd'hui, ils répondraient, eh bien, oui, parfois. Et ils le font en période de très grand stress. Il y a des périodes de l'année où ils ont soudainement beaucoup de travail et beaucoup de pression temporelle, et d'autres périodes de l'année où les choses sont assez calmes. Et ce qu'ils font, c'est qu'ils appliquent Kanban pendant cette période. où ils ont beaucoup de stress.
Nous avons mesuré le flux, n'est-ce pas ? Donc, nous avons regardé combien de tickets circulaient sur le tableau, nous avons collecté des métriques, mais c'était plus pour apprendre si nous nous concentrions sur les bonnes choses. Ce n'était pas l'outil principal pour conduire l'amélioration.
Le rythme réel d'amélioration dans ce scénario était si élevé que les graphiques ne pouvaient pas suivre. Et regarder les graphiques, c'était comme regarder toutes les choses. Donc, ce que nous devions faire était simplement observer où se trouvaient les problèmes, et ensuite, une fois que nous étions d'accord sur le fait que c'était un problème, alors aller l'attaquer.
Premier cas. Maintenant, un petit défi pour vous lorsque je passe en revue ces cas est de réfléchir aux schémas qui se répètent dans ces cas.
Deuxième cas, Kanban d'entreprise. Un peu de contexte à nouveau.
Donc, il s'agit d'une entreprise d'environ 500 personnes, divisée en deux départements différents. Un département marketing avec trois unités marketing distinctes, des flux de valeur. Un département informatique avec plusieurs équipes, comme cinq ou six équipes en développement, puis la gestion du changement et les opérations. Quelques détails supplémentaires qui sont importants à comprendre, c'est qu'ils avaient des opinions différentes sur l'état des choses. Si vous allez au département marketing, ils diront, eh bien, vous savez, ils font de l'agile et ils le font depuis trois, cinq ans. Nous ne voyons que dalle.
Le développement se plaignait, en fait, qu'il y avait des processus vraiment lourds autour d'eux. C'est ce qui nous empêche de faire les choses. Et si vous allez aux opérations, ils auraient une opinion complètement différente. Ils diraient, nous sommes surchargés de travail et s'il vous plaît, arrêtez. De pousser autant de changements tardifs, n'est-ce pas ? Vous ne pouvez pas changer un jour avant une mise en production parce que nous devons refaire tous nos tests d'intégration.
Donc, des opinions très différentes sur ce qu'il faut corriger.
C'est une entreprise très traditionnelle, donc ce n'est pas votre prochain Spotify. Et c'est une des raisons pour lesquelles je trouve vraiment intéressant de travailler avec eux, pour apprendre. Donc, comment une entreprise traditionnelle qui a beaucoup de patrimoine peut-elle s'améliorer ? Que se passe-t-il si vous n'avez pas les prochains super-héros dans votre département ? Que faites-vous alors ?
Ils sont responsables de grandes parties de l'infrastructure du pays.
Maintenant, imaginez ce que cela signifie. Si les choses se cassent, ils ne redéploient pas le serveur web.
Cela a mis beaucoup d'attention sur la qualité, n'est-ce pas ? Et une des raisons pour lesquelles vous voyez cette accumulation dans de nombreux processus très distincts.
Ils ont également, une petite note sur la complexité, environ 600 systèmes qu'ils maintiennent à un seul moment. Donc, ce n'est pas seulement à propos des équipes faisant du développement en ce moment. C'est beaucoup à propos des autres systèmes qu'ils doivent également gérer. Cela vous donne un peu de perspective.
Comment avons-nous commencé ? La première chose qui s'est passée, c'est que j'ai été entraîné dans une réunion avec une manager du marketing. Et elle a dessiné une image, et nous avons ensemble dessiné une image sur un tableau blanc. Rake, ils ne redéploient pas le serveur web.
Cela a mis beaucoup l'accent sur la qualité, n'est-ce pas ? Et l'une des raisons pour lesquelles vous voyez cette accumulation dans de nombreux processus très distincts.
Ils ont aussi, une petite note sur la complexité, environ 600 systèmes qu'ils maintiennent à un seul moment. Donc, il ne s'agit pas seulement des équipes qui font du développement en ce moment. Il s'agit beaucoup des autres systèmes qu'ils doivent également gérer. Cela vous donne un peu de perspective.
Comment avons-nous commencé ? La première chose qui s'est passée, c'est que j'ai été entraîné dans une réunion avec un manager du marketing. Et elle a dessiné un schéma, et nous avons ensemble dessiné un schéma sur un tableau blanc. Donc, nous avons demandé, que se passe-t-il lorsqu'une idée passe du début à une équipe de développement ? Racontez-moi le parcours. Et nous avons vu de nombreux agents différents impliqués dans ce processus. Et le chemin pour ces idées n'était pas très clair. En fait, nous avons convenu que nous n'avions pas d'idée de la manière dont cela se passait vraiment.
Ce que nous n'avons pas fait, c'est prendre ce schéma, sortir vers le département de développement et dire, nous avons une idée de la façon de régler cela. Nous allons simplement supprimer ces agents, avoir une relation en tête-à-tête avec chaque équipe de développement, et puis commencer. Non, nous ne l'avons pas fait de cette façon. Nous avons pensé que cela pourrait être un indice. Mais ce n'est probablement pas la seule partie de ce problème. Donc, ce que nous avons fait, c'est
Nous avons interviewé quelques personnes différentes tout au long de cette chaîne de valeur en une journée, en leur demandant, d'accord, alors quels sont les défis que vous voyez ?
Sur cette base, j'ai suggéré un certain nombre d'expériences à réaliser. L'une était un essai de Kanban, mais il y en avait quatre ou cinq autres.
Nous les avons présentées dans une salle où chaque équipe était présente. Donc, nous avons dit, voici ce que nous voyons, voici les choses que nous aimerions essayer. Ensuite, nous avons demandé aux membres de cette salle de voter à main levée à nouveau. Seriez-vous prêts à essayer cette expérience ?
Et quatre sur cinq ont dit oui, et la cinquième a dit non. Je ne vois pas l'intérêt de faire cela. Donc, nous avons dit, d'accord, laissons tomber pour l'instant. Et si ce problème persiste, alors peut-être reprendrons-nous cette expérience. Et voici le premier point de bascule.
Nous avons écouté les personnes qui y travaillaient, et s'ils avaient une idée concrète et vraiment bonne expliquant pourquoi cela était assez inutile, nous avons dit, d'accord, laissons tomber pour l'instant. Nous ne le leur avons pas imposé.
Donc, nous avons commencé. Nous avons mis en place un tableau Kanban. Et nous avons établi une certaine interaction entre différents départements marketing, départements de développement, départements d'exploitation, etc. La première chose que nous avons observée, c'est que, d'accord, ces gars travaillent en agile, ils utilisent Scrum. Nous posons une question simple. Où est mon idée de produit ? Et il s'avère que c'était vraiment difficile à répondre. Voici donc un Scrum Master, l'une des équipes de développement, parcourant son backlog Scrum, essayant de penser aux idées de produits qu'elle doit mettre sur un tableau Kanban. Et ce fut un exercice non trivial pour tous les impliqués, mais nous avons finalement réussi à le mettre en place.
Quel a été le point de bascule ? Eh bien, l'une des expériences que nous avons suggérées était d'arrêter de faire des sprints et de passer à un flux continu. Cela signifiait pour les équipes de développement abandonner une pratique et une habitude auxquelles elles étaient habituées depuis de nombreuses années. Mais ils ont accepté cela, en disant, d'accord, essayons. Maintenant, le premier point de bascule important s'est produit dans une situation après environ un mois, puis deux des équipes de développeurs ont dit, vous savez, nous voulons faire cela, mais nous sommes limités par quelques gros blocages.
Et ce que nous avons fait, c'est que nous avons dit, d'accord, Nous n'allons pas pousser de nouvelles choses dans ce flux tant que nous n'aurons pas résolu vos blocages. Donc, nous avons créé un espace en haut du tableau disant, voici les blocages. Et nous avons dit, tant que ces blocages sont en rouge, nous allons retenir de nouvelles idées de produits.
C'était un message vraiment important que nous leur avons donné. Cela, d'accord, il ne s'agissait pas de créer un tableau Kanban, il s'agissait d'améliorer les choses. Et l'entreprise était prête à prendre des risques assez élevés pour le bien-être des personnes qui y travaillaient. Ce n'était pas que des mots. C'étaient des choix difficiles qu'ils faisaient. Et nous les faisions dans les situations où nous voyions le problème, là et à ce moment précis.
Comment avons-nous fait des améliorations ? Eh bien, nous avons essayé une approche très simple. Nous avons demandé aux managers et aux Scrum Masters de regarder un graphique et le tableau une fois par mois, juste une demi-heure chaque mois, et de déterminer, d'accord, quel est le délai de bout en bout pour les choses ?
Et sur cette base, ils doivent suggérer des problèmes, des moyens de résoudre les problèmes, et les nouvelles expériences.
Ensuite, après un mois, nous avons analysé cette expérience et nous nous sommes demandé, d'accord, cela nous aide-t-il vraiment ou non ? Quelques éléments que nous avons remarqués dès le début, c'était très grossier de regarder le délai complet de bout en bout. Nous devons le décomposer en plus petits morceaux pour avoir une idée de ce qui consomme le plus de temps.
L'autre chose que nous avons également observée, c'est quoi, ça ? Je veux dire, d'accord, nous pouvons être aussi rapides que n'importe qui, mais si nous ne construisons pas des choses que les gens aiment, qui s'en souciera ? Donc, nous avons ajouté une section à la fin du tableau Kanban où, si nous plaçons l'idée de produit après son déploiement, Nous demandons des retours des départements marketing et des personnes utilisant le produit. Donc, est-ce que c'est bon ? Est-ce que c'est cool ? Ou est-ce que ça craint ? Et cela nous donnera des retours très francs. Et sur cette base, Nous avons placé le ticket en haut. Était-ce populaire ? En bas. Et si c'était en bas, alors nous avons réuni un certain nombre de personnes impliquées dans le développement de ce produit et avons fait une analyse des causes racines ensemble.
Maintenant, quelques éléments intéressants de ce cas sont les suivants.
Nous avons fait des estimations, des estimations vraiment simples sur les idées de produits dès le début. Donc, nous avons estimé petit, moyen, grand. Donc petit étant jaune, moyen étant vert, grand étant bleu. Et ensuite, nous avons corrélé cela au résultat réel. Donc, d'accord, combien de temps a-t-il fallu pour livrer cela réellement ?
Alors, que remarquez-vous ?
Donc, vous avez dit que c'est une ligne assez droite. D'accord. Remarquez-vous autre chose qui est...
Aucune corrélation entre ces liens.
Donc, aucune corrélation entre ces liens. C'est très intéressant, n'est-ce pas ? Et nous l'avons observé également. En fait, il semble que cela n'ait pas vraiment de sens. L'estimation initiale que nous faisons a très peu de corrélation avec le temps qu'il faut réellement pour publier quelque chose. Donc, il y a d'autres facteurs en jeu autres que l'estimation de la taille qui sont en fait plus corrélés avec le délai de livraison que l'estimation initiale. Donc, je suggère une expérience. Donc, j'ai dit, d'accord, abandonnons les estimations. J'ai une seule catégorie. Appelons ça environ 80 jours ou 80 jours complètement libres, comme trois, quatre mois.
Ils n'ont cependant pas accepté cette expérience.
Ils ont dit, non, continuons à faire petit, moyen, grand. D'accord, alors j'ai dit, il n'y a pas de gros coût à faire cela, alors continuons ainsi. Mais voici une situation où nous aurions pu apprendre de notre résultat, mais nous ne l'avons vraiment pas fait.
Mais cela a conduit à beaucoup de questions sur, d'accord, alors quels sont ces autres facteurs ? Et c'est à ce moment-là que nous avons commencé à résoudre les problèmes et à analyser.
Alors, où en sont-ils aujourd'hui ? En fait, ils n'utilisent plus Kanban Enterprise sur les mêmes équipes. Ce qu'ils ont fait, c'est que des personnes du département informatique ont physiquement déménagé et sont maintenant assises au sein des équipes de développement commercial.
Maintenant, ils peuvent utiliser Kanban, c'est parfois depuis que je leur rends visite, et je pense qu'ils le font dans certains cas, mais ils ne le font pas de la même manière que lorsque nous avons commencé. Pourquoi ?
Eh bien, parce que je pense qu'ils ont d'autres problèmes maintenant. Kanban a été vraiment utile pour accroître leur maturité, il a été très utile pour garantir que les conversations à travers la chaîne de valeur aient lieu, mais lorsque nous avons résolu les plus gros blocages, nous devions trouver d'autres façons de travailler, et ils l'ont fait.
Donc, certaines des leçons. Donc, le Kanban Anticrust a été vraiment crucial pour ouvrir la porte à la conversation entre ses départements. Et certaines difficiles.
Se concentrer systématiquement sur l'amélioration du délai de livraison de bout en bout a fonctionné.
Ces gars ont fait un tour de passe-passe. Ils ont simplement résolu un problème après l'autre jusqu'à pouvoir déployer en quelques jours.
Maintenant, la partie la plus difficile a impliqué de changer les vieilles habitudes. Donc, je vais vous raconter une histoire. L'une des choses avec lesquelles nous avons eu du mal était d'obtenir l'acceptation qu'une équipe de développement puisse déployer des choses en staging et en production. C'était un sujet sensible et nous avons dû parler avec de nombreux intervenants différents pour essayer d'obtenir l'acceptation de cette expérience. En fait, nous en sommes arrivés à un point lors d'une réunion où nous avions discuté des choses si longtemps et nous avons demandé, quels sont les, y a-t-il d'autres
commentaires sur les raisons pour lesquelles nous ne devrions pas faire cela, et la salle est restée silencieuse. Et l'un des développeurs a en fait dit, d'accord, demain je le ferai.
Et personne n'a objecté. Mais personne n'a dit oui non plus. Donc, après un certain temps, il arrive un moment où il faut sauter.
Vous avez une pratique existante, vous avez un exemple de quelque chose de mieux, je parle aux gens, mais à un moment donné, il faut le faire. On ne peut pas toujours rester du côté sûr.
Donc, ces gars ont amélioré d'un facteur de deux en environ un an. Donc, ils ont maintenant deux fois la vitesse. Je pense qu'en fait, ils ont plus. Mais juste pour vous donner une idée de la rapidité avec laquelle les choses fonctionnent aujourd'hui.
Parlons de ce cas. Donc, voici Kanban dans la gestion du changement. Et encore, un peu de contexte. Donc, cette équipe travaille en fait à l'intérieur du flux de valeur Kanban Enterprise.
Et la manière dont cela a commencé, c'est que les managers ont observé ce qui se passait avec l'une des équipes de développement qui utilisaient Kanban, et ils se demandaient, d'accord, est-ce que cela pourrait nous être utile ? Et ils sont allés suivre un cours, un cours Kanban, et dans le train du retour, ils ont commencé à esquisser leur propre tableau Kanban.
Et ils ont dit, comment allons-nous introduire cela auprès de l'équipe de développement que nous avons ? Donc, on m'a fait intervenir, et lors de la première session, nous avons en fait fait une rétrospective. Nous avons demandé, alors quels sont vos défis ? Dites-moi simplement, avec quoi luttez-vous ? Et nous avons fait en sorte que nous les rendions visibles sur le tableau, puis nous avons voté par points. Alors, quel défi devrions-nous aborder en premier ? Il s'avère que c'est aussi ça.
Nous manquons de temps, nous manquons de tests. C'est ce que nous devons corriger. Donc, nous avons proposé l'expérience et leur avons demandé, d'accord, le manque de temps, nous pensons que Kanban peut aider à cela. Seriez-vous prêts à l'essayer ?
Et nous avons demandé un vote à main levée. Et ils ont dit, d'accord, je serais prêt à l'essayer pendant deux mois. Donc, nous avons dit, d'accord, allons-y. Commençons par là. C'est là que nous avons mis en place le tableau commun.
Comment avons-nous amélioré ? Eh bien, un aspect important de ceci était que les managers étaient vraiment motivés pour aider cette équipe. Et ils ont fait beaucoup de travail en amont pour s'assurer que l'équipe ait une bonne situation de travail. Ils ont fait des présentations difficiles, ils ont mis en place la visualisation, ils ont engagé des améliorations, etc. Et voici l'un des managers qui observe les graphiques qu'elle a en dehors du système Kanban. Mais en fait, il y avait quelques étapes.
La première chose que nous avons faite, c'est simplement de nous concentrer sur la libération de temps. Pendant deux mois, il s'agit juste de libérer du temps. Assurons-nous d'avoir un peu de marge dans le système. C'est tout ce que nous avons fait. Limiter le travail en cours, supprimer le travail n'ajoutant pas de valeur, dire non aux projets parallèles, simplement sortir cela du système.
La chose suivante que nous avons faite est que nous nous sommes concentrés sur la construction de comportements partagés par l'équipe et leurs managers. Donc, nous nous sommes concentrés sur le fait de nous assurer que nous travaillions en tant qu'unité et nous avons formé cette unité à résoudre les problèmes. Nous avons continué à faire cela pendant un certain temps.
Et puis, lorsqu'ils ont senti que cela fonctionnait, et vous pouvez voir qu'ils commençaient à crier vers d'autres villes, venez voir ce que nous faisons, c'est vraiment cool. Ensuite, nous avons commencé à intégrer d'autres fonctions, et ils regardaient, oh, pourquoi ne pouvons-nous pas faire les choses comme ça ? Et ils ont commencé leurs propres expériences.
Maintenant, l'étape finale. Et aussi l'une des plus difficiles était qu'à partir de ce point, nous avions atteint un optimum local.
À partir de ce point, nous avions en fait besoin que cette équipe passe moins de temps ensemble et plus de temps avec les équipes en amont. Voici donc un défi, n'est-ce pas ? Nous avons construit cette unité vraiment solide. Elle a un vrai sens central d'elle-même. Et maintenant, nous lui demandons d'être un peu moins forte. C'était donc un défi mental, un saut, pour ainsi dire, que nous avons dû discuter pendant un certain temps avant qu'ils ne soient prêts à le faire.
Mais l'une des choses que nous avons reconnues, c'est que nous n'avions pas besoin de changer l'organisation pour améliorer le flux. Nous n'avons pas démantelé cette équipe. Nous l'avons gardée telle qu'elle était. Nous leur avons simplement demandé de changer leur façon de travailler, de passer plus de temps avec les autres agents autour d'eux qui avaient besoin de leur aide et de leur expertise. Voici un défi, n'est-ce pas ? Nous avons construit cette unité vraiment solide. Elle a un sens très fort d'elle-même. Et maintenant, nous lui demandons d'être un peu moins forte. C'était donc un défi mental, un bond, pour ainsi dire, que nous avons dû discuter pendant un certain temps avant qu'ils ne soient prêts à le faire.
Mais l'une des choses que nous avons reconnues, c'est que nous n'avions pas besoin de changer l'organisation pour améliorer le flux. Nous n'avons pas démantelé cette équipe. Nous l'avons gardée telle qu'elle était. Nous leur avons simplement demandé de changer leur façon de travailler, de passer plus de temps avec les autres agents autour d'eux qui avaient besoin de leur aide et de leur expertise. Et nous avons mis cela en place à la place. Alors, quelques apprentissages. Un leadership actif à toutes les étapes était crucial. Et je peux très clairement voir que l'étape qui était difficile était lorsque les leaders avaient du mal mentalement à savoir s'ils étaient prêts à faire le bond ou non.
Obtenir une visualisation était clé.
Et vous n'avez pas besoin de changer l'organisation pour améliorer la production. Vous pourriez en arriver à ce point dans certaines situations, mais il y a beaucoup de choses que vous pouvez essayer avant d'en arriver là. Et je pense que cela le prouve. Au moins, les données et la production que nous avons obtenues nous montrent que cela a fonctionné.
Examinons maintenant un cas qui ne s'est pas déroulé aussi bien. Voyons ce que nous avons fait différemment.
Alors, un peu de contexte. Voici une entreprise de plateforme, c'est une entreprise open source, qui développe un logiciel utilisé et soutenu par des entreprises du monde entier. Ils ont donc des équipes, des équipes de développement, qui utilisent Agile, et ils en sont très satisfaits. J'avais travaillé avec ces équipes pour les aider à mettre en place les pratiques, et oui, elles fonctionnaient plutôt bien. Maintenant, au milieu de toutes ces équipes, et en fait dans la même salle physique, se trouve une équipe de développeurs très seniors qui sont là depuis de nombreuses années, en fait depuis le début de l'entreprise.
Et ils travaillent, enfin, au moins ils sont assis ensemble. Ils sont plutôt solitaires, donc ils ne sont pas habitués à travailler en environnement d'équipe. On peut voir qu'ils sont des individus très forts, n'est-ce pas ? Pourtant, ils sont assez humbles pour pouvoir parler des choses. Donc une chose que vous pouviez observer si vous entriez dans cette salle, c'est que vous pouviez voir une équipe dire, en fait, vous savez, quand je veux de l'aide pour des choses difficiles, cela prend une éternité. Et si j'allais poser la même question aux gars de l'architecture, ils ne refléteraient pas cette situation. Ils diraient d'autres choses.
Pourtant, ils sont assis dans la même salle. N'est-ce pas bizarre ?
Alors, comment avons-nous commencé ? Eh bien, de la même manière, nous avons fait une rétrospective d'équipe. Nous leur avons demandé de proposer les défis qu'ils voulaient relever. Et le principal défi était : nous voulons travailler en équipe. D'accord, faisons cela. Voici donc le coach Eagle, et il suggère une expérience. Faisons du Kama. Parce que cela a fonctionné dans toutes les autres équipes avec lesquelles j'ai travaillé. Alors j'ai dit, faisons-le.
J'ai donc mis en place un tableau visuel. J'ai obtenu un accord, pensais-je, pour faire un stand-up chaque jour. Maintenant, une chose que nous avons observée, c'est qu'un ou deux de ces membres de l'équipe d'architecture ne se présentaient pas au stand-up. Ou s'ils se présentaient, ils arrivaient avec une demi-heure de retard, 50 minutes de retard, et des choses comme ça. Certains membres l'ont fait. Certains d'entre eux ont effectivement accepté et continué à faire ce sur quoi nous nous étions mis d'accord.
J'ai donc introduit le concept suivant : si quelqu'un est en retard, assurons-nous que cette personne, si elle est en retard cinq fois, offre une bière à tout le monde dans l'équipe. Pour que nous puissions avoir une équipe. Pensez-vous que cela a fonctionné ?
Non, absolument pas. Donc rien ne s'est passé et j'ai commencé à observer que les choses qu'ils avaient sur le tableau de commande ne bougeaient pas. Elles restaient simplement bloquées là sur le tableau. Alors j'ai commencé à les pousser un peu plus et j'ai dit, d'accord, vous savez, nous n'avons pas besoin de faire cela pour moi. J'ai fait une rétrospective après une semaine avec les gars dans la salle et j'ai dit, nous n'avons pas besoin de faire cela, n'est-ce pas ? Dites-moi ce que vous voulez faire. Ce n'est pas à moi de décider. Si vous voulez toujours poursuivre cela, faisons-le. Si vous voulez l'abandonner, je suis d'accord. Oui, nous voulons le faire. Nous voulons le faire. D'accord, nous avons continué à le faire. Maintenant, d'autres choses que vous remarquerez étaient que les comportements que ces gars montraient ne correspondaient pas à ce qu'ils disaient qu'ils allaient faire.
Il y avait des situations où nous commencions un stand-up, un scrum avec tous les membres de l'équipe, et le développeur senior entrait dans la salle, au lieu de se tenir debout comme tout le monde, il s'asseyait simplement.
D'accord, de quoi dois-je parler maintenant.
Des choses comme ça, c'était traité.
Donc après avoir eu cette discussion très honnête les uns avec les autres, l'équipe et moi, nous avons décidé, d'accord, faisons une analyse des causes racines ensemble. Nous avons donc réuni tout le monde devant le tableau. Nous avons fait une analyse des causes racines de la situation. Nous ne travaillons pas en équipe. Pourquoi ? D'accord, c'est un peu désordonné, mais voici une chose que j'ai apprise quelque temps après ce cas.
Il y a en fait un gars qui admet ouvertement : je n'ai vraiment aucune idée de ce que signifie travailler en équipe.
Je ne l'avais pas vu. Alors j'ai dit, d'accord, continuons à faire du Kanban.
Ah non, n'est-ce pas ? Nous allons travailler en équipe, n'est-ce pas ? Nous devons insister et créer la charte d'équipe, faire signer tout le monde, et eh bien, devinez quoi ?
Ça a échoué lamentablement. Je suis arrivé au point où j'ai réalisé que cela ne fonctionnait pas et que ma confiance avait maintenant été épuisée, donc je ne devrais plus rien pousser dans cet environnement. J'ai essayé à ma manière, il est temps pour quelqu'un d'autre d'intervenir et de prendre la responsabilité d'évoluer cette équipe. Que ce soit l'équipe elle-même, le PDG, peu importe, ils devraient essayer de trouver un autre agent de changement. Voici donc la question importante. Pourquoi cela n'a-t-il pas fonctionné ? Et il y a plusieurs facteurs, certains qui peuvent être attribués aux membres de l'équipe, bien sûr, et d'autres qui peuvent m'être attribués. Et je vais partager les choses que j'ai apprises à partir de cela.
Comment aurais-je pu aborder les choses ? Eh bien, sur la base de cette analyse des causes racines, il y avait en fait des informations importantes que j'ai ignorées.
Par exemple, travailler en équipe avait plusieurs causes différentes, des raisons que nous aurions pu résoudre. Nous aurions pu faire en sorte que cette équipe se concentre sur un périmètre plus restreint. Nous aurions pu faire en sorte que cette équipe fasse les choses plus intelligemment en automatisant des choses. Mais j'ai choisi de poursuivre la chose tri-curriculum. Sans écouter les autres approches différentes.
Donc, si vous êtes dans une situation comme celle-ci, si vous êtes ouvert à d'autres solutions à vos problèmes pendant la phase d'analyse des problèmes, vous êtes susceptible d'obtenir beaucoup plus d'adhésion
et un véritable engagement sur l'expérience de changement que vous proposez.
C'est donc ce que je fais différemment maintenant. Je suis toujours ouvert à voir quelles autres façons je pourrais aborder cela et pas seulement avoir celle que j'ai en tête et la pousser dès le premier jour.
Alors, quelle est la morale de l'histoire, n'est-ce pas ? J'aurais pu explorer d'autres causes profondes. Et j'avais certains signaux que j'aurais pu modifier. Je ne l'ai pas fait.
Je n'ai pas soulevé les problèmes de comportement dans un format en tête-à-tête. J'aurais pu prendre quelques personnes à part et leur parler en tête-à-tête. J'ai choisi d'aborder cela avec toute l'équipe en une fois. Ça n'a pas vraiment bien fonctionné.
Et la dernière raison est que si une équipe est sous un stress très intense, elle n'est pas très réceptive aux idées, peu importe le type d'idées que vous proposez.
Donc, si vous trouvez quelqu'un dans cette situation, trouvez des moyens de réduire ce stress avant de commencer à suggérer des expériences à poursuivre.
Maintenant, si vous voyez un comportement que vous n'aimez pas et qui est contraire aux bonnes pratiques, et que vous voulez en parler, assurez-vous d'être le miroir et non le juge. Donc, la situation pourrait être, je vois, présentez le problème et soyez franc à ce sujet, mais sans nécessairement inclure de jugements de valeur. Je vois que vous êtes assis pendant nos daily stand-ups. C'est être franc. Quel est votre avis à ce sujet ? Au lieu de dire, je vois que vous êtes assis pendant un daily stand-up, et je pense que c'est nul. Là, vous ajoutez un jugement de valeur à cette observation. Donc, vous pouvez être franc à ce sujet, mais vous n'avez pas nécessairement besoin d'exprimer votre opinion sur pourquoi ou à quel point c'est bien ou mal.
Alors, résumons quelques points.
N'est-ce pas ? Premières questions.
C'est une question pour vous. Quels schémas avez-vous observés ?
Où observez-vous ? D'accord. Écoutons ce gars.
Faire confiance en la mort ? Faire confiance aux gens dans la mort ?
Oui, alors faites-leur confiance. Dans toutes ces expériences au travail, nous avons fait confiance aux gens pour nous donner des retours sur les expériences que nous avons proposées. Et nous n'avons pas poursuivi celles qu'ils ont jugées inutiles. Autre chose ?
Nous devrions écouter les gens.
Nous devrions écouter les gens, n'est-ce pas ? Très important.
Donc, quelques éléments que j'ai appris à travers ces cas et que je voudrais partager avec vous.
Si vous traitez les gens comme des êtres pensants,
ils vous traiteront de manière similaire. Et c'est vraiment clé lorsque vous arrivez en tant qu'agent de changement, car c'est le premier test auquel vous allez être confronté. Poursuivez-vous un autre moyen que le mien ? Si vous ne réussissez pas ce test, il est peu probable qu'ils écoutent vos idées.
Donc, appliquer un outil comme Kanban, l'objectif, est problématique. Parce que maintenant vous êtes coincé avec l'idée que c'est ce que nous allons faire, je vais déplacer des post-it sur le tableau. Non, ce que vous devez probablement faire, c'est écouter,
Discuter des options. Quelles autres façons pouvons-nous aborder cela ? Et ensuite résoudre les problèmes ensemble.
La deuxième leçon, il était vraiment crucial d'obtenir un mouvement vers des améliorations au niveau du système en fonction de l'évolution de la maturité de l'équipe. Supposons qu'une équipe ait fait de très bonnes choses et qu'elle ait senti qu'elle était sur la bonne voie. Pour nous qui travaillions entre les équipes, il était vraiment essentiel de nous assurer que lorsque l'équipe arrivait à cette situation, nous pouvions leur donner confiance que nous travaillerions et résoudrions les choses en dehors des frontières de l'équipe, afin qu'ils continuent à sentir que cela allait dans la bonne direction.
Donc, le piège ici est que si vous ne poursuivez pas des améliorations systématiques au niveau du système, vous allez vous retrouver dans une situation où les choses s'arrêteront.
Donc, le comportement que nous recherchons est d'impliquer la direction dans l'amélioration du flux de bout en bout. Un moyen très simple de s'assurer que nous pouvons synchroniser les choses et améliorer au-delà de l'outil.
Troisième point, si l'expérience est grande, si elle est effrayante, suggérez-en une petite.
Mais faites quelque chose. Donc, le comportement ou l'habitude que vous devez vous inculquer ainsi qu'à votre entourage est Toujours faire quelque chose. Si vous voulez, c'est un grand pas, faites une petite chose, mais faites-la aujourd'hui. Cela crée un esprit selon lequel nous avançons toujours et c'est ce qui fait que les initiatives se réalisent.
Donc, il existe un algorithme d'amélioration très simple que vous pouvez appliquer.
Vous pouvez vous demander, qu'est-ce qui consomme le délai de livraison de bout en bout ?
Et ensuite, rendons cela un peu plus facile. Et vous répétez cela une centaine de fois environ. Et devinez quoi ?
Vous allez devenir une voiture de Formule 1.
C'est aussi simple que ça.
Bien sûr, cet algorithme est simple. Les choix et la résolution des problèmes peuvent être difficiles.
Et je vais partager certaines des choses dont vous devez être conscient. Maintenant, au fur et à mesure que vous avancez à travers différents stades de maturité, vous verrez que certains outils sont très utiles à certains stades et moins à d'autres. Au début, avant que nous ayons mis en place un quelconque processus, la méthode Waterfall était excellente. Elle a créé de l'ordre à partir du chaos. Ensuite, nous avons découvert que non, c'était nul. Nous avons trouvé une meilleure façon.
Et puis nous avons vu que, en fait, nous pouvions travailler avec Kanban.
Oh, en fait, nous pouvons utiliser un outil Kanban numérique, pas besoin de déplacer des post-it et tout ce surcoût. Et il y a d'autres étapes. Donc, lorsque vous faites ces améliorations, lorsque vous faites passer une équipe ou une organisation à travers l'amélioration de leurs capacités, il vous reste un casse-tête.
Allez-vous vous en tenir aux approches existantes que vous avez essayées jusqu'à présent ?
Ou allez-vous être ouvert à d'autres approches que vous n'avez jamais essayées, mais que d'autres personnes vous suggèrent ?
Et devinez laquelle vous devez... appliquer pour améliorer sur le long terme. Vous devez être ouvert à d'autres moyens, que vous n'avez pas vus auparavant, avant de tomber dessus.
Alors, comment les voyez-vous ? Comment voyez-vous les choses qui sont évidentes pour les autres, mais pas pour vous ?
Eh bien, il y a un indice ici.
Abandonnez la technique du copier-coller. C'est utile dans certaines situations, mais pas toutes. Et puis, faites-en votre objectif de faciliter la livraison de valeur. Chacun des problèmes que je vous ai présentés à travers ces cas aurait été repéré en posant simplement cette question.
Voilà mon résumé. Si vous voulez en savoir plus sur les cas, procurez-vous le livre. Si vous voulez poser des questions, je suis là. Et je vous conseille d'aller faire quelques expériences.
Merci.