Scrum ne serait plus une méthode Agile ?

La page "Scrum Méthode" de Wikipédia a été renommée "Scrum Outil". Au-delà de la linguistique, c’est un tournant pour ceux qui pensaient avoir à faire à une méthode Agile de développement informatique.

Plusieurs des changements intervenus au sein de la page "Scrum Méthode" de Wikipédia sont très récents et parfois déroutants. Au début, j’ai pensé à un "sabotage" non encore détecté. En observant la page de discussion (où j’étais intervenu il y a bien longtemps), et surtout l’historique des modifications, je me suis rendu compte que ce n’était pas le cas, mais que cela devait certainement être l’opinion de la Scrum Alliance France et/ou de l’Agile Alliance France (c’est généralement les mêmes), dont les principaux membres semblent être les contributeurs du nouvel article dépossédant Scrum de son qualificatif de "méthode Agile" pour le positionner à un niveau supérieur du changement organisationnel. Par contre, "la couleur" est désormais clairement annoncée : "Scrum est un schéma d’organisation …", et là, il devient évident que nous avons à faire à un puissant outil de remise en question organisationnelle, comme je le faisais déjà remarquer dans la chronique  intitulée "Le Product Owner, la Team et le ScrumMaster". Décidément cette nouvelle approche du changement va finir par me plaire.

J’ai listé ici les quatre points qui m’ont semblé les plus étonnants (ou revêtant une certaine  importance pour moi), même s’ils sont parfois "de principe".

1 – Dans le descriptif initial

"Scrum est considéré comme un cadre méthodologique et non à proprement parler comme une méthode agile" et  "Scrum n'ayant pas une portée technique il convient de l'associer à des méthodes de développement…"

Cette reconnaissance, qui pour moi allait de soi, et qui était la principale raison de ma proposition PUMA (Processus urbanisant les Méthodes Agiles), m’avait pourtant valu bien des critiques et des polémiques depuis 2002.

2 – Dans l’historique

"En 1995, Ken Schwaber (en) présente une courte communication décrivant les fondements de ce qui deviendra la méthode scrum à l'OOPSLA, à Austin, aux États-Unis. En 2001, Ken Schwaber fait équipe avec Mike Beedle pour décrire la méthode dans le livre Agile Software Development With Scrum."

La courte communication ressemblant à un sommaire d’une ou deux pages et présenté en 1995 n’est donc plus considérée comme la description opérationnelle  de la méthode. Sa date de diffusion étant alors officiellement devenue 2001.

3 – Pour tous les aspects de la mise en œuvre

L’ensemble des descriptifs (Acteurs, Cérémonials, Documents) est totalement francisé. C’est le point le plus impactant pour les organisations devant se trouver un style de communication, d’intégration, ou ayant déjà opté pour un franglais. choquant pour beaucoup de francophones.

Je m’étonne juste de la notion (pour le moment conservée) de BurnDown chart. Non pas à cause la langue anglaise, mais pour le fait que de nos jours, ce serait plutôt le principe du Burn-Up Chart (graphique d’avancement du produit) qui serait privilégié.

4 – Pour les aspects Incrémental, Itératif et Adaptatif déterminants, de l’Agilité

"Chaque sprint constitue donc un incrément, facilitant le pilotage du projet. La notion d'itération couvre l'adaptabilité au quotidien. Cette adaptabilité est limitée par le but immuable d'un sprint."

Cette parfaite intégration de concepts dans une seule phrase (je n’aurais pu faire mieux), explique parfaitement ce qui a conduit au point 1, et donne aussi une description  précise de la notion d’Itération telle que Scrum l’autorise (modifications mineures au quotidien). On notera aussi la limite évidente de la possibilité d’adaptabilité dans l’interdiction d’accepter des changements conséquents du contenu d’un sprint, et par la même des éléments déjà produits, sans remise en question de ce sprint et éventuellement du contrat projet.

Les différences entre Incrémental et Itératif ne sont pas triviales. Jeff Patton avait en son temps pris conscience que les notions de contrôle de projet dépendait uniquement de l’Incrémental et que l’Itératif se rapportait  à l’affinement du besoin applicatif  (bien que ces deux problématiques soient liées dans la méthode XP). Comme les deux termes étaient incompris et utilisés à mauvais escient par une bonne partie des informaticiens, il les représenta dans une métaphore utilisant la Joconde, devenue désormais universelle et incontournable en matière d’agilité.

Je ne sais pour quelle raison, mais certainement en pensant avoir été assez clair, Jeff Patton en est resté là. C’est la raison pour laquelle, je proposais  à l’époque (en le référençant et en respectant intégralement sa pensée), une prolongation et un complément de concept (l’itératif – incrémental). Lequel correspond (officialisé plus tard dans le Scrum Guide) à l’autorisation de modifications mineures dans un Sprint.

Le respect de la quatrième des valeurs Agiles, "L’adaptation au changement", fit alors apparaître la nécessité d’ajouter à l’Incrémental et à l’Itératif le concept d’Adaptatif. À ce point, il faut savoir qu’aucune des méthodes Agiles, même celles acceptant les changements profonds (essentiellement RAD en 1991, XP en 1999  ou Puma en 2009), ne disposaient d’une technique de gestion des modifications "en cours de développement" et des abandons de code "déjà développé". Ce qui était pourtant indispensables à la maîtrise, à la fois du pilotage des aspects charges et délais, en regard de modifications destinées à maintenir l’adéquation du produit avec des exigences métiers en évolution. Ce fut la raison pour laquelle je formalisais en 2009 à la suite de PUMA, une technique en ce sens, nommée "Métrique du changement" qui introduisait les concepts de "livré utile" et de "livré abandonné" dans le graphique d’avancement du projet. Cette métrique est basée sur un "contrat projet" initialement accepté par l’équipe de développement - à la suite du Planning poker (Jeu d’estimation consensuelle de la charge à développer qui permet : de déterminer une productivité, ou vélocité théorique initiale de l’équipe) indispensable à la planification des Sprints.  Il découla de ce concept une explication visuelle reprenant, pour l’enrichir, la métaphore de la Joconde (où un client imposait à Léonard de Vinci d’abandonner une partie du buste déjà peint pour le reprendre intégralement en Picasso).

Pour expliquer cette métrique en synthèse : l’équipe pour respecter son engagement moral, doit livrer le nombre d’unités d’œuvre qu’elle a prévu dans le contrat projet. Ce, même si le contenu a changé en cours de développement, ou après développement (notion de livré abandonné). Ce respect s’exprimant dans un graphe d'avancement et par une simple formule : Livré total = livré utile + livré abandonné. Il y a aussi quelques petites astuces pour récupérer le récupérable, mais cette chronique n’est pas le lieu pour détailler cela. 

Conclusions

Bien évidemment, je n’ai rien à voir avec  tous les changements dans la page Wikipédia, même s’ils correspondent à ma vision depuis longtemps. Ce qui m’étonne le plus, c’est leur production par des membres influents des communautés Scrum et Agile (qui rejoignent ainsi mes thèses, ce qui va par contre assécher la source d’insatisfaction à la base de mes chroniques sur le JDN). 

Pour conclure, je conseillerais à tout un chacun de lire l’article "Scrum Outil" en détail afin de déterminer l’impact de ces changements dans son organisation, si celle-ci souhaite évoluer avec cette approche organisationnelle, couplée bien sûr, à d’autres méthodes de développement de produit.