Scrum : sur quoi vous avez tort

Vous avez tort si vous pensez que le framework Scrum doit être appliqué à la lettre, quelle que soit la situation.

Et en réalité, vous avez tout loisir de l’agrémenter de pratiques personnalisées en pagaille…tant qu’elles sont cadrées par les limites indiquées dans le Guide. En effet, dans certains cas, une application trop académique ou trop austère de Scrum peut freiner ou entraver le travail des équipes. Comment s’en rend-on compte ? Habituellement, les symptômes crèvent les yeux (et les oreilles) :

• des cérémonies vécues comme des corvées,
• des tentatives de négociation sur la fréquence des rétrospectives (pour rappel, en Scrum elles sont indéboulonnables…),
• les stakeholders ne sont pas motivés par la Revue de Sprint (“…je suis sous l’eau, je viendrai à la prochaine!…”),
• le niveau de motivation est minimal et tout le monde se plaint,
• Etc.

En somme, l’ambiance est au plus bas. Comment corriger cette situation peu propice à la génération de valeur ?

La réponse ? Ça dépend. Si en plus des points cités au dessus l’équipe peine à formuler un Sprint Goal clair à chaque Sprint Planning, si chaque développeur travaille sur des objectifs sans liens particuliers avec ceux de ses collègues, si l’incrément ressemble à un lot incohérent de différentes “stories”, ou si le sprint est sans cesse perturbé par l’ajout de tâches qui devraient être attribuées à une autre équipe, alors peut-être est-il temps d’envisager de passer à un autre cadre de travail (Kanban par exemple ?)…

Ou pas…Peut-être que Scrum convient très bien mais qu’il est mal utilisé ou mal compris (habituellement les deux). Quelques questions à se poser :

• Les différentes parties font-elles le nécessaire pour que tout se passe correctement ?
• Le ou les managers s’emploient-ils activement à lever les obstacles rencontrés par les équipes ?
• Le Scrum Master est-il bien à l’écoute de l’équipe ?
• Les valeurs et les piliers de Scrum transparaissent-ils dans les décisions qui sont prises ?
• Les évènements Scrum ne sont-ils pas trop longs et épuisants ? (Même si l’ambiance est à la camaraderie, les rétrospectives de 1h30 en fin de semaine, ça use…beaucoup…)
• Les évènements sont-ils trop répétitifs ? Qui n’aurait pas une crise d’apoplexie à sa cinquième rétrospective “étoile de mer” ou “speed boat” consécutive ?

Et la liste pourrait encore s’allonger…Heureusement, les leviers sont nombreux qui permettent d’adapter Scrum sans en trahir les fondamentaux. Quelques idées :

• Ce que vous faites pendant vos rétrospectives. L’énergie que vous y mettez. Le temps que vous y consacrez. Le lieu où vous vous réunissez. Ce que vous en tirez (bénéfices, observations). L’ambiance globale…
• La cadence des Sprints : un mois, deux semaines, une semaine ? Elle est fixe mais sujette à révision selon vos besoins d’inspection et d’adaptation. Plus le contexte est imprévisible (à haut risque) plus on aura tendance à experimenter sur des itérations courtes.
• Les modifications d’équipes : les développeurs (au sens large) ne sont pas des rouages de machinerie. Vous devez prendre en compte dans une certaine mesure les affinités des uns ou des autres avec leur collègues, leurs technos…
• Les pratiques en daily Scrum : il y a d’autres choses à faire que les trois questions soporifiques habituelles, qui sans grande surprise, ont disparu du guide Scrum 2020.
• Etc.

 

Vous avez également tort si vous pensez que le framework Scrum doit systématiquement faire l’objet d’aménagements et d’accomodements divers.

J’y vois là une sorte de fantasme de la diversité et aussi une certaine forme de snobisme. Comme nous sommes tous différents, et que nous travaillons tous dans des contextes eux aussi bien différents (chaque organisation a ses spécificités), il faudrait également que chacun ait son “Scrum à lui”. Chacun devrait avoir son “Scrum fait maison”, aux qualités certainement bien supérieures à l’original, puisque, après tout il est adapté pour notre organisation. Nous avons donc fait du “sur-mesure” et quoi de mieux que du “sur-mesure” ma bonne dame ?

Comme si ce cadre de travail n’était déjà pas suffisamment permissif, comme s’il ne donnait pas suffisamment de latitude pour s’organiser “sur-mesure” justement. Car ce n’est évidemment pas un hasard si la structure du framework est à la base aussi légère…

