Scrum à la Rescousse 🕳 🚑

Merci Cédric Crevier pour ta contribution à cette conversation sur DT et PO !

Face au faux-dilemme “livrer des stories vs résorber de la dette” tu suggères (et je suis 💯 👍) de suivre Scrum, notamment les prérogatives propres à chaque rôle.

Un PO n’a pas à dire s’il faut refactorer ou non 🔑

Scrum ne définit pas précisément ce que les développeurs doivent faire dans le détail (rien sur le refactoring dans le guide Scrum, à ma connaissance) mais leurs responsabilités incluent le fait d’instiller la qualité en adhérant à une “Definition of Done”, et de se rendre mutuellement des comptes en tant que professionnels.

Ce n’est pas dans le rôle du PO de fixer ou d’altérer les standards de qualité interne que les développeurs appliquent, et donc pas dans son rôle non plus de dire s’il faut refactorer ou non.

Il doit fixer le Cap, si les devs estiment qu’il y a besoin de refactorer pour atteindre l’objectif du Sprint alors il faut refactorer 🔑

💯 D’accord ! Comme dit Kent Beck : First make the change easy, then make the easy change.

💯 Le PO doit fixer le cap : il a pour responsabilités de maximiser la valeur du produit réalisé, de définir et prioriser ce qui doit y être ajouté, et de diffuser le backlog.

Les règles de Scrum sont simples, et c’est peut être pour cela qu’elles sont parfois difficiles à appliquer dans les entreprises compliquées. Elles sont basées sur les principes de transparence, d’inspection et d’adaptation.

La présence de dette dans le code de l’entreprise montre que ces principes n’ont pas toujours été appliqués, au moins jusqu’à aujourd’hui, jour du sprint planning, où le besoin de désendetter se trouve en butte au pilotage fonctionnel du projet.

En effet, si on appliquait toujours au mieux la transparence, l’inspection et l’adaptation, la DT se résorberait presqu’aussitôt créée, à mesure de la progression de l’équipe sur les stories : il suffirait d’ajouter des règles de qualité de code à la DoD, puis de relire ensemble le code, pour se prémunir contre la DT — au moins pour ce qui concerne les gros emprunts.

🚯 Sans jeter Scrum aux orties, ni même le mettre de côté pour toujours, je propose qu’on lise la situation dans l’entreprise telle qu’elle est et non telle que le guide Scrum la voit.

L’entreprise compliquée tire sa culture de modèles qui ont précédé Scrum et qui à mon avis pourraient lui survivre. 🏭 🧬

Dans l’entreprise compliquée :

• le PO ne fait pas partie de l’équipe, il est en face de l’équipe (de développeurs)
• la lecture de code ensemble (afin d’appliquer la DoD) est vue par beaucoup comme une perte de temps
• le Backlog Produit devient la liste des tâches des développeurs; leur activité y est est consignée et tracée (yes, why ? 🤷‍♂️)
• le PO fixe le cap et s’il estime qu’il y a besoin de ne pas refactorer afin d’atteindre l’objectif du Sprint alors il ne va pas se priver de le dire.

Scrum 🪄 …not.

publié sur LinkedIn le 16/03/2023