Le thread de Max m’a donné envie de rappeler quelques trucs que j’applique en Scrum. Déjà que la réponse de @juliendorra “Design the design process” est la base : Scrum inclut aussi un méta process (basé sur la rétrospective, la DOD…) qui peut très bien mener à décider… d’abandonner Scrum.

Scrum est anti-agile. Le must est Kanban. Mais Scrum permet de protéger l’équipe contre une domination du produit sur la technique, en négociant des périmètres, toutes les deux semaines. Scrum doit protéger l’équipe technique en injectant un peu d’opacité, le temps, d’une part, que la confiance se crée avec le produit, et, d’autres part, que ses propres membres s’alignent en termes d’objectifs internes.

L’opacité est l’objectif de Scrum, pour protéger les parties, chacun pouvant de tromper sans qu’on le lui reproche. Dans ce sens, j’ai trouvé que Scrum reste la moins mauvaise manière d’embrasser l’agilité dans une organisation pétrifiée dans ses rapports de force.

Scrum introduit des freins, des traitements en batch, de l’opacité (10 jours avant de pouvoir changer d’avis, 10 jours avant d’avoir du feedback : en 2000 c’était souvent peu ; en 2020 c’est parfois beaucoup). Mais ça permet à une nouvelle équipe de se connaître avant d’aller vers Kanban. Après, comme il suffit d’une nouvelle personne pour devoir tout recommencer, avec un peu de turn-over on est obligé de stagner à Scrum.

J’ai appris de @davidhussman que sa loi (la Dude’s law), privilégier le pourquoi du comment, s’applique quand on définit un process, quand on accompagne une équipe. Mais pour celleux qui n’en sont pas capables, quelques “comment”.

  • Le Scrum master est garant de la résilience de l’organisation. Cela passe par défendre la réduction de la “dette technique” (ou l’investissement technologique).
  • Le PO doit être le plus en retrait possible pendant les daily, se taire, ou, à la rigueur si l’équipe est d’accord, répondre aux questions quand ça ne nécessite pas plus de trois mots.
  • Le PO ne doit pas être le manager des devs.
  • Les estimations peuvent être un outil pendant le sprint planning pour s’assurer que tout le monde voit la même chose derrière une US, et que l’US est suffisamment petite. Mais on les jette après.
  • Jira ne doit pas chercher à modéliser le processus réel (ça le figerait), encore moins pour en déduire des KPI pour le management, mais peut aider l’équipe à activer et visualiser le flux, surtout quand on est à distance. Et à chatter sur les US (c’est mieux que Slack ;)).
  • Le sprint planning doit être rapide, c’est un lieu où l’on valide ensemble quelque chose qui aura été préparé en amont avec des “refinements”, des “POC”, des “tri-amigos”. La seule chose qu’on pourrait découvrir en sprint planning c’est ce qui a été remonté juste avant en démo.
  • Mettre en prod avant la revue, c’est mettre en prod désactivé. Et là c’est un niveau de maturité qui mériterait d’évaluer la pertinence de passer en Kanban :).

Scrum est là pour rendre objectif et négociable la tension produit/technique, CT/LT ; mais s’il permet de structurer une relation de domination manager/dev, expertise métier/expertise technique, c’est juste que vous voulez tout changer pour que surtout rien ne change.