L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

What challenges teams most with Scrum? de Kiron Bondale

https://kbondale.wordpress.com/2022/03/20/what-challenges-teams-most-with-scrum/

L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

La première partie de ce cliché est évidente car le Guide Scrum ne comporte que 11 pages (si vous ne comptez pas la page de titre, l’objectif et la table des matières). Il y a 3 rôles, 3 livrables et 4 événements/cérémonies (cinq si vous incluez les sprints en tant qu’événement, mais je préfère ne pas le faire car l’idée générale d’événements dans des événements me donne la nausée).

La deuxième partie de ce cliché devient apparente une fois que vous essayez d’implémenter Scrum dans un système existant. Ce n’est que dans de très rares cas qu’il est possible d’introduire Scrum sans affecter radicalement la façon de travailler de l’équipe. Ceci, en soi, n’est pas une mauvaise chose car l’amélioration des résultats de livraison implique un certain nombre de changements.

Cependant, la nature immuable de Scrum est l’endroit où les défis se matérialisent. En surface, introduire un nouvel ensemble d’événements ou de livrables ne semble pas trop drastique, mais lorsqu’il s’agit de remplacer les rôles, les livrables et les événements existants par les rôles Scrum, et de les mettre en œuvre tels qu’ils sont destinés à être utilisés, c’est là que les défis émergent.

Compte tenu de mes observations personnelles sur les problèmes d’adoption de Scrum, j’ai pensé qu’il serait utile de sonder un public plus large sur l’aspect de Scrum qui a généré le plus de défis.

Au total, 35 membres de la communauté LinkedIn PMI Project, Program and Portfolio Management ont répondu au sondage avec la répartition suivante des votes :

1. Les événements/cérémonies : 31 %
2. Les rôles : 31 %
3. Les livrables/artefacts : 17 %
4. Le timeboxing de 1 à 4 semaines : 20%

Cela concorde avec ce que j’ai observé.

Bien qu’il puisse y avoir des problèmes de qualité avec les sprints et les arriérés de produits, et que les équipes immatures ne produisent pas toujours un incrément, il ne faut généralement pas trop de temps à la plupart des équipes pour se familiariser avec ces artefacts. De même, bien qu’il puisse être nécessaire d’augmenter la durée du sprint lorsque vous prenez en compte des contraintes du « monde réel » des projets non logiciels, au fil du temps, les équipes s’améliorent pour découper les éléments de travail de sorte que « quelque chose » de valeur puisse être produit en peu de temps.

Les plus grands défis que j’ai vus concernent l’adoption correcte des événements et des rôles Scrum.

Qu’il s’agisse des Daily Scrums qui se transforment en réunions de statut, de rétrospectives de sprint dangereuses psychologiquement, de revues de sprint auxquelles n’assiste aucune partie prenante externe ou de planification de sprint qui prend des jours à compléter, le but et les conditions préalables à la réussite des événements se perdent dans leur mise en œuvre.

Alors que nous voulons tous des Product Owners fantastiques et des équipes « entières » interfonctionnelles, nous nous retrouvons avec des Product Owners qui n’ont aucun pouvoir décisionnel ou pas de temps, et une répartition imprévisible des membres de l’équipe d’un sprint à l’autre.

Aussi, lorsque nous considérons le grand nombre de conditions requises pour permettre à Scrum d’être mis en œuvre tel que conçu, la probabilité qu’elles soient toutes remplies au sein d’une organisation typique est assez faible.

Et c’est pourquoi « Scrumbut » (Scrum mais…) est la valeur par défaut, pas l’exception.

+++++++++++++++++++++++++++

Qu’est-ce que le « Scrumbut » ?

https://www.scrum.org/resources/what-scrumbut

Les ScrumButs sont des raisons pour lesquelles les équipes ne peuvent pas tirer pleinement parti de Scrum pour résoudre leurs problèmes ni tirer pleinement parti du développement de produits à l’aide de Scrum.

Chaque rôle, règle et timebox Scrum est conçu pour fournir les bénéfices souhaités et résoudre les problèmes récurrents prévisibles.

ScrumBut signifie que Scrum a mis en évidence un dysfonctionnement qui contribue au problème, mais qui est trop difficile à résoudre.

Un ScrumBut conserve le problème tout en modifiant Scrum pour le rendre invisible afin que le dysfonctionnement ne soit plus une épine dans le pied de l’équipe.

Un ScrumBut a une syntaxe particulière : (ScrumBut)(Raison)(Contournement)

Exemples de ScrumBut

• « (Nous utilisons Scrum, mais) (avoir un Daily Scrum tous les jours génère trop de frais) (donc nous n’en avons qu’un par semaine.) »
• « (Nous utilisons Scrum, mais) (Les rétrospectives sont une perte de temps) (donc nous ne les faisons pas.) »
• « (Nous utilisons Scrum, mais) (nous ne pouvons pas créer une fonctionnalité en un mois) (donc nos Sprints durent 6 semaines.) »
• « (Nous utilisons Scrum, mais) (parfois nos managers nous confient des tâches spéciales) (donc nous n’avons pas toujours le temps de répondre à notre définition de Done.) »