Scrum : Contresens et Décryptages I

Alors que je faisais une recherche sur les limitations du framework Scrum, je suis tombé par hasard sur un article étranger qui tente d’en résumer le fonctionnement en quelques lignes avant d’en lister rapidement les avantages et inconvénients. Une démarche tout à fait honorable…Sauf que la quantité de contresens et d’inexactitudes qui le parsèment m’ont fait tomber de ma chaise. L’auteur n’est d’ailleurs ni Coach Agile, ni Scrum Master mais “Senior Content Writer” ce qui explique bien des choses…

Je suis prêt à parier qu’en prenant le temps de chercher un peu, je trouverais des dizaines et des dizaines d’articles comme celui-ci sur le web. En temps normal je ne m’y arrêterais pas, mais dans ce cas particulier, je trouve les erreurs suffisamment intéressantes pour prendre le temps de les décrypter le temps d’un article. J’ai choisi de diviser cette analyse en deux parties. Je vais couvrir aujourd’hui la partie “Survol de Scrum”, puis les avantages et inconvénients dans un second post.

Je mets ici le lien vers l’article. (En Anglais)

Titre de l’article – La Gestion de Projet avec Scrum : Avantages et Inconvénients.

Parler de “gestion de projet avec Scrum” est déjà un problème en soi. C’est un sujet presque philosophique qui fait couler pas mal d’encre…Juste pour vous donner les contours de la discussion, l’idée générale est que dans une équipe Scrum, il n’y a pas de Chef de Projet. Il y a en revanche un Product Owner. Ce dernier s’occupe d’un produit et non pas d’un projet. Rien que pour cette raison (parmi beaucoup d’autres) parler de gestion de Projet avec Scrum n’a pas tellement de sens.

Pour autant, le Guide Scrum 2020 affirme que chaque Sprint peut être considéré comme un mini-projet en lui-même…Ce qui ne justifie toujours en rien l’ajout d’un Chef de Projet en plus de l’équipe : cette dernière est autonome et se gère elle-même…

Bref, si vous êtes prêts à vous tirer une balle à l’écoute de ces considérations un peu pointues c’est normal. Si malgré tout cela vous vous demandez pourquoi il y a parfois encore un Chef de Projet “en agilité” et si vous souhaitez y voir plus clair, je vous invite à faire une recherche sur les différences entre l’organisation en “mode projet” ou “mode produit” et aussi à consulter cet article très éclairant : “Why do Scrum teams Have a Project Manager”.

Passons ensuite à la description de Scrum dans ses grandes lignes. Traduit de l’anglais par mes soins, j’ai essayé de respecter les tournures précises de l’auteur :

Décryptage

Le Product Owner crée un Product Backlog (essentiellement une liste de tâches qui ont besoin d’être priorisées dans le projet)

Je ne reviens pas sur le mot “projet”, dont je parlais à l’instant. Pour le reste, le Product Owner ne crée pas son backlog tout seul, enfermé dans une cellule avec du pain sec et de l’eau croupie. Il en reste seul maître mais le construit en concertation avec les stakeholders, et peut se faire accompagner par les Développeurs, le Scrum Master, un Coach Agile etc. C’est par ailleurs un processus continu. Le backlog évolue avec le produit.

Le Backlog n’est pas exactement une liste de tâches. Plutôt que des “tâches” on parlera “d’items”, d’éléments, de fonctionnalités ou même de “stories”. En général (mais ce n’est plus toujours vrai) les tâches est un mot utilisé pour décrire les travaux (le plan) envisagés par les développeurs pour réaliser telle ou telle fonctionnalité. Mais j’avoue que le mot est un peu galvaudé désormais. On le retrouve utilisé à tort et à travers dans pas mal d’examens blancs pour la certification Scrum…

L’équipe Scrum conduit une Session de Sprint Planning dans laquelle les tâches nécessaires pour réaliser les items du Backlog sont découpées en morceaux plus petits et plus gérables.

Ici l’auteur utilise le mot “tâches” dans le bon contexte. Pour être plus clair, les éléments du Backlog (les items) sont découpés en fonctionnalités plus digestes pour les Sprints. Les développeurs prévoient ensuite au mieux de leur capacité les tâches nécessaires pour les réaliser.

Cet exercice n’est qu’une petite partie du Sprint Planning. L’auteur décrit ici plutôt une réunion d’affinage du Backlog. Ce n’est pas un évènement “officiel” de Scrum, c’est un processus continu dont le rythme est choisi par l’équipe.

L’équipe crée un Sprint Backlog et planifie son implémentation.

