La matière noire est une matière hypothétique composée de WIMP, que l’humanité n’a jamais vue, qui représenterait 5 fois plus de matière que celle que nous connaissons ;  elle explique des phénomènes astronomiques inexplicables. Ca laisse rêveur mais quel est le lien avec le développement logiciel et le lean management ?

Les équipes projet travaillent sur des objets visibles (appelons les « user stories »), sur des objets observables si l’on s’en donne la peine (les demandes de support et les incidents) et, enfin sur des activités de matière noire. Cette analogie éclairante bien que peu réjouissante a tout de même un côté positif : alors que la matière noire représente 5 fois la masse de la matière visible, les activités de matière noire des équipes projet sont moins nombreuses. Lors de mon dernier gemba, le chiffre flirtait avec les 50 %.

J’avais choisi cette analogie sous le coup de l’inspiration du moment et l’équipe a tout de suite compris en quoi cela reflétait leur réalité. Bien entendu, ces 50 % d’activités dont on ne parle jamais dans les points du matin, les rétrospectives de fin de sprint, les comités de pilotage des projets, ces 50 % donc sont pleinement occupés. Personne ne joue aux cartes ou ne fait la sieste. Un tour de table rapide fait émerger des cycles de relance multiples, des réunions variées, des comptes-rendus, des formations, des plans sur la comète, etc, etc, etc. Aucune des personnes présentes au moment du gemba n’a énoncé y trouver du plaisir.

Cette équipe, donc, déclarait passer 30 % de son temps sur le projet, soit l’équivalent pour chaque personne de 6 jours par mois (30 % de 20 jours ouvrés). Dans une autre entreprise, quelques mois plutôt, nous étions arrivés au chiffre de 5 jours de développement par mois par développeur. On voit que l’ordre de grandeur est le même. Qu’en est-il chez vous ?

Poser le sujet en ces termes, c’est commencer à réfléchir avec le prisme lean : les choses deviennent plus distinctes et amènent des questions nouvelles. Pour accélérer, par exemple, faut-il doubler la taille de l’équipe de dev ? Faisons un petit calcul :

Taille d’équipe multipliée par 2 (disons de 5 à 10 personnes) : 

• nombre de jours de développement disponibles de 5 jours x 5 personnes à 5 jours x 10 personnes, donc on passe de 25 jours à 50 jours de capacité
• de ces 50 jours, je propose de retirer 10 % car une équipe plus grande avec des personnes à  onboarder demande du temps de coordination, le passage d’informations aux nouveaux, etc… Nous arrivons donc à une capacité de 45 jours.

Cette capacité de 45 jours représente un budget de 10 développeurs x 20 jours de rémunération x 500 euros de TJM, soit 100 000 euros par mois ou 2 222 euros par jour de développement (100 000 euros divisés par 45 jours).

L’alternative serait de trouver du temps au sein de la masse noire :

• sur une estimation de 50 % de masse noire, pour équipe de 5 développeurs, nous arrivons à 10 jours par personne, soit 50 jours homme pour l’équipe
• faisons l’hypothèse que l’organisation fasse l’effort de laisser un peu plus de temps aux développeurs pour développer et qu’ils récupèrent chacun 2 jours par mois sur les 10 de matière noire : voici 2 jours x 5 développeurs, soit 10 jours de capacité supplémentaire

20 jours initiaux + 10 jours = 35 jours. Ce n’est pas autant qu’en doublant la taille de l’équipe mais le budget ne bouge pas (50 000 euros par mois) et le coût du jour de développement passe de 2 000 euros à 1 428. C’est un bon début.

Améliorer la qualité

Dans notre modèle, 20 % du temps est consacré au support, soit 4 jours par mois et par développeur, donc 16 jours au total.

• Baisser d’un tiers apporterait 5 jours de plus de capacité à l’équipe, lui permettant d’aller de 35 à 40 jours par mois et d’abaisser le coût du jour de développement à 1 250 euros.

Baisser d’un tiers le temps consacré au support et aux incidents, dans un monde lean, est une cible tout à fait atteignable. Ce que l’expérience à grande échelle confirme d’ailleurs.

