« L’avenir n’est que du présent à mettre en marche », une citation de Saint Exupéry qui éclaire nos pratiques lean à Operae
J’ai découvert cette citation à l’occasion des vœux de 2020. Elle a immédiatement fait écho à la façon dont mes clients définissent leurs attentes vis-à-vis du lean management : ils décrivent clairement et sans complexité comment ils aimeraient que fonctionnent leurs entités dans un, deux ou trois ans et s’engagent dans une démarche lean pour construire cet avenir, un pas après l’autre.
André est directeur technique d’une entreprise gérant des milliards de transactions chaque année. L’une des priorités qu’il s’est fixées, lorsqu’il a pris son poste, consiste à réduire à quelques minutes le temps nécessaire à la création des environnements sur lesquels sont déposés les systèmes informatiques construits par les équipes de la DSI. Ces environnements sont des objets complexes, assemblages de hardware (serveurs, réseaux, etc…), de middleware (système d’exploitation, politique de sécurité, bases de données, etc…) et de software.
Tellement complexes, d’ailleurs, que leur construction fait l’objet d’une conduite de projet technique parallèle au projet de développement informatique. Conduire deux projets en parallèle, devant se rejoindre à des moments bien précis, génère beaucoup d’occasions de retard et d’agacement. Par exemple, l’un n’obtient pas son certificat de sécurité au moment prévu, l’autre découvre qu’il a besoin de plus de puissance de calcul qu’imaginé. Ces aléas ont impact immédiat sur le planning du projet. Tout se décale et les relations se tendent.
L’avenir…
André et ses équipes connaissent bien les nouveaux processus DevOps qui permettent d’alimenter les développeurs en environnements informatiques de façon rapide, fluide et automatisée.
Pour eux, l’avenir serait de permettre aux équipes projet de mettre en production leurs développements chaque jour, en moins de cinq minutes avec la possibilité d’un retour arrière en moins de 15 minutes.
… n’est que du présent à mettre en marche.
Ils décident rapidement de les mettre en œuvre, achètent les outils ad hoc, sélectionnent trois domaines informatiques qui seront des pilotes et entament les paramétrages. Les résultats au bout de six mois offrent autant de promesses que de problèmes à résoudre.
Seul l’un des trois périmètres tient à peu près la promesse faite. Les deux autres demandent beaucoup de paramétrages en amont des mises en production et ces mises en production prennent bien plus de temps que prévu. Elles ne sont donc possibles qu’en week-end, pour ne pas pénaliser l’activité.
En parallèle, André a entamé dans son périmètre le déploiement du lean management, qu’il connait bien et dont il apprécie les valeurs managériales sous-jacentes. Il propose à l’équipe DevOps de travailler avec Edmond, coach lean IT, pour comprendre comment finaliser leur processus, le rendre bien robuste et le déployer rapidement au-delà des trois patrimoines pilotes.
Edmond n’est disponible que quelques semaines et n’est pas un spécialiste du DevOps. En revanche, il connait parfaitement le monde informatique, ce qui va l’aider dans ses échanges avec l’équipe, et il sait comment transformer une intention en un flux de problèmes à régler. Voici le fil de son coaching :
| Les objectifs d’Edmond | Les activités avec les équipes d’André |
| Construire un management visuel du projet « DevOps » afin de rendre les difficultés explicites et de les révéler au fil de l’eau.
Point clé : l’équipe DevOps doit se sentir parfaitement à son aise avec l’outil pour le faire vivre dans les mois à venir. Edmond est donc vigilant à cadrer la réflexion et à laisser toute latitude à l’équipe sur la construction elle-même. |
Edmond organise un atelier avec l’équipe DevOps et les contributeurs importants du processus, tels que les administrateurs des bases de données, le responsable de la sécurité informatique, les gestionnaires de flux, etc…
Cet atelier leur permet de construire notamment une représentation visuelle de leur produit cible (interface utilisateur, composants techniques, flux de données). Les participants conduisent ensuite une analyse critique de l’existant pour identifier les points d’écart avec la cible. Certains de ces points sont traduits en action, car ils savent comment les traiter. Et d’autres en « problèmes », qui sont des sujets à explorer. |
| Développer la collaboration par la pratique de routines collectives, autour du visuel.
Point clé : sanctuariser les moments de discussion et ne parler que des sujets qu’on maîtrise mal. Regarder ensemble un dessin, en discuter, le manipuler est bien plus explicite que de s’envoyer de longs mails techniques et souvent confus. Bien plus sympa aussi. |
Edmond propose de choisir des moments d’échanges autour du visuel. Certains sont dédiés à l’équipe DevOps, d’autres sont ouverts à tous les contributeurs.
Il prend le temps de co-animer les premières réunions pour qu’elles soient intéressantes pour tous. Cela sécurisera la participation future. Par exemple, il demande à chacun de mettre à jour le visuel avant la réunion. Le temps utilisé à dire « j’ai fait ci, j’ai fait ça » n’a plus lieu d’être. On peut focaliser tout de suite l’attention sur les sujets qui nécessitent échanges et réflexions ultérieures. |
| Transmettre la détermination à traiter tous les points difficiles et les bonnes méthodes pour réussir.
Point clé : ne jamais mettre un sujet sous le tapis. Oui, cela prend du temps de le traiter et personne n’est riche de temps. Ceci dit, ce sera tellement plus couteux de se débattre avec les conséquences de la non décision plus tard… |
Edmond a mis dans le management visuel des « marqueurs » qui vont rendre évidents les problèmes de qualité, de coordination, de délai, etc…
Dès que ces marqueurs s’activent, il va proposer aux personnes concernées de pratiquer le PDCA (Plan Do Check Act), une méthode rigoureuse issue du monde de la recherche scientifique, qui permet d’explorer un sujet mal maîtrisé jusqu’à le résoudre. Il prend le temps de travailler avec plusieurs groupes, de faire émerger des succès et de les faire partager par l’équipe afin d’ancrer la pratique. |
5 semaines plus tard, l’équipe est remise sur les rails. Sans avoir eu de cours sur le lean IT, l’équipe a mis en place son obeya de projet, son système de juste à temps et d’arrêt au défaut, sa pratique du PDCA. Elle a réussi à obtenir des avancées significatives avec leurs interlocuteurs responsables des bases de données, ce qui a permis aux deux projets pilotes d’atteindre les objectifs fixés. Elle est très confiante sur sa capacité à rendre le processus plus simple et plus robuste. André, le directeur technique, a annoncé à son collègue DSI que le processus allait maintenant pouvoir être déployé sur les 250 patrimoines informatiques dont il a la charge.
Cela prendra encore deux ans mais, comme le dit le poète : « L’avenir n’est que du présent à mettre en marche ».
Better, faster, together 