Faciliter l’adoption de l’Agile grâce au «Shu Ha Ri»

Lors de mes deux dernières missions, j’ai participé à l’accompagnement d’une équipe projet pour l’adoption de la méthode Agile. Ce qui m’a frappé dans ces missions c’est que bien que les deux missions soient très semblables (même objectif, même équipe OCTO, même caractéristiques de l’équipe côté client) nous avons pu améliorer significativement le passage de compétence à notre client grâce à l’adoption de la méthode « ShuHa Ri ».

Cet article aura comme objectif d’expliquer le « Shu Ha Ri », d’exposer comment nous l’avons adopté et les bénéfices que nous avons pu en tirer.

Présentation du « Shu Ha Ri »

Le « Shu Ha Ri » est, à l’origine, un concept décrivant les différentes étapes d’apprentissage des arts martiaux. Ce concept a été, par la suite, appliqué dans le cadre de l’approche Lean chez Toyota (« The Toyota Way to Lean Leadership: Achieving and Sustaining Excellence through Leadership Development », Jeffrey Liker, Gary L. Convis).

Le « Shu Ha Ri » est constitué de 3 étapes par lesquels un novice doit passer pour acquérir une compétence ou maîtriser une technique:

  • Shu : le disciple apprend les fondamentaux en suivant les règles édictées par le maître
  • Ha : ayant maîtrisé les fondamentaux, le disciple applique les règles en les questionnant, en comprenant leurs subtilités et en cherchant les exceptions
  • Ri : le disciple ayant maîtrisé les règles, peut les transcender et les adapter

Chez notre client, nous avons eu recours avec succès au modèle du « Shu Ha Ri » afin de structurer notre mission d’accompagnement et le passage des compétences agiles à l’équipe projet. Nous avons opté pour ce modèle car il est simple et qu’il a fait ses preuves chez Toyota. Nous allons détailler dans la suite comment nous avons procédé.

Application du « Shu Ha Ri » en mission

Avant de montrer l’apport du « Shu Ha Ri », nous allons donner des éléments de contexte sur les deux missions pris en exemple. La première a été conduite sans l’approche « Shu Ha Ri » et la deuxième avec.

Points communs entre les deux missions

Les deux missions considérées sont très semblables :

  • Même contexte client : PME du secteur assurance
  • Même typologie de projet : projet de refonte en technologie Web d’une application Mainframe
  • Même équipe OCTO (mêmes personnes !)
  • Même dispositif côté client
  • Neutralité des équipes projet du client par rapport à l’Agile : elles n’étaient pas réfractaires mais en attente de résultats sur l’apport de la méthode
  • Même objectif de mission : accompagner une équipe projet à monter en compétence sur la méthodologie Agile
  • Même durée de mission : 6 mois

Différences entre les deux missions

La différence majeure entre les deux projets consistait dans l’approche d’accompagnement que nous avions adopté

Approche sans le « Shu Ha Ri »

Dans le premier projet, nous avions convenu avec le client de positionner les membres de son équipe dans les postes de décision en accompagnant chacun d’un consultant OCTO pour l’assister et le coacher. Par exemple

  • Responsable projet : 1 membre de l’équipe client + 1 assistant côté OCTO
  • Product Owner : 1 membre de l’équipe client + 1 assistant côté OCTO
  • Tech lead : 1 membre de l’équipe client + 1 assistant côté OCTO

Dans cette configuration, c’est l’équipe du client qui porte la responsabilité des résultats du projet dès le début.

Approche avec le « Shu Ha Ri »

Dans le deuxième projet, nous avions réussi à convaincre le client de procéder de manière incrémentale en planifiant 3 livraisons de l’application espacée entre-elles de 3 mois. Par la suite, nous avions convenu avec lui de procéder comme suit :

  • Pour la première livraison, (phase du « Shu »), les experts agilistes (consultants OCTO) sont les décisionnaires du projet (pilotage du projet, arbitrages fonctionnels, arbitrages techniques) et les apprentis agilistes (équipe du client) se conforment aux décisions des experts. Par conséquent, c’est l’équipe OCTO qui porte la responsabilité des résultats de cette première livraison.
    • Exemple : étant dans l’équipe MOA, dans cette phase j’étais responsable de l’organisation de l’équipe, de l’organisation et de l’animation des rituels MOA, de la bonne livraison des User Stories, des tests et des écrans
  • Pour la deuxième livraison, (phase du « Ha »), les experts agilistes cèdent leurs rôles de décisionnaires au profit des apprentis agilistes. Par la suite, les experts agilistes se positionnent plus en tant qu’assistants pour aider les apprentis dans leurs tâches et les conseiller. D’où, la responsabilité des résultats de cette deuxième livraison revient à l’équipe du client.
    • Exemple : étant dans l’équipe MOA, dans cette phase, j’ai créé une liste des tâches MOA à réaliser et nous avons distribué les différentes tâches aux membres de l’équipe MOA du client. Pour ma part, je n’étais responsable d’aucune tâche. Par contre, je continuais à participer aux tâches de spécifications, je levais les alertes lorsque c’était nécessaire et j’intervenais lorsque quelqu’un me demandait de l’aider.
  • Dans la troisième et dernière phase (le « Ri »), les consultants quittent le projet pour laisser l’équipe client gérer seule son projet.