Avant d’aller plus loin, je précise : libre à vous de modifier la structure de Scrum comme bon vous semble en sortant des rails définis dans le guide, et probablement en tirerez-vous de grands bénéfices, mais comme précisé dans ce même guide…ce n’est plus Scrum. Auquel cas il vaudra mieux adapter votre terminologie au nouveau modèle/framework que vous avez créé pour éviter toute confusion.

Quelques exemples de bricolages à mon sens bizarres, pratiqués sous la bannière Scrum :

• Instaurer des rétrospectives “à la demande”. Après la VOD (Video On Demand), vous avez le FOD (Framework On Demand). Choisissez vos évènements dans le menu faites vous livrer au jour et à l’heure de votre choix…Une idée qui peut provoquer un climat néfaste : beaucoup plus de pression pour s’exprimer puisqu’il faut formuler une demande explicite, et si la même personne la réclame systématiquement…il peut devenir un mouton noir…
• Placer la rétrospective (du Sprint 1) après le Sprint Planning (du Sprint 2). C’est original, fun et ça ne risque pas de désorienter quiconque n’est-ce pas ? Pourquoi faire simple quand on peut faire compliqué ?
• Des Product Owners qui participent activement au Daily Scrum (en adressant les questions des développeurs). Un point très polémique. Certains soutiennent mordicus que c’est une erreur (comme moi), d’autres estiment que ça apporte son lot de bénéfices aux développeurs puisque le PO est là pour répondre à leurs questions si besoin (mais des questions, ils en auront toujours). Mon avis personnel est que ça n’apporte en réalité pas grand-chose de positif, que c’est un évènement réservé aux développeurs et que le PO est de toute façon à leur disposition pour répondre aux questions en dehors du Daily Scrum.
  C’est de toute façon contre-indiqué par le guide sauf si le PO développe également : “The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.” (Guide Scrum 2020)
• Des Sprints de Consolidation (Hardening Sprints) dans lesquels les équipes corrigent les bugs et s’attaquent (trop tard) à la dette technique. Là on passe de “bizarre” à “formellement interdit” par le guide. L’excellence technique émerge au fil des Sprints, ce n’est pas un interrupteur qu’on allume quand c’est la panique ou avant une “grande présentation/mise en production/démonstration”…

 

Et finalement, si vous ne bricolez pas la structure originelle de Scrum, que reste-t-il ? Du Scrum, appliqué normalement et si possible, efficacement. Habituellement, la moitié des lecteurs se sont déjà étranglés à la seule idée d’appliquer Scrum tel quel et pourtant…Les articles sont nombreux sur internet pour annoncer d’un air victorieux que telle ou telle organisation a détourné Scrum et que la magie a enfin opéré dans les équipes. Pour autant, sont tout aussi nombreux sur le web les articles dénonçant les cas de “Zombie Scrum” et autres déviances résultant d’une utilisation malavisée du framework.

Comme quoi modifier Scrum reste une option qui se choisit à vos risques et périls. Le framework a d’ailleurs longtemps été qualifié de “ facile à comprendre mais difficile à maîtriser” (dans la version 2017 du Guide), un avertissement qui en dit long. Difficile pour certains de résister à la tentation de modifier la structure du framework lorsque les problèmes commencent à s’accumuler…

Finalement, que faire ?

Pour pouvoir se prononcer sur telle ou telle situation il faudra pouvoir observer avec précision le contexte dans lequel le framework est mis en œuvre, comment il est mis en œuvre, voir si les valeurs sont appliquées (ouverture, courage, focus, respect, engagement), voir si les piliers sont respectés (transparence, inspection, adaptation), voir comment les humains qui le pratiquent le vivent etc. Si après une période d’expérimentation (à définir) l’adoption de Scrum coince de tous côtés, et si beaucoup de choses ont été tentées dans le cadre établi du framework alors peut-être est-il temps de passer à autre chose…mais les aléas fréquemment rencontrés dans son adoption ne devraient pas pousser systématiquement à des arrangements douteux…

Enfin, pour les plus audacieux, je ne pourrais pas terminer sans mentionner l’excellent article de Jeff Sutherland, Scott Downey et Björn Granvik, “Shock Therapy, A bootstrap for Hyper-Productive Scrum” (2009) dans lequel ils analysent les exceptionnels résultats obtenus avec une application “militaire” du framework sur une courte période de lancement (après quoi l’équipe reprend progressivement son autonomie et sa liberté de décisions).