Matthew Philip
Transcription (Traduit)
Bonjour à tous. Merci beaucoup.
Je suis désolé, je ferais toute ma présentation en français. Mon professeur de français du lycée serait probablement horrifié par moi. Et vous aussi. Après quelques diapositives, je n'aurais plus rien à dire. Mais en fait, vous pourriez préférer cela après avoir vu les diapositives.
Quoi qu'il en soit, c'est merveilleux d'être ici avec vous. C'est une excellente conférence. C'est très excitant pour moi de venir des États-Unis et d'entendre tous les différents points de vue, des gens faisant différentes choses à travers le monde. Et donc cette conférence ne fait pas exception. Ma présentation pourrait être une exception, mais il y a plein de bonnes idées qui circulent. Donc ma présentation va être simplement cela, quelques idées, quelques expériences que nous avons essayées dans mon organisation. Donc pas beaucoup de théorie, plus d'expérience pratique. Donc j'espère que cela pourra aussi vous être utile.
Je vais donc diviser la présentation en quelques parties différentes. J'aimerais donc vous encourager à poser des questions tout au long de la deuxième partie. Alors n'hésitez pas à m'interrompre ou à lever la main, et j'essaierai de répondre à vos questions.
Je viens de St. Louis aux États-Unis.
En gros, mon travail consiste à aider les gens à s'améliorer, à aider les gens à apprécier davantage leur travail. C'est ce que j'aime faire.
Ce rapport traite de la manière dont nous faisons les choses dans mon organisation pour essayer d'approfondir un peu plus avec Kanban.
Donc St. Louis est nommé d'après Louis IX. Et c'est en fait intéressant. Aux États-Unis, nous avons plus que le nombre typique de rues, de quartiers et d'endroits portant des noms français ou avec des noms français. Mais nous avons notre propre façon particulière de prononcer ces noms français. Donc j'ai pensé que ce serait assez amusant, avant de commencer, de demander à tous ceux qui connaissent le français comment nous devrions prononcer ces noms. D'accord, donc c'est une leçon de français, et vous pouvez m'aider lorsque je rentrerai chez moi. Je vais donc vous donner le nom de l'endroit ou de la rue à St. Louis, et j'aimerais que vous me disiez. Comment il se prononce correctement, d'accord ? Et ensuite, je vous dirai comment nous le prononçons. D'accord, donc le premier. D'accord, de Belviere.
Non, vous avez tort. La réponse est de Baliver. D'accord, très bien. Je pensais que vous auriez celui-là, mais bon. D'accord, celui-ci. Gravois.
Oui.
C'est Gravois. D'accord, Gravois, exact.
D'accord, celui-ci. Shoto ?
Shoto ? Non.
C'est Chouteau.
D'accord. Le suivant. Gracia ?
D'autres options ?
Gracia ? C'est Gratiot.
D'accord, celui-ci ?
C'est très facile, non ? Oui, ça sonne si beau quand vous le dites. Non, c'est Creve Cœur.
D'accord, et enfin ?
Soulard.
En fait, c'est celui-là que nous prononçons correctement, et évidemment cela signifie ivrogne, n'est-ce pas ? C'est là que nous célébrons Mardi Gras chaque année. Quoi qu'il en soit, merci pour cela. Je veillerai à dire à tout le monde chez moi la bonne façon de prononcer ces noms. C'est ce qui se passe quand des Allemands arrivent après que les Français aient fondé la ville, vous savez, et la modifient un peu. Allemands, Italiens, Irlandais. Quoi qu'il en soit, merci. Nous avons donc une structure qui nous est propre à St. Louis. Elle est un peu plus courte que la Tour Eiffel, mais voici notre arche. Donc, en tant que structure pour la présentation, j'aimerais simplement vous donner un contexte. Il est vraiment important, lorsque vous faites des expériences et que vous écoutez nos rapports d'expérience, de considérer le contexte. Donc, les choses que nous essayons peuvent fonctionner pour vous, ou non. Vous devrez considérer le contexte. Donc, je vais vous donner cela. d'abord. Je vais donc entrer un peu dans les détails de notre expérience avec la profondeur de nos évaluations Kanban, à quoi elles ressemblaient. Et puis nous menons une expérience avec un rôle de gestionnaire de flux.
Donc, je vais en parler un peu. Et ensuite, passer en revue les trois principales boucles de rétroaction auxquelles nous pensons dans la méthode Kanban. D'accord, donc le contexte.
Donc, comme David Anderson aime le demander, dans quel secteur êtes-vous ? Vous devez savoir dans quel secteur vous êtes. Donc, je vais vous dire ce que je pense que nous faisons. Nous sommes dans le secteur de la livraison de logiciels sur mesure pour une variété de clients différents. Plutôt que d'avoir une seule division ou un service informatique qui soutient une structure d'entreprise, nous réalisons des projets et des produits pour de nombreux clients différents. Donc, David a également demandé, qu'est-ce qui fait que les gens choisissent votre produit ou service plutôt que d'autres ? L'un de nos différenciateurs est que nous sommes capables de faire les choses très rapidement. Nous avons une vaste expérience dans les applications mobiles et différents types de technologies. Nous sommes donc capables de résoudre des problèmes ardus là où d'autres ont échoué. Nous avons donc beaucoup de petites équipes. Excusez-moi. En général, nos équipes sont composées de six à dix personnes. Nous avons un environnement relativement ouvert, comme vous pouvez probablement le voir sur la photo ici. Donc, comme je l'ai mentionné, nous avons une variété de clients. Et donc Toutes ces différentes équipes fonctionnent principalement de manière autonome. Toutes ces différentes équipes fonctionnent principalement de manière autonome.
D'accord, donc j'ai commencé avec l'entreprise en 2000. Nous étions une entreprise relativement petite, et à l'époque, nous avions une idée de ce que nous appellerions aujourd'hui une startup lean. À l'époque, nous appelions cela une dot-com. Et donc la dot-com n'a pas aussi bien marché que nous le pensions, alors nous avons pivoté et sommes devenus une entreprise de livraison de logiciels pour différents clients. Ainsi, au fil des ans, nous avons grandi et depuis les premiers jours, je considérerais notre structure, notre ADN si vous voulez, comme proto-agile, une sorte de pré-agile avant même que nous sachions qu'il existait une chose telle que l'agile. Fortement ancrés dans les pratiques de XP, la programmation extrême, nous sommes un endroit très orienté développement.
Nous accordons vraiment une grande importance aux pratiques d'ingénierie. Et donc nous avons adopté formellement Agile XP, puis quelques années plus tard, nous avons développé ce que David a mentionné ce matin comme étant du proto-Kanban. Donc, mettre des cartes sur un mur, visualiser le travail, cette partie de gestion visuelle du Kanban.
Et puis je suis parti pendant quelques années, et je ne sais pas si c'est une coïncidence, mais quand je suis parti, l'entreprise a encore plus grandi.
Mais je suis parti pendant trois ans. J'ai travaillé dans un autre endroit. Je suis revenu juste cet été passé, et beaucoup de choses avaient changé. Nous faisions des applications mobiles, beaucoup de technologies cool, de nouvelles personnes, des visages intéressants. Donc, c'était super. Nous avions évidemment grandi. Quand je suis parti, nous étions 100 personnes, et depuis mon retour, nous sommes plus de 200 maintenant. Donc beaucoup de nouvelles personnes, des gens qui sont dans l'entreprise depuis moins de deux ans.
Ainsi, bien que nous ayons grandi de nombreuses façons, en nombre d'employés, en types de technologies que nous utilisions, en différents clients, notre pratique du Kanban avait vraiment atteint un plateau. Je me rends compte que je vais vous donner quelques concepts géologiques différents aujourd'hui. C'est involontaire. Donc l'iceberg, le plateau, je vais parler de montagnes.
Mais nous n'étions pas vraiment allés au-delà de la pratique de visualisation du Kanban. Donc ce proto-Kanban. Il y avait une certaine limitation du travail en cours, un certain temps de cycle, certaines métriques différentes, mais pour la plupart, nous avions atteint un plateau au stade de la visualisation du travail.
Et je pense que quelques-unes des raisons à cela, nous avions grandi si rapidement que nous étions vraiment concentrés sur la livraison, ce qui est toujours une bonne chose. Donc, nous nous concentrions sur l'aide à nos clients.
L'autre chose était que nous avons adopté Kanban comme nous avons adopté d'autres pratiques XP et Agile. C'était juste une des nombreuses choses qui semblaient fonctionner pour nous. Sans vraiment considérer la profondeur ou la promesse dont David a parlé ce matin concernant ce que Kanban peut apporter à votre organisation. Donc, c'était juste un autre outil pour nous, si vous voulez.
Ainsi, Kanban était omniprésent dans notre entreprise à une échelle très superficielle, cependant. Nous faisons très bien les murs de cartes.
Donc, mais ce n'est que la partie émergée de l'iceberg. Encore une fois, si vous pensez à un iceberg, quel est l'attribut distinctif d'un iceberg ?
Exact. Quelle partie de l'iceberg est sous l'eau ? La majeure partie. La majeure partie ? Des chiffres ? 90 %. 80 % ? D'accord, oui. 90 %, c'est ce que j'ai lu, oui. Donc, la masse du système est sous la surface, invisible. La chose facile à voir est la toute petite partie.
En fait, c'est intéressant. Si vous connaissez Pavel Brzezinski, il a aussi une autre idée du Kanban comme iceberg. Je ne sais pas si je l'ai volée à lui. Je l'ai probablement volée à lui sans m'en rendre compte. Mais nous aussi, il a une conférence où il utilise le Kanban iceberg.
Le sien est plus coloré que le mien, en fait. D'accord, donc si nous considérons les pratiques comme étant le sommet de l'iceberg, et même juste la partie de visualisation de celui-ci au tout sommet, ce sont toutes des choses très importantes, évidemment. Ce sont en quelque sorte les véritables façons dont nous mettons en œuvre de manière pratique.
Plus nous nous éloignons de ces choses, plus il est facile d'oublier pourquoi nous les faisons. Et nous n'avions pas vraiment considéré toutes ces choses lorsque nous avons commencé à visualiser notre travail. Il était facile de mettre notre travail sur un mur. Mais comme je l'ai dit, nous le traitions essentiellement comme une autre pratique, une autre chose à faire pour nous aider à livrer le travail.
Donc, David a mentionné Mike Burrows ce matin, et dans le livre de Mike, il pose des questions très pertinentes pour mon organisation.
Certaines des questions qu'il a posées : la transparence et l'équilibre de style Kanban pourraient-ils apporter un certain soulagement là où les gens sont encore surchargés ?
Votre collaboration est-elle principalement tournée vers l'intérieur ? Donc orientée équipe. Votre concentration sur le client souffre-t-elle en raison d'une intermédiation trop protectrice autour de l'équipe ou d'une concentration interne excessive sur la technologie, le produit ou l'équipe ? Et donc je pense que c'était quelque chose qui se produisait probablement aussi pour nous.
Nos développeurs aiment vraiment la technologie, adorent se plonger dans la technologie, ce qui est génial. C'est une chose très utile pour nos clients, mais il n'y avait pas le même niveau de concentration sur le client.
Notre approche centrée sur l'équipe ne parvient pas à apporter des gains dans le flux de bout en bout. Donc, voir le système dans son ensemble plutôt que l'équipe.
La compréhension et l'accord de la direction sont sous-estimés. Le respect est-il trop facilement oublié lorsque des décisions importantes sont prises ? Donc, ce sont des questions vraiment beaucoup plus importantes pour moi que je pensais que nous devions considérer. Et alors que nous réfléchissions à la promesse du Kanban et à notre pratique de celui-ci, Nous devrions. considérer ces questions.
Donc, en plus de commencer par le haut en termes de pratiques, nous voulions aussi regarder par le bas, en commençant par les valeurs.
Encore une fois, plutôt qu'une alternative à Scrum ou XP, Kanban était quelque chose qui allait nous permettre d'améliorer tout ce que nous faisions. Ainsi, toutes nos équipes fonctionnent de manières très différentes, mais Kanban pourrait être un point commun pour nous en termes d'amélioration, pour tirer le meilleur parti de ces pratiques et processus.
Si vous connaissez le Cercle d'Or de Simon Sinek, il parle de commencer par le pourquoi. Et pour moi, commencer par les valeurs, c'est un peu comme commencer par le pourquoi.
D'accord, donc David en a parlé ce matin.
Kanban est un système de gestion pour le changement culturel et l'amélioration de la maturité organisationnelle. Nous avions en quelque sorte manqué cela. Dans notre précipitation à pratiquer la visualisation, nous avions manqué cette réalité, cette grande promesse. Donc, les murs de cartes sont le moyen d'atteindre cet objectif. Ils ne sont pas une fin en soi. Et en effet, ils ne sont même pas particulièrement nécessaires.
D'accord, donc dans notre pratique de visualisation de notre travail, nous avions oublié, ou dans de nombreux cas, simplement pas connu le but du Kanban de conduire un changement organisationnel évolutif. Alors, comment aider les équipes pour lesquelles Kanban se résume simplement à des murs de cartes ?
Des idées ? Je peux faire une pause ici pour les questions. Des questions sur l'iceberg.
Le contexte ?
Oui. Vous avez dit que vous faisiez d'abord de l'Agile XP puis que vous avez changé, mais utilisiez-vous Scrum et pourquoi avez-vous changé ?
cette fin. Ils ne sont pas une fin en soi. Et en effet, ils ne sont même pas particulièrement nécessaires.
D'accord, donc dans notre pratique de visualisation de notre travail, nous avions oublié, ou dans de nombreux cas, simplement ignoré la finalité du Kanban qui est de conduire un changement organisationnel évolutif. Alors, comment aidez-vous les équipes pour lesquelles le Kanban n'est que des murs de cartes ?
Des idées ? Je peux faire une pause ici pour les questions. Des questions sur l'iceberg.
Le contexte ?
Oui. Vous avez dit que vous faisiez d'abord de l'Agile XP puis que vous avez changé, mais utilisiez-vous Scrum et pourquoi avez-vous changé ?
Exact. Donc la question était, nous utilisions Agile XP, utilisions-nous Scrum, avons-nous changé ? Nous n'avons jamais formellement adopté Scrum en tant que tel. Cela est plutôt né des pratiques de XP, la programmation extrême. Certaines choses de type gestion dont parle Scrum. Nous n'avions pas de Scrum Masters ou certains des rôles formels dont parle Scrum. Est-ce que cela répond à votre question ?
Donc certains de nos clients utilisent Scrum, et nous essayons donc d'interagir avec eux ou d'avoir une base commune là où c'est le cas.
D'autres questions sur le contexte ?
Encore une fois, il est très important de considérer le contexte. C'est quelque chose qui va être valable dans notre environnement. J'essaierai d'abstraire certaines choses au fur et à mesure pour vous. Des questions ? Continuer ? D'accord.
Donc, j'avais suivi et lu certaines des discussions de David Pavel et Hocken Force sur la profondeur des évaluations Kanban qu'ils utilisaient et que les gens faisaient. Et j'ai particulièrement aimé la formulation de David sur la question du Kanban, non pas de savoir si vous le faites ou non, mais pourquoi vous le faites, l'intentionnalité, cela m'a vraiment parlé. si vous le faites ou non, mais pourquoi vous le faites, l'intentionnalité, cela m'a vraiment résonné.
Nous faisions clairement du Kanban à un certain niveau, mais quel était le pourquoi ? Pourquoi faisions-nous du Kanban ?
J'ai mentionné Mike Burrows plus tôt.
J'ai lu son article de blog. Ceci provient de son blog.
Il a parlé d'une évaluation de profondeur basée sur les valeurs. Donc, cela pose des questions sur le pourquoi, sur les valeurs qui sous-tendent la pensée, les pratiques et les principes.
Voici donc à quoi cela ressemble. Vous pouvez obtenir la feuille de calcul depuis son blog. C'est une série de questions et de réflexions sur
la réalité du Kanban, comment vous le pratiquez. En gros, il organise ces neuf valeurs, et il les a en fait condensées en six catégories pour les besoins de cette évaluation. Et donc nous avons pensé que cela pourrait être quelque chose d'utile pour nos équipes à considérer et à utiliser comme outil éducatif.
Donc, nous avons en moyenne entre 20 et 25 équipes en activité à la fois dans notre organisation. Comme je l'ai dit, très différentes à bien des égards, toutes très axées sur les pratiques d'ingénierie, faisant beaucoup de développement piloté par les tests, de livraison rapide.
Prototypage UX. Toutes fonctionnent de différentes manières en termes de leur avancée avec le Kanban. Alors, par où commencer ? Par où commencer quand on a autant d'équipes et qu'on aimerait que les choses
bougent rapidement.
Nous savions que nous ne pouvions pas toutes les faire, pas toutes en même temps en tout cas. Donc, nous avons commencé avec quelques-unes.
Donc, nous avons demandé autour de nous sur notre système de messagerie instantanée de l'entreprise, en parlant aux gens dans les couloirs, en allant simplement vers les équipes des gens, en disant, hé, il y a cette évaluation de la profondeur du Kanban. Seriez-vous intéressés ? Et c'était super parce que certaines personnes ont levé un sourcil, d'autres étaient intéressées. Mais il y avait quatre équipes dont les responsables ont dit oui, ils étaient intéressés à le faire. Et ce sont des équipes de niveaux de maturité variés. Une équipe en particulier livrait très bien. Quelques-unes des équipes étaient un peu stagnantes et avaient quelque peu perdu leur chemin.
Mais ce qu'elles exigeaient de nous, c'est que ces évaluations soient légères. Donc, elles ne voulaient pas y consacrer beaucoup de temps. Elles voulaient continuer à se concentrer sur la livraison. Et elles ne voulaient pas avoir beaucoup de réunions. Et cela devait être pragmatique pour elles. Donc, plutôt que beaucoup de théorie, elles voulaient vraiment pouvoir trouver des choses qu'elles pourraient ramener et utiliser immédiatement.
Oui, Ben.
Pourquoi voulaient-elles participer ? Qu'est-ce que cela leur apportait ?
Exact. Qu'est-ce que cela leur apportait ? Pourquoi voulaient-elles faire cela ? C'est une bonne question. Donc, je pense que quelques personnes ont réalisé qu'elles avaient stagné et qu'elles avaient besoin d'une sorte de catalyseur pour améliorer leur équipe.
Une équipe était simplement curieuse de savoir comment elles se débrouillaient. Elles obtiennent des retours sur, eh bien, voici ces gens qui parlent de la profondeur du Kanban. Comparons-nous à ce que c'est. Donc, je pense que c'était une combinaison de plusieurs de ces différentes choses.
D'accord, donc tout d'abord, nous avons décidé qu'il y avait une sorte de lacune en termes de compréhension. Il y a des gens qui visualisent leur travail, mais qui n'ont pas vraiment une compréhension appropriée de ce qu'est le Kanban et de ce que le Kanban peut faire. Et donc nous avons commencé par une brève introduction à la méthode Kanban, en commençant par les valeurs. Et donc nous avons utilisé la métaphore de l'iceberg. Et les gens étaient très intéressés, très surpris qu'il y ait plus dans le Kanban que simplement visualiser son travail.
Nous avons ensuite présenté la grille d'évaluation, l'échelle de mesure en quatre points ici. Et donc c'était utile. C'était intéressant. Certaines de nos équipes avaient passé une évaluation CMMI. En fait, David a mentionné Hillel Glazer. Il avait fait notre évaluation.
Donc c'était un peu similaire. Cela commençait à ressembler à une évaluation CMMI. Et nous ne voulions pas vraiment cela tout de suite. Parce qu'il y avait le concept de supériorité illusoire, où la plupart des gens pensent qu'ils sont meilleurs qu'ils ne le sont réellement dans quelque chose. Je le fais moi-même, évidemment. Nous avons tous ces tendances. Mais c'était très évident pour moi. J'avais vu leurs murs de cartes. J'avais vu comment ils fonctionnaient. Vous ne limitez pas vraiment votre travail en cours, ou vous ne comprenez pas vraiment et ne contrôlez pas votre système. Mais les gens avaient tendance à se noter quatre et trois sur des choses qui me semblaient plutôt être des un et deux, ce qui est bien. Mais encore une fois, l'idée d'éviter la résistance émotionnelle est très importante ici. Et donc David a mentionné ce matin, soyez comme l'eau et évitez les rochers. Nous avons rapidement constaté qu'il y avait ce genre de relation antagoniste entre les équipes que nous aidions. Nous étions un groupe de trois ou quatre personnes. venant faciliter les évaluations, et ils commençaient à se défendre et à défendre leurs pratiques, se notant plus favorablement que nous le pensions. Et donc l'une des premières leçons que nous avons tirées a été de dire : nous, en tant que facilitateurs, nous n'allons pas vous évaluer. Nous sommes tous amis ici. Nous travaillons pour la même entreprise. Et donc nous avons dit : évaluez-vous vous-mêmes. Nous vous aiderons à comprendre les questions. Nous vous guiderons à travers ces éléments, répondrons à vos questions. Mais en réalité, lorsqu'il s'agissait de voter et de décider, si vous étiez un un, un deux ou un trois, nous avons laissé cela aux équipes. Et donc cela a été en quelque sorte libérateur au début, plutôt que d'avoir cette résistance émotionnelle où il pourrait ne pas y avoir de transparence,
cela a en fait commencé à aider. Et donc, encore une fois, nous voulions créer un environnement de transparence. C'est évidemment l'une des valeurs. Et donc, même en faisant ces évaluations, démontrer les valeurs.
Et puis nous voulions aider l'équipe à s'approprier ses propres évaluations. Donc ce n'était pas simplement un groupe extérieur disant : vous devez faire ceci pour nous apaiser, pour apaiser la direction. Il n'y avait aucune demande de la direction pour cela. C'était juste un groupe d'entre nous qui s'intéressait à aider les équipes et les équipes elles-mêmes. Et nous avons dit que nous ne partagerions pas ces informations avec la direction. Nous anonymiserions les données si les gens voulaient les voir au-delà de ces équipes, mais en réalité, c'était par les équipes pour les équipes. Voilà. Et les notations sont subjectives de toute façon.
Vous savez, on pourrait dire qu'il y a des raisons d'avoir des échelles relatives et objectives, mais en réalité, c'était juste un moyen de donner aux équipes un point de référence ou un point de départ en termes de ce sur quoi elles voulaient travailler et de se donner une sorte de miroir pour voir ce qu'elles faisaient vraiment.
Nous l'avons fait comme beaucoup d'équipes sont familières avec l'estimation, une estimation de groupe. Donc avec des estimations lancées, nous faisions un, deux, trois, partez, et ensuite ils s'auto-évaluaient. Nous les aidions à travailler là-dessus. En gros, c'était très simple, un processus très rapide, une série de réunions d'une heure.
Puisque nous travaillions avec quatre équipes simultanément, nous avons pu essayer des choses et parfois échouer avec certaines de ces équipes. L'une des choses que nous avons réalisées très tôt, c'est que nous, en tant que groupe de facilitateurs, ne connaissions pas les valeurs aussi bien que nous l'aurions dû. Cela nous a vraiment poussés à nous éduquer nous-mêmes également.
Une autre chose était que, en raison de cet écart de connaissances ou de compréhension, la formulation de Mike dans l'évaluation était différente pour nous. Nous, vous savez, les Anglais parlent un anglais un peu différent de nous, les Américains. Et donc nous avons dû traduire certaines formulations de ses questions en quelque chose de plus intelligible ou applicable dans notre environnement. Nous avons donc trouvé quelques exemples différents qui s'appliquaient à notre contexte.
J'ai mentionné le livre de Mike, mais en fait, il n'aurait pas pu sortir à un meilleur moment parce que dès que nous l'avons eu, nous avons pu mieux infuser notre compréhension. Ainsi, ceux d'entre nous dans l'équipe d'évaluation ont vraiment pu mieux saisir ce que nous aidions nos équipes à comprendre.
Donc, dès le début, les équipes, simplement par le processus de poser des questions et d'apprendre, ont pu commencer à apporter des changements. L'une des parties de l'évaluation parle de transparence et de politique explicite. L'une des équipes qui utilisait un outil, Mingle, que j'aime bien, il ne fait pas tout ce que vous pourriez vouloir, mais ils ont dit : eh bien, notre outil ne nous permet pas de faire de la politique explicite. Et donc je leur ai dit que ce n'est pas parce que votre outil ne vous permet pas de faire quelque chose que vous ne devriez pas le faire. Et donc ils ont pris cela à cœur, et immédiatement après notre première réunion, ils sont allés afficher des cartes très simples, très basiques, rudimentaires qu'ils ont attachées à leur écran électronique.
Ainsi, le simple fait de faire cela a suscité beaucoup de bonne volonté. Les gens étaient heureux que nous investissions en eux, et que nous leur donnions une chance de faire une pause par rapport à une livraison très ciblée et de prendre un peu de recul pour examiner le système dans un but d'amélioration. Et donc ceci est une citation de l'un des membres de l'équipe. Encore une fois, juste l'idée de se soucier des gens, donc les valeurs de respect, d'accord, de compréhension. Le simple fait de faire ce processus a été utile à ces égards. Cela a également introduit un langage commun pour nous. J'ai mentionné l'écart de connaissances, mais pouvoir parler de Kanban avec un langage commun à travers le processus des évaluations a été très utile.
Qu'est-ce que le temps de cycle ? Qu'est-ce qu'une politique explicite ? Que signifie avoir un focus client ? Ce sont toutes des conversations très utiles à avoir.
Ainsi, chaque équipe s'est notée différemment, ce que nous avions évidemment prévu. J'ai mentionné les six domaines, les six domaines de valeur dans lesquels l'évaluation regroupe les choses. Ceci est une équipe. Donc nous avons laissé cela aux équipes. Encore une fois, c'est un apprentissage que nous avons fait. Après avoir terminé les évaluations, j'ai initialement supposé que ce serait quel que soit votre score le plus bas, c'était la chose sur laquelle vous voudriez vous améliorer. Et ce n'est pas nécessairement le cas. Vous pourriez vouloir jouer sur vos points forts. Donc travailler ou développer les choses que vous faites déjà bien.
Cette équipe voulait se concentrer sur le flux. Nous leur avons donc fixé comme objectif d'augmenter leur note d'un point au cours du mois suivant.
Ceci est une autre équipe. Ils étaient les plus faibles en transparence, et donc nous avons parlé de la transparence et des questions réelles que l'évaluation aborde, et c'était leur objectif, améliorer la transparence. Et comme vous le savez probablement, si vous travaillez à améliorer l'une de ces choses, il y aura des retombées ou des effets d'entraînement dans les autres domaines. Donc ce n'est pas comme si vous isoliez une chose dès le début.
La transparence à travers le système. Voilà, exactement. D'autres parties prenantes, les gens, encore une fois, garder le système en équilibre, rendre la capacité transparente pour les personnes qui font des demandes sur le système.
Beaucoup de nos équipes sont très transparentes en leur sein. Donc un groupe de six personnes, ils travaillent de manière collaborative. Ils sont co-localisés. Ils ont des réunions debout, visualisent leur travail. Beaucoup de choses sont transparentes au sein de l'équipe, mais au-delà des frontières de l'équipe, ce n'est généralement pas autant le cas. Oui, bonne question.
Notre premier groupe d'équipes avait terminé ses évaluations. Elles voulaient toutes utiliser cette évaluation pour s'améliorer. Vous savez, elles avaient reçu de bons retours. Elles s'étaient essentiellement donné des retours. Mais le problème était qu'elles étaient encore trop occupées pour investir le temps à s'améliorer. Et encore une fois, sans changer radicalement leur processus, ce qui n'allait pas être nécessaire. Ce n'est pas ce dont parle Kanban. Mais il faut encore se concentrer sur l'amélioration, avoir le désir de s'améliorer, et vraiment juste comprendre par où commencer. Elles ne savaient pas exactement par où commencer. Je vais donc faire une pause ici pour les questions sur l'évaluation. Donc, notre premier ensemble d'équipes avait terminé leurs évaluations. Elles voulaient toutes utiliser cette évaluation pour s'améliorer. Vous savez, elles avaient reçu de bons retours. Elles s'étaient essentiellement donné des retours à elles-mêmes. Mais le problème était qu'elles étaient encore trop occupées pour investir le temps pour s'améliorer. Et encore une fois, sans changer radicalement leur processus, ce n'était pas nécessaire. Ce n'est pas de cela que parle Kanban. Mais il faut tout de même se concentrer sur l'amélioration, avoir le désir de s'améliorer, et vraiment comprendre par où commencer. Elles ne savaient pas exactement par où commencer. Je vais m'arrêter ici à nouveau pour des questions sur l'évaluation.
J'ai une question. Avez-vous vécu une sorte de désaccord à un moment donné ?
Oui, en fait, oui. Et c'était bien. C'était bien d'avoir un peu de dissension. Vous savez, il y avait beaucoup de fois où l'équipe, trois, quatre ou cinq personnes pensaient qu'elles faisaient vraiment bien cette chose. Oui, nous faisons des limites de travail en cours. Oui, pas de problème. Et puis il y avait une personne qui était en quelque sorte la voix solitaire, la voix courageuse disant, les gars. Soyons honnêtes. Nous ne faisons pas ça. Nous pensons faire des limites de travail en cours, mais nous avons une limite de travail en cours pour le développement, puis il y a cette file d'attente infinie de travail qui s'accumule avant le contrôle qualité.
Pas vraiment limité en travail ou en WIP dans ce système. Donc c'était vraiment bien. Et c'est pourquoi il était formidable pour nous d'utiliser la technique de vote en groupe à laquelle les gens étaient déjà habitués grâce à XP et à l'estimation. Cela permet aux gens de, vous obtenez la diversité cognitive et vous révélez les cas isolés. Et les gens disent, vous savez, en groupe, tout le monde dit quatre et il y a une personne qui dit un. Et ensuite, cela mène vraiment à une bonne conversation. Nos équipes aiment de toute façon débattre, donc c'était naturel. Oui, allez-y.
Exact.
Pas initialement, non. Nous voulions utiliser l'évaluation pour générer certaines de ces choses. En gros, notre seul objectif était d'aider les équipes, encore une fois, à avoir un miroir pour voir comment elles se débrouillaient. Et mon espoir était qu'en faisant cela, cela catalyserait en fait une réflexion sur le changement et un intérêt pour l'amélioration.
Pas de pression, oui. Encore une fois, ce n'était pas dirigé par la direction, et j'en parlerai dans un instant parce que nous avons une structure, peut-être unique, de notre organisation. Il n'y a pas de niveau de management intermédiaire. Et donc nos dirigeants ne demandaient pas nécessairement cela. Ils m'avaient en quelque sorte mandaté pour aider les équipes de manière générale à s'améliorer. Mais à part cela, il n'y avait pas d'initiative. Oui, allez-y.
Absolument pas. Oui, c'est un très bon point. C'était essentiellement pour que les équipes s'améliorent par rapport à leurs propres capacités. Et c'est l'une des raisons pour lesquelles nous voulions créer un climat de sécurité pour ces équipes en premier lieu, en insistant sur le fait que ce n'est pas une question de comparaison. Encore une fois, toute information qui intéressait la direction allait être anonymisée afin que les équipes ne soient pas comparées les unes aux autres. Et de toute façon, nous n'avons pas cette culture, donc je vois comment cela pourrait être. Certains de nos clients avec lesquels nous avons travaillé, cela poserait un problème. Donc encore une fois, le contexte est clé ici. Mais oui, une partie de la sécurité était de ne pas faire en sorte que les équipes se sentent comparées les unes aux autres. Elles étaient cependant intéressées. En fait, les responsables d'équipe se demandaient les uns aux autres comment ils s'en sortaient, mais c'était plus une rivalité amicale et une sorte de curiosité. Est-ce que cela répond à votre question ?
La dernière partie que vous venez de donner est excellente car créer une sorte de rivalité amicale, ce genre de, vous savez, compétition interne,
Exact.
Cela devrait alors élever le niveau partout. Exact. C'est le genre d'approche que l'armée adopte, un peu de rivalité entre les régiments n'est pas une mauvaise chose. Exact.
Oui, c'est un très bon point. Oui. Oh, désolé. Oui.
Le bug est de notre côté ce mois-ci. Si vous n'aviez pas eu le gars courageux disant, oh, vous me soutenez, auriez-vous essayé de contester leurs scores ou de poser des questions pour voir si les scores étaient réels ?
J'ai un peu fait ça. Oui, c'était difficile pour moi parce qu'au début, comme je l'ai dit, j'avais travaillé avec certaines de ces équipes et j'étais... Et je pense que c'était en partie simplement de savoir quelles étaient les réponses ou de quoi parlaient les questions.
Au début, je les ai beaucoup plus contestées qu'après. Parce que je pouvais voir que les contester ou essayer de les faire changer de score n'allait pas vraiment aider. Nous nous concentrions sur la mauvaise chose. Le focus aurait vraiment dû être sur la compréhension.
Et trouver comment améliorer cela plutôt que le score réel. Le score était un moyen pour atteindre une fin.
Je vais poser les questions pour que les gens commencent à réfléchir davantage ici.
Exact, exactement. C'était donc l'une de mes propres fautes. J'étais un peu trop agressif en les contestant. Et donc je me suis un peu retiré après un moment. Les laisser apprendre par eux-mêmes. J'ai parfois demandé : êtes-vous sûrs de cela, les gars ? Vous savez, c'est de cela qu'il s'agit. Je vous donne une dernière chance. Mais de toute façon, oui, essayez.
Vous avez dit que cette évaluation n'était pas destinée à être consommée par le...
Mais ma question est, pendant les deux années où les équipes ont pratiqué Dunbar, elles ont probablement collecté certaines métriques qui étaient utilisées ou le sont encore aujourd'hui par la haute direction. Y a-t-il quelque chose de non métrique du tout ?
Non, non. Pas autant que vous pourriez vous y attendre.
Nous avons certaines métriques d'équipe que nous utilisons et qui préoccupent la direction.
Je veux dire, pour comparer les équipes entre elles.
Oh.
Vraiment pas tant que ça dans notre environnement. Certains de nos clients s'y intéressent. Nous avons un client particulier qui a plusieurs équipes avec lesquelles nous travaillons sur des projets pour eux. Et ils sont intéressés à savoir, à quel point cette équipe produit par rapport aux autres équipes ? Et donc pour leur bénéfice, nous fournirons certaines
style normalisé, que ce soit des histoires par semaine, une sorte de point de données pour eux. Mais en réalité, il n'y a pas beaucoup de comparaison d'équipe à équipe. C'est une chose que nous maîtrisons plutôt bien. Mis à part essayer d'aider toutes nos équipes à s'améliorer et identifier les équipes qui ne performant pas aussi bien, il n'y a pas beaucoup de comparaisons du type pommes et oranges. Est-ce que cela répond à votre question ?
D'accord, d'autres questions sur les évaluations ?
Donc David a parlé de Kanban en intégrant l'ADN évolutif dans votre organisation. Et donc, comme je l'ai mentionné plus tôt, Kanban n'est pas vraiment une question de savoir si vous le faites ou non, mais quelle est votre intention. Et donc cela aurait pu être une question, avions-nous déjà cet ADN, ou avions-nous besoin de faire une certaine modification génétique de nous-mêmes ? Comment obtiendrions-nous cet ADN si nous étions vraiment concentrés sur la livraison et ne pensions pas vraiment à comment utiliser... Kanban pour nous améliorer. D'où viendrait cet ADN ?
J'ai mentionné notre structure organisationnelle. Elle est très plate, donc il n'y a vraiment que deux niveaux. Il y a nos principes fondateurs, les trois personnes, nous avons quatre au niveau C, et puis il y a tous les autres. Et ces gars-là sont plutôt bons pour responsabiliser les équipes. Et donc, il n'y a pas de niveau de management intermédiaire dans notre organisation. Et donc l'une des grandes choses à propos de Kanban est qu'il est conçu pour être dirigé depuis le milieu, vers le haut et vers le bas. Mais nous ne l'avons pas. Alors que ferions-nous ? Nous ne voulions pas créer une couche de management intermédiaire juste pour cette raison. De toute façon, ce n'est pas ce qui fonctionne dans notre environnement. Et donc, mais nous avions encore besoin de quelqu'un pour catalyser ce changement. Quelqu'un qui était vraiment désireux de le faire et de le voir se produire, d'investir dans les équipes, de donner aux équipes une chance de... Posséder encore l'amélioration. C'est là que nous avons tenté l'expérience. Donc, euh, Anshuans, il a écrit à ce sujet plus tôt cette année dans InfoQ, en fait, l'idée d'un gestionnaire de flux. Et nos équipes sont réticentes à avoir des titres de rôles vraiment distincts. J'ai mentionné que nous n'utilisons pas de scrum masters.
Même nos responsables d'équipe sont essentiellement des responsables techniques promus qui ont certaines responsabilités de gestion. Nous avons donc pensé au rôle de gestionnaire de flux comme un moyen possible de catalyser le changement au sein de nos équipes qui avaient atteint un plateau et faisaient les choses plus comme d'habitude.
Il est donc vraiment important lorsque vous entendez l'idée de convenir de poursuivre le changement. C'est une partie vraiment importante de Kanban. Mais pour moi, lorsque vous convenez de poursuivre le changement, vous convenez de voir l'amélioration comme faisant partie de votre travail, pas seulement le codage, pas seulement le contrôle qualité, pas seulement la conception, mais que vous voyez l'amélioration comme faisant partie de votre travail également. Et c'est ce que signifie pour moi convenir de poursuivre le changement. Que diriez-vous qu'un gestionnaire de flux fait ? C'est une bonne question. En fait, les dirigeants étaient intéressés par cela. Je présentais cette idée. Même juste une expérience légère, je voulais avoir leurs pensées et leur accord, leur compréhension également. Donc, la façon dont Chris l'a décrit dans son article est qu'il y a un besoin pour quelqu'un au sein de l'équipe de prendre en charge pour que l'implémentation tienne. Le rôle présente certaines similitudes avec celui de Scrum Master. Une fois qu'il est retiré, des aspects de gestion de projet dont il est souvent chargé. Donc, en réalité, c'est quelqu'un dont le seul but est d'aider l'équipe à s'améliorer et à se concentrer sur la fourniture de métriques, en posant de bonnes questions sur la façon dont l'équipe se porte, pour aider l'équipe à réfléchir et à agir. Donc suivre les politiques qu'elle s'est fixées, identifier de nouvelles politiques, amender les existantes, mener des expériences et les faire de manière scientifique. Beaucoup de nos équipes effectuent des changements, évidemment, mais elles ne mènent pas nécessairement leurs changements ou leurs améliorations comme des expériences. En fin de compte, le gestionnaire de flux inspire, coache et défie l'équipe.
Donc Mike décrit le leadership comme étant aussi simple que de regarder le tableau de travail et de demander, qu'est-ce qui est bloqué aujourd'hui ? Voyez-vous un flux ? Où nos blocages se produisent-ils de manière répétée et pourquoi ? Nos équipes sont relativement bonnes pour poser la première question. Donc nous avons des réunions quotidiennes en stand-up. Les équipes sont vraiment bonnes pour dire, qu'est-ce qui est bloqué ? Réparons-le et passons à autre chose. Mais nous n'avions pas ce deuxième niveau de compréhension ou cette façon de penser orientée analyse des causes racines concernant nos problèmes. Encore une fois, se concentrer sur la livraison. C'est super. Se concentrer sur la suppression des obstacles et apporter des changements systématiques et systémiques passe souvent à la trappe.
Donc Mike a aussi demandé, et si ce type de leadership ne venait pas naturellement à votre organisation ? Et c'est pourquoi nous avons pensé qu'un gestionnaire de flux injectant cette sorte d'attitude aiderait.
Vous avez probablement déjà vu cette image, n'est-ce pas ?
D'accord, je sais que le gars au fond l'a vue.
D'accord, donc au-delà de poser les questions importantes sur une base quotidienne, le gestionnaire de flux aide l'équipe à faire des expériences avec des données pour être présent là où le travail se fait. Donc l'idée de GembaWalk. En fait, ce n'est pas quelqu'un qui peut simplement passer à la réunion stand-up et puis partir. C'était l'une des choses que nous avons expérimentées. Ce ne serait pas ce rôle vraiment, vraiment à temps partiel où vous faites juste un saut. Dire, quel est votre temps de cycle ? Que se passe-t-il aujourd'hui ? Et puis envoyer un email à quelqu'un. Il fallait vraiment que ce soit quelqu'un. Nous avons une excellente QA. Elle s'appelle Allison Hawk. Elle voit son rôle dans la QA comme une façon d'écouter aux portes. C'est une grande partie de son rôle parce qu'elle veut être présente pour les conversations lorsqu'elles se produisent, car c'est ce qui lui permet de bien faire son travail. Et donc écouter aux portes est important pour le gestionnaire de flux également, d'une manière Gemba.
Alors, quelles sortes de métriques intéressent un gestionnaire de flux ? Cela est encore une fois très contextuel. Cela va de pair avec l'adéquation à l'objectif. Qu'est-ce qui est important pour votre organisation ? Qu'est-ce qui vous tient à cœur ? Pour nous, nous nous soucions vraiment de l'assurance de livraison et du respect des délais rapides. Et la qualité, la rapidité, toutes ces choses sont importantes pour nous. Donc nous avons commencé avec ces quatre domaines généraux. Cela peut changer en fonction de l'équipe.
Certains de ces éléments sont plus faciles à obtenir que d'autres. Pouvez-vous deviner laquelle de ces quatre choses est la plus difficile à obtenir en termes de données ?
Le retour sur investissement, oui. Oui, c'est celui qui est insaisissable. C'est vraiment assez ironique. Cela devrait être la première chose, la valeur avant tout. Mais c'est la chose la plus notoirement difficile à obtenir.
Pour les gestionnaires de flux, c'est un peu comme une enquête de détective. Vous essayez de comprendre, en rassemblant des morceaux du puzzle, en mettant des données ensemble, et en construisant cela. David a mentionné plus tôt, il est beaucoup plus facile de faire cela lorsque vous avez des outils numériques.
Pour moi, il y a quatre sources ou emplacements différents d'information dans une équipe. Il y a des choses explicites, donc explicites sur les murs de cartes. Nous avons des données là-bas, à la fois physiques et numériques. Mais il y a aussi des informations implicites. Donc, ce sont des choses qui se trouvent dans la tête des gens. Mais il y a aussi des informations qui existent sans que les gens le sachent. Alors, quelle est la valeur de ce que nous construisons ?
Quelqu'un a une idée notionnelle. Nous voulons faire cela. Pourquoi ? Et en fait, je vois Josh au fond. Si vous êtes capables de venir. à sa session, il vous aidera à bien comprendre cela. Mais ce sont les choses avec lesquelles nous avons commencé. Ce sont des choses qui étaient importantes pour nous.
Nous avons vraiment senti que, avec le travail de visualisation, c'était super. Et cela mène effectivement à la conversation, mène à la compréhension, et cela mène à l'action et au changement. La partie critique pour nous était ce qui se passe entre la visibilité et la conversation. Nous avions besoin que quelqu'un pose les questions. Pour lancer cette conversation. Et c'est là que nous avons vu le gestionnaire de flux.
Nos équipes, comme je l'ai mentionné, avaient en quelque sorte atteint un plateau. Elles s'étaient habituées à faire les choses de manière routinière pour livrer, ce qui est bien. Cela nous permet de rester en affaires. Cela nous permet de nous améliorer. Cela nous permet d'obtenir plus d'affaires. Mais nous n'avions pas cela cet œil tourné vers l'amélioration. Et donc, les psychologues parlent de l'idée de plutôt que de briser les habitudes, d'éteindre les habitudes. Et David Mann parle de cela dans son livre. L'idée que nous voulons commencer à faire des choses et les faire de manière répétée, plus un processus graduel. Donc, nous parlons d'éteindre certaines de nos habitudes dans nos équipes.
Donc, certains des défis. Ce n'était pas aussi facile que cela en avait l'air. J'ai mentionné que cela nécessitait plus de temps au sein de l'équipe. Ce ne serait pas juste quelque chose qu'une seule personne pourrait faire pour 10 équipes. L'idée que l'information est parfois très difficile à collecter. en assemblant ces choses. Nous avions des outils disparates. Nous avons probablement au moins 10 outils électroniques différents que nous utilisons. Et donc, être capable d'avoir une certaine flexibilité et compréhension de tous ces différents outils et comment chaque équipe individuelle a créé le tableau est un peu un défi. Mais notre objectif était d'aider initialement les équipes à améliorer un domaine à la fois, et encore une fois, sur une période d'un mois. Petit, court, nous pouvions déterminer si cela fonctionnait pour votre équipe. Est-ce que cela fonctionne ? Est-ce que cette chose de gestionnaire de flux est un échec total ? Nous essaierons autre chose. C'est un coût très faible pour l'expérience. Des questions ici sur l'expérience du gestionnaire de flux ? Oui, David.
Évidemment, pendant longtemps, j'ai résisté à l'idée de mettre en place des rôles.
Exact.
Parce que c'est le genre de choses que vous avez maintenant officialisées. Oui. Mais je vois de plus en plus de preuves, y compris un de nos propres clients il y a juste deux semaines, littéralement cette énorme unité commerciale d'une très, très grande entreprise technologique. Donc, une unité commerciale très rentable, une entreprise massivement rentable. Personne dans l'unité commerciale n'était réellement responsable du résultat.
Pourrions-nous déterminer si cela fonctionne pour votre équipe ? Est-ce que cela ne fonctionne pas ? Est-ce que ce truc de gestionnaire de flux est un échec total ? Nous essaierons autre chose. C'est très peu coûteux comme expérience.
Y a-t-il des questions ici concernant l'expérience du gestionnaire de flux ? Oui, David.
J'ai une observation. Évidemment, pendant longtemps, j'ai résisté à l'idée de regrouper les règles dans la caméra.
Exact.
Parce que c'est le genre de choses que tu sais, mec, que les règles sont ce que tu as. Mais je vois de plus en plus de preuves, y compris un de nos propres clients il y a seulement deux semaines, littéralement cette énorme unité commerciale d'une très, très grande entreprise technologique. Donc une unité commerciale très rentable, au sein d'une entreprise massivement rentable. Personne dans l'unité commerciale n'est réellement responsable du résultat.
Et c'était le chef de l'unité commerciale, le directeur senior, et il a dit : alors qui va vraiment se soucier de ces métriques dont vous parlez et vouloir les utiliser et conduire l'amélioration ? Et j'ai dit : eh bien, qui est responsable de prendre les commandes des clients et de les leur livrer ? Il a dit : oh, nous n'avons personne pour faire ça. J'ai dit : eh bien, que font vos scrum masters ? Parce que dans les affaires, vous savez, il y a beaucoup de scrum masters.
Et il a dit : eh bien, ils font respecter les règles du scrum.
Et nous avons en fait dû avoir une discussion pour savoir si vous me disiez qu'il fallait embaucher six, je devais embaucher six nouveaux managers ?
Donc encore une fois, j'ai dit : que font vos scrum masters ? Eh bien, peut-être devons-nous nous en débarrasser.
Donc, il ne m'était jamais venu à l'esprit qu'il pourrait y avoir des organisations où il n'y avait en fait personne responsable de la livraison au client. Et je pense que peut-être que c'est effectivement vrai. Et que nous devons spécifier un rôle, mais avec cette mise en garde qui dit : seulement si vous n'avez personne actuellement responsable de collaborer, installez ce rôle. Si vous l'avez, alors ne changez pas les choses.
Oui, c'est un excellent point. Et cela a conduit à une plus grande discussion dans ce sens. Qui est responsable de la livraison ? Vous savez, nous disons toujours que c'est l'équipe. D'accord, c'est super. Il n'y a pas tout à fait le même niveau de responsabilité et, vous savez, de préoccupation pour, qui se soucie finalement de ces choses. Et donc, Une partie pour nous va être de savoir si c'est un rôle de personne ou un chapeau que quelqu'un de l'équipe porte. Il semble que ce soit quelque chose qui nécessitera plus de temps que simplement une autre activité qu'une personne fait. Et en fait, nous avons défini le rôle basé sur le travail standard. Nous avons donc passé en revue et fait une activité où nous avons énuméré toutes les différentes choses que le gestionnaire de flux devrait faire quotidiennement, hebdomadairement, mensuellement, trimestriellement. Et donc j'ai effectivement mis cela sur mon blog, dont j'ai un lien à la fin de la présentation. Mais c'est une conversation émergente pour nous. Et puis vous avez la difficulté accrue de dire, d'intégrer cela dans une déclaration de travail, en disant, qu'est-ce que ce flux ? Nous avons entendu parler des scrum masters. Nous comprenons cela. Certains de nos clients en sont à ce niveau. Ils comprennent le langage du scrum. Gestionnaire de flux, qu'est-ce que c'est que ce truc ? C'est bizarre. Je ne comprends pas. Et donc aider les équipes à utiliser ce rôle sans nécessairement, encore une fois, rencontrer de la résistance lorsque vous présentez cela aux clients ou créez des contrats.
Je me disais, oui, allez-y.
Vous avez parlé de votre organisation sans managers. Est-ce quelque chose que vous avez déjà, ou est-ce quelque chose que vous mettez en place au fil des années ?
Donc les managers, vous avez dit ? Oui. Nous n'avons pas vraiment de managers.
Nous sommes une organisation sans managers.
Nous n'avons pas ce rôle formel. Nous avons nos dirigeants exécutifs. Et puis nous avons des équipes, et ensuite nous avons des responsables d'équipe.
Est-ce quelque chose que vous avez depuis le début ?
Oui, dès le tout début c'était comme ça.
Quelle est la taille de votre organisation ?
Nous avons maintenant plus de 200 personnes. Cela pourrait donc être une fonction de la taille de notre organisation et du cycle de croissance naturel pour les organisations de cette taille.
Lorsque vous atteignez ce niveau, vous commencez à ajouter une couche intermédiaire. Mais pour nous, encore une fois, ce n'est pas notre culture. Et donc proposer quelque chose comme une carte de flux. un gestionnaire qui travaille aux côtés et au sein des équipes sera probablement un meilleur modèle pour nous.
Nos équipes sont très autonomes, et nous voulons conserver cela. Nous ne voulons pas créer de friction à ce niveau. Très rapidement, je continue. Merci. Merci. Vous avez entendu parler des trois principales boucles de rétroaction. C'est comme nous les appelons, les réunions debout. C'est une réunion quotidienne pour toutes nos équipes. Et puis nous avons les rétrospectives. Nous pratiquons les rétrospectives depuis plusieurs années maintenant. Et au cours de l'année dernière, nous avons mis en place la revue des opérations. Et encore une fois, c'est un contexte différent pour nous parce que nous avons toutes ces différentes équipes autonomes, faiblement liées, qui se réunissent pour une revue des opérations, que vous pourriez normalement considérer comme étant une chose divisionnaire.
D'accord, donc j'ai mentionné que nous faisions plutôt bien les deux premières choses. Il y a, je ne sais pas si vous pouvez le voir d'ici, il y a plusieurs réunions debout qui se déroulent. C'est vers 9h30 du matin. C'est une partie régulière de notre vie.
Et nous avons des rétrospectives, généralement hebdomadaires ou bihebdomadaires. Nous avons créé un groupe de facilitateurs volontaires, des personnes qui vont d'autres équipes pour aider d'autres équipes à faciliter les rétrospectives, ce qui est une très bonne pratique pour nous. Nous les avons aidés à apprendre à être de meilleurs facilitateurs. J'ai mentionné, cependant, que certaines de ces choses sont devenues obsolètes, et nos équipes, bien qu'elles identifient des améliorations, ne gèrent pas nécessairement leurs améliorations comme des expériences. Donc c'est un peu comme, oui, ça fait du bien, on a l'impression que ça s'améliore, sans vraiment utiliser de données pour comprendre correctement s'ils ont effectivement amélioré, en fixant des conditions cibles, etc. D'accord, j'ai mentionné la revue des opérations. Voici à quoi cela ressemble. Les gens se réunissent. Cela incite les gens à gérer avec des données. Et donc si vous venez à cette réunion, vous devez avoir une sorte d'expérience basée sur des données
que vous êtes en train de mener. Alors, qu'est-ce qui est bien dans cela ? C'est un lieu pour partager ces pratiques et juger de leur efficacité. Il y a donc une certaine responsabilité légère, une responsabilité entre pairs lors de ces réunions. Mais en réalité, c'est plus comme des gens sur différentes montagnes qui se crient des choses à travers les montagnes. Ils sont à mi-chemin et ils disent, hé, comment ça se passe sur ta montagne ? Et ils n'ont pas vraiment nécessairement la capacité de
supprimer les obstacles ou éliminer les blocages pour atteindre le sommet. Et donc, il n'y a pas vraiment d'orientation vers la résolution de problèmes dans ces réunions. Il n'y a pas de boucle de rétroaction à un niveau supérieur. Et donc
Nous voulons rendre celles-ci plus orientées vers la résolution de problèmes et la responsabilité au plus haut niveau. Il y a donc certains projets qui sont liés à des clients individuels, et c'est là que nous voyons notre revue des opérations évoluer. Il y aurait donc un moyen pour les équipes de comprendre et de bénéficier de ce que font les autres équipes, mais ce serait vraiment le niveau suivant d'avoir un sponsor de projet travaillant avec les clients pour éliminer les blocages que les équipes ne peuvent pas résoudre simplement lors de leurs rétrospectives.
D'accord. Donc, les choses se passent bien au stand-up. Nous cochons simplement la case pour les rétrospectives. Et nous réfléchissons encore à ce à quoi ressemble la revue des opérations dans notre monde.
D'accord, donc c'est notre prochaine expérience.
Donc, très rapidement, les points à retenir. J'ai mentionné que je m'intéresse principalement à ce que les gens aiment leur travail. Et donc, le fait que les gens soient heureux est ce qui me rend heureux. Donc, les gens sont déjà satisfaits, déjà plus satisfaits de leur travail d'équipe. Même dans une seule équipe, nous avions une équipe de six personnes. Ils avaient environ 45 éléments en cours. Qu'ils ne pouvaient pas voir parce qu'ils les avaient tous accrochés derrière un seul post-it. Et donc, en rendant cela visible en une semaine, ils ont réduit cela à 12 éléments en cours. Une équipe a déjà réduit le temps de cycle.
Et de manière générale, à ce stade, cela crée une plus grande sensibilité à leur système, en voyant leur système dans son ensemble, une prise de conscience de ce qui se passe, des changements qu'ils peuvent apporter. J'ai mentionné l'idée que nous avons un espace de travail très collaboratif, l'idée de viralité. Des personnes d'autres équipes viennent maintenant me voir en disant, hé, j'ai entendu ce que tu as fait, et c'est un peu ce que David mentionnait. J'ai entendu ce que tu as fait avec cette équipe. Penses-tu pouvoir en parler à mon équipe ? Et donc, il y a des gens qui parlent de l'idée de découvrir les sources d'insatisfaction dans le système. Les gens disent, nous nous en sortons bien, nous livrons, mais nous pourrions faire mieux. Et donc, cela suscite ce genre de conversation dans notre organisation. L'idée est que nous catalysons le changement une équipe à la fois. Donc, la façon dont vous mettez à l'échelle Kanban n'est pas de le faire à l'échelle de manière traditionnelle, mais il semble que ce que nous faisons ici soit une manière vraiment utile. Et encore une fois, en seulement quelques mois, pouvoir exposer de nombreuses équipes à ce type de réflexion. Donc, le contexte est important. Nous avons trouvé que l'éducation présente très peu de friction. Donc, aider simplement les gens à comprendre les choses est vraiment utile. Et il n'y a pas beaucoup de résistance émotionnelle à cela.
Donc, en tout cas, c'est tout, je sais que nous sommes presque à court de temps.