C’est juste, et ce point devrait être inclus avec le précédent puisqu’il fait partie des activités du Sprint Planning. Planifier l’implémentation du Sprint Backlog, c’est prévoir les tâches nécessaires à la réalisation des différents items choisis pour le Sprint, qui eux-mêmes doivent amener à la réalisation de l’objectif de Sprint décidé par l’équipe lors du Sprint Planning.

L’équipe décide d’une durée pour les Sprints (l’intervalle le plus courant sera probablement de deux semaines)

C’est correct. J’y ajouterai que cette décision dépend de nombreux facteurs, notamment le risque. Plus les risques et l’incertitude sont importants, plus il faudra inspecter le travail régulièrement afin de pouvoir corriger la trajectoire prise si besoin. Dans ce cas libre à l’équipe d’expérimenter sur des Sprints plus courts. L’inspection et l’adaptation sont deux des trois piliers de Scrum.

L’équipe se réunit chaque jour pour une réunion rapide (souvent appelée Daily Standup) dans laquelle chaque membre de l’équipe partage sa progression, pour aider le Chef de Projet à mesurer l’avancée du projet.

C’est presque entièrement faux.

Il y a bien un Daily Standup chaque jour, et il s’agit effectivement d’une réunion rapide limitée à un maximum de 15 minutes. Par contre, ce n’est pas l’équipe au complet qui s’y réunit mais les Développeurs, accompagnés ou non de leur Scrum Master (ce choix leur appartient). Le Product Owner et/ou d’autres personnes peuvent y assister en tant qu’observateurs. Cette réunion est réservée aux développeurs afin qu’ils se synchronisent entre eux et qu’ils y partagent leur progression entre eux.

Normalement il n’y a pas de Chef de Projet en Scrum, mais admettons pour cette fois qu’il existe…Il n’aurait rien à faire dans le Daily Standup. Même en tant qu’observateur. Cette réunion n’est pas une réunion bilan (”status meeting”) dans laquelle les développeurs rendraient des comptes à une autorité. C’est d’ailleurs une des raisons pour lesquelles je ne recommande pas la présence du product Owner, même en tant qu’observateur car observer c’est aussi influencer.

Si un manager souhaitait se renseigner sur l’avancée du projet il peut le faire à la Revue de Sprint, chaque fin de Sprint ou quotidiennement en consultant les Backlog et Sprint Backlog qui sont normalement visibles de tous…Rien ne l’empêche non plus de faire des points avec le Product Owner. La transparence est l’un des trois piliers de Scrum.

Le Scrum Master guide l’équipe, aide les membres à se concentrer et à rester motivés.

Entre autres…Mais le rôle du Scrum Master englobe beaucoup plus de responsabilités. Sans m’étendre sur celles-ci (cf le Guide Scrum 2020), j’aurais quand même rajouté une des plus importantes : le Scrum Master est chargé notamment de dégager la voie à l’équipe lorsque quelque chose les bloque dans leur progression.

Enfin, l’équipe a un objectif de Sprint, qui normalement doit les motiver. C’est sur ce dernier que les membres de l’équipe doivent se concentrer en particulier.

Les Stakeholders (parties prenantes) et le Product Owner conduisent une Revue de Sprint à la fin de chaque Sprint.

C’est à peu près ça. Plus précisément c’est le Scrum Master qui va conduire la Revue de Sprint. Le Product Owner invite les parties prenantes. L’évènement ne se limite pas à une simple “démo” de l’incrément produit par les développeurs. Il inclut une discussion sur le Sprint récemment écoulé, la démo et une discussion sur les orientations du travail à venir. Le Backlog y est modifié pour refléter les décisions prises par l’ensemble des participants.

Voilà pour la description de Scrum…Mais même pour une simple liste à points, même pour un survol rapide, elle aurait du mentionner la Rétrospective, grande absente de ce résumé…

Scrum est simple ?

Pour qui veut bien se pencher sérieusement sur le Guide Scrum, comprendre le framework dans ses grandes lignes n’est pas très difficile. La répartition des rôles et des compétences est relativement claire, les évènements sont peu nombreux…Ce cadre de travail est apprécié notamment pour sa simplicité et son efficacité.

Malgré cela, les subtilités sont nombreuses, et il est facile de s’y perdre pour qui a une connaissance trop superficielle du framework…C’est notamment pour cette raison que les formations de deux jours m’ont toujours paru suspectes…quand elles ne sont pas suivies d’un accompagnement par un Coach Agile pour solidifier les connaissances des apprenants, leur éviter certains écueils et leur permettre de tirer pleinement parti de Scrum.

Voilà pour aujourd’hui, dans le prochain épisode, je décrypterai la partie “avantages de Scrum” de l’article !