2/3 : Le LEAN dans l’IT traitons le problème.
Après mon premier article « vendre la peau de l’ours avant de l’avoir tué » dans lequel je vous ai présenté le LEAN, voici le deuxième article qui vous permettra, cette fois-ci, de comprendre comment le LEAN peut être utile dans un contexte IT.
Effectivement le mindset (on peut parler de mindset plus que de méthode) est moins connu en IT que d’autres méthodes qui s’en inspirent.
Pourquoi peut-on parler de mindset plus que de méthode ?
Car il a été créé dans l’objectif d’améliorer la satisfaction du client final / utilisateur sans réel process type à suivre.
Certains adeptes du LEAN appellent cet objectif l’étoile du Nord car il est à l’image des navigateurs perdus dans l’océan, sans autre indication que ce repère pour naviguer.
C’est une des raisons qui explique que le LEAN est mal compris, donc mal mis en oeuvre et par voie de conséquence n’apporte pas les résultats espérés.
Quelle est la différence entre les activités de développement de logiciel et celles des chaînes de production industrielle ?
Essayons de donner une définition pour chacune des activités :
- La production en usine : consiste à réaliser une succession de gestes ou d’activités similaires pour toutes les pièces afin de produire un sous ensemble ou un ensemble optimal vendu par la suite à un client.
- La réalisation d’un logiciel : consiste grossièrement à prendre un besoin exprimé par l’utilisateur, le construire et le mettre à sa disposition pour une solution efficace.
Que remarque-t-on ? Dans les deux cas on produit un élément qui vise à satisfaire un client lequel est en attente de la réalisation de son besoin. Cela implique une notion d’optimisation de réalisation de la demande au plus tôt.
La difficulté dans l’activité de développement logiciel est de concrétiser les objectifs du demandeur par rapport à ce qu'il désire (donc à la formulation de sa demande).
Le développeur doit y consacrer beaucoup de matière grise, car il est confronté de manière récurrente à construire une nouveauté qui reste de l’ordre de l’imaginaire.
Comment travailler dans l’inconnu ?
L'inconnu est le quotidien des projets IT : être expert exclusivement en développement ne suffit pas pour être efficace; il est aussi nécessaire de comprendre les aspects fonctionnels du logiciel ou l’historique du code.
Sans cette compréhension, le développeur risquerait de faire des choix techniques contradictoires avec le besoin réel du client, ce qui nécessiterait probablement de refondre tout le code préexistant.
On éviterait ainsi de mettre en danger le client ou l'utilisateur.
Pour concrétiser cela, j’entends souvent les managers des équipes que j’accompagne dire qu’une tâche peut prendre trente minutes à un expert mais deux jours à une autre personne de l’équipe et avec des anomalies.
Pourquoi cet écart ?
L’expert sait qu’il doit commencer à rechercher à tel endroit puis à tel autre pour avancer. Alors que d'autres personnes n’ont pas forcément ce savoir, et vont passer du temps à chercher (beaucoup de temps) sans se rendre compte qu’elles ne cherchent pas au bon endroit, le client attend toujours. Certes, c’est en se trompant que l’on apprend, mais cela a des limites quand on est client.
Le standard est un élément indispensable dans le fonctionnement d’une équipe.
En effet, le standard est la colonne vertébrale de l’activité, ce qui est valable à tous les niveaux de l’entreprise.
Dans l'état de l'art actuel mis en oeuvre au sein d'une organisation, il permet surtout de partager une vision commune de la meilleure façon de procéder pour réaliser une action.
Cela concerne à la fois les développeurs mais également le top management pour prendre une décision.
En LEAN on parle du bon geste.
La meilleure ne veut pas dire l’unique. Cela doit absolument rester un guide et non un processus indispensable à suivre pour travailler.
L’objectif n’est pas de verrouiller les personnes dans leur manière de faire mais au contraire d'échanger leurs bonnes pratiques. Pour rappel en IT on produit de l’inconnu donc on ne peut pas toujours tout maîtriser.
Faites confiance aux personnes pour en sortir dès que possible. Le standard reste la base de la créativité des développeurs et doit être remis en cause le plus régulièrement possible (même tous les jours). Il doit être réalisé par des opérationnels pour des opérationnels, mais pas par un expert méthode.
Par où commencer ?
Faire établir en préliminaire un standard global de fonctionnement d’équipe :
- Il décrira la chaîne de valeur qui transforme la demande client en un produit fini.
- Il servira de base pour le management visuel et permettra ainsi d’éviter qu’un développeur oublie de passer par une phase d’analyse (avant de coder ou bien qu'il oublie de tester).
Si nécessaire, vous pouvez détailler les étapes, créer un standard pour chaque élément de la chaîne de valeur, et partager par exemple la meilleure façon d’analyser ou de tester un développement.
Voici quelques pistes :
- Mesurez la durée de votre standard global, combien de temps il faut pour qu’une demande soit réalisée (quel est le lead time) ?
- A quel endroit perdez-vous le plus de temps ? Où l’équipe est-elle la moins efficace ?
- Sur quel sujet avez-vous le plus d’anomalies ou de retours clients ? Êtes-vous sûr que lorsqu’un sujet du même type reviendra, l’équipe ne reproduira plus l’anomalie (sans mettre en place tout une procédure bien lourde) ?
- Un logiciel étant constitué de plusieurs fonctionnalités, il est conseillé d’en faire également un pour chacune d’entre elles.
Quelle est la recette du LEAN pour avoir plus d’experts dans son équipe ?
L’objectif connu du LEAN est d'identifier et de localiser les gaspillages. Or, comment identifier les gaspillages sans les bonnes lunettes -- c’est-à-dire celles de l’expert ?
Le manque de coordination et d'échanges d'informations empêche les personnes d’une équipe d’avoir ce regard. En LEAN, l’idée est de rédiger un guide avec les experts confirmés d’un sujet, puis de le partager pour l’essayer et enfin d’en faire un standard de réalisation. ATTENTION : le standard est surtout un guide pour arriver à reproduire une action ou une tâche et non une règle fixe.
Que recherche-t-on ? L’objectif est de partager l’expérience et surtout de transmettre la meilleure pratique de l’équipe ce qui représente plusieurs avantages :
- le standard sert de guide pour les nouveaux collaborateurs. Ils peuvent l'utiliser pour essayer de traiter des sujets sans se perdre dans un océan d’informations ou sans avoir besoin d’une personne de l’équipe.
- le standard est un support de communication de bonnes pratiques à “challenger “ au maximum pour avancer.
Comment faire évoluer ces standards ?
Profitez de l'arrivée de nouveaux collaborateurs dans l’équipe pour les « challenger ». Je vous encourage à leur donner ces standards tels quels et leur faire identifier les blocages.
Comment faire sans nouveaux collaborateurs ?
Recherchez qui dans votre société exerce la même activité que vous, et partagez avec elles les standards, profitez-en pour connaître le(s) leur et pour les « challenger ».
OUVREZ-VOUS !!!!!!!!
Profitez également des points quotidiens de synchronisation (Daily meeting) pour stimuler leur évolution.
Vous avez eu un retour de la recette, qu’est ce qui n’a pas fonctionné dans les standards ? Travaillez sur le sujet dans la journée et reparlez-en le lendemain.
Le client n’est pas satisfait du résultat livré, comment faire pour que cela ne se reproduise pas ? A quel moment cela n’a-t-il pas fonctionné ?
N’hésitez pas à faire venir un maximum de « sachants » afin de renforcer votre esprit de réflexion.
C’est là que l’outil préféré du LEAN doit vous servir, utilisez le PDCA (voir 1er article).
On peut enfin travailler sur les gaspillages.
Je devine mes collègues experts du LEAN dire : « comment ne pas parler de LEAN sans les gaspillages ».
Je trouve cela trop réducteur. Je n'appartiens pas à ceux qui pensent : « pas de LEAN sans Kanban » ou « pas de LEAN sans gaspillage » …
C'est en contradiction avec l’ouverture proposé par le LEAN.
Prenez bien en compte les risques de désordre inhérents à tout changement**.**
Et le mindset qu’en faites-vous ? Restez ouvert, ne faites pas les choses de façon trop livresque.
Vous avez la structure, mesurez maintenant.
Reprenons le standard de fonctionnement global, soit la chaîne de valeur pour livrer un produit. Essayez de positionner l’ensemble des tâches à chacune des étapes et surtout à lister le stock présent en entrée (backlog pour les équipes Agile).
Pour rappel, les fondateurs de Toyota furent choqués par toutes les accumulations de pièces lors de leur visite chez FORD (cf. l'article précédent Le LEAN 1/3). C’est de ce constat qu’a démarré le LEAN avec l’aide de Shewart et Deming et c’est en observant le flux tiré dans les supermarchés américains qu’ils ont trouvé une réponse à leur problème.
En quoi votre situation n’est-elle pas la même que FORD ? Dans combien de temps allez-vous avoir fini le stock en entrée ? Êtes-vous vraiment capable de le consommer ?
Faites la même chose à chaque étape de la chaîne de valeur et essayez de savoir qui travaille concrètement sur les sujets. Vous allez être surpris de voir que des personnes sont capables de travailler sur sept, dix sujets ou même plus en même temps.
Donnez vite la recette ou déposez un brevet....
Pourquoi est-ce un problème ?
Repensez à FORD, il y avait des stocks de pièces de toute part, des bonnes pièces sans défaut mais également de mauvaises à retravailler. Figurez-vous que vous êtes certainement dans la même situation. Comment se projeter sur une date de livraison ? Mettez-vous à la place du client qui attend et qui est noyé par ces stocks. Vous avez tout un tas de tâches ou « User Stories » en présence, qui n’avancent pas, qui traînent. D'autant qu'il ne s'agit pas seulement d'un élément d'affichage, et cela génère plus de conséquences sur l'avancement que vous ne pouvez le croire. Quelle est la valeur pour le client ?
Comment prioriser les demandes à partir d'une liste de cent sujets en stock ? Comment savoir que cette demande sensible est actuellement en attente de tests ? Est-ce que l’environnement n’est pas disponible, ou bien l’équipe est-elle perdue dans le stock de tâches ?
Quelle solution : Vous voulez maintenant « tuer » les stocks ? Le stock est de cent sujets aujourd’hui, or il n'est possible d’en produire que trente dans le mois. Comment arriver à ne pas dépasser trente demandes en stock ? N'est-il pas nécessaire de passer par une phase intermédiaire dans laquelle il n'y en aurait que quatre-vingts ? A vous de résoudre le problème par une action adaptée. Ne faut-il pas créer un standard pour gérer le stock ? Faites un PDCA.
On avait dit trois articles.
Il est tout à fait possible d'écrire encore des pages et des pages sur l’apport du LEAN dans l’IT. C'est ainsi que je me suis concentré sur l’apport de valeurs sûres pour éviter de s’écarter de la standardisation visant au partage et à la visualisation des stocks. De fait, on cherche à modifier de manière optimale la cohérence des divers processus.
Dans le prochain article je vous proposerai d’approfondir ce « challenge » en parlant implémentation, et de découvrir une démarche possible de mise en place d’un mindset LEAN IT.
En synthèse voici ma proposition de la maison du LEAN avec trois piliers :
