L'échelle agile : la question essentielle à se poser
Nous entendons la même chose de la part de presque toutes les grandes entreprises avec lesquelles nous travaillons : « Nous avons besoin d'un framework de mise à l'échelle agile. » Quand 50 développeurs ou plus doivent collaborer ensemble, l'utilisation d'un framework de mise à l'échelle est effectivement avantageuse. Mais une question reste sans réponse. Une hypothèse non formulée, jamais remise en question, plane comme un spectre au-dessus de chaque approche de mise à l'échelle. Avant de poser cette question, examinons d'abord pourquoi il est essentiel d'y répondre.
Développer un produit complexe
Les systèmes complexes sont – de par leur définition même – complexes. Une hypothèse courante est que Divide+Conquer (D+C) est une bonne approche pour résoudre des problèmes complexes : on découpe un grand problème en plusieurs petits, on les répartit et on rassemble ensuite les solutions. Cela semble prometteur.
On peut alors utiliser un framework de mise à l'échelle pour maximiser l'efficacité du D+C.
Commençons par les questions périphériques pour nous rapprocher de la question centrale :
Comment définir le problème ?
Quand on commence à développer un grand produit, on a d'abord un besoin – et on veut créer un produit qui répond à ce besoin. La nature du développement de produit fait que la solution adaptée au besoin n'existe pas encore.
Le problème est-il seulement bien décrit ? Est-il déjà suffisamment clair où les efforts doivent être investis ? Le domaine du défi est-il déjà assez clair pour pouvoir appliquer D+C de manière pertinente ?
Quel est vraiment le problème ?
Quand on organise un développement de produit, on suppose simplement que le besoin est clairement défini et que le reste n'est « que du travail ».
Mais : que se passe-t-il si même la question sur laquelle on a planifié était déjà fausse ? Que se passe-t-il si le plan échoue et qu'on poursuit la mauvaise réponse ? Est-ce que ça aide si plus de personnes travaillent sur les mauvaises choses ?
Où est vraiment le problème ?
L'hypothèse de base de la mise à l'échelle agile : « Le problème principal, c'est qu'il y a plus de travail que ce que peu de personnes peuvent accomplir. » Comme décrit dans un autre article, le problème principal avec beaucoup de travail, c'est que beaucoup de travail génère encore plus de travail ! Il s'agit ici du travail sans valeur ajoutée comme la coordination, le changement de tâches, les réunions et autres activités similaires.
As-tu déjà réfléchi à la proportion de travail à valeur ajoutée sur le produit par rapport au travail sans valeur ajoutée consacré à la gestion des processus dans ton organisation ? Combien de temps tes développeurs passent-ils en coordination à cause de la complexité de vos structures ? Ton focus est-il sur la livraison de produits ou sur le respect des processus ? Que se passe-t-il avec les frais généraux quand tu étends tes processus ? Que devient le temps de développement à valeur ajoutée ?
Le problème est-il vraiment si important ?
Avec la mise à l'échelle agile, vous supposez simplement que vous avez besoin de beaucoup de personnes pour construire le produit que vous planifiez. La question suivante est alors de savoir comment organiser ces personnes de manière optimale.
Saviez-vous que Google a été développé par deux personnes durant ses premières années ? Et Facebook par une seule ?
Votre produit est-il vraiment si grand qu'il éclipse Google et Facebook ? Allez-vous vraiment gagner des billions avec ? Votre compréhension et votre approche sont-elles réellement optimales ?
Est-ce que plus c'est vraiment mieux ?
Le livre « The mythical man-month », écrit il y a plus de 40 ans par Frederick P. Brooks, a depuis longtemps réfuté l'idée selon laquelle « plus il y a de personnes qui travaillent sur un produit, plus vite il sera terminé ». Pourtant, aujourd'hui encore, beaucoup d'entreprises croient que la « mise à l'échelle Agile » est la solution au « mois-homme mythique ». Comme mentionné précédemment, de grands produits ont été développés par peu de personnes – et plus de personnes créent certes plus de travail, mais pas plus de valeur !
Ne pourrait-on pas trouver une meilleure solution avec moins de développeurs et moins de travail ? Serait-ce vraiment plus lent si moins de personnes étaient impliquées ?
Et c'est ainsi qu'après tant de questions, nous arrivons à la question centrale cruciale :
La « mise à l'échelle agile » est-elle vraiment nécessaire ?
Réfléchissez aux points suivants :
Les développeurs possèdent-ils les meilleures connaissances à 100% pour fournir une solution ?
Disposent-ils de la meilleure technologie possible à 100% pour résoudre les problèmes ?
Les développeurs se concentrent-ils à 100% sur la livraison de la valeur maximale ?
Chaque activité est-elle à 100% créatrice de valeur ?
Le travail accompli est-il efficace à 100% ?
Lorsque plus de personnes arrivent, ces pourcentages ont tendance à ne pas augmenter. Ils diminuent.
Si on additionne ces pourcentages, le résultat est souvent effrayant. Peut-être avez-vous 10 personnes qui ne peuvent utiliser que 20% de leur potentiel – alors que 3 personnes pouvant exploiter 80% de leur potentiel avanceraient plus vite !
Si 100 développeurs sont limités à 5% de leur potentiel, une seule équipe serait peut-être plus efficace qu'eux tous !
Avez-vous déjà exploité toutes les possibilités pour faire plus avec moins ?
C'est seulement lorsque toutes ces questions ont déjà reçu un « Oui » – qu'alors la réponse à la question centrale est aussi « Oui ». Avant cela, vous allez faire grandir vos problèmes – et non leur solution !