Améliorer la productivité

Peut-on gagner de la productivité dans les activités de développement ? La réponse est oui, et il ne faut pas en avoir peur. Voici un exemple de quick win trouvé trente fois : les ordinateurs ne sont pas assez puissants et les développeurs attendent en permanence. Un peu plus de rigueur dans la gestion des branches, des user stories un peu plus précises, un peu de partage de connaissances : les pistes sont nombreuses. Certaines sont plus évidentes et d’autres plus techniques mais je ne connais pas une équipe qui n’apprécie l’exercice.

• Trouver 10 % de productivité est à portée de main.
• Notre équipe a maintenant une capacité équivalente à (40 jours de développement + 10 %), soit 44 jours pour un coût du jour de développement de 1 136 euros.

Pas mal.

Récapitulons de façon synthétique :

Stratégie 1. Doubler la taille de l’équipe

	Nombre de développeurs	Capacité	Surcoût	Coût du jour de développement
avant	5	25		2 000 €
après	10	45	50 k€/mois	2 222 €

Stratégie 2. Faire du lean

	Nombre de développeurs	Capacité	Surcoût	Coût du jour de développement
avant	5	25		2 000 €
réduction de la masse noire	5	35	0	1 429 €
amélioration du support	5	40	0	1 250 €
amélioration de la productivité	5	44	0	1 136 €

Le coût du jour de développement a presque été divisé par 2 (-49 %), c’est bien !

Ce qu’apportent 15 ans de pratique multipliée par 15 coachs, c’est qu’in fine, le moral des équipes s’améliore considérablement. Les collaborateurs se libèrent d’une foule d’irritants. La baisse maitrisée du nombre d’incidents lors des mises en production se traduit par des nuits et des week-ends bien plus sereins. La montée en qualité et en productivité s’obtient pour beaucoup par le développement du craftmanship, très apprécié des collaborateurs. Enfin, les relations s’apaisent.

Faut-il y réfléchir ?

J’ai abordé le sujet sous l’angle du budget et de la qualité de vie au travail. Ces deux points peuvent constituer une vraie motivation pour entamer une démarche dont l’issue sera positive mais qui demandera à plusieurs personnes d’accepter de voir leurs activités différemment.

En ce qui me concerne, la réponse est donc oui car le changement ne m’effraie pas. Mais c’est un point à considérer sérieusement.

Ceci dit, vous pouvez aussi intégrer dans votre réflexion la question suivante : est-il facile de recruter aujourd’hui dans la tech ? La plupart des DSI que je connais y voit l’une des principales incertitudes des années à venir. Donc la solution 1 « doubler la taille de l’équipe » peut s’avérer moins opérationnelle que prévu.

Est-ce que je sais compter ?

C’est une question qui m’est souvent posée car je regarde les chiffres de façon très directe. Je mets l’interrogation plus sur l’effet de la surprise que sur une misogynie sous-jacente qui place les femmes dans la cuisine plutôt que face à excel.

Dans le cas présent, un développeur recruté pour développer dont le TJM est de 500 euros, qui travaille 20 jours par mois et réalise 5 jours de code au total aura donc un coût du jour de développement de 500 € x 20 / 5, soit 2 000 euros.

Par où commencer ?

Je recommanderais volontiers de trouver un bon coach lean et agile mais revenons plutôt à cette idée de matière noire qui nous entoure et que nous ne voyons pas. La première préconisation du lean est de construire un management visuel, un vrai management visuel : celui qui clarifie la situation, montre les problèmes au fil de l’eau et encourage à s’améliorer au fur et à mesure.

Les équipes qui travaillent de façon agile ont des managements visuels et ont l’habitude de s’en servir en groupe. Ils constituent une base de départ mais auront besoin d’être enrichis.

Saurez-vous rendre visible votre matière noire ?

---

Vous souhaitez être accompagnés ou connaître nos offres ? Contactez-nous par email à l’adresse contact at operaepartners point com, par téléphone au 01 40 05 96 88 ou avec le formulaire ci-dessous :