Fabrice Aimetti

Paulo Caroli - Dans ce billet, je parle du whisky et de la Loi de Little... Lire la traduction

J'ai traduit ce billet de Jason Yip : "Exploring Lean and Kanban for Portfolio Management".

J'ai récemment animé une discussion sur le Kanban pour la gestion de portefeuille pour la Limited WIP Society à Sydney. Avec le recul, étant donné le nombre de concepts inconnus soulevés, je me demande s'il n'aurait pas été plus utile de faire une présentation avant que la discussion commmence. Dans tous les cas, afin d'être prêt la prochaine fois, j'ai créé une carte heuristique que je pense utile de partager avec vous (cliquez dessus pour l'agrandir) :

Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Bon, j'ai encore craqué (merci la météo) sur un billet de Steve Blank : "Why Startups are Agile and Opportunistic – Pivoting the Business Model".

Les startups sont le moyen de trouver l'ordre dans le chaos.^[1] Steve Blank

La semaine dernière, lors d'une réunion du conseil d'administration d'une startup, j'ai observé comment son jeune PDG s'y prenait pour annoncer les mauvaises nouvelles. "Notre stratégie actuelle ne fonctionne pas. Nous n'arrivons pas à développer l'entreprise. Chaque vente nous oblige à prendre le client par la main et cela prend beaucoup trop de temps pour conclure l'affaire. Mais je crois que je sais comment y remédier." Il a pris une profonde inspiration, son regard a fait le tour de la table du conseil d'administration et il a ensuite procédé à une reconfiguration radicale de la gamme des produits (reconditionner les produits plutôt que les reconcevoir) et un changement dans la stratégie de vente, en se concentrant sur un segment de clientèle différent. Certains des investisseurs juniors ont littéralement pété une durite. "Nous avons investi dans la stratégie que tu nous avais vendue." D'autres investisseurs ont suggéré d'ajouter de nouvelles fonctionnalités aux produits, d'autres encore ont suggéré de virer le Responsable des Ventes. J'ai alors remarqué que l'investisseur principal s'est juste assis confortablement pour écouter la suite.

Finalement, une fois que le tour de tout le monde est passé, l'investisseur principal, aux cheveux gris, s'est tourné vers le fondateur et a dit : "Si tu fais ce que nous te disons de faire et que tu échoues, nous te virons. Si tu fais ce que tu penses être juste et que tu échoues, nous te virons aussi. Mais au moins tu auras exécuté ta stratégie et pas la nôtre. Suis ton intuition et fais ce que tu penses que le marché te dit. C'est la raison pour laquelle nous avons investi sur toi." Il s'est tourné vers les autres investisseurs et a ajouté : "C'est pour ça que nous signons les chèques et que les entrepreneurs dirigent l'entreprise."

La recherche du modèle économique^[2]

Une startup est une organisation constituée pour trouver un modèle économique reproductible et évolutif^[3].

Les investisseurs de la startup parient sur un PDG pour trouver le modèle économique reproductible et évolutif.



Contrairement aux histoires qu'ont lit dans la presse quotidienne, les entrepreneurs qui bâtissent des entreprises prospères ne le font pas du premier coup. Cela arrive seulement une fois que c'est fait et qu'ils ont raconté leur histoire. Le monde réel est beaucoup, beaucoup plus compliqué. Et beaucoup plus intéressant. Voici ce qui arrive vraiment.

Observer, Orienter, Décider et Agir

Qu'ils utilisent un processus formel pour trouver un modèle économique comme le Développement Client ou simplement par essais / erreurs, les fondateurs d'une startup sont intuitivement à la recherche d'un moyen d'optimiser leur modèle économique. Ils peuvent établir leur modèle économique de façon formelle ou ils peuvent conserver les pièces dans leur tête. Dans les deux cas, les fondateurs qui réussissent, observent d'abord que quelque chose ne fonctionne pas dans leur modèle économique actuel, s'orientent sur la base de ces nouvelles informations, décident quelle partie de leur modèle économique doit changer et ensuite agissent sans aucune hésitation.



C'est un stratège de l'US Air Force, le colonel John Boyd, qui a en premier décrit cette boucle itérative Observer, Orienter, Décider et Agir (OODA). Le modèle de Développement Client que j'ai décrit et enseigné est la version entrepreneuriale de la boucle OODA de Boyd.

Faites pivoter le modèle économique