Apport de la méthode « Shu Ha Ri »

Au cours de la mission d’accompagnement sans le « Shu Ha Ri », un effet pervers a rendu le passage de compétence particulièrement ardu. En effet, étant soumis à la pression de résultats pour le projet, les apprentis agilistes (équipe du client) avaient tendance à s’accrocher aux modèles et aux méthodes qu’ils connaissent le mieux et qu’ils maîtrisent pour se rassurer sur le résultat final (ce qui est tout à fait naturel!). Par conséquent, à chaque fois que nous essayions d’introduire une pratique agile, il s’en est suivi des discussions sans fin où l’expert agiliste (consultant OCTO) devait convaincre du bénéfice d’une telle pratique pour le projet. Ce qui rend la tâche compliquée c’est que, pour l’apprenti agiliste, le bénéfice est théorique dans le sens où c’est une promesse alors qu’il a besoin de certitude et de résultats immédiats. Par conséquent, pour pouvoir avancer, l’expert agiliste était obligé de chercher un compromis en tordant la pratique agile (ce qui est loin d’être bénéfique !)

Exemple : nous avons perdu beaucoup de temps et d’énergie à convaincre le Product Owner et le Tech lead du client des bienfaits de la spécification et du développement en mode incrémental (commencer par des choses simples et complexifier au fur et à mesure en « refactorant » le code si nécessaire). En effet, ils étaient habitués à la logique des projets en cascade où il faut tout spécifier et prévoir avant de commencer le moindre développement. De plus, ils avaient des difficultés à accepter de mettre en production l’application sans toutes les fonctionnalités (vitales et confortables). En réalité, ils craignaient la réaction des utilisateurs et il était difficile de les rassurer sur ces aspects. Par conséquent, le Product Owner client cherchait toujours à créer des User Stories trop grosses en espérant embarquer le maximum en développement ce dont les développeurs se plaignaient régulièrement.

Quant au projet avec le « Shu Ha Ri », l’effet pervers cité précédemment a été neutralisé. En effet, dans la phase du « Shu », les porteurs de la responsabilité du projet sont les experts agililistes et c’est à eux de décider quels éléments mettre en place pour assurer la réussite du projet. Par conséquent, les apprentis agilistes ont moins de pression et ils ont le temps d’observer et de comprendre la mécanique et les valeurs de l’Agile. De plus, ils peuvent constater concrètement comment avec les pratiques de l’Agile il est possible de livrer et d’atteindre la satisfaction desutilisateurs.

Exemple : dans notre projet, après la 1ère livraison de l’application, le responsable du projet côté client a été étonné de constater que les utilisateurs étaient satisfaits du résultat même si nous n’avions pas pu livrer tout ce qui était prévu initialement. Effectivement, les utilisateurs étaient contents de pouvoir utiliser certaines fonctionnalités vitales pour eux au bout de 3 mois seulement et étaient confiants dans notre capacité à leur livrer d’autres dans les 3 mois suivants.

Par la suite, grâce à cette première réussite, les apprentis agilistes étaient convaincus de l’efficacité de la méthode Agile et avaient plus confiance pour abandonner leurs anciennes pratiques au profit de celles de l’Agile. Ceci a grandement augmenté l’efficacité de la phase du« Ha ». En effet, l’équipe OCTO a constaté une grande rigueur dans l’application des principes et des outils utilisés dans l’étape du « Shu ». De plus, l’équipe client commençait à vouloir pousser le modèle pour voir ses limites et proposer des améliorations du processus. Bien évidemment, l’équipe OCTO restait présente pour répondre aux interrogations, apporter son aide et lever des alertes si nécessaire.

Exemple : l’équipe de développement commençait à bien maîtriser ses cycles de développement (itérations) et se demandait si le passage à un mode de développement au fil de l’eau ne serait pas plus productif. Cette question intéressait le responsable projet du côté client et nous avons décidé de l’étudier ensemble pour en mesurer les bénéfices et les inconvénients par rapport au contexte et aux contraintes du projet.

Au final, la phase du « Ri » va bientôt avoir lieu et tout le monde est confiant dans son succès.

Conclusion

A travers les deux expériences que je viens de décrire, j’ai été séduit et convaincu par la méthode « Shu Ha Ri ». Personnellement je vais y avoir recours pour tous les cas nécessitant un passage de compétence (en étant l’apprenti ou l’expert). Je vous encourage vivement à l’expérimenter (même dans un cadre personnel) pour en constater les bénéfices.

Suggestion d’articles :

  1. Open Space « La Pilule Rouge – Comment faciliter la collaboration distante dans nos organisations ? »
  2. « Behavior Driven Development » grâce au pattern MVVM et GreenPepper
  3. Ne craignez plus l’effet démo