SCRUM est une méthodologie relativement à la mode dans certains secteurs du développement logiciel.

SCRUM est une méthodologie relativement à la mode dans certains secteurs du développement logiciel, en particulier le développement de sites internet.

Souvent présenté comme LA solution à tous les problèmes d’organisation et de productivité par ses promoteurs, il est intéressant de voir si cette méthodologie est universelle ou non.

Qu’est-ce que SCRUM? Pour être rapide, il s’agit d’une méthodologie consistant à :

• Maintenir de manière transparente une liste de demandes d’évolution ou de correction à implémenter pour un produit,
• Exécuter des itérations de développement rapides (30 jours, ou “Sprint”),
• Utiliser 3 types de réunions : réunion d’équipe quotidienne, planification du travail pour un sprint, revue du travail à la fin d’un sprint, et enfin rétrospective du sprint,
• Suivre le progrès du travail à l’aide d’un graphique.

SCRUM identifie aussi différents rôles impliqués dans le développement d’un produit :

• Vous êtes un « cochon » ou un « poulet » (sic), selon que vous appartenez à l’équipe de dévelopement ou non,
• Il y a aussi les utilisateurs, les clients, les vendeurs et les managers comme partout, les clients se devant d’être proches de l’équipe.

Mais ce n’est pas tout : SCRUM propose une liste de règles et de suggestions qu’il est fortement recommandé de suivre :

• Règles concernant la tenue des réunions,
• Auto-organisation des équipes (processus adaptatif), tout en suggérant fortement, par exemple, de placer tout le monde dans le même espace commun (ce qui en soit peut apparaître comme une contradiction, le choix est restreint à la collocation),
• Taille d’une équipe de 7 personnes maximum,
• Avoir recours à un « coach » certifié (ceci est une suggestion)

Les règles constituant la méthodologie SCRUM sont-elles issues d’une étude objective des résultats que cette méthodologie apporte dans la réalité?

D’où ces règles sont-elles issues ? Les règles constituant la méthodologie SCRUM sont-elles issues d’une étude objective des résultats que cette méthodologie apporte dans la réalité? On peut parfois en douter, quand par exemple la taille d’une équipe est limitée par definition à 7 personnes. Pourquoi pas 3, 15, 30 ? En fait, la limite provient de l’approche utilisée par la méthodologie elle-même : difficile en effet d’organiser des réunions de 100 personnes tous les jours pour suivre la progression du travail. On peut parler d’une méthodologie autocontrainte, et non adaptative, faisant abstraction d’études actuelles ou passées sur ce domaine, et omettant de tirer profit des meilleures pratiques dans chaque branche industrielle, en particulier le développement logiciel.

Passons maintenant de la théorie au monde réel. Dans le monde réel, certains facteurs compliquent le succès de la recette miracle :

• Les demandes d’évolution ou de correction proviennent de différents canaux qui ne s’intègrent pas entre eux,
• La capacité de production de l’équipe est insuffisante,
• La production est réalisée par de multiples équipes pouvant être distantes géographiquement,
• La qualité du code est insuffisante, le produit contient trop de défauts,
• Séparation forte des rôles (les développeurs d’un côté, les testeurs d’un autre, les ingénieurs applicatif quelque part, etc.).

Ce type de situations est commun dans le domaine du développement logiciel, soit pour des raisons historiques (le code est trop vieux et doit être ré-architecturé), soit pour des raisons de cout (externalisation dans des pays où les couts de production sont inférieurs), etc. Toute organisation développant du logiciel est un jour confrontée à ce genre de situations.

La nature même de l’organisation SCRUM induit un conflit d’intérêt du à la manière dont elle diffuse la méthodologie.

Le chemin vers une implémentation de SCRUM commence donc souvent par faire appel aux services d’un coach.  Or la nature même de l’organisation SCRUM induit un conflit d’intérêt du à la manière dont elle est diffuse la méthodologie: afin d’être promu dans la hiérarchie de l’organisation SCRUM, le coach, certifié si possible (souvent entendu), cherche en général à obtenir le statut de « change manager » chez l’entreprise cliente, et à implémenter exactement les préceptes de cette méthodologie, afin que son travail soit reconnu comme valide par l’organisation SCRUM. D’où une volonté farouche de réaliser la recette dans une lecture mot à mot de celle-ci, ce qui peut mettre en danger certains choix de l’entreprise, car SCRUM n’adresse pas spécifiquement certains aspects clée d’une organisation, tels que le facteur d’échelle, la qualité, la distribution géographique des équipes.

Un autre exemple consiste à vouloir systématiquement limiter la taille d’une équipe à 7 personnes : quel est l’intérêt d’une telle division si la taille de l’équipe n’est pas un problème en termes de productivité, de qualité et d’ambiance dans l’équipe?

Ce conflit d’intérêt, consistant à promouvoir les préceptes de SCRUM avec une importance supérieure aux objectifs et choix de l’entreprise, pose problème. On s’approche ici d’une vision limitée, détachée des réalités de l’entreprise. Une conception peut-être vouée à la promotion de l’organisation en charge de déployer cette méthodologie dans le monde du travail, et, in fine, à accroitre les revenus des prétendus consultants et inventeurs, qui n’ont objectivement pas apporté grand chose depuis “The New New Product Development Game” paru en 1986.

