Andy Carmichael
Transcription (Traduit)
Si c'est nous, alors nous sommes un groupe sélectionné, alors traitez ceci comme une session interactive et posez des questions au fur et à mesure. Je vais parler du test Kanban dans... Le test décisif en Kanban, qui concerne vraiment la nature de la méthode Kanban et si les gens l'utilisent. Nous allons donc parler un peu de la motivation pour ce test qui y est intégré. Juste avant cela, je veux faire un peu de publicité parce que certains collègues français ont travaillé dur sur la traduction de ce livre qui est Essential Kanban Condensed et si vous souhaitez le télécharger
Vous pouvez le télécharger depuis Dropbox à cette URL. Donc, ceci est probablement une édition 0.1 de la traduction. Nous recherchons des retours de la part des gens. Donc, si vous souhaitez le faire, vous pouvez obtenir ce livre sur Amazon ou également le télécharger depuis cette URL. Et le PDF en français sera également sur ce lien. Mais pour le moment, vous pouvez le télécharger dès aujourd'hui depuis ce lien ici.
L'essentiel sur Kanban en condensé. Comment c'était ? Plutôt mauvais. Oui.
C'est pourquoi je parle en anglais aujourd'hui. Je m'en excuse vraiment.
D'accord, assez parlé de ça.
J'en ai juste quelques-uns, donc si quelqu'un veut me donner 10 euros pour ceux-ci, c'est moins cher que ce que vous pouvez obtenir sur Amazon.
Mais nous n'avons pas de boutique ici.
Plongeons-nous.
Utilisez-vous Kanban, le test décisif ?
Est-ce que c'est... Non, je vais juste utiliser un clicker.
Donc, si vous voulez tweeter, voici mon identifiant Twitter. Je l'ai mis là aussi juste parce que cette diapositive va disparaître. Euh, Et...
Voici à nouveau une publicité pour le livre. Donc, voici le téléchargement gratuit. Obtenez le PDF à partir de là. Vous pouvez le distribuer librement dans l'entreprise. Si vous souhaitez les livres physiques, je vous encourage évidemment à le faire aussi. Ils sont disponibles sur Amazon. Et le prix le moins cher est un peu plus de 10 euros.
Donc, si vous souhaitez jeter un œil à ceux-ci, il y a quelques exemplaires là. Nous avons inclus le test décisif dans le guide. Donc, l'idée du test décisif est une manière très simple de regarder, d'accord, Vous avez entendu parler de Kanban, vous avez commencé à mettre des post-its sur le mur, vous dites que vous utilisez Kanban. Utilisez-vous réellement la méthode Kanban ? Et encourager les gens à approfondir. Il y a la même raison, en fait, pour laquelle je me suis impliqué avec David Anderson dans l'écriture de ce guide, parce que...
Je suis un nouveau venu relatif dans le Kanban. Je me suis impliqué, donc j'ai commencé à travailler avec des gens utilisant Kanban en 2012 et j'ai suivi une des formations là-bas et j'ai participé au masterclass de David en 2013, qui est essentiellement David Anderson parlant pendant cinq jours de toutes ses pensées, vous savez, en quelque sorte se déversant dessus. Donc, si vous aimez ce genre de choses, et il se trouve que c'est mon cas, C'est une très bonne façon de comprendre la méthode réelle, et ce n'est pas simplement une question de, d'accord, c'est la même chose que ce que Toyota faisait avec les systèmes Kanban en production. Ce n'est pas simplement coller des post-its sur le mur. Il y a une réflexion derrière cela sur une manière flexible de définir les processus et de les améliorer en continu. Voici un test. Utilisez-vous Kanban ?
Je ne sais pas si vous connaissez l'origine du test pour mesurer l'acidité. Vous savez, vous mettez le papier dedans et si vous avez un rouge et qu'il devient bleu, alors c'est...
alcalin et si vous avez un bleu et qu'il devient rouge alors c'est acide. C'est un test très simple et en fait, il a été inventé par un alchimiste vers l'an 1300 après J.-C. Il a découvert que ce lichen sur certaines pierres a cette propriété de changer de couleur lorsque
lorsque vous l'ajoutez à de l'acide. Donc, c'est un test très simple pour essayer là-dedans. C'est la raison derrière cela, en utilisant ce mot. Et ce que nous cherchons vraiment en utilisant le test Kanban, c'est d'aider les organisations à examiner ce qu'elles font avec Kanban et à se demander si cela permet d'approfondir ce qu'est la méthode. Je dois surveiller le temps parce que nous sommes, je pense, sur un horaire plus court... Il serait utile que quelqu'un découvre à quelle heure je dois m'arrêter, mais je pense que nous sommes revenus à l'horaire normal. Donc, je vise la demie.
Beaucoup de gens commencent à utiliser Kanban comme ceci. Scrum est trop compliqué, il a trop de règles, il a trop de contraintes. Tout ce que je dois faire, c'est mettre mon travail sur le mur, vous pouvez voir ce que nous faisons, les choses que je dois faire, les choses en cours et puis les choses qui sont faites. Et c'est ainsi que beaucoup de gens commencent et disent, eh bien, Scrum est trop compliqué. compliqué, j'utiliserai Kanban, c'est en fait et si vous êtes intéressé par Wikipedia, je ne sais pas à quoi cela ressemble en français, mais les pages en anglais pour Kanban et le tableau Kanban sont assez pauvres et donc entrez-y et améliorez-les
et peut-être pensez à un meilleur exemple que cet ensemble particulier de post-its qui illustre un tableau Kanban. L'autre but de ceci est que peut-être cela suggérera des domaines où les entreprises utilisant un système de flux, Kanban,
ou d'autres méthodes peuvent chercher des moyens d'obtenir des améliorations. Quels sont les domaines que vous devriez examiner ? Et pour provoquer et défier les implémentations superficielles de la méthode Kanban afin que nous puissions réellement faire avancer ces choses vers des idées plus matures.
Donc, j'ai un historique de ceci. Donc, je suis allé, comme je l'ai dit, au masterclass de David en 2013, essentiellement dans le but de dire, qu'est-ce que Kanban ? Je sais ce qu'est Scrum parce que je peux télécharger le guide de 16 pages qui me dit les règles de Scrum. Et il y a un nombre quelconque de livres. En plus de cela, mais dans ces 16 pages, Ken Schwaber et Jeff Sutherland ont expliqué ce qu'ils entendent par les règles de Scrum. Et c'est une très bonne méthode, et je suis d'accord avec plus ou moins tout ce qui s'y trouve. à part la dernière phrase qui dit que vous ne pouvez pas changer les règles. Donc, à part cela, c'est un très bon point de départ pour un cadre du processus que vous utilisez pour développer des logiciels.
Kanban a une portée plus générale que cela.
Il s'agit du travail de la connaissance. Comment améliorer le travail de la connaissance ? Donc, il n'y a rien de spécifique en termes de développement de produits ou de développement de logiciels qui en fait partie. Alors, qu'est-ce que Kanban ?
Donc, en 2013, après être allé au masterclass de David et l'avoir écouté parler pendant cinq jours, je me dis, d'accord, maintenant je pense savoir ce qu'est Kanban. Comment pourrais-je résumer ces cinq jours ? J'ai essayé sur Twitter.
C'était ma tentative.
Si vous voulez commencer à utiliser Kanban, vous devez voir votre flux de travail, vous devez commencer là où vous êtes, vous devez rendre votre travail visible et vos politiques visibles, et vous devez apporter des améliorations en les validant au fur et à mesure. Donc, c'était mon résumé le plus court possible. Pouvez-vous faire 140 caractères en français ? Essayez ceci. Quel est votre résumé pour commencer à utiliser Kanban ? Voir le flux, commencez ici, avec un travail visible et des politiques, validez vos améliorations. Maintenant, la chose intéressante à propos de ces trois étapes est que deux d'entre elles n'impliquent de ne rien faire.
C-Flow est simplement une manière différente d'envisager le travail qui se déroule dans votre organisation. C'est ici que commence la vieille blague. Vous demandez au gars près de la clôture qui se penche par-dessus, disons, comment puis-je arriver là où vous essayez d'aller, ce village au fin fond de la campagne. Et alors le fermier vous regarde et dit, en fait, vous ne pouvez pas arriver à ce village d'ici.
D'accord, il faut commencer là où vous êtes. Ainsi, Kanban est également connu comme le processus de commencer avec ce que vous faites maintenant. Donc, d'accord, je l'ai raccourci, mais cela ne signifie pas nécessairement que c'est utile. J'ai récemment revisité cela, et après avoir fait le résumé en environ 40 pages de la définition de la méthode,
Pourrions-nous résumer les trois éléments clés, qui sont deux ensembles de principes, les principes de gestion du changement et les...
et les principes de livraison de service, ainsi que les six pratiques de Kanban. Et aussi, ceux-ci tiennent également dans des tweets. Voici donc le premier, gestion du changement, commencez ici, convenez d'évoluer, et dirigez partout par tout le monde.
Le leadership est une partie clé de sa mise en œuvre. Et pour les principes de service, vous pouvez suivre : mettez le client en premier, gérez le travail, pas les travailleurs, et faites évoluer les politiques pour les résultats.
Et enfin, les pratiques. Vous pouvez les rechercher sur Twitter si vous... Je l'ai fait récemment, donc le 10 novembre, peu importe.
Les pratiques générales d'un processus Kanban Rendez le processus visible, limitez le travail en cours, faites-le circuler, rendez-le explicite, rendez-le réactif, cela parle des boucles de rétroaction, et faites-le évoluer.
C'est une sorte de Kanban comme point de départ. Ce n'est donc pas surprenant. Les gens peuvent commencer à faire du Kanban, comme je l'ai dit, sans rien changer, en mettant des lunettes différentes et en voyant leur flux de travail et en commençant ici pour s'améliorer. Vous faites du Kanban si vous commencez à partir de là. Bien sûr, les pratiques, la toute première est généralement là où les gens s'arrêtent, rendez-le visible.
Les pratiques entrent progressivement en jeu au fur et à mesure que vous faites cela. Et je pense que l'autre chose à ce sujet, et je pense que certaines des choses que Jim Benson disait ce matin, c'est qu'il est bon d'y aller lentement. Il est bon plutôt que de dire, attendez une minute,
Nous avons essayé Scrum pendant cinq ans. Nous voulons faire quelque chose de différent. Laissons tomber tout ça. Nous ferons une grande analyse de ce que c'est, puis nous introduirons un nouveau processus et l'appellerons Kanban. En fait, ce n'est pas très utile. Il est bon de faire de petits pas vers un meilleur processus. C'est bien que vous puissiez faire du Kanban sans d'abord changer le monde. Mais lorsque vous le faites ou lorsque vous en avez fait un peu, comme le disait Jim, les colonnes sur le mur, surtout si vous utilisez des post-it pour les colonnes et que vous faites dessiner par un artiste les... Noms des colonnes en haut, cela devient une bureaucratie difficile à changer. Nous devons donc toujours chercher des moyens d'avancer. Et j'espère que le test de tournesol est l'une de ces façons qui peut vous aider à avancer, peut remettre en question le statu quo, peut remettre en question la bureaucratie et dire, Faisons-nous ces choses ? Obtenons-nous ces avantages ? Et il y a quatre questions. Les voici. Quand vous le faites, ou quand vous en avez fait un peu, comme le disait Jim, les colonnes sur le mur, surtout si vous utilisez des post-it pour les colonnes et que vous faites dessiner par un artiste les noms des colonnes en haut, cela devient une bureaucratie difficile à changer. Nous devons donc toujours chercher des moyens d'avancer. Et, espérons-le, le test de litmus est l'une de ces méthodes qui peut vous aider à avancer, peut remettre en question le statu quo, peut défier la bureaucratie et dire, faisons-nous ces choses ? Obtenons-nous ces avantages ? Et il y a quatre questions. Les voici.
La première question concerne le comportement des gestionnaires.
Il ne s'agit pas tant de parler de mauvaise conduite ou autre, mais est-ce que la manière dont les gestionnaires travaillent dans l'organisation est cohérente avec les principes de Kanban ?
Le comportement des gestionnaires a-t-il changé pour permettre Kanban ? La deuxième concerne la manière dont nous interagissons avec les clients. Une partie importante de cela consiste à vous demander, dans le processus où vous utilisez Kanban, qui est le client ? Qui est mon client ? Encore une fois, Jim l'a mentionné dans le discours d'ouverture. Si les gens répondent immédiatement et disent, qui est le client ? Et qu'ils disent que c'est lui, alors nous ne réfléchissons probablement pas vraiment à qui sont les bénéficiaires du service que nous fournissons dans notre organisation. Et qu'est-ce qui rend le service que nous leur fournissons adapté à l'objectif qu'ils ont ? J'ai en quelque sorte une autre règle ici lorsque nous parlons des clients : si, lorsque vous répondez à la question, lorsque vous approfondissez la raison pour laquelle votre groupe existe, pourquoi votre département ou votre service ou quelle que soit votre équipe,
si les personnes que vous servez sont au sein de votre organisation, continuez à poser la question jusqu'à ce que vous sortiez de l'organisation, jusqu'à ce que vous arriviez aux personnes qui bénéficient des services que votre organisation offre, car c'est essentiel. Nous parlerons un peu d'optimisation du point de vue du système, mais c'est essentiel. Donc le client, et la première question sur le client est : quelle est l'interface avec le client ? A-t-elle changé à cause de Kanban ?
La troisième question est : le contrat avec le client a-t-il changé, informé par Cameron ? Le problème avec le mot contrat ici, c'est que nous pensons à des morceaux de papier écrits et ainsi de suite. Il s'agit davantage de comprendre ce dont le client a besoin de notre part et comment il comprend cette interaction, après avoir d'abord compris l'interface avec le client. Comment cela change-t-il et comment est l'accord sur ce que nous leur livrons ? Et enfin, le modèle économique de prestation de services a-t-il changé pour exploiter Kanban ? Et cela nous amène dans de nombreux autres domaines, en se concentrant sur la valeur, en se concentrant sur le but du service en termes de génération de revenus ou... Service à un secteur particulier ou autre. Je vais développer ces quatre points. C'est l'ensemble du sujet. Je vais parler de chacun à tour de rôle. Donc, la première question est : le comportement des gestionnaires a-t-il changé pour permettre Kanban ? Voici un petit diagramme. Diagramme tiré de la couverture du livre, où nous avons dessiné les principes de Kanban en deux groupes. Donc, si vous êtes familier avec ceci, en 2013, il y avait quatre principes, bien et simple. Mais lorsque j'ai eu, la première réunion que David et moi avons eue à propos de ce livre, je lui ai dit, écoute, il y a quatre principes dans Kanban, mais en fait, je pense qu'il n'y en a que trois, parce que deux d'entre eux disent la même chose, à savoir commencer ici, sans changer les rôles ou les responsabilités des personnes dans votre service, et commencer ici en utilisant le processus qui est réellement pratiqué en ce moment. Ils disent tous les deux la même chose, commencez ici, commencez par ce que vous faites maintenant. Et donc ces trois principes, commencez par ce que vous faites, convenez de poursuivre un changement évolutif, encouragez les actes de leadership à tous les niveaux, ils concernent beaucoup la manière dont le leadership peut agir. Kanban réussit lorsque les gestionnaires dans le processus respectent les politiques du système Kanban. Vous remarquerez peut-être, si vous êtes très observateur en regardant cette diapositive, qu'il y a Kanban avec un K majuscule sur cette diapositive et Kanban avec un k minuscule. Nous devons donc faire la distinction car malheureusement, en 2007, je dis malheureusement, je pense que ce n'est pas un mauvais nom, mais la méthode dont nous parlons a été nommée Kanban. Kanban est un mot existant en japonais. Il signifie panneau ou signal visuel ou une manière visuelle de contrôler un processus de flux utilisé dans les systèmes Toyota depuis les années 40.
Nous utilisons des systèmes comme celui-ci dans le travail de connaissance dans la méthode Kanban. C'est pourquoi il y a parfois Kanban avec un K majuscule et parfois Kanban avec un k minuscule.
La méthode Kanban, la communauté Kanban, le Kanban... En parlant de ces choses, K majuscule, et les tableaux Kanban, les systèmes Kanban, les kanbans en tant que signaux physiques réels ou signaux virtuels dans un système basé sur la connaissance qui contrôlent le travail en cours.
Donc, pour en revenir au point, Kanban réussit lorsque les gestionnaires respectent les politiques du système Kanban, adoptent une orientation client et gèrent en accord avec les principes de prestation de services, ces choses. Et cela concerne principalement l'orientation client.
Nous avons donc suggéré à partir de ce cadre quelques questions supplémentaires. La première est : le comportement des gestionnaires est-il cohérent avec l'approche de Kanban en matière d'engagement différé et de système de tirage ? Cela signifie donc que nous devons décomposer certains de ces mots et dire réellement ce qu'ils signifient.
Le premier, l'engagement différé. Est très important. Si nous voulons avoir un système qui s'écoule, nous ne voulons pas que le travail soit poussé dans ce système de manière aléatoire sans considérer si cette demande de service peut être satisfaite. par le service lui-même.
Je réalise que j'utilise beaucoup le mot service et de multiples façons différentes, mais j'espère que vous pouvez le décomposer dans votre tête en français, vous êtes une personne plus intelligente que moi.
Donc, l'engagement différé. La première chose est que sur un tableau Kanban, ou du moins dans un système Kanban lorsque nous le comprenons, il y a un point où le travail entre dans le système et un point où nous disons qu'il est terminé. C'est la portée de ce service, depuis le moment où nous sélectionnons les éléments à faire jusqu'à celui où nous disons qu'ils sont terminés.
En d'autres termes, le point d'entrée et le point de sortie du système doivent être compris. Et à l'intérieur de celui-ci, nous devons limiter le travail en cours afin qu'il y ait un délai d'exécution prévisible, une nature prévisible du système.
La deuxième chose Parce que les limites de travail en cours (WIP) sont le principal moyen que nous utilisons pour obtenir ce flux prévisible à travers le système lui-même,
nous devons examiner les limites de travail en cours en termes de système, et pas seulement en termes de limitation de la surcharge pour les individus dans le processus. C'est l'une des façons, encore une fois, Une fois que les gens ont dépassé l'idée que Kanban consiste à coller des post-it sur un mur avec ce que vous faites en ce moment, l'étape suivante... D'accord, nous voulons empêcher les gens de faire du multitâche. Nous voulons limiter ce qu'ils font. Et une bonne façon de faire cela est d'introduire cette idée d'avatars ou peut-être d'avoir des couloirs par personne où nous pouvons voir ce que cette personne fait. A-t-elle trop de choses à faire et est-elle donc un goulot d'étranglement dans trop de parties du processus ? C'est donc une bonne évolution simple par rapport à la simple visibilité du travail.
Mais nous appelons cela un système proto-Kanban parce que ce n'est pas un système où le flux est considéré dans son ensemble.
Et en particulier, vous pouvez voir lorsque vous utilisez, vous savez, j'ai trois avatars pour chaque personne ici, donc le nombre maximum de tickets sur lesquels cette personne pourrait travailler est de trois, cela ne limite pas réellement le travail en cours dans cette colonne ici parce qu'il y a quelques cartes sur lesquelles personne ne travaille. Ainsi, vous pouvez faire entrer du travail dans le système sans que les gens y travaillent même si vous le limitez par personne. Donc, c'est la première chose à comprendre que le système Kanban limite le travail en cours en tant que système dans son ensemble et à faire comprendre cela aux gestionnaires et à les faire soutenir cela tout au long du processus. Sinon, il est simplement vu comme un moyen de rendre le travail visible et ensuite de continuer à pousser du travail dans le système. Maintenant, ces types de systèmes... et Dave en a classé un certain nombre appelés systèmes proto-Kanban. Ce sont des étapes sur le chemin vers un système Kanban complet, et ce sont des étapes utiles pour, vous savez, lorsque vous commencez à visualiser votre travail et à comprendre les politiques qui peuvent... Ils rendent le travail transparent, nous pouvons voir ce qui se passe, il y a un soulagement de la surcharge en particulier si nous utilisons quelque chose comme le système d'avatars pour réduire le multitâche, il y a potentiellement une amélioration de la qualité et une meilleure collaboration et une plus grande empathie et ainsi de suite, et des niveaux améliorés de capital social à travers cela. C'est donc précieux, nous ne voulons simplement pas que les gens s'arrêtent là. C'est vraiment l'idée du test de litmus Kanban. Ne vous arrêtez pas. Continuez à poser ces questions, et puis quand vous les aurez toutes posées, vous aurez, espérons-le, compris qu'il y a encore plus à faire. Notre prochain système proto-Kanban courant est le système Kanban d'équipe, où vous avez un backlog, vous avez des choses en cours, et vous avez du travail en cours d'exécution. Cela pourrait être votre backlog de produit et votre backlog de sprint et vous êtes en cours et vous avez terminé.
Ce qui, si c'est votre système et c'est votre service, est une bonne façon de le gérer. Lorsque nous mettons réellement plusieurs équipes Scrum ensemble, ce n'est pas le système complet. Et c'est là que cela devient non optimal en termes de vision de bout en bout. Donc nous limitons, voici notre point d'engagement ici, et voici notre point de fin ici, notre point d'achèvement. Ainsi, tout le travail est contrôlé en termes de ne pas trop démarrer, de ne pas commencer un travail que nous ne pouvons pas terminer, mais nous ne contrôlons pas les files d'attente ici. Dans un système plus large où plusieurs équipes travaillent, cela peut poser problème car nous avons ces files d'attente infinies qui arrivent globalement.
Par exemple, il existe plusieurs façons de relier des systèmes Kanban entre eux.
Vous pouvez voir que cela a été fait sur un tableau ici où nous avons une équipe de développement et une équipe de test. Et l'équipe de développement examine son processus. Ils limitent le travail en cours dans leur activité en continu et ils placent le travail terminé ici. Et il en va de même pour l'équipe de test ici. Ils ont une file d'attente d'entrée, ils limitent le travail en cours jusqu'à ce que le travail soit terminé. Mais cette file d'attente infinie au milieu signifie effectivement que nous ne contrôlons pas le travail en cours sur l'ensemble du système. Donc, c'est vraiment un plaidoyer lorsque vous examinez les systèmes, que vous regardiez l'ensemble de la portée de ce qui se passe et que vous voyiez...
Contrôlons-nous réellement le travail en cours sur l'ensemble de la portée afin d'obtenir un débit prévisible ? et les délais d'exécution.
Donc, oui, je pense avoir couvert cela. Donc, la troisième chose concernant le comportement de gestion est : comprenons-nous tous, et du point de vue d'un manager, que nous devrions nous concentrer sur le client ? La concentration sur le client est-elle toujours une raison comprise pour le changement ? Et cela se rapporte à l'un des autres aspects de ce pilier, l'aspect des valeurs et la concentration sur le client comme partie clé des valeurs dans Kanban.
Concentrez-vous sur le client, concentrez-vous sur le fait de rendre le service que vous fournissez adapté à leur usage afin que les choses puissent s'améliorer.
La première chose, et c'est en fait l'un des principes de livraison de service, se concentrer sur le travail plutôt que sur les travailleurs. Plusieurs personnes que j'ai entendues parler hier et aujourd'hui ont évoqué ce besoin de ne pas garder les gens occupés, mais de regarder le travail circulant dans un système afin que le travail reçoive de l'attention au bon moment. Il faut avoir une certaine flexibilité pour que parfois les gens travaillent en attendant que du travail arrive plutôt que d'être pleinement concentrés, pleinement engagés sur un travail précédent. À Lean Kanban Central Europe, Nicholas Modig parlait d'un système pour diagnostiquer les enfants atteints de TDAH. Et le changement dont il parlait est ce passage de la volonté de garder des ressources coûteuses comme les médecins, les infirmières et les cliniques, etc., pleinement utilisées, afin que le travail reçoive de l'attention au bon moment. Il faut avoir une certaine flexibilité pour que parfois les gens travaillent en attendant que du travail arrive plutôt que d'être pleinement concentrés, pleinement engagés sur un travail précédent. Lors de Lean Kanban Central Europe, Nicholas Modig parlait d'un système pour diagnostiquer les enfants atteints de TDAH. Et le changement dont il parlait est ce passage de maintenir des ressources coûteuses comme les médecins, les infirmières et les cliniques, etc., pleinement utilisées.
Afin que nous ne gaspillions pas leur temps parce qu'ils n'ont personne sur qui travailler. Et en inversant cela pour examiner le processus du point de vue du patient, dans ce cas, un enfant diagnostiqué avec un TDAH. La chose intéressante lorsque vous faites cela et que vous vous concentrez sur le travail que vous devez faire et les étapes que le travail traverse, et que vous optimisez pour le patient, vous obtenez également un meilleur débit, vous obtenez également un meilleur taux de livraison. Donc, ce n'est pas uniquement un coût de se concentrer sur le client
et non sur les managers, sur les travailleurs, mais en encourageant effectivement les gens à s'auto-organiser et à améliorer leur façon de travailler.
travail et quels sont les blocages dans le travail lui-même. Donc, ce sont trois choses et ce principe de gestion, nous avons eu des discussions parce qu'il a commencé en tant que numéro quatre et il est assez évident qu'il doit être le numéro un car il s'agit de la manière dont nous cherchons à améliorer notre façon de travailler.
Et pour obtenir ce leadership à tous les niveaux grâce à l'utilisation de Kanban et en permettant aux gens de comprendre cette idée que nous voulons nous améliorer en continu à partir de là où nous en sommes. Donc, la deuxième question du test décisif est l'interface avec les clients. Votre interface client a-t-elle changé en accord avec Kanban ?
Et que voulons-nous dire par cela ? Eh bien, nous allons revenir sur cet aspect de l'engagement différé et des systèmes de flux et comment nous pouvons en fait empêcher le travail d'être poussé dans un système et ensuite de bloquer le système et de causer un pire service à livrer en conséquence.
Donc, les éléments de ceci, nous avons besoin d'un engagement différé, nous avons besoin d'une stratégie de réapprovisionnement pour planifier et desservir et sélectionner le travail afin que nous maximisions la valeur mais aussi afin que nous ne commencions pas un travail qui ne peut pas être complété dans cette chose. Donc, c'est un aspect clé. Nous nous concentrons donc sur l'interface client, sur la maximisation du flux de valeur et l'exploitation des contraintes du système. Peut-être sommes-nous contraints en termes de ressources, c'est probable à court terme, au moins à court terme. Mais il y a d'autres contraintes que nous ne pouvons pas changer immédiatement. Nous travaillons dans ce cadre pour trouver la meilleure façon de fournir un service adapté à l'objectif du client. Donc, encore une fois, il y a quelques questions supplémentaires à poser à ce sujet. Ce n'est pas une bonne couleur pour cet écran, mais c'est un peu comme celui que j'ai fait précédemment. Les demandes arrivent ici, nous en sélectionnons certaines, nous en développons certaines, nous les acceptons, puis elles sont complètes. Il y a une petite colonne ici qui dit 'publié'. Est-ce un système Kanban ? Petit k. Eh bien, pas encore. Nous devons identifier le point d'engagement et de livraison. Nous avons donc défini le périmètre du système, et ensuite nous disons que ceci est potentiellement un système Kanban, à condition que nous ayons un mécanisme pour limiter le travail en cours. Et c'est la manière la plus courante que nous voyons... les systèmes Kanban être définis dans le travail de connaissance avec des chiffres ici. Donc, je trouve que c'est un quatre, donc c'est rouge parce que vous ne pouvez plus en mettre. C'est un six. C'est un un.
Je recommande ce modèle, d'ailleurs, d'utiliser dans... Une partie de votre processus que vous avez en cours et prêt. Il y a différentes façons dont les gens indiquent que le travail est prêt pour l'étape suivante d'un processus comme celui-ci. Parfois, c'est un marqueur ou le marquer comme terminé d'une manière ou d'avoir une colonne 'terminé'. Parfois, il y a une file d'attente entre les deux qui est partagée, mais vous pouvez pousser des éléments d'ici à ici parce que cela fait partie de ce processus. Ce que vous ne voulez pas faire, c'est le pousser à l'étape suivante parce que, encore une fois, vous voulez que chaque partie du processus, surtout si c'est un service indépendant ou un travail indépendant,
nous voulons que cela soit tiré vers l'étape suivante. Donc, ces gars ont la capacité de tirer ces deux tickets vers l'étape suivante du processus.
Donc, un système de tirage avec un travail en cours limité. Et je pense que l'autre chose à dire à propos des limites de travail en cours, c'est que ce n'est pas une science exacte. Je vois Don assis au fond de la salle et il nous a donné de très bonnes bases scientifiques et mathématiques sur les niveaux de limites de travail en cours qui donnent le meilleur équilibre entre
le débit ou le taux de livraison et le délai d'exécution. Aucune limite de travail en cours ne pose le problème qu'il est possible que vous ayez une variation de la demande, beaucoup de travail arrive, il est poussé dans le système, et le débit s'effondrera en raison de la congestion et de la dépendance entre trop de travail en cours. Si vous sur-contraignez un système Kanban et mettez des limites très petites et douloureuses, vous obtiendrez moins de débit, ou au moins au-delà d'un certain point, vous obtiendrez moins de débit. Parfois, vous entendrez des coachs dire que c'est une bonne chose, car cela provoque de la douleur dans le processus. Nous essayons de faire avancer le travail. Nous n'avons rien à faire parce que nous attendons l'étape suivante du processus. Donc, ces analystes d'affaires définissant toutes les exigences ici ne peuvent pas pousser leur travail ici et ensuite commencer autre chose. Alors, que font-ils ? Vous savez, c'est une frustration. Maintenant, si nous encourageons la collaboration, nous en parlons chaque fois que nous nous réunissons au stand-up ou autre, ce fait, je n'ai rien à faire pour le moment, provoque une discussion sur la manière dont nous pouvons élaborer, comment nous pouvons peut-être briser certaines des parties, ou soutenir certaines des parties du processus qui sont congestionnées et qui ont trop de travail. S'il n'y a pas de collaboration ici, ces limites de travail en cours très strictes feront chuter le débit. Même si vous allez obtenir un meilleur délai d'exécution. Ne traitez donc pas vos limites de travail en cours comme gravées dans le marbre. Je passais en revue un tableau Kanban l'autre jour et il était magnifiquement disposé avec des post-it et tout ce que vous vous attendez à voir. Mais j'ai remarqué que les limites de travail en cours avaient été dessinées et c'était 3-3-3-3 dans ces colonnes. Et elles avaient été écrites et jamais effacées, jamais remises en question. Quelqu'un a dit que ce serait une bonne idée d'avoir une limite de travail en cours de 3 dans la colonne de développement ici. Et remettez cela en question. Vous savez, ce sont ces points de douleur lorsque vous pensez, que faire maintenant parce que la limite de travail en cours dit que je ne peux pas travailler, qui devraient provoquer une discussion. Encore une fois, si vous êtes allé à l'atelier de Dimitar hier, il simulait en fait l'effet des limites de travail en cours où il y a peu de collaboration. Et vous pouvez non seulement obtenir un effondrement en termes de, eh bien, un effondrement en termes de débit va se produire si cela a lieu. Donc, les limites de travail en cours et la collaboration doivent aller de pair. Donc, la deuxième question subliminale sur les choses de l'interface client est, les points d'engagement et de livraison sont-ils clairement définis et enregistrons-nous les délais d'exécution et les taux de livraison ? Et cela semble vouloir que je vous fasse entrer dans beaucoup de graphiques et de collecte de chiffres et c'est de la magie de processus, n'est-ce pas ?
En réalité, ce n'est pas difficile. Tri McGuinness a récemment publié des feuilles de calcul qui sont vraiment utiles pour simplement, si vous collectez simplement les dates des éléments qui entrent dans un système Kanban à partir de la date à laquelle ils en sortent, vous obtenez beaucoup d'informations sur ce qui se passe, quelle est la variabilité dans le processus, quelle est la variabilité de la demande et ainsi de suite. Ce n'est pas dans le but de le faire pour lui-même, c'est dans le but de savoir où l'améliorer. Nous voyons que cela alimente l'étape suivante dans le test Kanban. Limites également.
Voici ce que nous entendons par délai d'exécution. Je l'ai étiqueté délai d'exécution du système et cela deviendra clair dans un instant. Donc, du point d'engagement de votre système au point de livraison de votre système, vous capturez les délais d'exécution afin de comprendre où se trouvent les goulots d'étranglement, quel type de service vous pouvez offrir aux clients.
Et quelle est la variabilité, etc. Et l'autre fondamental qui ressort de ceci est combien est livré, le taux de livraison.
Il existe différentes façons d'afficher ces données, mais ce sont deux des plus courantes, un diagramme de dispersion des délais d'exécution et un diagramme de flux cumulatif, qui montre en quelque sorte l'entrée dans le système et la sortie du système. Lorsque vous voyez des diagrammes de flux cumulatifs très striés, cela peut vous être utile, mais en termes de simple explication de ce qu'est un diagramme de flux cumulatif, simplement tracer le point d'entrée point, le point d'engagement de votre système et le point de sortie ou de livraison de votre système est un bon point de départ. Vous pouvez immédiatement voir alors quel est le travail en cours à tout moment et vous pouvez obtenir des indications sur la manière dont cela change, si le travail en cours augmente, ce qui arrive aux délais d'exécution, etc. Et le gradient de cette ligne vous donne le taux de livraison ou le débit.
J'ai dit que j'expliquerais le délai d'exécution du système parce que cela concerne l'interface client et nous devons considérer ce que le client expérimente en termes de délai d'exécution. Et en général, nous avons une situation quelque peu similaire à ceci. Voici le système que, vous savez, voici notre équipe, voici ce que nous faisons et nous en sommes très fiers le délai d'exécution que nous avons avec le délai d'exécution du système à partir du point d'engagement jusqu'au point de livraison, c'est ce que nous faisons mais qu'en est-il du client ? Le client, lorsqu'il fait une demande, s'attend à une sorte de service. J'ai fait la demande, je l'ai saisie sur le site web ou j'ai demandé cette fonctionnalité ou j'ai convenu avec les ventes ou autre chose.
Et donc il attend à partir de ce point. Nous comptons à partir de ce point. Et à l'autre extrémité, nous y voilà, nous avons fait tout le travail. Tout ce qui doit être fait maintenant, c'est la mise en production. Et voici le délai d'exécution du système, du moment où nous commençons le travail jusqu'à la livraison, qui est de deux semaines. C'est prêt à partir. Et la mise en production prend 16 semaines.
Nous devons examiner cela dans son ensemble. Il s'agit donc de changer l'interface client. L'interface client a-t-elle changé pour votre service parce que vous utilisez Kanban ? Et cela concerne beaucoup cette partie, tout d'abord,
Lorsqu'un client fait une demande, cela signifie-t-il que vous allez travailler dessus ? Eh bien, non si nous limitons le travail en cours. Le simple fait de demander quelque chose ne signifie pas que nous avons la capacité de répondre à cette demande. Et nous devons rendre cela visible pour le client.
Nous dire à ce stade que nous avons livré le travail ne signifie pas que le client l'a reçu. Il y a un moment ultérieur où cela devient réellement opérationnel ou lorsque le système en direct active la fonctionnalité qu'ils ont demandée. Donc, cela ne suffit pas.
Ce que nous recherchons, c'est quelque chose comme ceci, où
Le client comprend que faire une demande n'est pas la même chose que le service s'engageant à la livrer. Nous avons expliqué au client pourquoi nous faisons cela. Cela signifie que nous avons des délais d'exécution prévisibles que nous pouvons vous donner sous forme de SLA. un accord sur le type de service que nous allons fournir. Pourquoi un client accepterait-il cela ?
Vous savez, attendez une minute, je veux un système, si je vous dis que j'ai besoin de ceci, j'ai besoin que vous travailliez dessus. Pourquoi le client dirait-il, oh, ce sera mieux, alors j'attends que vous me disiez que vous allez le faire. Est-ce que c'est bien ? Eh bien, oui, si nous impliquons le client dans le processus, si nous rendons cette file d'attente visible. Et en réalité, ce que nous faisons, c'est que nous déplaçons la responsabilité de ce travail dans le domaine du client. Je vais vous donner une analogie, qui, je l'espère, sera utile dans un instant. À l'autre extrémité... Que faisons-nous concernant l'équipe de développement qui dit que ce travail est terminé et que le client ne l'obtient pas avant 16 semaines ? Eh bien, nous devons rendre cela explicite. Maintenant, dans ce cas, je l'ai montré sur un rythme régulier plutôt que sur un élément limité par le WIP. Mais si nous avons un rythme régulier de publication, c'est une façon de limiter la quantité de travail en cours globalement, à condition que, peu importe la quantité de travail effectuée,
au moment où cela devient opérationnel, cela se fait à un rythme régulier. Ce n'est pas pour dire que nous pouvons, eh bien, l'essentiel est que nous ne négligeons pas l'expérience client en termes de moment où ils obtiennent le service qu'ils ont demandé.
Un restaurant de sushi et un restaurant ordinaire. Y avait-il quelqu'un ici à l'événement Kanban Leadership de Barcelone ?
Nous avons eu une petite session pour dessiner des affiches expliquant comment expliquer Kanban à votre grand-mère.
Si vous êtes aussi vieux que moi, cela fait longtemps que j'aurais pu le faire. Mais votre mère, comment expliquez-vous Kanban à votre mère ?
Eh bien, nous avons eu l'idée de deux restaurants, un restaurant de sushi et un restaurant ordinaire. Et en fait, l'équipe qui a décidé de faire une autoroute et de montrer tous les mécanismes pour obtenir un flux sur une autoroute était une bien meilleure façon d'expliquer Kanban. Mais je pense toujours que nous avons eu une bonne idée ici, alors je vais vous la raconter quand même. événement sur le leadership.
Nous avons eu une petite session où nous dessinions des affiches pour expliquer le Kanban à votre grand-mère.
Si vous êtes aussi vieux que moi, cela fait longtemps que j'aurais pu le faire. Mais votre mère, comment expliquez-vous le Kanban à votre mère ?
Eh bien, nous avons eu l'idée de deux restaurants, un restaurant de sushi et un restaurant ordinaire. Et en fait, l'équipe qui a décidé de faire une autoroute et de montrer tous les mécanismes pour obtenir un flux sur une autoroute était une bien meilleure façon d'expliquer le Kanban. Mais je pense toujours que nous avons eu une bonne idée ici, alors je vais vous la raconter quand même.
C'est l'heure du déjeuner. Paris est très bien. Je ne vais pas utiliser Paris parce qu'il y a trop d'endroits sympas où il faut faire la queue et où vous devriez profiter du déjeuner. Donc à Londres, il est très important de déjeuner rapidement. Et les clients choisissent les restaurants, oui, en termes de qualité et du type de nourriture qu'ils vont avoir, ce dont ils ont envie et combien de temps ils ont. Mais aussi en fonction de la rapidité et de la certitude d'obtenir de la nourriture dans un certain délai. Donc, comparez simplement les deux processus dans un restaurant de sushi. Quand vous entrez dans le restaurant, vous vous asseyez à la table et la nourriture défile. Et en l'espace de... Une douzaine d'assiettes passent devant vous, celle que vous voulez est là, vous la prenez, vous la mangez et vous pouvez manger autant que vous voulez, puis vous partez. Et le chef, à la fin de la journée, regarde quels plats ont été mangés et il les remplace sur le tapis roulant. Très bien. Quand vous entrez dans un restaurant ordinaire,
Il y a une file d'attente devant la porte, mais une fois que vous êtes entré, vous vous asseyez à une table et vous attendez que la serveuse vienne vous demander ce que vous aimeriez boire. Et puis vous attendez, selon le temps que cela prend pour préparer les boissons, jusqu'à ce que les boissons arrivent. Et ensuite, on vous demande ce que vous aimeriez manger. Et il y a une autre file d'attente que vous ne voyez pas, le chef préparant ce repas et l'apportant à la table pour le servir.
En d'autres termes, il y a ici des files d'attente... invisibles que vous ne pouvez pas voir. Cette file d'attente est visible. Elle est devant la porte. Ce sont deux restaurants très populaires. C'est que, une fois que vous êtes à l'intérieur de celui-ci, le restaurant peut vous dire combien de temps il faudra avant que vous obteniez les cinq plats que vous voulez.
C'est-à-dire que les files d'attente sont externes et sous le contrôle du client. Quand le client voit ces deux files d'attente devant le restaurant, le client peut décider : je pense vraiment vouloir manger dans ce restaurant, donc j'attendrai. Je peux voir approximativement à quelle vitesse la file d'attente avance. Ou pas, ou je peux aller dans un snack et prendre un sandwich. Donc, il s'agit de rendre les files d'attente visibles. C'est vraiment ce que nous essayons de faire dans ce processus. Cette partie du processus doit être visible pour le client et dans une certaine mesure sous le contrôle du client, car elle n'est pas sous le contrôle du service.
C'est vraiment pour insister sur l'engagement différé. Il n'y a pas d'engagement de la part du restaurant à vous donner un repas avant que vous ne passiez la porte. Et ensuite, ils s'engagent à vous donner de la nourriture. Et surtout, le client s'engage à manger la nourriture. D'accord, je sais que vous pouvez partir. Je sais que si vous regardez le menu et que vous détestez. Oui, je l'ai fait aussi. Mais c'est vraiment embarrassant. Donc, cela n'arrive pas trop souvent. Une fois que vous avez passé le point d'engagement, vous êtes tous les deux engagés. à ce que ce contractant prépare et mange la nourriture. Pas nécessairement la manger. Délai d'exécution prévisible pour le client. Donc, ne pensez pas seulement en termes de délai d'exécution. Nous en sommes toujours au numéro deux.
Je n'ai plus de temps.
Et le feedback est une chose clé. Donc, je vais passer très rapidement sur le reste.
Le contrat client concerne, d'accord, nous collectons les délais d'exécution et les taux de débit, etc., au fil du temps. Nous pouvons maintenant, parce que nous contrôlons le travail en cours, donc le processus est plus prévisible, nous pouvons fournir... Un SLA ou nous pouvons répondre aux attentes du client en termes de délai d'exécution. En comprenant toujours que nous déplaçons le point d'engagement vers un point d'engagement partagé.
Donc, nous nous concentrons à nouveau sur l'adéquation à l'usage. Cela peut être un arrangement explicite. C'est pourquoi il est dit que le contrat client a changé. C'est très rarement un contrat à mon avis, bien que parfois ça le soit. Mais nous pouvons rendre explicite... Et probablement des vues probabilistes du service que nous pouvons fournir par cette équipe. Et si le client a des attentes de niveau de service, une fois que je suis à l'intérieur du restaurant, je vais obtenir de la nourriture dans un certain délai. Donc, les engagements sont basés sur des niveaux convenus ou compris.
Désolé, je vais dans la mauvaise direction. Et nous pouvons, parce que nous capturons les délais d'exécution et les taux de livraison, utiliser également la prévision probabiliste. C'est la feuille de calcul de Troy McGinnis. Je pense qu'il y a une référence à la fin. de
pour être réellement prévisible en termes de ce que le client attend du service. Dans la variabilité qui est connue, et c'est encore une fois rendre cela visible en termes des attentes que le client a pour le niveau de service qu'il reçoit.
Et enfin, le modèle économique de prestation de services a-t-il changé à la suite de Kanban pour exploiter Kanban ? C'est ici que nous avons un focus sur la valeur. Nous avons donc un système prévisible. Nous avons une compréhension entre le client d'un service et le prestataire d'un service. Il y a un point d'engagement mutuellement convenu, et il y a un taux prévisible, dans des plages de variabilité, que nous pouvons traverser. Mais nous pouvons également aller plus loin en termes d'exploitation de certains des autres aspects de Kanban, comme les classes de service, comme la répartition des capacités. allocation et réservation, comme la formation de la demande et la tarification différenciée.
La tarification différenciée est intéressante, mais bien sûr, si vous avez des classes de service, nous savons que très souvent le service de première classe coûte plus cher que le service de seconde classe. C'est un modèle courant dans les affaires et nous pouvons l'utiliser dans la prestation de services.
Les questions supplémentaires ici.
Premièrement, le modèle économique de service utilise-t-il les classes de service de manière appropriée ? Donc, l'idée des classes de service est parfois confondue dans Kanban avec les types de travail.
Très souvent, il y a différents types de travail qui arrivent, des corrections de bugs et de nouvelles fonctionnalités, de grandes initiatives et de petits paris.
Nous devons distinguer les types de travail si nous essayons d'analyser les délais d'exécution et les taux de livraison parce qu'ils varieront en fonction du type de travail que vous faites. Un bug d'urgence comparé à une nouvelle fonctionnalité qui nécessite une validation avec la communauté des utilisateurs, etc. Donc, faites des distinctions entre le type de travail, mais vous pouvez attacher différentes politiques aux différents types de travail ou au travail avec différents coûts de retard. Et l'idée du coût du service et l'idée de ces archétypes. Qui viennent du livre bleu de David. Donc, le livre bleu de David date de 2010, il est donc présent depuis un bon moment. Donc, ceux-ci sont assez matures, mais ce que j'encouragerais les gens à faire, c'est de regarder le principe derrière cela dans votre contexte, et non pas simplement de dire que chaque tableau Kanban a une voie express, par exemple. En général,
les voies express sont mises en place sur les systèmes Kanban parce que les gens ont lu cela dans le livre de Davis ou ont vu ces archétypes ou autre chose.
Et oui, lorsque nous avons des éléments où le retard, si nous retardons ces choses du tout, nous allons encourir des coûts très élevés. Par exemple, le serveur est en panne et nous ne pouvons pas prendre de commandes. Vous savez, l'ensemble des revenus de l'entreprise est en danger ici jusqu'à ce que nous le remettions en marche. Ou si nous ne publions pas cela à cette date, nous sommes condamnés à une amende par le régulateur. Encore une fois, il y a un point très clair où le coût du retard change. Donc, celles-ci sont utiles à comprendre, mais aussi à examiner dans votre contexte où vous pourriez concevoir des classes de service pour le contexte dans lequel vous travaillez. Le danger d'ajouter des voies express dans les systèmes Kanban est que le PDG arrive, voit une voie express, dit, oh oui, j'ai cette fonctionnalité préférée, j'aimerais qu'elle aille dans la voie express. Vous devez avoir des discussions sur la raison pour laquelle vous avez une voie express et à quoi elle sert, etc. Alors soyez prudent avant de simplement adopter ces éléments. Et les appliquer. Il y a d'autres éléments intéressants. dont les gens ont parlé dans la communauté Kanban et qui sont utilisés dans divers endroits.
Et l'idée générale derrière cela est : y a-t-il une capacité dans le système pour couvrir les risques provenant de différentes sources de demande et de différents types de travail ? Donc, utilisons-nous les ressources au sein des ressources disponibles pour le service de différentes manières selon le type de travail entrant ? Par exemple, les ressources peuvent-elles être détournées vers des tâches prioritaires pendant les périodes de forte demande ?
Regardons simplement ceci. Donc, encore une fois, Don est au fond de la salle. J'ai suivi le cours de Don sur le Coût du Retard cette année. J'ai pensé que, puisque j'avais déjà écrit une partie du livre sur le Coût du Retard, il valait mieux parler à la source, ce qui est très utile. Et nous avons immédiatement fait une deuxième édition.
Donc... Voici certaines des choses dont Don parle dans son cours en termes de gestion de la variabilité. Le travail de la connaissance traite fondamentalement du travail variable. Ce n'est pas comme une chaîne de production mécanisée. Nous devons donc nous attendre à la variabilité et nous devons même accueillir la variabilité. Ce n'est pas quelque chose à éliminer du processus. Mais il existe différentes façons de limiter cela en utilisant des limites de travail en cours (WIP), en utilisant des classes de service, en utilisant différentes sortes de moyens pour limiter le WIP comme le con WIP, en purgeant effectivement les WIP lorsque nous obtenons
un effondrement dû à la congestion parce qu'il y a trop de travail en cours, en redéfinissant le point final avant que le backlog ne soit terminé. Celle que je voulais aborder, plutôt que d'en parler, je n'ai pas le temps, mais nous l'avons en quelque sorte couverte.
Il y a aussi un autre aspect en termes d'exploitation de ce système de flux, qui consiste à réfléchir à la manière dont nous déployons les ressources.
Encore une fois, nous restons bloqués à penser à un seul modèle. Donc, les systèmes bureaucratiques avec des départements cloisonnés où les gens font le même type de travail par opposition à des équipes pluridisciplinaires et transversales où vous réunissez des personnes pour résoudre un problème particulier. Ces deux approches sont valables.
Dans leur contexte. Et il existe également des variantes que nous pouvons concevoir en fonction des contraintes et des besoins particuliers pour fournir de la valeur à notre client. Donc, l'idée de l'attraction des ressources, où nous pouvons déplacer les ressources vers des zones de forte demande, est comme utiliser des analystes d'affaires pour les tests.
Nous pouvons...
Nous pouvons nous assurer que nous utilisons les classes de service ou la classification du type de travail que nous faisons, que nous incluons toujours un certain travail à bénéfice intangible, qui est interruptible en période de
forte demande ou autre, et ne pas charger complètement les services avec du travail planifié. Nous faisons de la planification de portefeuille dans la banque avec laquelle je travaille en ce moment, et la règle est que les équipes ne réservent pas plus de 50 % de leur temps pour le travail qui est planifié trois mois à l'avance. Il s'avère que cela augmente le débit global parce que nous avons de la marge dans le système, parce que nous ne saturons pas. Lorsque nous chargeons complètement les équipes, ce que vous trouvez, c'est que tout ce qui est à la fin des trois mois n'est pas, vous savez, rien n'a été fait. Et donc, ne pas charger complètement les services avec du travail planifié est une chose importante. Les personnes T-SHAPED, vous avez probablement entendu parler de cette idée où des ressources plus expérimentées ayant une large gamme de compétences mais ayant toujours leurs spécialités.
Sont une ressource très utile à avoir dans les équipes. Et en utilisant les personnes, plutôt que de dire, d'accord, voici un nouveau travail qui arrive, nous mettons la personne la plus expérimentée avec la plus large gamme de compétences sur le premier travail qui arrive. Ces personnes sont maintenues, nous les utilisons comme experts flexibles, et nous attribuons généralement le travail. Donc, c'est plus ou moins là où je vois que j'ai dépassé le temps imparti. Et donc je vais simplement afficher la diapositive de résumé. Et très rapidement, y a-t-il des questions ? C'est tout.
Des questions ? Je vais mettre les diapositives sur SlideShare.
Voici mon identifiant Twitter si vous voulez me contacter directement. Et téléchargez la version française de cela et donnez vos commentaires à Dimitri. Il coordonne cet effort pour avoir le livre physique disponible dès que possible. Merci pour votre temps.