Qu'advient-il lorsque le leader de la startup reconnaît que le modèle économique initial ne fonctionne pas comme prévu ? Dans les startups traditionnelles, c'est à ce moment-là que le Responsable des Ventes ou du Marketing se fait virer et que l'on commence à chercher les coupables. En revanche, dans une start-up qui suit le processus de Développement Client, c'est lorsque les fondateurs réalisent que quelque chose ne va pas avec le modèle économique (parce que le chiffre d'affaires ne décolle pas). Ils décident de ce qui doit changer et agissent en conséquence pour reconfigurer certaine(s) partie(s) de leur modèle.



Le processus de Développement Client suppose que bon nombre des hypothèses initiales prises dans le cadre de votre modèle économique seront probablement mauvaises, il propose donc une boucle d'itération pour les corriger. Eric Ries a proposé un nom pour cette boucle dans l'itération du modèle économique : le Pivot.

L'une des conséquences positives du Pivot pour l'équipe d'une startup, c'est de se rendre compte que l'insuffisance de chiffre d'affaires n'est pas de la faute des départements Ventes, Marketing ou Ingénierie, et que la solution n'est pas de virer les gens mais bien de reconnaître qu'il y a un problème avec les hypothèses prises dans le cadre du modèle économique initial.

Les types de Pivots

Vous "Pivotez" quand vous modifiez une partie fondamentale du modèle économique. Cela peut être aussi simple que de reconnaître que votre produit se vendait au mauvais prix. Cela peut être plus complexe si vous découvrez que la cible de vos clients ou utilisateurs doit changée ou que l'ensemble des fonctionnalités est mauvaise ou que vous devez "reconditionner" un produit monolithique en une famille de produits ou que vous avez choisi les mauvais canaux de vente ou que votre programme d'acquisition de nouveaux clients a été inefficace.



Si vous établissez votre modèle économique, il sera plus simple de découvrir comment le Pivoter en listant les différents possibilités de changement. Il y a beaucoup de livres pour vous aider à comprendre comment bâtir un "Plan B", mais les grands entrepreneurs (et leurs conseils d'administration) reconnaissent que ce processus doit se faire rapidement et continuellement.

Agir dans un contexte Chaos + Vitesse + Pivots = Succès

Contrairement à une grande entreprise rentable, les startups sont contraintes par leurs liquidités disponibles. Si une startup ne trouve pas un modèle économique rentable et évolutif, elle fera faillite (ou pire se retrouvera dans la "Terre des morts-vivants", se maintenant péniblement au seuil de rentabilité). Cela signifie que les PDGs de startups sont continuellement en train de regarder s'ils ont besoin de faire un Pivot pour trouver un meilleur modèle. S'ils croient qu'un Pivot est nécessaire, ils n'hésitent pas à faire les changements. La recherche d'un modèle économique rentable et évolutif pourrait nécessiter qu'une startup fasse plusieurs pivots : certains ne seront que de petits ajustements, et d'autres seront des changements majeurs.

En tant que fondateur, vous devez vous préparer à penser de façon créative et indépendante parce que, la plupart du temps, les conditions sur le terrain vont changer si rapidement que votre modèle économique initial, sur lequel vous avez passé beaucoup de temps à réfléchir, deviendra rapidement obsolète.

Résumé

Les startups sont intrinsèquement chaotiques. Les changements rapides dans le modèle économique sont ce qui différencie une startup d'une entreprise bien établie. Les Pivots sont l'essence de l'entrepreneuriat et la clé de la réussite d'une startup. Si vous ne pouvez pas pivoter ou ne pas pivoter rapidement, vous risquez d'échouer.

Pivotez.

Leçons apprises

- Une startup est une organisation constituée pour trouver un modèle économique reproductible et évolutif.
- La plupart des modèles économiques des startups sont initialement mauvais.
- Le processus d'itération pour rechercher et trouver le meilleur modèle économique s'appelle le Pivot.
- Les Pivots doivent se produire dès que possible, rapidement et souvent.
- Lorsqu'ils investissent en amorçage, les micro-fonds d'investissement et les "super angels" savent que les entreprises sont encore à la recherche d'un modèle économique (ils comprennent la notion de Pivot).
- La plupart du temps, lorsqu'une startup cherche à lever un premier ou second tour institutionnel, les investisseurs en capital-risque s'attendent à ce qu'un modèle économique évolutif ait déjà été trouvé.
- Les Pivots sont la raison pour laquelle les startups doivent être agiles et opportunistes, et pour laquelle leurs cultures sont différentes des grandes entreprises.

Feedback :

• Je remercie Ronan Amicel pour sa relecture de l'article traduit et ses propositions.
  

Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

J'ai traduit ce billet de Steve Blank : "No Business Plan Survives First Contact With A Customer – The 5.2 billion dollar mistake.".

Avec 5,2 milliards de dollars, Iridium a été l'un des plus grands et audacieux pari de création d'entreprise^[1] jamais réalisé. Conçu en 1987 par Motorola et essaimée en 1990 en tant que société distincte, Iridium prévoyait de construire un système de téléphonie mobile qui pourrait fonctionner n'importe où dans le monde. Ce système devait couvrir chaque ville, village et pouce carré de la terre, des navires au milieu de l'océan arctique, en passant par les jungles de l'Afrique jusqu'aux sommets des montagnes reculées de l'Himalaya. Et Iridium comptait le faire sans construire un seul relai de téléphonie mobile.

Comment ? Avec une stratégie d'entreprise^[2] venue d'ailleurs. D'abord, l'entreprise a acheté une flotte de 15 fusées provenant de la Russie, des États-Unis et de la Chine. Ensuite, elle a construit 72 satellites sur une chaîne de montage et utilisé les fusées pour les lancer en orbite à 800 kilomètres d'altitude. Là-haut ces satellites se sont comportés comme des relais de téléphonie mobile capables de fournir une couverture téléphonique à n'importe quel endroit sur la planète. Sept ans après sa fondation, ses satellites et ses stations au sol étaient en place. Ce fut un tour de force technique.


Réseau de satellites de Iridium

Mais en 1998, neuf mois après que le premier appel téléphonique ait été effectué, Iridium se plaçait sous la protection du chapitre 11 de la loi sur les faillites^[3]. Ce fut l'un des plus retentissants échecs de création d'entreprise enregistrés jusqu'alors. Qu'est-ce qui a mal tourné ?

Nous pensons avoir identifié un problème sérieux

Lorsqu'initialement Iridium fut conçu au sein de Motorola en 1987, la couverture téléphonique mobile était très éparse, les appels n'étaient pas fiables et les coûts à la minute étaient rédhibitoires. Les téléphones mobiles étaient de la taille d'un panier repas et coûtaient des milliers de dollars.


Motorola Dynatac 8000x ~1987

Quand elle essaima en tant que société distincte en 1990, la stratégie d'entreprise de Iridium se basait sur certaines hypothèses concernant les clients potentiels, leurs problématiques et les produits nécessaires pour les résoudre. Toutes ces hypothèses étaient fondées sur le contexte de l'industrie du téléphone mobile en 1990. Iridium a également fait d'autres hypothèses sur les différents types de canaux de ventes, les partenariats et le modèle de revenus dont elle aurait besoin. Elle a ensuite modélisé tout ça dans un ensemble de prévisions financières avec une "taille de marché" estimée à 42 millions d'ici 2002 par divers cabinets de conseil marketing. Lorsqu'elle a lancé ses satellites dans l'espace, Iridium a vraiment cru qu'elle faisait tourner une planche à billets.

Une stratégie d'entreprise figée dans le temps

Mais au cours des 11 années qu'il a fallu à Iridium pour passer du concept au lancement, l'innovation dans les téléphones et les réseaux mobiles s'est développée à une vitesse incroyable. Au moment où Iridium s'est lancé, il y avait beaucoup d'endroits sur la planète où les services de téléphonie mobile étaient indisponibles. Aujourd'hui, les entreprises traditionnelles en téléphonie mobile assurent une couverture dans les parties les plus importantes du monde. Les prix pour les services locaux et internationaux en téléphonie mobile ont baissé de façon spectaculaire. La taille d'un combiné de téléphone mobile a rétréci et peut maintenant tenir dans votre poche.

En revanche, lorsque le service Iridium devint disponible, son téléphone satellite était plus gros qu'une brique et faisait à peu près le même poids.


iridium-9500 satellite phone ~1999

Pire, on ne pouvait pas téléphoner avec le mobile de Iridium à partir des voitures, des bureaux ou des autres bâtiments, les téléphones devaient en fait être utilisés à l'extérieur pour une connexion directe avec les satellites. Quant au prix, c'était la goutte qui faisait déborder le vase. Au lieu des 50 centimes par minute d'un téléphone mobile normal, les appels par Iridium coûtait 7$ la minute, sachant que les utilisateurs devaient en plus payer 3000$ pour le combiné.

Au cours des onze années qui se sont écoulées depuis, le marché potentiel de Iridium a quasiment diminué chaque jour qui passait. Par contre, les hypothèses du modèle économique^[4] de Iridium, elles, restaient figées comme en 1990. Iridium était mort à l'arrivée alors qu'elle se destinait à être le service de masse de la téléphonie mobile lorsqu'elle s'est lancée.

Aucune stratégie d'entreprise ne survit au premier contact avec un client

Le résultat a été un classique échec de création d'entreprise, au sens large. Iridium s'est entêté à suivre les hypothèses initiales de sa stratégie d'entreprise comme si elle avait passé un point de non retour. Ses erreurs ? Premièrement, en 1990, l'entreprise pensait qu'elle connaissait déjà la problématique de ses clients, et donc qu'elle connaissait déjà la solution à construire.

Deuxièmement, étant donné que Iridium connaissait la solution, elle s'est engagée dans un processus de développement en cascade^[5] pendant 8 ans. Le développement en cascade est une méthode séquentielle de développement d'un produit (cahier des charges, conception, implémentation, vérification, déploiement). Cette méthode est pertinente dans un marché où le problème du client est connu et où tous les besoins du client et les fonctionnalités des produits peuvent être spécifiés à l'avance. Par contre, c'est la mort assurée sur un marché qui évolue rapidement. Le développement en cascade a donc freiné la capacité d'Iridium à écouter, apprendre, tester et s'adapter aux besoins changeants des clients sur un marché en évolution rapide.

Troisièmement, sa stratégie d'entreprise n'incluait pas les notions d'apprentissage et de découverte. L'idée d'itération était impensable. Sa stratégie d'entreprise était donc un document statique. Ce qui était formidable pour lever des fonds, pour communiquer dans les écoles de commerce et les grandes entreprises, mais complètement obsolète lorsqu'il a fallu la confronter aux réalités du marché de la téléphonie mobile en mutation constante. Lorsque la société s'est lancée, elle s'est heurtée à une diminution des clients et des marchés qui ne correspondaient pas à sa stratégie d'entreprise et ses projections financières, sans pour autant avoir la capacité de changer son modèle économique. Un processus de découverte et de validation de la clientèle, mené en parallèle du développement produit, aurait permis de réaliser plus tôt que le marché ne se développait pas en la faveur d'Iridium. Au lieu de ça, la direction d'Iridium était confortablement en train d'exécuter son plan initial.

Tout s'est écroulé d'un coup

Lorsqu'on ajoute à ce qui a été dit précédemment, l'orgueil de l'entreprise d'avoir levé des milliards de dollars, le fait qu'aucun adulte du conseil d'administration de Iridium ou de Motorola n'ait demandé "Est-ce que cela encore un sens ?", on aboutit à ce désastre. Au lieu des 42 millions de clients prévus initialement dans sa stratégie d'entreprise, Iridium a simplement eu un pic de 30 000 abonnés. La société a brûlé ses 5,2 milliards de dollars parce qu'elle est tombée amoureuse de la technologie, qu'elle a succombé au développement en cascade de produits et qu'elle n'a jamais pris la peine de sortir de l'immeuble, de sortir la tête de ses feuilles de calcul et de se demander "Qu'est-ce que veulent les clients aujourd'hui ?".

En 2000, de nouveaux investisseurs ont racheté les satellites Iridium et son réseau pour 25 millions $, soit un demi pour cent du capital investi. Aujourd'hui, la nouvelle entreprise dessert quelques 300 000 clients dans une série de marchés de niche incluant les soldats américains appelant leur foyer à partir de zones de combat, les responsables de plateformes pétrolières et les chasseurs de gros gibiers.

Une politique de développement de la clientèle, de conception du modèle économique et de développement Agile aurait pu complètement changer la donne.

Leçons apprises

- Les stratégies d'entreprise sont la principale cause de la mort prématurée des entreprises nouvellement créées.
- Aucune stratégie d'entreprise ne survit au premier contact avec un client.
- Des marchés en mutation constante requièrent le développement itératif d'un modèle économique continue en fonction du client.
- Votre capacité à lever des fonds n'a aucun lien avec l'adoption de votre produit par les clients.

Feedback :

• Je remercie Ronan Amicel pour sa relecture de l'article traduit et ses propositions.
  

Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

J'ai traduit ce billet de David Joyce : "Deming’s 14 Points". Je trouve incroyable que Deming ait réussi à observer, expérimenter et théoriser tant de choses... et que nos qualiticiens ne nous parlent que de la roue PDCA ! Chacun de ses 14 points tape juste et fait (très très) mal... en fait on n'a pas progressé d'un iota, c'est navrant.

Les 14 points de W. Edwards Deming sont les fondements de la transformation de l'industrie. L'adoption et la mise en œuvre des 14 points constituent un message fort comme quoi le management a bien l'intention de poursuivre les activités de l'entreprise, de protéger les investisseurs et les emplois. Un tel système fut à la base des leçons données au top management japonais à partir de 1950.

Les 14 points s'appliquent partout, pour de petites organisations aussi bien que pour des grandes, aux services aussi bien qu'à l'industrie. Ils s'appliquent aussi bien à toute entité au sein d'une entreprise qu'à ses fournisseurs.

Pendant que vous lirez ces 14 points, demandez-vous s'ils s'appliquent encore aujourd'hui, soit au sein de votre organisation actuelle, soit au sein des organisations dans lesquelles vous avez récemment travaillé. Les réponses pourraient être surprenantes.

1. Des objectifs stables

Créez une stabilité dans les objectifs d'amélioration continue de vos produits et services, avec un plan pour devenir compétitif et pour poursuivre les activités de l'entreprise.

Le management a deux préoccupations. L'une traite de diriger l'entreprise au jour le jour. L'autre porte sur l'avenir de l'entreprise.

Le management doit avoir les idées claires sur ces questions ; que faisons-nous et pourquoi le faisons-nous ?

La réponse à ces questions nécessite d'avoir certaines connaissances et de regarder vers l'avenir. C'est la différence entre la vision à court terme et la vision à long terme ; la tortue et le lièvre.

La capacité à traiter les problèmes futurs exige d'avoir des objectifs stables et la véritable volonté de s'améliorer.

Créez une stabilité dans les objectifs d'amélioration continue de vos produits et services, allouez des ressources pour répondre aux besoins à long terme plutôt qu'uniquement à une rentabilité court terme, avec pour objectif de devenir compétitif, poursuivre les activités de l'entreprise et offrir des emplois.

Poursuivre les activités de l'entreprise exige que les leaders passent du temps sur l'innovation, la recherche et la formation. Ils doivent constamment améliorer la conception de leurs produits et services.

L'objectif est une intention, un but, une vision d'une situation future souhaitée. Pour avoir un objectif stable, on doit d'abord avoir un objectif.

2. Une nouvelle philosophie

Nous sommes entrés dans une nouvelle ère économique, créée au Japon. Le management doit se réveiller devant ce défi, doit apprendre ses nouvelles responsabilités et prendre le leadership du changement.

L'amélioration ne s'arrête jamais. Le système est capricieux, imprévisible, il aura des impacts différents sur les individus d'un mois sur l'autre. C'est pourquoi vous avez besoin d'amélioration continue, cela ne peut jamais finir puisque le changement ne finit jamais.

Les demandes et les goûts des clients changent très vite, et la concurrence sur le marché croît à un rythme rapide aujourd'hui.

Henry Ward Beecher a déclaré : "La philosophie d'un siècle est le sens commun du suivant." ; nous devons accepter de nouvelles philosophies selon les tendances du marché et les révolutions technologiques.

Apprendre et adopter une toute nouvelle philosophie, celle de la coopération au bénéfice de tous.

Le management doit se réveiller devant ce défi, il doit apprendre ses nouvelles responsabilités et prendre le leadership du changement.

Nous sommes dans une nouvelle ère économique, créée au Japon. Nous ne pouvons plus vivre avec des niveaux de retard, d'erreurs, de matériels défectueux et de fabrication défectueuse communément admis. Aujourd'hui, nous ne pouvons plus accepter les niveaux d'erreur qui étaient encore tolérés hier. Les produits et les services défectueux représentent un coût pour le système.

Seul le management est en mesure de faire quelque chose pour la grande majorité des erreurs. La transformation du style de management occidental est nécessaire pour enrayer le déclin continu de l'activité et de l'industrie.

Cela fait partie des tâches du management d'éliminer les obstacles qui empêchent les personnes de faire leur travail correctement.

3. Arrêtez d'être dépendant aux contrôles de masse

Éliminez la dépendance aux contrôles pour atteindre la qualité. Éliminez le besoin de contrôle de masse en construisant la qualité intrinsèque au produit d'abord.

Vous ne pouvez pas économiser de l'argent si vous êtes plus préoccupé par l'argent que vous ne l'êtes par la qualité.

Arrêtez d'être dépendant aux contrôles de masse pour atteindre la qualité. Les contrôles de masse ne sont pas fiables. Le contrôle rassure, mais c'est faux.

Vous ne pouvez pas contrôler la qualité, et pourtant nous avons des organisations utilisant l'ISO et les audits comme un moyen de prouver la qualité.

Les contrôles de routine reviennent à la même chose que planifier les défauts, reconnaître que le processus n'est pas correct ou que les spécifications n'ont pas de sens. Le contrôle a lieu trop tard, est trop inefficace et coûteux.

Demandez plutôt des preuves statistiques que la qualité intrinsèque existe.

La qualité ne provient pas des contrôles, mais de l'amélioration du processus. Améliorez le processus de sorte que les défauts ne soient pas générés dès le départ. Ceci élimine le besoin des contrôles de masse.

Éliminez la nécessité de recourir à des contrôles de masse, puisque votre démarche pour atteindre la qualité passe par la construction de la qualité intrinsèque au produit d'abord. Exigez la preuve statistique de l'amélioration de la qualité.

Vous ne pouvez pas économiser de l'argent si vous êtes plus préoccupé par l'argent que vous ne l'êtes par la qualité.

4. Mettez fin à la politique d'achat au plus bas prix

Mettez fin aux pratiques d'attribution des contrats sur la seule base de l'étiquette du prix. Cherchez plutôt à minimiser le coût total. Privilégiez un fournisseur unique pour chacun des articles et une relation à long terme basée sur la loyauté et la confiance.

Sans mesures adéquates de la qualité, les entreprises se dirigent vers le soumissionnaire offrant le prix le plus bas, par conséquent, le résultat est de faible qualité et de coût élevé.

Le prix n'a aucun sens sans mesure de la qualité achetée.

Mettez fin aux pratiques d'attribution des contrats sur la seule base de l'étiquette du prix. Exigez plutôt des mesures significatives de la qualité par rapport au prix.

Réduisez le nombre de fournisseurs pour le même article, en éliminant ceux qui sortent des statistiques ou autres preuves de qualité.

L'objectif pour les deux parties est de travailler ensemble en minimisant les variations de qualité pour l'augmenter, de minimiser le coût total (et non simplement les coûts initiaux) pour les deux parties.

Ceci peut être atteint en sélectionnant un fournisseur unique pour chacun des articles, sur la base d'une relation à long terme basée sur la loyauté et la confiance.

Cela conduira à une amélioration continue entre les deux parties et, par conséquent, vous obtiendrez des fournitures de qualité à coûts réduits. C'est pourquoi les constructeurs japonais sont si étroitement liés à leurs fournisseurs.

Nous dépensons souvent beaucoup de temps et d'argent pour trouver de meilleurs fournisseurs et passer rapidement de l'un à l'autre pour finalement opérer de légers gains financiers. Au lieu de demander que les fournisseurs se concurrencent uniquement sur le prix, pensez sur le long terme. Les directeurs des achats ont un nouvel emploi et ils doivent l'apprendre.

Aujourd'hui, de nombreux organismes se contentent simplement d'externaliser vers le fournisseur le moins cher, et multiplient souvent le nombre de fournisseurs au sein de la même entité métier ou projet.

5. Améliorez chaque processus

Améliorez constamment et perpétuellement le système de production et les services, pour améliorer la qualité et la productivité, diminuant ainsi les coûts.

Améliorez constamment et perpétuellement le système de production et les services pour améliorer la qualité et la productivité, diminuant ainsi les coûts.

Acceptez que rien ne soit jamais assez bon. Améliorez sans cesse tous les processus de planification, de production et de service.

L'amélioration n'est pas un projet avec une date de fin. Pensez plutôt amélioration continue et perpétuelle.

Instaurez l'innovation.
Chacun doit chercher continuellement des problèmes afin d'améliorer toutes les activités de l'entreprise, d'améliorer la qualité et la productivité et donc de constamment diminuer les coûts.

Trouver ce qui cloche n'est pas une amélioration. Boucher des fuites n'est pas une amélioration. Ne regardez pas les résultats ou les défauts, regardez plutôt ce que produisent les défauts.

Il devrait y avoir une formation permanente sur les gaspillages et une amélioration continue de la qualité dans chaque activité, cela augmenterait de façon continue la productivité.

Il incombe au management de travailler en permanence sur le système (par exemple la conception du travail, le travail à planifier, l'amélioration des outils, la supervision, la formation continue). Il n'y a aucun point d'arrêt dans le processus de gestion de la qualité.

Le système de l'entreprise et les services doivent continuer à croître indéfiniment, afin de rattraper le marché concurrentiel.

6. Instaurez la formation sur le lieu du travail

Instaurez des méthodes modernes de formation sur le lieu du travail.

Fournissez apprentissage et développement aux personnes. Instaurez la formation sur le lieu de travail, la formation pour développer de nouvelles compétences.

Les gens apprennent de différentes manières. Le processus de formation doit être totalement reconstruit.

Lorsqu'ils se forment, les gens doivent comprendre en quoi consiste leur travail et pourquoi il faut le faire.

La formation doit être faite sur le lieu de travail, c'est-à-dire l'apprentissage par la pratique ; rentrez dans les problématiques du travail, expérimentez des méthodes de travail et de nouvelles idées, étudiez les résultats et visez la perfection.

Un employé formé génère plus de productivité et de qualité qu'un employé non formé, donc tenir des sessions de formation améliorera considérablement la qualité de la personne et contribue aussi directement à une meilleure performance à l'égard de la qualité du produit.

Instaurez des méthodes modernes de formation sur le lieu de travail pour tous, y compris pour le management, pour faire un meilleur usage de chaque employé.

De nouvelles compétences sont nécessaires pour s'adapter aux changements d'outils, de méthodes, de techniques, de conception des produits et des services.

7. Instaurez le leadership des personnes

L'objectif du management devrait être d'aider les individus à faire un meilleur travail. Le management a besoin d'être rénové.

Le leadership est requis, pas le contrôle.

Le leadership a besoin d'être rénové, le travail des managers est d'aider les individus.

Adoptez et instaurez le leadership vise à aider les individus à faire un meilleur travail.

Adoptez et instaurez des principes pour l'amélioration du leadership.

Le management ne doit plus être fondé sur la culture absolue des chiffres mais sur la qualité. L'amélioration de la qualité provoquera automatiquement l'amélioration de la productivité.

Le management doit s'assurer que l'analyse et les mesures sont prises sur la base des rapports d'anomalies, des conditions du système, des mauvais outils, de procédures opérationnelles floues, des changements et de toutes conditions nuisibles à la qualité. Vous ne pouvez pas déléguer la qualité, c'est une route qui mène à l'échec assuré.

Le principe de base est que c'est le travail des managers de coacher leur personnel et d'améliorer le système :

- Premièrement, ils doivent passer du temps au travail à renforcer l'engagement de l'organisation envers ses clients et la qualité.
- Deuxièmement, ils consacrent du temps à s'assurer que le personnel qui effectue le travail a tout ce qu'il faut pour être en mesure de servir le client.
- Troisièmement, quand ils ont une décision à prendre au sujet de ce qui précède, ils cherchent à obtenir plus d'informations pour fonder leurs décisions. Il n'y a pas de réflexe automatique, ils apprennent plutôt à acquérir la connaissance.

8. Chassez la peur

Chassez la peur afin que chacun puisse travailler efficacement pour l'entreprise.

Faites disparaître les craintes afin que tout le monde puisse travailler efficacement pour l'organisation.

Construire la confiance. La coopération et la collaboration exigent des valeurs et des relations différentes de celles utilisées dans la méthode obsolète qu'est le contrôle-commande.

Les personnes ont peur du changement, toute tentative pour améliorer les choses conduira à une peur de l'inconnu.

De nombreuses organisations sont dirigées par la peur ; la peur de ne pas obtenir sa prime, la peur de ne pas pouvoir réussir son évaluation annuelle ou d'être en dessous des échelles de notation annuelle.

Pour atteindre une meilleure qualité, les individus ont besoin de se sentir en sécurité. Nous devons éliminer la peur afin que chacun puisse travailler efficacement pour l'entreprise. La peur va disparaître au fur et à mesure que le management s'améliore et que les employés développent une confiance dans le management.

Maîtriser notre peur fait partie d'au moins 8 des 14 points.

9. Brisez les barrières

Brisez les barrières entre les départements. Les gens travaillant dans les services de recherche, de conception, de vente, de technologie et de production doivent travailler en équipe.

Brisez les barrières et les silos entre les départements. En d'autres termes construisez un système.

Traditionnellement, les silos deviennent des royaumes indépendants, chacun essayant de maximiser ses propres chiffres.

Les gens travaillant dans les services de recherche, de conception, de vente, de technologie et de production doivent travailler en équipe pour être capable de prévoir tous les problèmes liés à la production, aux produits ou aux services.

A moins que le personnel se mette à travailler ensemble dans un esprit de coopération, chaque domaine va essayer de faire ce qui est le meilleur pour lui-même, plutôt que ce qui est bon pour l'organisation. Coopération et non compétition : tout le monde gagne si le système gagne.

10. Éliminez les slogans

Éliminez l'utilisation de slogans exhortant les employés à atteindre le zéro défaut et de nouveaux niveaux de productivité.

- Éliminez les quotas au travail. Remplacez par le leadership.
- Éliminez le management par les objectifs. Remplacez par le leadership.
- Éliminez le management par les chiffres, les objectifs chiffrés. Remplacez par le leadership.

Éliminez les slogans, les avertissements et les objectifs exhortant les employés à faire bien du premier coup, à atteindre le zéro défaut et de nouveaux niveaux de productivité. Une telle pression ne peut uniquement générer que des réactions d'hostilité.

Des posters affichent ce que les gens ne peuvent pas faire.

Des posters et des slogans sur les murs indiquent "Faites bien du premier coup" ; qui peut faire bien du premier coup, lorsque le sujet sur lequel doit travailler la personne est déjà mauvais ?

Les causes vont au-delà du pouvoir des employés, puisque la majorité des causes de faible qualité et de faible productivité sont générés par le système.

Si le système a été construit autour de la qualité, alors il fera bon du premier coup, de sorte que le slogan sera dénué de sens.

Assurez-vous de remplacer les quotas de travail par un leadership efficace et des méthodes efficaces. Remplacez le management (par objectifs, chiffres et objectifs chiffrés) par un leadership efficace.

11. Éliminez les objectifs chiffrés fixés arbitrairement

Éliminez les normes de travail qui prescrivent des quotas aux employés et des objectifs chiffrés pour le management. Les responsabilités du management doivent évoluées d'une culture unique des nombres à celle de la qualité.

Les objectifs chiffrés n'accomplissent rien.

Traditionnellement, on a plus de règles sur la quantité que la qualité.

Les coûts que vous générez en accordant plus d'attention aux nombres qu'à la qualité sont énormes, il en résulte des coûts élevés à rechercher et résoudre les erreurs. Cet argent dépensé ne produit rien.

Concentrez-vous sur la qualité plutôt que sur la quantité de produit. Supprimez les obstacles privant les employés de leur droit d'être fiers de leur travail. Les managers doivent se concentrer sur la qualité, plutôt qu'absolument sur des chiffres.

Remplacez tout par un leadership utile qui permette d'atteindre l'amélioration continue de la qualité et de la productivité.

Un système d'amélioration continue génère une production de meilleure qualité à moindres coûts. L'accent est mis non pas sur la quantité mais sur la façon dont vous réussissez à bien faire.

12. Autorisez la fierté au travail

Supprimez les obstacles qui privent les employés et les managers de leur droit d'être fier de leur travail. Cela signifie, par exemple, l'abolition de la note annuelle au mérite et du management par objectif.

Supprimez les obstacles et les barrières qui privent les employés et les managers de leur droit d'être fiers et d'avoir du plaisir dans leur travail. Cela implique l'abolition de la notation annuelle au mérite (évaluation de la performance) et du management par objectif, à l'origine des conflits et de la compétition.

Ces barrières à la fierté (un besoin humain fondamental) génèrent entre autres un moral bas et de l'absentéisme.

Nous avons besoin de gens qui soient fiers de leur travail et non pas qui soient capables de bien se classer.

Encore une fois, les responsabilités des chefs d'équipe, managers, directeurs et dirigeants doivent passer d'une culture absolue du nombre à celle de la qualité.

Pourquoi fixer des objectifs aux employés et chercher à les classer dans l'entreprise, insuffler un esprit de compétition au sein de cette organisation. Nous voulons de la collaboration et non de la compétition.

Impliquez les employés, à tous les niveaux, dans le processus d'amélioration. Fournissez aux employés les méthodes, le matériel et outils appropriés. Les managers travaillent sur le système qui fait obstacle à la performance.

13. Encouragez la formation

Instaurez un programme énergique de formation et d'auto-amélioration.

Instaurez un programme énergique de formation et encouragez l'amélioration pour chacun.

Une organisation n'a pas juste besoin de gens qui soient bons ; elle a besoin de personnes qui s'améliorent par la formation.

La formation ne doit pas être un sujet relié à leur travail.

L'auto-amélioration maintient en éveil l'esprit des gens. Le point 6 concerne la formation au travail, le point 13 fait progresser l'esprit des gens.

Les progrès dans votre positionnement concurrentiel ont leurs racines dans la connaissance. Aucune organisation ne peut survivre juste avec des gens bons, elle a besoin de gens qui s'améliorent.

14. Engagement du top management et mise en action

Engagez tout le monde dans le travail de transformation de l'entreprise. La transformation est l'affaire de tous.

Engagez tout le monde dans l'entreprise pour accomplir le changement.

Développez une masse critique qui puisse provoquer le changement ; une masse critique incluant le top management.

Créez une structure de management qui prendra une part active et consacrera du temps au renforcement des 14 points et sur l'engagement de l'organisation envers ses clients et la qualité.

Les managers doivent consacrer du temps à s'assurer que les employés disposeront de tout ce qu'il faut pour être en mesure de servir le client. Ils utilisent des données et des connaissances réelles obtenues du point de vue du client pour prendre des décisions.

Sans une telle structure, vous n'obtiendrez aucun bénéfice viable sur le long terme.

Résumé

Les 14 points ne sont pas un supermarché dans lequel vous faites vos courses. Deming prévoyait que vous utilisiez les 14. Ils constituent une véritable philosophie.

"Le moyen de ne pas dépendre du contrôle de masse (point 3) est d'améliorer continuellement le processus (point 5), pour ce faire vous aurez besoin de fournitures de qualité (point 4), trouver un fournisseur de qualité prendra du temps (point 1), vous aurez donc besoin d'adopter la philosophie (point 2)." Lloyd Dobbins

"Nous voulons que les gens travaillent ensemble, mais il est difficile de le faire sans les points 8, 9, 10, 11 et 12. Lloyd Dobbins

Les 14 points s'appliquent partout, des petites organisations aux grandes, des services à l'industrie. Ils s'appliquent également à toute entité au sein d'une entreprise.

"Les 14 points ont tous un seul but : permettre aux gens de travailler avec joie et fierté." Deming

Source : CC-M Productions, Inc. 7755 16th Street, NW Washington, DC 20012 ManagementWisdom.com (800) 453-6280wbob@cc-m.com

Source : Vanguard http://www.systemsthinking.co.uk/home.asp

Source : Vanguard Scotland http://www.systemsthinkingmethod.com/

Source : Illustrations par Pat Oliphant http://www.managementwisdom.com/freilofdem14.html

Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

J'ai traduit ce quatrième billet de Eli Weinstock-Herman : Applying Kanban to IT Processes (Part 4).

Cet article est le quatrième d'un ensemble d'articles qui décrit les bases de Kanban et son application dans les processus informatiques :
- La première partie donnait un aperçu de Kanban et la façon dont il est utilisé dans l'industrie.
- La deuxième partie donnait un aperçu de Kanban et la façon de l'utiliser dans un service helpdesk (fictif).
- La troisième partie donnait un aperçu de Kanban et la façon de l'utiliser dans un projet de déploiement de PC (fictif).
Les articles qui suivent explorent différents scénarios pour vous aider à trouver des idées s'appliquant à votre propre contexte.

Dans la quatrième partie de cette série "Appliquer Kanban aux processus informatiques", nous allons suivre une équipe de développement logiciel. Ils appliquent actuellement un processus qui a été baptisé le modèle sashimi, un modèle en cascade modifié avec recouvrement des phases : exigences, conception, développement et tests. Cet exemple se concentre sur l'utilisation de Kanban pour améliorer et affiner un processus actuellement utilisé plutôt que d'exécuter un processus de conversion complet.

Bienvenue à la société GHI

GHI est une petite société de développement qui se spécialise dans la construction et l'intégration de systèmes d'inventaire et de valorisation des stocks dans le B2B et le B2C. Un des défis qu'ils ont choisi de relever est le suivi et le reporting d'activités. Étant donné que leurs produits nécessitent de grands développements côté logique métier et administration et très peu côté interface utilisateur, le client ne peut pas voir la façon dont le produit évolue. Améliorer les mécanismes de suivi et de reporting fournira au client de plus amples informations sur la façon dont le projet progresse, augmentant ainsi leur niveau de confiance à la fois dans la solution et dans la société. Cette dernière estime que l'amélioration de cette confiance n'affectera pas seulement la relation avec ce client, mais améliorera également son image sur le marché et avec d'autres clients potentiels.

État courant

Le processus actuel de l'équipe commence par le recueil des exigences de haut niveau et la construction de l'architecture générale, sans aborder aucune des règles métier. Une fois le squelette développé, l'équipe se concentre sur le fait de mener de façon itérative le recueil des exigences et la construction des plus petits modules nécessaires pour ajouter la chair au squelette. La conception globale du système suit une approche N-tier, avec des couches définies pour l'accès aux données, la logique métier, la séparation des processus de transaction et de traduction pour chaque système externe et une interface utilisateur limitée. Cette démarche itérative permet de découvrir plus avant la logique métier et les exigences pendant le développement. Cette approche modulaire permet également de développer en pilotant par les tests des parties du système sans disposer des vrais systèmes tiers donc sans exiger que la solution soit complète. Ce pilotage par les tests permet également au personnel technique du client et aux analystes métier d être impliqués et de relever d'éventuelles contradictions au plus tôt.

On a demandé à l'équipe de fournir une meilleure visibilité et des indicateurs clairs qui puissent être partagés avec le client. Bien que de nombreux membres de l'équipe sont intéressés pour essayer des méthodes Agile, comme Scrum ou XP, l'équipe décide qu'appliquer Kanban à leur processus initial constituera un faible changement du point de vue du client. Une fois que l'équipe disposera d'une meilleure visibilité et de meilleurs indicateurs, elle a bien l'intention de réévaluer le potentiel d'utilisation de Scrum ou de tout autre méthode Agile, mais elle perçoit qu'un changement progressif sera acceptable pour les clients là où un changement de processus complet ne le sera pas.

Dans le cadre de ses efforts continus, l'équipe est également à la recherche d'un moyen d'améliorer sa vitesse de livraison. La plupart des membres de l'équipe approuvent le fait qu'un développeur supplémentaire permettrait d'accélérer leur processus de livraison d'au moins 15%, mais ils ne seront pas en mesure de défendre le recrutement d'effectifs supplémentaires sans disposer d'indicateurs convaincants permettant de légitimer leurs demandes.

Définir le processus

Suite à plusieurs longues réunions, l'équipe a élaboré son processus comme une série d'étapes clairement définies qui suivent des cycles, en se concentrant de manière itérative sur de plus petits morceaux.


Processus en cascade itératif (Sashimi)

Bien que le processus suivi soit presque fractal dans son exécution, chaque passe détaillée de plus en plus finement suit une série d'étapes :

Reste à faire : travaux non encore bien déterminés qui doivent être conçus et développés
Exigences : recueil d'exigences métier ou système tiers pour une tâche ou un module
Conception : application des standards de conception, de modélisation et d'exigences externes pour concevoir la tâche ou le module
Développement : développement selon la conception et les exigences
Test : test des développements terminés pour détecter les défauts* et valider l'alignement aux exigences
Revue client et acceptation : groupes de revue des tâches avec le personnel technique, les analystes métier ou les services tiers

L'équipe compte actuellement un chef de projet, cinq développeurs et une personne pour la QA. Une fois défini son processus, l'équipe a décidé que l'un des développeurs serait en charge de l'architecture (exigences et conception), le chef de projet sera responsable des étapes client et de la priorisation du reste à faire (avec l'aide de l'architecte), le reste des développeurs et la personne QA prendront en charge le développement et les tests. L'architecte sera également responsable d'une partie du développement si l'équipe prend de l'avance sur les exigences et la conception.

*Les défauts sont des imperfections du produit qui apparaissent en situation de production ou d'exploitation normale. Des exemples de défauts dans l'ingénierie logicielle sont du code mal saisi, un référencement incorrect des variables et d'autres erreurs techniques. Les problèmes au niveau des exigences sont par exemple des options manquantes dans les filtres de recherche, une mise en page incorrecte d'un formulaire et d'autres éléments directement liés au client.
Exemple : le client n'exigera jamais explicitement que la fonction de validation ne bloque pas le serveur, donc une erreur dans une fonction de validation qui bloque le serveur est classée dans la catégorie défaut.

Tableau visuel 1

A des fins de visualisation et de suivi, l'équipe découpe plusieurs étapes en sous-étapes. Les étapes d'exigences et de conception ont été définies comme une série de trois sous-étapes, la dernière étape étant une étape "prêt" qui indique que les tâches peuvent être sélectionnées et commencées par les développeurs. Le développement a été découpé en deux sous-étapes, une étape "en cours" et une étape "terminé". Les éléments de la sous-étape "terminé"" sont mis à disposition pour être sélectionnés et testés par la QA.


Le premier tableau visuel

L'équipe utilise un grand tableau blanc magnétique pour son tableau Kanban. Au lieu d'utiliser des couloirs pour visualiser les travaux en cours, l'équipe a créé des emplacements spécifiques sur le tableau pour les tâches et pour la photo de chaque membre de l'équipe. Par exemple, lorsque l'architecte de l'équipe recueille les exigences pour une tâche, il place sa photo dans la colonne exigences avec la tâche sur laquelle il travaille actuellement. Le chef de projet a donné une série de timbres d'animaux colorés aux membres de l'équipe pour estampiller les tâches qu'ils terminent, permettant au reste de l'équipe de suivre facilement qui a travaillé sur une tâche donnée. Cela permet à la personne de la QA ou à un développeur qui prend la suite de communiquer facilement avec le développeur d'origine sans faire appel à des mécanismes complexes de traçabilité.


Limites Kanban

Les limites Kanban ont été définies en fonction du nombre de personnes affectées à chaque étape et de quelques approximations sur la quantité de travail attendue à chaque étape sans que les étapes avales du processus manquent de travail. Les étapes d'exigences et de conception sont limitées à trois tâches pour trouver un équilibre entre conserver des informations fraîches sur les exigences et fournir suffisamment de travail pour l'étape de développement. La étapes de développement possèdent une limite de cinq tâches pour permettre à l'architecte d'avancer et de développer de petites tâches lorsque la limite est atteinte pour les exigences et la conception. L'étape de QA est limitée à une seule tâche, tirée à partir des tâches de développement terminées. Cela permet à la personne QA de terminer une série de tests sans être perturbée par de nouveaux développements déployés en cours de tests. La file d'attente des éléments en attente de la revue clients n'est pas limitée car le chef de projet a déjà des réunions hebdomadaires avec le client pour discuter des tâches terminées. La file d'attente permet au chef de projet de sélectionner des ensembles de tâches terminées et d'en discuter avec les participants, ou d'envoyer des rappels assez tôt pour s'assurer que les bons participants seront présents à la réunion.

Exécuter le nouveau processus

Initialement, le processus est un peu brut puisque l'équipe tente de terminer les tâches qui dépassent les limites à travers le flux. L'architecte commence à s'acclimater à un rôle qui exige de consacrer plus de temps avec des tableaux blancs et moins avec un éditeur de code. Le chef de projet commence à opérer la transition de la gestion des flux de tâches dans le processus vers la gestion des priorités et l'amélioration des communications avec le client.

Après quelques semaines, le processus est plus fluide. Le chef de projet priorise les tâches dans la file d'attente, parfois en impliquant l'architecte pour s'assurer que les exigences de conception sont prises en compte. L'architecte sélectionne les tâches prioritaires en haut de la pile, recueille des exigences plus détaillées de la part du client, et construit une conception globale qui intègre les exigences et les aligne avec la conception de haut niveau. Lorsque les étapes d'exigences et de conception atteignent la limite Kanban, l'architecte passe à l'étape de développement et soit aide les développeurs soit sélectionne une petite tâche de développement qu'il finira lui-même. Les développeurs sélectionnent des tâches de l'étape d'architecture et les implémentent. Après avoir terminé une tâche, ils la déplacent dans la sous-étape "fini" et soit aident l'un des autres développeurs soit sélectionnent une nouvelle tâche. Lorsque l'étape de développement atteint sa limite Kanban, les développeurs sans tâches attribuées se déplacent en amont du processus pour aider la personne QA à tester afin de supprimer les obstacles. La personne QA teste chaque tâche, à la recherche d'anomalies ainsi que pour vérifier l'alignement avec les exigences clients et la conception interne.


Les tâches de QA retournent au développement ou passent à la suite

Après avoir testé une tâche, la personne QA soit la renvoie dans la colonne de développement pour être corrigée soit la déplace dans la file d'attente. Renvoyer une tâche aux développeurs causera souvent l'atteinte ou le dépassement de la limite Kanban pour le développement. Le développeur qui prend la suite et qui atteint ce point d'arrêt, soit aide à continuer les tests soit sélectionne la tâche renvoyée pour corriger les problèmes en suspens.

Première révision

Dans le cadre de la définition du processus initial, l'équipe a convenu d'examiner et de réviser son processus régulièrement. Pendant les premières semaines, le chef de projet a recueilli des statistiques de haut niveau pour mesurer le débit du processus et fournir des informations pour la réévaluation du processus. L'information détaillée comprend des statistiques sur la fréquence des tâches renvoyées par l'étape de test, le nombre de fois où l'architecte ou les développeurs sont amenés à se déplacer en aval du processus pour aider à débloquer les obstacles, et une estimation générale de la façon dont le client réagit lors chaque réunion hebdomadaire.

Évaluation

Il y avait un certain nombre de tâches partiellement terminées lorsque l'équipe a commencé et ils attendaient l'étape de QA pour se stabiliser. Malheureusement, cela n'a pas eu lieu, et afin de maintenir un flux régulier de tâches, les développeurs sont souvent aller en aval du processus pour aider la personne de la QA à traiter son backlog. Les quelquefois où les développeurs ont eu des journées exceptionnelles, la QA a presque immédiatement bloquée, nécessitant plusieurs développeurs pour aider à traiter le backlog.

Le rôle d'architecte requiert moins de temps que prévu, conduisant l'architecte à développer environ 50% de son temps. Cela exige, pour quasiment chaque tâche réalisée par l'architecte, un débogage et une correction par l'un des développeurs et réduit encore un peu plus l'efficacité du processus en forçant quelqu'un, peu familier avec les exigences et le code de la tâche concernée, de dépanner rapidement et d'apporter les corrections.

Changements de processus

Initialement l'équipe croit que la plus grande limitation pour accomplir des tâches est la main-d'œuvre et qu'augmenter le nombre de développeurs conduirait à une augmentation directe du nombre de tâches qu'ils réalisent chaque semaine. Toutefois, après avoir travaillé pour obtenir un processus plus raffiné et mesurable, ils ont constaté que l'ajout de développeurs offrirait peu ou pas d'avantages parce que la contrainte actuelle sur leur processus est le goulot d'étranglement sur la QA. S'ils augmentent le débit de cette étape, alors le processus entier sera beaucoup plus fluide et générera un débit plus élevé, puisque la QA sera en mesure de tirer des tâches de la zone de développement plus rapidement.

L'équipe a pris en compte plusieurs idées pour accroître la main-d'œuvre à l'étape de test, y compris l'embauche d'une personne supplémentaire pour la QA et même utiliser l'architecte à temps partiel sur la QA au lieu de le faire développer. Après avoir discuté de plusieurs options, un membre de l'équipe a suggéré d'utiliser l'architecte et tout développeur disponible pour construire des tests automatisés. La théorie est que l'automatisation de certains des tests ne réduira pas seulement la quantité de travail pour la personne QA, mais réduira aussi le nombre de tâches qui sont renvoyées par la QA au développement pour débogage et correction. L'équipe a décidé d'essayer cette idée parce qu'elle ne nécessite pas de dépenses supplémentaires et qu'il y a peu d'impact négatif d'avoir l'architecte travaillant sur les tests unitaires au lieu d'aider à terminer les travaux de développement en respectant la limite Kanban.


Tableau Kanban révisé avec des étapes supplémentaires

Le tableau Kanban a été modifié pour inclure une sous-étape de création de tests en plus des exigences et de la conception. L'architecte est responsable de la construction d'un certain nombre de cas de test pour chaque tâche à définir. Lorsque les limites de la zone exigences sont atteintes, l'architecte travaille sur la construction. Cela garantit que les tâches en cours ont des tests automatisés et qu'au fur et à mesure que le temps passe, la couverture augmente pour tester l'intégration des modules et tout risque d'effets de bord ou de lacunes lors de l'intégration des modules conçus ensemble.

La limite pour l'étape de développement sur le tableau est augmentée et une petite zone est créée pour les tâches renvoyées par la QA. Ces tâches sont traitées avec une priorité plus élevée que les tâches de la zone d'exigences pour s'assurer que la plupart des tâches seront corrigées et terminées avant que tout nouveau travail démarre. Pour aider à augmenter l'efficacité des développeurs à corriger ou déboguer le code écrit par d'autres, une nouvelle revue de code est mise en place. Chaque fois qu'une tâche est terminée, le développeur revoit le code avec un ou plusieurs des autres développeurs pour s'assurer qu'il est simple, commenté où il faut et qu'il suit les standards existants. Ce processus est relativement rapide et réduit les coûts et le temps supplémentaire consommé lorsque quelqu'un d'autre dépanne les tâches réalisées initialement par quelqu'un d'autre.

Analyse finale

Bien que l'équipe continue à réévaluer et réviser son processus selon une fréquence de quelques semaines, elle a déjà réalisé un certain nombre d'améliorations par rapport à son processus original et à la première version des limites de Kanban.

Flux de processus

L'équipe n'a pas révisé ses priorités, exigences ou processus de conception, de sorte que ces étapes continuent à travailler de la même manière qu'avant l'application des limites Kanban. Le nouveau processus de création de tests unitaires pour les tâches a été lent pendant la première semaine, mais comme l'architecte a acquis une expérience avec le framework de tests, le processus de construction de tests est devenu plus fluide et a commencé à donner du temps pour construire des tests sur les modules déjà terminés. Au fur et à mesure que les développeurs terminent leurs tâches, ils regardent en premier la file d'attente des "corrections" provenant de la QA pour voir si des tâches sont en attente d'être déboguées ou corrigées. Cela met donc la priorité sur les tâches précédemment commencées et assure que les nouvelles tâches ne sont démarrées que lorsque la zone à corriger est vide. Le nouveau framework de tests unitaires a donné aux développeurs un moyen rapide de tester leur travail avant de déclarer qu'il est terminé et leur a également fourni des informations d'une toute autre dimension sur les exigences métier et de conception. Les tests unitaires ont également réduit le nombre de tâches correctives sur lesquelles les développeurs doivent travailler parce qu'ils signalent la plupart des défauts que la QA avait l'habitude de trouver auparavant.

L'étape de QA est devenue beaucoup plus rapide et il semble probable que la personne QA aura besoin d'un second boulot bientôt, l'équipe des 4 développeurs a été maintenue mais la QA a subi deux "périodes de sécheresse" la semaine précédente puisqu'elle était en avance sur les développeurs. Le nombre moyen de tâches retournées a été considérablement réduit, avec seulement environ 5% des tâches retournées pour dépannage là où plus de 50% étaient autrefois retournées. L'étape QA évalue et utilise aussi des tests automatisés pour s'assurer qu'aucun défaut n'a été négligé et le gain de temps, lié au fait de ne pas avoir à construire des tests et ne pas avoir à les passer manuellement pour chaque tâche, est énorme.

Avec l'étape de QA terminant l'évaluation des tâches plus rapidement, la file d'attente des éléments à revoir par le client croît à un rythme beaucoup plus rapide. Le chef de projet commence à avoir des difficultés à couvrir le tout en une seule réunion hebdomadaire, car le nombre d'éléments terminés a augmenté et se révèle un peu compliqué à traiter dans le format de réunion actuel. Des modifications des méthodes de communication sont susceptibles de survenir dans un proche avenir pour aider à gérer le flux croissant des tâches accomplies. Les mesures globales du débit des tâches et l'estimation des dates de fin sont plus cohérentes et ne varient pas énormément par rapport à avant. Alors que les indicateurs ont reflété l'amélioration du processus, la variation ou la plage des valeurs s'est considérablement restreinte.

Succès

L'équipe a seulement travaillé sur son processus quelques mois, mais elle a déjà commencé à voir des améliorations positives et elle envisage déjà des pistes pour son prochain cycle d'amélioration. Voici quelques-uns des succès qu'elle a déjà obtenus :

- Augmentation de la productivité : le rythme global de développement a augmenté par rapport au rythme constaté avant mise en œuvre de Kanban
- Augmentation de la confiance : l'amélioration de la vitesse de développement, l'utilisation d'outils automatisés et de nouveaux indicateurs ont tous contribué à l'amélioration de la confiance du client
- Clarté de la vision : la définition du processus et le tableau Kanban ont donné à l'équipe une meilleure vue de leur processus et un moyen de comparer avec d'autres méthodologies
- Estimation de la variabilité réduite : la capacité à mesurer le débit et de meilleures estimations ont permis à l'entreprise de mieux évaluer le moment d'approcher de nouveaux clients potentiels
- Mesurabilité : de bons indicateurs fournissent un outil important pour continuer à améliorer le processus et évaluer si des améliorations potentielles ont amélioré le processus ou non
- Support à la formation : des améliorations dans le processus ont contribué à diminuer les coûts et fournir un argument pour consacrer ce temps à se former, pour aider à conduire de futures améliorations ou empêcher la société de se lancer sur une technologie qui n'offrira pas ce qui est demandé

Dans le prochain article, nous conclurons cette série en 5 parties, "Appliquer Kanban aux processus informatiques", avec des idées issues d'autres domaines de l'informatique. Nous allons également discuter de certains processus non-humains pour lesquels Kanban peut être appliqué, ainsi que quelques brèves informations sur certains des autres concepts qui ont été abordés dans la série (tels que l'amélioration continue).

A propos de l'auteur

Eli a plus d'une dizaine d'années d'expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l'administration de bases de données, l'architecture et l'intégration de systèmes industriels, l'administration de systèmes, ... dans plusieurs secteurs industriels, en passant par l'éducation et l'industrie pour aller jusqu'au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l'amélioration des processus, le codage, la qualité, l'administration de systèmes, les pratiques de développement et l'architecture logicielle.

Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

J'ai traduit ce troisième billet de Eli Weinstock-Herman : Applying Kanban to IT Processes (Part 3). Le sujet de ce billet m'a clairement rappelé mon année passée au service informatique des pompiers de la Gironde avec la maintenance du parc PC des 80 centres de secours. Ca m'aurait bien aidé à l'époque...

Cet article est le troisième d'un ensemble d'articles qui décrit les bases de Kanban et son application dans les processus informatiques :
- La première partie donnait un aperçu de Kanban et la façon dont il est utilisé dans l'industrie.
- La deuxième partie donnait un aperçu de Kanban et la façon de l'utiliser dans un service helpdesk (fictif).
Les articles qui suivent explorent différents scénarios pour vous aider à trouver des idées s'appliquant à votre propre contexte.

Dans la troisième partie de cette série "Appliquer Kanban aux processus informatiques", nous explorons l'utilisation de Kanban pour gérer un projet fonctionnel court terme. Cet exemple se concentre sur l'utilisation de Kanban pour créer un processus transparent pour suivre le flux des équipements à travers un certain nombre d'étapes complexes, sans générer de coûts supplémentaires pour le logiciel de suivi, de processus complexes et de formation, ou même d'efforts en double. Une meilleure uniformité et qualité des processus de déploiement permettront également d'améliorer l'efficacité et les délais de dépannage mais aussi d'assurer un niveau de documentation élevé par rapport aux standards en termes de gestion de logiciels et de licences.

Bienvenue sur le projet annuel de déploiement des PC de la société DEF

La société DEF est une PME disposant actuellement d'environ 1000 PC et portables déployés. Son service informatique fonctionne comme la plupart des services de cette taille, c'est-à-dire avec un haut niveau de management individuel, des liens solides dans l'équipe et un personnel relativement restreint pour couvrir une grande variété de rôles. Sur les 15 personnes, seulement deux vont travailler sur le déploiement des PC et on leur a donné toute liberté pour s'organiser et effectuer leur travail. L'équipe exige un reporting sur l'état d'avancement qui soit clair et simple afin d'éviter que leur travail acharné devienne un projet invisible. Par ailleurs, il y a un espace de stockage limité pour les équipements non déployés, l'équipe aura donc besoin de bien gérer le nombre d'équipements non déployés ainsi que les commandes de nouveaux équipements.

L'équipement et les tâches

Le déploiement annuel de PC doit tenir compte de l'équipement suivant :

- 160 nouveaux PC à déployer
- 40 nouveaux portables à déployer
- 120 PC et 10 portables à mettre à jour et à redéployer

Une image logicielle est disponible pour installer de base un système d'exploitation et un ensemble de pilotes sur chaque PC, en réduisant la variabilité de la procédure d'installation initiale. Des tâches comme l'enregistrement sur le domaine réseau, l'installation de logiciels utilitaires,bureautiques, ... doivent devenir le standard d'installation, mais il y aura bien sûr également quelques installations personnalisées de logiciels selon l'utilisateur final ou son rattachement à une entité. Mettre à jour un PC existant passe par les mêmes étapes, avec cependant l'ajout d'une tâche d'audit pour vérifier le passage d'un ancien mode d'utilisation à un nouveau. Si on se base sur l'historique, il est clair que l'un des problèmes les plus perturbants est lorsque l'on doit repasser sur un système (rework*) pour installer un logiciel manquant ou modifier une mauvaise configuration, l'équipe a donc décidé d'ajouter certaines vérifications au processus pour limiter ces risques.

*Le rework est le nom du processus qui consiste à terminer un élément et le renvoyer à travers une partie du processus pour corriger une étape de production incomplète ou ratée. Dans le cas du déploiement d'un PC, cela pourrait être un logiciel non installé pendant le processus de configuration, de mauvaises permissions allouées, ou toute une douzaine d'autres éléments qui nécessiteraient qu'un technicien revienne sur un PC déjà déclaré "déployé" afin de finir le travail. Les coûts de rework comprennent les coûts liés au fait d'exécuter une seconde fois une étape, de ré-exécuter les étapes suivantes une seconde fois, de basculer de son travail actuel sur l'élément qui nécessite un rework, et les retards liés au fait de terminer les travaux en cours par rapport à l'estimation initiale ou au délai initial.

Première version du tableau visuel

Après avoir discuté des exigences et des étapes du processus, les techniciens ont créé un processus commun à tous les équipements :

- Réception : le nouvel équipement et l'équipement à redéployer qui n'ont pas encore été "étiquetés"
- Stock : le nouvel équipement et l'équipement à redéployer qui ont été "étiquetés"
- Image : installer l'OS de base, les pilotes et l'image logicielle
- Analyse personnalisée : construire une liste des logiciels client et/ou des paramètres spécifiques pour l'utilisateur final concerné
- Bureautique : installation et configuration initiale des logiciels bureautiques et installation des templates spécifiques à la société
- Utilitaires : installation d'un ensemble standardisé d'utilitaires pour le dépannage informatique et l'audit
- Installation personnalisée : installation des configurations personnalisées
- Audit : exécution du premier audit du PC et mise à jour des liens d'affectation pour un PC redéployé
- Déploiement : déploiement de l'équipement pour l'utilisateur final

Pour gérer les PC à travers ce processus, l'équipe a inventé un "système d'étiquetage" de l'équipement. Les techniciens ont conçu un formulaire check-list copié et mis à jour pour chaque PC. Le coin supérieur droit du document devient la carte Kanban, tandis que le reste est une check-list qui sera utilisée pour vérifier l'étape précédente de chaque étape du déploiement au fur et à mesure que l'équipement progresse dans le processus. Par le passé, l'équipe avait déterminé qu'il y avait en moyenne 5% de rework nécessaire pour pallier une configuration ou un logiciel manquant.


Exemple de formulaire avec carte Kanban prête à détacher

Au lieu d'inclure une étape de QA à la fin de son processus de déploiement, l'équipe a choisi de commencer par vérifier la tâche de chaque étape précédente. En vérifiant le plus tôt possible, l'équipe espère réduire le besoin d'un long processus de QA, réduire la quantité de rework, détecter et corriger le plus tôt possible pour prévenir la répétition tardive des tâches (par exemple exécuter le logiciel d'audit). Des cases à cocher "Fait" et "Vérifié" sont mises à disposition sur chaque ligne du formulaire.

Maintenant que les tâches ont été définies, l'équipe initialise son premier tableau visuel avec du ruban et des étiquettes sur un tableau de liège. Les punaises seront utilisées pour positionner les cartes Kanban liées à chaque pièce d'équipement dans l'étape appropriée du tableau.


Tableau Kanban avec quelques cartes

Les limites Kanban à chaque étape sont basées sur l'espace de travail disponible et sur le souhait de conserver un flux lissé de l'équipement dans le processus. L'équipe a décidé que, pour trouver un juste équilibre entre la régularité du flux (petites limites) et l'efficacité des installations menées en parallèle (grandes limites), elle définirait des limites basées sur les temps d'installation des logiciels pour s'assurer que les étapes les plus longues soient correctement dimensionnées et ne génèrent pas de retards pour les étapes ultérieures. Copier l'image, installer les logiciels bureautiques et exécuter l'audit nécessitent peu d'intervention humaine mais beaucoup de temps, tandis que l'Analyse personnalisée, le Déploiement et les deux étapes restantes d'installation des logiciels nécessitent un niveau élevé de participation et d'attention de la part de l'installateur.

Créer un reporting

Il y a un certain nombre d'exigences et de facteurs à prendre en compte pour établir le reporting lié à ce processus. En se basant sur les exigences et les souhaits exprimés par le responsable informatique, l'équipe a produit la liste suivante des points devant faire l'objet d'un reporting :

- Avancement : basé sur le concept d'un burndown (lien mort), le tableau d'avancement affiche les progrès réels et une date de fin prévisionnelle
- Délai déstocké -> déployé : un graphique simple pour montrer le temps de déploiement réel par rapport à la moyenne et aux années précédentes
- Satisfaction des utilisateurs : un couple de barres horizontales qui affiche le nombre de livraisons réussies à la date prévue et le nombre de déploiements incomplets (rework)


Feuille de calcul et graphiques associés pour le reporting hebdomadaire

Pour générer ce rapport, il faudra mettre à jour la feuille de calcul chaque fin de semaine avec le nombre de PC réellement terminés, incrémenter (le cas échéant) la quantité totale dans une deuxième cellule et indiquer le nombre de PC qui n'ont pas respecté la date de livraison cible dans une troisième cellule. Les projections sont automatiquement mises à jour sur la base d'une équation définie dans le tableur et l'information réactualisée dans les graphiques. Un simple copier/coller des graphiques dans les documents en fin de semaine permet de produire le nouveau reporting hebdomadaire.

Analyse finale

Pendant l'exécution du processus de déploiement, l'équipe a légèrement modifié les limites Kanban ainsi que le mécanisme de reporting, mais elle n'a pas eu d'importants changements à apporter à son processus. Compte tenu de la transparence des travaux, elle a pu rester sur la bonne voie et déployer les équipements à un rythme régulier. Au fur et à mesure qu'elle a ajusté le rythme du processus, elle a commencé à planifier les commandes de nouveaux PC pour que cela coïncide mieux avec la consommation des stocks, lui permettant d'augmenter la taille de ses commandes, de bénéficier de meilleurs devis concernant l'achat des équipements, sans pour autant manquer de travail entre les commandes. Un reporting final a été réalisé à partir des graphiques tirés des rapports hebdomadaires et des informations supplémentaires concernant la réduction des dépenses et du travail.

Flux du processus

Tout nouvel équipement ou équipement remasterisé était affecté à un utilisateur et étiqueté avant de démarrer quoique ce soit. Ceci a empêché qu'apparaissent les problèmes survenus au cours des années antérieures, tels que les mauvaises affectations, les doubles affectations et les réaffectations avec les mauvais logiciels. Le processus a également fourni un inventaire précis des équipements disponibles à tout moment, permettant ainsi de répondre aux questions immédiatement plutôt que de demander à quelqu'un de se rendre dans l'espace de stockage et d'effectuer un inventaire. Une communication au plus tôt avec l'utilisateur final sur la date à laquelle l'équipement serait disponible, a réduit la difficulté à déployer les PC qui étaient prêts, les utilisateurs finaux étant préalablement avertis, ceux-ci pouvaient aider à mieux définir leur disponibilité, avec comme conséquence de réduire la replanification des installations comparativement aux années antérieures. La vérification immédiate des étapes antérieures et les limites Kanban ont favorisé un flux lissé des équipements dans le processus, en fournissant les bases d'un temps de cycle plus cohérent et reproductible. Une meilleure estimation de la durée du processus de déploiement (disponibilité des stocks) a permis de réaliser des économies budgétaires directes, tout en permettant à l'équipe d'augmenter la taille de ses commandes et de profiter de meilleures économies pour la même quantité d'équipements. Enfin, le mécanisme de reporting créé par l'équipe était assez simple pour que le responsable informatique soit capable de l'utiliser lors de chaque réunion de département, sans devoir passer la nuit précédente dessus pour tout préparer.

Succès

Voici quelques-unes des succès de l'équipe :

- Visibilité 100% : visibilité dans le processus et l'inventaire à tout moment, sans effort supplémentaire consacré au suivi des techniciens ou au comptage à la volée de l'équipement
- Moral amélioré : réduction de la confusion et de la négativité des utilisateurs finaux dans l'attribution des équipements en se basant sur des communications claires et un véritable processus d'affectation
- Gains de temps : aucun rework est synonyme de gain de temps dans le processus de déploiement, ainsi que dans la suppression des interruptions que causaient le rework
- Gains financiers : une meilleure estimation et une meilleure gestion des stocks a permis d'augmenter la taille des commandes sans nuire aux délais de réalisation
- Marketing bon et peu onéreux : le processus simple pour générer les rapports a non seulement apporté un gain de temps, mais a aussi produit des métriques assez simples pour qu'elles soient réutilisées lors des réunions managériales avec une publicité positive sans pour autant exiger plus de temps et d'efforts de la part du responsable informatique
- Productivité accrue : en se fondant sur la cohérence du processus, l'amélioration des estimations, la réduction du niveau d'interruption constatée sur les précédentes années, l'ensemble du processus prenait moins d'heures de travail à dérouler
- Amélioration mesurable : les statistiques identiques sont suivies attentivement pendant l'exécution du processus et permettent de constater en fin d'année les améliorations au niveau de l'équipe et du département.

Les succès énumérés ici couvrent aussi bien des aspects durs (financier) que mous (moral) et ne couvrent probablement pas l'ensemble des succès qui auraient pu être obtenus dans une version non-fictive de cette histoire. En un mot, le processus a pu s'exécuter de façon plus facile, plus efficace et plus prévisible, ce qui a généré au niveau de l'équipe un certain nombre d'améliorations mesurables par rapport aux années antérieures. Ce même processus sera réutilisable dans les années à venir, et peut désormais être utilisé comme une base pour de nouvelles améliorations ou pour permettre de porter les efforts sur l'amélioration d'autres processus puisque celui-ci se déroule simplement et en douceur. Même si utiliser un système Kanban pour un processus temporaire n'est pas fréquent, il démontre sous un autre angle la façon dont il peut être utilisé pour "apprivoiser" des processus de travail complexes et promouvoir l'amélioration globale du processus.

Dans le prochain article, nous explorerons l'utilisation de Kanban par une équipe de développement logiciel qui cherche à livrer et maintenir un ensemble de produits. Bien qu'il existe déjà beaucoup de comptes-rendus réels de la part de personnes appliquant Kanban au processus de développement logiciel, le développement est une activité notoire d'un département informatique et je serais négligent si je n'apportais pas ma touche personnelle sur la façon dont Kanban peut être utilisé par une équipe de développement.

A propos de l'auteur

Eli a plus d'une dizaine d'années d'expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l'administration de bases de données, l'architecture et l'intégration de systèmes industriels, l'administration de systèmes, ... dans plusieurs secteurs industriels, en passant par l'éducation et l'industrie pour aller jusqu'au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l'amélioration des processus, le codage, la qualité, l'administration de systèmes, les pratiques de développement et l'architecture logicielle.

Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

J'ai traduit ce billet de Eli Weinstock-Herman : Applying Kanban to IT Processes (Part 1).

Cet article est le premier d'une suite décrivant les fondamentaux du Kanban et son application dans les processus informatiques. Ici, on donne un aperçu de Kanban et la façon dont il est utilisé dans l'industrie. Les articles qui suivront explorent différents scénarios pour vous aider à trouver des idées s'appliquant à votre propre contexte.

Récemment, j'ai vu une augmentation du nombre d'articles dans les communautés de développement et de gestion de projet Agile et qui vantent les mérites de Kanban, en montrant la valeur que Kanban a permis d'apporter lorsqu'il est utilisé avec des méthodes Agile. La plupart de ces articles se concentrent fortement sur l'aspect visualisation (Visualiser des projets agile en utilisant des tableaux Kanban par exemple), certains font même ressortir quelques autres avantages de Kanban, ou se contentent simplement de revendiquer que Kanban est un "marteau d'argent à la recherche d'un clou". Dans la communauté informatique, il semble que cela soit fortement orienté gestion de projets logiciels et développement, mais Kanban est applicable à de nombreux autres domaines de l'informatique.

Qu'est-ce-que Kanban ?

Kanban est un terme japonais signifiant "tableau visuel" ou "enseigne" et est un outil pour réduire le temps de cycle^[1] d'un processus, permettant d'accroître la visibilité dans le flux des processus et de réduire la quantité de travail en cours^[2]. En tirant le meilleur parti de cette visibilité, nous pouvons voir où le flux de travail stagne, se bloque en créant des goulots d'étranglement ou en réduisant l'efficacité des étapes amonts. Kanban est utilisé dans le Lean Manufacturing pour disposer d'une meilleure visibilité du processus et de son état d'avancement, pour réduire les gaspillages (et les coûts), et pour aider à atteindre une capacité de production juste-à-temps^[3].

Le signal Kanban

À son stade basique, Kanban est un système de signalisation qui indique aux étapes amonts d'un processus de production qu'il y a une exigence ou une demande client pour faire X.



Dans un processus de fabrication, la commande client est convertie en une ou plusieurs cartes qui représentent les exigences de production permettant de satisfaire la commande. Chaque carte ou symbole définit le produit à fabriquer et la quantité nécessaire. La carte est communiquée au responsable de l'entité concernée qui va répondre à la demande de production. Si ce responsable a un tableau visuel pour afficher la file d'attente des commandes ou la capacité disponible, il placera la carte reçue dans l'emplacement vide suivant, sinon il met à jour le tableau. Selon la complexité du processus, la réception ou l'exécution du signal Kanban pourra déclencher des signaux supplémentaires dans les étapes amonts du processus ou vers le personnel chargé d'amener le matériel nécessaire à la réalisation de l'étape de production. Chaque étape a un nombre limité d'emplacements sur le tableau qui définit le nombre maximum de cartes qui peuvent cohabiter à un point du processus à un instant donné. Cette limite Kanban contraint la quantité de travail et le nombre d'éléments en cours de travail et empêche que le travail non fini ou les demandes s'accumulent.



Limiter la quantité de travail en cours dans le processus à une petite valeur maîtrisable, nous permet de continuer à utiliser pleinement nos ressources (dans ce cas, les machines et les opérateurs), tout en réduisant la quantité de travail partiellement terminé et en attente d'être terminé. L'application de limites Kanban à un processus nous aide à commencer à réduire la variabilité du temps de production d'un produit, ainsi qu'à supprimer la nécessité (et la tentation) de différer la priorité du travail lors de chaque étape. Bien que cela puisse sembler ralentir les temps de réponse lorsqu'une commande prioritaire arrive, cela accélère en réalité son traitement parce que nous n'avons pas besoin de réorganiser nos ressources pour abandonner 47 tâches en suspens partiellement démarrées. Nous positionnons tout simplement la commande prioritaire dans la file d'attente de la dernière étape (si un emplacement est disponible) et nous laissons le signal remonter à travers les étapes précédentes de manière classique. Puisque nous avons déjà une quantité limitée de travail en cours, nous sommes en mesure de traiter de nouvelles demandes rapidement, sans interrompre les items sur lesquels nous nous sommes déjà engagés.

En supprimant les files d'attente de travaux non terminés et la repriorisation entre chaque étape, nous avons réduit la quantité de non-valeur générée par les opérateurs et amélioré à la fois la précision et (généralement) le délai estimé et communiqué au client. Nous avons également réduit le nombre des changements de priorité parce que nous terminons chaque tâche avant de passer à la suivante, au lieu d'aller et venir entre plusieurs commandes en suspens. La suppression des changements de priorité inutiles constitue une économie immédiate, car ils n'apportent aucune valeur directe au client, la diminution des délais de livraison^[4] améliore notre réactivité pour le client final et la diminution des changements de priorité ainsi que du temps consacré au fait de recommencer à travailler sur une tâche^[5] augmente notre capacité sans coûts additionnels.

Visualisation et Métriques

Visualiser les demandes à chaque 'poste de travail' en utilisant un tableau réel est un bon moyen de communiquer à travers le groupe et de gérer votre Kanban. Si votre tableau n'a que 3 emplacements pour les 'cartes' alors vous ne pourrez pas prendre plus de 3 demandes. Les personnes situées aux étapes amonts et avales, peuvent voir les progrès réalisés ainsi que la potentielle capacité excédentaire (rien à faire) à votre étape. Le tableau n'est pas seulement une méthode pour gérer vos tâches, mais aussi un outil de communication instantanée, vous permettant de vous concentrer davantage sur le fait de réaliser votre travail plutôt que de faire du reporting et de mettre à jour les métriques des tableaux de bord.


On finit 2 unités/jour, soit environ 14 jours pour traiter une nouvelle commande

Un autre avantage majeur des méthodes Kanban apparaîtra avec la création initiale du tableau visuel. Outre le fait de définir clairement les opérations ou les étapes de production, les tâches actuelles sur le tableau, les demandes actuelles et les travaux en cours vont commencer à mettre en évidence les goulots d'étranglement. Au fur et à mesure que le temps passe et que le système kanban vous oblige à réduire ce backlog, les goulots d'étranglement vont continuer à devenir de plus en plus évidents, montrant les étapes où des améliorations directes auront un impact sur le délai de livraison pour l'ensemble du processus. Dans de nombreux systèmes, lorsqu'une étape n'a plus rien à traiter dans un système Kanban, les personnes affectées à cette étape remontent à l'étape précédente pour aider à terminer les tâches en suspens. Des règles simples ou une réorganisation de l'équipe actuelle peuvent continuer à donner des gains de performance au fur et à mesure que le tableau nous permet de visualiser et détecter les problèmes de ralentissements, les hoquets de production ainsi que les étapes potentiellement sans travail en cours.


On finit 2 unités/jour, soit environ 5 jours pour traiter une nouvelle commande

La communauté du lean manufacturing a des centaines d'exemples de tableaux visuels, mais j'en profite plutôt pour vous donner ici quelques liens sur des articles concernant le développement logiciel Agile. Les tableaux Kanban ne sont pas coûteux et, à mon avis, devraient toujours commencer par un tableau réel avant d'être enfoui dans une solution logicielle (si vous le faites).

- Article "Lean Software Development in Small Teams (lien mort)" - Tableau blanc et aimants
- Article "Evolution of a Kanban Board" - Tableau blanc et post-its
- Article "Visualizing Agile Projects with Kanban Boards" - Copieusement illustré et beaucoup d'informations
- Article "The Kanban Story - Kanban Board" - Résultat final (et simple !) pour un exemple concernant le développement logiciel

Une recherche sur Internet vous donnera de nombreux exemples supplémentaires dans une variété d'environnements.

Appliquer Kanban dans un département informatique

Maintenant que nous avons une idée sur la manière dont fonctionne Kanban, nous pouvons commencer à explorer comment l'appliquer à des processus informatiques, que ce soit dans des environnements administratif, support et développement logiciel. Initialement l'idée d'appliquer Kanban dans un environnement non industriel peut sembler difficile... les exemples couvriront donc un large éventail de situations possibles. En explorant plusieurs exemples de réalisations, nous pourrons avoir un aperçu ou de nouvelles idées sur la façon d'appliquer ces concepts (et voir les avantages qui en résultent) dans nos environnements informatiques respectifs.

A propos de l'auteur

Eli a plus d'une dizaine d'années d'expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l'administration de bases de données, l'architecture et l'intégration de systèmes industriels, l'administration de systèmes, ... dans plusieurs secteurs industriels, en passant par l'éducation et l'industrie pour aller jusqu'au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l'amélioration des processus, le codage, la qualité, l'administration de systèmes, les pratiques de développement et l'architecture logicielle.

Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

J'ai traduit cet article de Nick Oostvogels : 5 arguments against Kanban.

(image by Saltatempo)

A chaque fois que vous songez à utiliser Kanban pour gérer vos flux de valeur, vous entendrez des arguments cinglants contre cette pratique. Ceci est normal et n'est pas lié à Kanban, cela arrive à chaque initiative de changement. J'ai compilé une liste de questions et d'arguments auxquels j'ai dû faire face lors de l'introduction de Kanban et je propose quelques moyens d'y répondre.

1. Il faudra plus de temps !

Les gens craignent que si l'on passe à un modèle de flux continu, sans timeboxes ou itérations, le travail prenne plus de temps au final. Après tout, la plupart des managers ont entendu parler de la loi de Parkinson qui stipule que le travail se développe de façon à remplir le temps disponible pour son achèvement.

C'est une préoccupation légitime. Une équipe moyenne aura des difficultés à se concentrer fortement autant qu'ils l'auraient fait dans un cycle itératif où il y a toujours une démo qui se prépare dans un proche avenir. Heureusement, il existe des moyens de travailler dans un flux continu et de toujours conserver une grande concentration. Par exemple, vous pourriez mettre en œuvre une cadence. Toutes les x semaines, nous faisons une démo à nos parties prenantes. Quoique vous ayez terminé à cette date, cela leur sera montré. Nos mesures seront utilisées pour définir les besoins. Si vos parties prenantes savent qu'en moyenne vous livrez 6 features par semaine, ils s'attendront à voir six features terminées lors de la démo hebdomadaire.

Une autre façon de stimuler la concentration est de visualiser la tendance de votre moyenne de lead time ou de temps de cycle. Lorsque le temps moyen est en hausse, quelque chose cloche et nous pouvons inspectez l'ensemble. Lorsque le temps moyen est en baisse, l'équipe est sur sa lancée et gagnera encore plus d'énergie en visualisant son travail.

Conclusion : des équipes très mûres garderont leur concentration d'après mon expérience. Nous pouvons aider des équipes de maturités basses et moyennes à se concentrer en utilisant des techniques telles que la cadence ou la visualisation.

2. Nous perdons notre capacité à planifier

Passer de l'estimation à la mesure déclenchera toujours cette réaction. Comment pouvons-nous prendre des engagements pour nos clients si nous n'avons pas d'estimation sur l'effort ?

La vérité c'est que rien n'a vraiment changé. En Agile, nous utilisons déjà la vélocité comme une mesure pour corriger notre planning. En Kanban, nous utilisons des mesures pour planifier.

Bien entendu, vous devez être en mesure d'extrapoler vos premières mesures pour créer un planning de livraison que vous pouvez régulièrement faire coller à la réalité. Il y a deux façons simples de faire cela. Découpez toutes les features de sorte qu'elles aient plus ou moins la même taille, ou attribuez-leur un poids relatif.

De cette façon, vous pouvez utiliser vos mesures de lead time moyen ou temps de cycle moyen pour calculer le temps nécessaire qu'il faudra pour terminer les fonctionnalités restantes de votre prochaine version.

3. Coûts élevés de refactoring de l'architecture

Si nous tirons une feature à la fois, personne n'aura le temps de penser à l'architecture du système et se contentera juste de construire au-dessus de l'existant.

Cet argument ne proviendra probablement pas d'une équipe Agile, car elle connaît déjà la faisabilité d'une architecture émergente. Ce n'est pas moins différent dans un modèle de flux que dans un cycle itératif. Des tâches techniques doivent être prévues dans chaque feature et le refactoring est un effort continu. Je ne dis pas que c'est facile, mais vous pouvez apprendre à le faire.


4. Les choses vont rester coincées, nous ne pouvons pas garder les limites de TAF^[1]

Quand vous êtes porteur du message que seulement x features pourront être traitées et que les limites ne peuvent pas être dépassées, les gens commencent à paniquer. Ils savent par expérience que certaines features restent en cours pour une longue période parce qu'ils attendent quelque chose qui est en dehors de leur contrôle. L'idée de respecter la limite et de faire autre chose ne remet pas en cause nos croyances et la façon dont nous avons été élevés. Vous devez rester occupé tout le temps et faire de votre mieux !

Par contre ! Dans le cas d'un système à flux tirés comme Kanban, respecter les limites de TAF est une chose puissante. Si vous êtes coincé et ne pouvez pas démarrer une nouvelle tâche, un peu plus tard, le poste de travail aval va rester coincé aussi et ainsi de suite. Cela crée un problème immédiat pour l'ensemble du système, et ne se limite plus à vous seul. C'est sûr que les limites de TAF seront inconfortables au début, mais elles vont déclencher une action rapide ! Ensemble, vous allez trouver un moyen de désengorger le système et de terminer le travail, au lieu de simplement commencer une autre tâche et de ne rien finir.

5. Nos parties prenantes ne se soucient pas d'alimenter le flux

Elles veulent que toutes les features soient livrées aussi vite que possible.

Dans cette situation, allez à la cause racine. Pourquoi ne se soucient-elles pas de prioriser la file d'entrée ? Elles n'ont probablement pas vu la valeur que cela créait. Elles n'ont peut-être jamais eu la possibilité de changer et de s'adapter lorsque le développement commençait. Expliquez-leur que le planning est obsolète immédiatement après avoir été créé en raison de nouvelles idées, des changements de situation du marché, etc. Certaines features ne sont pas si urgentes que ça, tandis que d'autres peuvent devenir plus importantes. Être capable de changer rapidement le périmètre de votre prochaine version vous donne un énorme avantage concurrentiel parce que vous êtes en mesure de répondre aux attentes des clients avec plus de précision.

C'est la liste de mes cinq arguments contre Kanban et quelques options pour y répondre. Si en vous connaissez d'autres, je suis très intéressé.

Feedback :

• Pablo Pernot : KanBan, Le cheval de Troie
  

Retrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.