Un autre exemple de problème majeur avec SCRUM est son absence de solution quand le facteur d’échelle est déterminant :

• Que faire si plusieurs canaux différents enrichissent la liste de demandes d’évolutions pour un seul et même produit ?
• Comment gérer les priorités des demandes émanant de plusieurs canaux ?
• Peut-on réellement effectuer une estimation de l’effort en une seule réunion avant le démarrage d’un « sprint » ?
• Comment gérer les dépendances entre plusieurs équipes ?

Qu’il s’agisse de facteur d’échelle (taille d’une organisation, nombre de canaux générant des demandes, gestion de priorités dans le contexte de capacité de production réduite), de qualité (utilisation de methodes et processus), bref, d’adaptabilité dans un contexte Agile, les solutions proposées par SCRUM sont trés légères. Elles consistent souvent en:

• Une réduction du nombre de demandes d’évolution,
• L’utilisation d’une liste unique de demandes d’évolutions,
• La réduction de la taille des équipes et la collocation dans une même pièce afin de pouvoir suivre le progrès du travail, estimer l’effort au cours d’une réunion unique,
• Le respect du séquençage des réunions: réunion d’estimations après la fin d’un sprint et avant de démarrer le suivant,
• L’utilisation d’une réunion avec des représentants de chaque équipe chaque jour (SCRUM of SCRUM) dans une même salle de réunion.

SCRUM est une méthode qui apporte des réponses simples, pour ne pas dire simplistes, aux problèmes réels qui se posent chaque jour.

On le voit, SCRUM est une méthode qui apporte des réponses simples, pour ne pas dire simplistes, aux problèmes réels qui se posent chaque jour. Globalement, SCRUM prône

• la division, la réduction de taille,
• la collocation en un seul et même espace physique afin de réduire les problèmes de communication,
• la mise en place de sprints courts (30 jours).

Il apparait clairement que SCRUM n’est pas la méthodologie de la rapidité, de l’expansion des capacités de production (limitation de la taille des produits, du nombre de demandeurs d’évolutions), et de la réduction des couts (coachs, pas gestion de la collaboration avec des équipes distantes géographiquement), sans parler de la gestion de qualité qui n’est jamais abordée directement par SCRUM. L’adaptabilité, en particulier aux changements de facteurs d’échelles, n’est pas le propre de SCRUM.

Par ailleurs, un danger consiste à limiter l’univers des possibles en termes psychologiques, en introduisant auprès des membres d’une organisation l’idée réflexe que tout choix non conforme à l’idée SCRUM sera voué à l’échec. Ceci est particulièrement vrai par exemple pour la collaboration avec des membres d’équipes distants : ceux-ci ne pouvant pas assister aux réunions SCRUM, ils sont de fait non intégrés à l’écosystème. SCRUM est une méthodologie adaptative qui restreint les adaptations à tout changement ne la remettant pas en cause.

Or, de nombreuses techniques de management, de gestion de projets, ainsi que de nombreux processus spécifiques apportent des solutions extrêmement efficaces, peu complexes et peu couteuses aux problèmes liés à la gestion du chaos, à la productivité et à la qualité :

• Utilisation d’un flux défini et négocié pour la gestion des demandes d’évolutions,
• Utilisation d’un support digital (intranet, logiciel, lettre d’information) pour assurer la transparence sur le suivi de la progression du travail, des dépendances entre équipes et le suivi de la qualité,
• Définition du cadre de la communication avec les équipes distantes (en négociant par exemple la publication ou l’envoi d’un statut quotidien sur l’activité),
• Utilisation de techniques éprouvées de gestion de cycle de vie de développement (intégration continue)

Il est parfaitement possible de gérer des structures de grande taille en mode Agile, et de bénéficier des apports du paradigme Agile.

En combinant différents types de processus, techniques, idées provenant de différentes méthodologies Agiles ou classiques, il est parfaitement possible de gérer des structures de grande taille en mode Agile, et de bénéficier des apports du paradigme Agile. SCRUM, bien que définie comme étant une méthodologie de bon sens et adaptative, est rigide dans le sens où elle impose des limitations par définition, et fait abstraction de pratiques éprouvées au fil du temps. Les recettes de SCRUM ne fonctionnent bien souvent qu’à petite échelle.

Il est tout aussi intéressant de constater que les adeptes de SCRUM en général, et son “inventeur” en particulier, réalisent petit à petit les limitations fondamentales de cette méthode. Je conseille la lecture de ce compte-rendu de la rencontre annuelle qui s’est tenue à Stockholm en 2008, intitulé “scrum is dead“, où l’on apprend que finalement il est utile de prendre en compte les équipes distantes, et ce n’est qu’un exemple.

Cela met en évidence deux points importants :

• SCRUM est loin d’adresser la complexité des organisations contemporaines, il s’agit d’un cadre minimal,
• SCRUM n’est pas une méthodologie réellement opérationnelle en soi, la méthodologie évoluant très peu au fil du temps (pas d’évolution majeure depuis 1986), elle ne prend pas en compte l’un des fondements de l’agilité, qui est l’approche “holistique” des écosystèmes.