Le Shu Ha Ri(*) est constitué de 3 étapes par lesquels un novice doit passer pour acquérir une compétence ou maitriser 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
Le Shu Ha Ri c’est très bien. Mais il ne faut pas confondre, apprentissage et respect des règles édictées par le maître et dogmatisme. Même pendant le Shu, n’oubliez jamais votre bon sens et votre droit de douter !
(1) Source de la définition du Shu Ha Ri : https://blog.octo.com/faciliter-ladoption-de-lagile-grace-au-shu-ha-ri/
De ce que je comprends dans le Shu Ha Ri, je suis d’accord avec ce que tu dis : « Même pendant le « Shu », n’oubliez jamais votre bon sens et votre droit de douter ! » Par contre, pour moi, dans cette phase comme dans les autres, douter revient à « remettre en question », et pas « aller contre ». C’est à dire qu’avant « d’aller contre » une règle (dans ton exemple le PO à la team retro), il faut remettre cette règle en question en se demandant « pourquoi cette règle existe ? ».
J’ai eu ce soucis avec le PO intervenant au Daily Scrum. Scrum, by the book, l’en empêche (sauf à la demande de l’équipe de dev), il faut se demander : « pourquoi ? ».
Oui, tout à fait d’accord avec toi. C’est ce que j’appelle « le bon sens ». Les guides sont là pour nous guider. Les règles ont été écrites pour une bonne raison. Les appliquer donnent un très bon résultat si elles sont toutes appliquées dans leur intégralité. Hors, lorsqu’on n’est pas 100% conforme au guide, il est dommage d’être rigide sur une règle, alors que les autres règles ne sont pas appliquées (pour diverses raisons). Le secret, c’est de se poser la question « pourquoi? » comme tu le dis et de suivre ensuite son bon sens.
D’ailleurs, pour la petite histoire, même si l’extrait du « Guide Less » écrit bien ceci : « The Product Owner does not attend the team-specific meetings: Sprint Planning Two, Daily Scrums, team PBRs, team Retrospectives ». Quand on fouille dans le « Guide LeSS », il est aussi écrit que c’est uniquement pour protéger le PO pour lui éviter de passer sa journée à assister à tous les rituels de toutes les équipes, puisqu’en LeSS, on a qu’un seul PO pour 2 à 8 équipes. Il est aussi écrit que le PO fait parti des Scrum Team, et chaque membre de la Scrum Team est le bienvenue dans tous les rituels de la Scrum Team, dont la rétro.