Suivre la méthode, rater le projet
Vos plannings dérapent, vos deadlines explosent et le périmètre se réduit.
Est-ce la faute de votre méthode de gestion de projet ?
Non, bien sûr. Chaque méthode a ses forces et son utilité et offre un cadre plus efficace que le développement au fil de l’eau et au doigt mouillé.
Mais toute méthode a deux effets pervers :
La méthode donne souvent un faux sentiment de sécurité
La méthode rassure parce qu’elle rend visible ce qui est facile à mesurer, mais des KPI au vert peuvent masquer un projet qui va dans le mur :
- vélocité stable mais dette technique qui explose
- cérémonies Scrum impeccables mais équipe démoralisée
- burndown correct mais plus personne ne croit à la date
Elle rassure parce qu’elle fournit des garde-fous pour les principaux risques.
Mais respecter les rituels ne garantit pas l’avancement : on peut tenir des daily où l’on contourne les vrais blocages, ou des rétrospectives dont rien ne sort.
Elle rassure enfin, parce qu’elle marche pour “les autres”.
La méthode rigidifie le travail
Aucune méthode n’est gratuite : trop détaillée elle finit par ralentir, trop légère elle finit par laisser passer l’essentiel. Dans les deux cas, le projet paie la note.
Les méthodes peinent à s’adapter aux changements de contexte.
Un même rituel n’a pas le même objectif selon que le projet explore, exécute ou survit. En phase d’exploration, il faut surtout réduire l’incertitude. En phase d’exécution, il faut synchroniser. En phase de crise, il faut arbitrer vite et rétablir la lucidité.
La rigidité augmente encore quand la méthode cesse d’être un support de décision pour devenir un objet de conformité. Quand l’équipe cherche moins à résoudre le problème qu’à montrer qu’elle a respecté le cadre.
Par exemple quand on exécute un rituel plutôt qu’affronter le blocage, ou quand on remplit le board plutôt que traiter l’incertitude.
Le paradoxe de la méthode
Une méthode reste nécessaire pour faire émerger un peu d’ordre du chaos. Sans elle, on ne pilote pas : on réagit.
Les méthodes sont nécessaires, mais pas suffisantes pour exceller.
Le vrai sujet n’est donc pas seulement la qualité de la méthode, mais la maturité de celui qui l’applique.
La progression pour atteindre cette maturité a été formulée depuis longtemps dans d’autres disciplines. Les arts martiaux en donnent une expression particulièrement juste
Comme le disait mon maître, plein de sagesse et de bon sens, en me remettant ma ceinture noire :
- “N’oublie jamais qu’une Ceinture Noire, ça ne sert qu’à fermer ton kimono”
- “Tu as appris les techniques, tu les as intégrées, maintenant tu dois apprendre à t’en libérer”
Je crois que l’humilité est un principe universel qui devrait s’appliquer un peu plus dans tous les domaines, en particulier dans l’informatique.
Mais c’est cette dernière phrase dont je vais vous parler.
En japonais elle se dit Shu-Ha-Ri (守破離).
Shu-Ha-Ri : la voie vers la maîtrise
Shu: Dont on traduit souvent le sens par “Suivre la technique”Ha: Qu’on associe à “Modifier/intégrer la technique”Ri: Qu’on interprète comme “(Se) libérer (de) la technique”
L’idée est simple : Le chemin vers la maîtrise passe par trois étapes; apprendre la méthode, puis se l’approprier pour enfin s’en libérer.
Une méthode peut échouer parce qu’elle est mal appliquée, modifiée trop tôt, ou devenue inadaptée au contexte. Confondre ces trois cas empêche tout progrès : on accuse la méthode quand le problème est dans l’exécution, ou l’on invoque “l’agilité” pour justifier une dérive qui n’est qu’un relâchement.
Le Shu-Ha-Ri permet de distinguer trois échecs très différents :
- Les équipes qui appliquent mal la méthode (pas assez de
Shu) - les équipes qui restent bloquées à l’application rigide de la méthode et à la défense de l’orthodoxie (trop de
Shu) - Les équipes qui la déforment en voulant la modifier avant de l’appliquer correctement et de la comprendre (Mauvais
Ha)
Maîtriser le pilotage, c’est s’approprier le fond de la méthode pour en adapter la forme sans en perdre les bénéfices.
Suivre la méthode même quand c’est difficile mais la changer quand il le faut n’est pas chose facile. Résister à la pression des clients, des donneurs d’ordre, des délais mais aussi à l’inertie de l’habitude demande beaucoup de clarté et un peu d’expérience.
Notre modification de la méthode améliore-t-elle les choses sans rien sacrifier ? Où est-ce juste une concession à un manque, une déficience ou une exigence que vous ne pouvez satisfaire ?
Est-ce que cette adaptation reste fidèle aux principes de la méthode ? Et a-t-elle réellement prouvé sa valeur ?
La maîtrise, ce n’est pas juste mieux appliquer la méthode ; c’est savoir quand la suivre, quand l’adapter, et quand cesser de s’y accrocher.
Comment appliquer Shu-Ha-Ri ?
Prenons Scrum.
En Shu, l’équipe applique Scrum réellement, parce qu’elle n’a pas encore assez de recul pour savoir ce qu’elle peut retirer sans se mettre en danger.
En Ha, elle adapte la forme sans sacrifier la fonction : raccourcir un rituel, oui ; perdre la synchronisation, l’apprentissage ou la clarification, non.
En Ri, elle ne cherche plus à ressembler à Scrum, mais à servir lucidement les besoins du projet.
Vous vous en doutez, le point clé est le passage du Shu au Ha, ce n’est pas une histoire de durée. C’est une histoire de compréhension. Pas une compréhension intellectuelle, érudite de la méthode, mais une compréhension opérationnelle et systémique.
On ne passe pas du Shu au Ha quand la méthode devient inconfortable, mais quand on comprend assez bien ce qu’elle protège pour pouvoir adapter sa forme sans détruire sa fonction.
Attention à ne pas appeler « adaptation » ce qui n’est qu’impatience ou relâchement. Supprimer une rétrospective faute de temps n’est pas du Ha : c’est renoncer à l’apprentissage au moment où on en a le plus besoin.
Conclusion
La ceinture noire ne ferme que le kimono. Scrum, Kanban, PRINCE2 ne sont que des ceintures : elles maintiennent une forme, mais ne font pas le maître. La méthode n’est jamais un but, seulement un rappel de principes à intégrer.
La prochaine fois que vous hésiterez à bousculer un rituel, demandez-vous : est-ce que je cherche à protéger la méthode, ou à sauver le projet ? La réponse vous dira si vous êtes encore dans le Shu ou déjà dans le Ha.
