Shu Ha Ri : Et si Scrum n’était qu’un Kata ?

Faut-il estimer les tâches ? Si l’équipe est dynamique, s’il y a une vision partagée des enjeux, un simple découpage en tâches, bien visualisées peut parfois suffire pour tenir l’engagement. L’estimation importe moins que l’identification, l’organisation, la répartition, la remise en question, …

De même, faut-il estimer les user stories ? Il faut débattre des user stories, les challenger au niveau de l’architecture, des implications.
Maintenant, à quoi sert le chiffre de la vélocité si l’on est capable d’avoir des user stories en gros de même taille ? On peut se contenter alors de compter le nombre de user stories par sprint.

Les gens du business ont rarement la dispo que l’on attend d’un scrum master.
Parfois la connaissance du métier est plus dans l’équipe qu’en eux.
On crée des relais vers LE product owner, des intermédiaires et le travail crucial de négociation entre besoin et solution est dilué, éclaté et inéfficace.
A l’inverse des binômes technique / métier peuvent parfois porter les sujets beaucoup plus efficacement, quitte à ce que cela soit supervisé et arbitré par un lead business.
Alors pourquoi ce passage obligé unique ? Est-ce que cela ne serait pas une matérialisation organisationnelle d’un enjeu (la cohérence fonctionnelle) qui peut être traité différemment ?
Je peux comprendre qu’il soit nécessaire d’avoir un interlocuteur unique pour chaque sujet, mais pourquoi toujours le même d’un sujet à l’autre ?

Et puis pourquoi faut-il un Scrum Master si l’équipe est convaincue de la nécessité d’être agile ?
Pourquoi confier les tâches administratives toujours à la même personne ?
Pourquoi incarner en une personne ce que l’équipe devrait assumer d’elle même, la privant même de l’occasion de l’assumer ?
Pourquoi pas un Scrum Master tournant, à supposer que l’information circule bien pour une action dans la durée.

Et puis d’abord pourquoi faut-il des sprints ?
Pourquoi pas une démo tous les mois, avec des rétros toutes les 2 semaines, et une présentation des User Stories chaque semaine ?
J’imagine que c’est psychologique : imposer une durée fixe pour être sûr d’avoir des démos régulières. Mais n’est-ce pas un peu ridicule de se retrancher derrière des règles immuable pour matérialiser un enjeu (le feedback et la transparence) qui peuvent être traités différemment.

Toute la panoplie Scrum, vendue par le coach en début de projet, déployée par le Scrum Master.
Quand ça va bien, ce déploiement est challengé par l’équipe, des contre propositions émergent.
Kanban apporte une approche plus continue dans l’introduction des pratiques.
Il ne s’agit pas de Scrum-But, mais de Not-All-At-First

Et donc il y a des fois ou je me demande si Scrum n’est pas un peu comme un kata : on le répète consciencieusement pour s’approprier les techniques, mais on sait bien que le kata n’est pas réaliste.
Personne ne prendrait au pied de la lettre les symboles et simplifications pédagogiques.
Personne n’irait dérouler un kata tel quel dans un combat de rue.

L’estimation pour apprendre à gérer ses tâches et ses User Stories
Le product owner pour mettre en marche la machine à négocier besoin et solution.
Le scrum master pour mettre en marche la responsabilité de l’équipe.
Les sprints pour insuffler un rythme.

N’oublions juste pas que c’est une forme pédagogique, pas une finalité.

PS: je soupçonne Christophe Addinquy d’une part  (« En finir avec le product owner« ) et la conference « Lean Kanban France 2012 » de m’avoir mis cette idée dans la tête, cette autre lecture du Shu Ha Ri.