La solution ? Faire comprendre en priorité la raison d’être de chaque élément de Scrum, faire confiance à l’équipe pour construire ses pratiques, et l’accompagner dans son amélioration continue.
Notre constat chez nos clients
Ce n’est pas parce qu’une équipe affirme « passer en Scrum » qu’elle pratique Scrum au sens où l’entendent les concepteurs du framework. On observe régulièrement chez nos clients que de nombreuses équipes n’ont de Scrum que le nom – ou, serait-il plus juste de le dire, les noms. Les entreprises s’empressent d’avoir un Product Owner, un Scrum Master, un backlog, à pratiquer les Dailys et les rétrospectives… Elles semblent penser que la mise en place du vocabulaire utilisé dans Scrum va les rendre « agiles ». Les termes techniques fonctionnent alors comme un culte du cargo.
Mais si l’on demande à ces équipes de définir tous ces termes, ce que l’on entend est au mieux incomplet, et souvent un contre-sens. Par exemple :
- Scrum Master : « celui qui anime les rétrospectives et les Dailys »
- Rétrospective : « le rituel fun avec les post-its à la fin des sprints »
- Daily : « là où on détaille ce qu’on a fait hier, par exemple hier j’ai eu 2h de réunions et puis j’ai mangé et puis je me suis brossé les dents… »
Le constat est clair : si les noms sont à peu près toujours là, les concepts que sont censés recouvrir ces noms sont parfois absents.
Sur le papier, ces équipes ont tout de Scrum ; pourtant elles ne sont pas des Scrum Teams. En conséquence, elles n’en tireront pas les bénéfices, et seront parfois persuadées que « Scrum, ça ne marche pas ! »
Ou encore, dans le cas le plus courant, ce quasi-Scrum apportera tout de même des améliorations, mais seulement parce que le contexte précédent était pire, et l’on se satisfera à tort de ces résultats tièdes.
Pourtant, ces équipes ont généralement reçu une formation complète. On leur a fait une présentation détaillée de tous les rôles, événements et artefacts du Guide Scrum, ainsi que ce qui n’y figure pas, comme les User Stories, les points d’efforts, etc.
Et c’est peut-être là qu’est le problème.
Le plus important : la raison d’être
C’est mécanique : quand on essaie d’apprendre trop de choses à la fois, on n’en retient qu’une infime minorité. Pire, en tentant de jongler avec une surabondance de données, on met à égalité, dans la mémoire, les informations cruciales et les détails triviaux. On augmente alors la probabilité que les rares éléments retenus fassent partie de ces derniers plutôt que des premiers. Les messages essentiels sont dilués dans la masse et oubliés.
Or, ces messages essentiels sont ceux qui permettent la compréhension, et on ne saurait utiliser correctement Scrum sans le comprendre.
Une formation un peu trop chargée peut, par exemple, mener à retenir que le Daily Scrum dure 15 minutes maximum et qu’on y parle de ce qu’on a fait… tout en oubliant la raison d’être du Daily : ajuster le plan des développeurs pour le sprint.
Les données « durée du Daily » et « objectif du Daily » n’ont clairement pas la même valeur. Que nous importe la durée d’une réunion si l’on ne comprend même pas ce qu’on est censé y faire ?
Scrum n’est pas un mode opératoire détaillant étape par étape une façon de procéder. C’est un cadre qui, en se basant sur certaines convictions (par exemple, l’importance de l’amélioration continue), décrit une forme d’organisation qui permet aux équipes d’aller dans le sens de ses convictions, tout en leur laissant une grande autonomie. Dans l’exemple de l’amélioration continue, Scrum lui dédie une réunion appelée rétrospective, mais laisse l’équipe entièrement libre de conduire cette réunion comme elle le souhaite.
Le bon usage de Scrum dépend de la compréhension des convictions sous-jacentes, donc de la raison d’être de chaque élément du cadre
Scrum, un cadre plutôt qu’une recette
Cela mérite d’être répété : Scrum ne cherche pas à détailler aux équipes ce qu’ils sont censés faire de leurs journées. En témoigne cette citation du Guide Scrum 2020 :
« Le Framework Scrum est volontairement incomplet, ne définissant que les parties nécessaires à la mise en œuvre de la théorie Scrum. Scrum repose sur l’intelligence collective des personnes qui l’utilisent. Plutôt que de fournir aux gens des instructions détaillées, les règles de Scrum guident leurs relations et leurs interactions. »
L’idée est bien plutôt de faire comprendre aux personnes le quoi et le pourquoi, et de leur faire confiance pour le comment. Un médecin pourra par exemple expliquer à un patient qu’il a besoin de passer du temps au Soleil pour sa santé. Il le laissera ensuite se débrouiller pour se rendre dans le Sud, sans avoir besoin de détailler l’itinéraire routier à suivre !
Scrum fonctionne selon le même esprit : recommander, par exemple, un rituel d’amélioration continue à la fin de chaque itération (la rétrospective) en expliquant pourquoi, mais ne pas prescrire dans le détail la manière de conduire la réunion ! On fait confiance à la Scrum Team pour explorer et découvrir le fonctionnement qui lui convient le mieux.
Non seulement cette philosophie, minimaliste et non contraignante, est plus propice à la capacité d’adaptation chère à l’agilité, mais elle est également plus favorable à un apprentissage rapide, durable et (surtout) sans faux-sens.
Pour revenir à la métaphore médicale, il est plus facile de faire retenir « allez dans le Sud prendre le Soleil » qu’une série d’instructions routières.
Scrum en quelques post-its
Oui mais, me direz-vous, Scrum est tout de même un peu plus complexe que « allez dans le Sud prendre le Soleil ». Raison de plus pour se concentrer sur les éléments fondamentaux, ceux qui permettent d’appréhender le framework dans son ensemble, pour s’assurer que chacun retienne et comprenne ce qui compte avant d’apporter tout élément complémentaire.
Et puis, si l’on regarde bien dans le Guide Scrum 2020, chaque rôle, rituel, artefact a individuellement son équivalent de ce « allez dans le Sud prendre le Soleil ».
Quelques exemples (un rôle, un évènement, un artefact) :
« Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de la Scrum Team. »
« L’objectif du Daily Scrum est d’inspecter la progression vers l’Objectif de Sprint et d’adapter le Sprint Backlog si nécessaire, en ajustant les futurs travaux planifiés. »
« Le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit. C’est la seule source du travail accompli par la Scrum Team. »
On comprend la raison d’être, la fonction de chaque élément au sein du cadre, et ce par une définition qui tiendrait sur un post-it. D’ailleurs, appelons donc arbitrairement ces définitions les « post-its » des éléments de Scrum. Après tout, c’est bien connu, Scrum et post-its vont de pair !
Si l’on connaît et comprend tous ces post-its, alors on comprend tous les éléments et leurs relations dans le cadre. On comprend alors Scrum dans son ensemble, on en comprend la valeur, et on saura en tirer parti, quand bien même il y aurait tâtonnement sur le « comment ».
Consolider les bases
La priorité d’un Scrum Master doit être que chaque membre comprenne et s’approprie les grands principes du framework décrit dans chaque « post-it ». Il faut comprendre comment les interactions forment le système qu’est Scrum.
Certes, il y a dans le Guide Scrum d’autres informations que le contenu de ces « définitions post-its ». On y trouve notamment des timebox et autres considérations pratiques.
Mais peu importe si l’équipe ne sait pas tout dès le début.
En effet, le Scrum Master sera là pour les aider dans l’application pratique. Son rôle, comme celui de tout coach agile, est précisément d’accompagner l’équipe dans son acculturation agile, et dans le développement de ses propres pratiques.
Nul besoin donc, en formation, de faire du bourrage de crâne sur les détails techniques : le Scrum Master veillera au grain. Par la pratique les développeurs assimileront très vite, par exemple, qu’un Daily n’est pas censé dépasser 15 minutes. Il faut en revanche qu’ils comprennent dès le début la raison d’être de ce rituel (ajuster leur plan pour atteindre l’objectif du sprint), faute de quoi les mauvaises habitudes s’installeront très vite et seront coûteuses à corriger.
De même pour les nombreuses pratiques de la culture agile élargie, dont celles qui sont prises à tort pour des prescriptions de Scrum, telles que le Poker Planning, les User Stories, les points d’effort, les formats « classiques » de rétrospectives. Bien sûr, elles peuvent s’avérer utiles à l’équipe, mais mieux vaut les introduire dans un second temps, au fil de l’eau, en les présentant bien comme des propositions qui peuvent être utiles mais ne sont pas obligatoires. Si elles apportent un réel avantage par rapport aux solutions que l’équipe avait jusque-là improvisées pour répondre aux exigences du cadre Scrum, alors elles n’en seront adoptées qu’avec plus de ferveur, puisqu’il y aura un réel ressenti dans la comparaison.
Quelle approche suivre pour bien démarrer ?
Commencer par une formation au contenu minimaliste, centrée sur les raisons d’être de chaque élément et leurs relations. Se donner le temps en séance de comprendre et retenir ce qui est présenté. C’est l’occasion idéale pour un « serious game », tel que nous en utilisons souvent chez onepoint pour rendre la formation plus participative tout en consolidant les connaissances. Par exemple, un jeu de type memory où l’on aura deux cartes pour chaque élément Scrum (son nom et sa définition post-it) et où il faudra regrouper les bonnes paires.
Ensuite, se lancer dans le développement du produit ! L’équipe, accompagnée de son Scrum Master, va définir sa propre pratique de Scrum au fur et à mesure de ses progrès. En fonction du besoin, le Scrum Master suggèrera aussi de temps à autre telle pratique vue ailleurs, qui sera ou non adoptée et adaptée par l’équipe.
Ainsi, armée de l’expérience des autres et de sa propre force d’innovation, la Scrum Team va construire sa façon de travailler, dans une démarche d’amélioration continue. Chaque modification qu’elle apportera à son processus sera là parce qu’elle l’aura voulu, parce qu’elle en aura compris l’intérêt. Il n’y donc pas de danger qu’elle soit réfractaire ou qu’elle l’applique mal par mécompréhension.
Une telle démarche sera la plus efficace pour appliquer Scrum, car c’est la meilleure manière d’en respecter l’esprit !
Continuer l’expérience Agile – Votre transformation Agile s’est mal passée. Avez-vous oublié l’essentiel ?
