Après une première partie dédiée à la description succinte du framework, voici la seconde partie de mon décryptage d’un article sur Scrum dans laquelle j’aborde cette fois la partie Avantages du framework, telle que vue par l’article original, avec mes commentaires en cadeau bonus.
Je remets ici le lien vers l’article d’origine. (En Anglais)
Les Avantages de Scrum
Voilà pourquoi le framework est si populaire aujourd’hui :
Scrum peut aider les équipes à réaliser des livrables rapidement et efficacement.
Oui et c’est d’ailleurs un des objectifs principaux de Scrum, permettre à l’utilisateur ou aux stakeholders d’avoir quelque chose de concret à tester à chaque fin de Sprint. Autrement dit, délivrer de la valeur de manière prédictible. La durée des Sprints varie entre une semaine (durée arbitraire car il n’y a pas de limite basse) et un mois au maximum. Cette durée est à définir en fonction du marché, des incertitudes, du risque etc. Plus le contexte dans lequel on travaille est imprévisible plus on aura intérêt à inspecter fréquemment nos avancées.
Les livrables en question doivent aussi former un tout cohérent, c’est l’Objectif de chaque Sprint : produire une “portion de logiciel” utilisable, une fonctionnalité qui va pousser à la collaboration de toute l’équipe. Le piège serait ici la production de jeux de livrables sans aucun lien entre eux…
“In order to provide value, the Increment must be usable.”
Scrum assure un usage efficace du temps et du budget.
Tout dépend de ce que l’on en fait…Mais dans l’absolu le fait de travailler sur des cycles courts (les Sprints) permet normalement de limiter les dépenses inutiles en travaillant sur des fonctionnalités priorisées et ciblées, en inspectant et adaptant régulièrement le travail en cours et en corrigeant la trajectoire de l’équipe si besoin. En 2020, le Guide Scrum a même ajouté l’obligation pour l’équipe de se fixer un objectif à plus long terme, le “Product Goal”. Il doit figurer dans le Backlog Produit et aide l’équipe à orienter ses choix.
Les diverses réunions/évènements fixés par le framework aident l’équipe à mieux structurer leur temps. Chaque évènement a un objectif précis. Et même si les développeurs s’en plaignent parfois, ce système les protège plutôt bien des “crises de réunionite” à répétition improvisées dans d’autres organisations. Dans ce cadre ces dernières n’ont plus vraiment lieu d’être.
Mais comme je le disais au début, Scrum n’est pas une garantie d’obtenir un usage efficace du temps et du budget. Il est facile de faire n’importe quoi avec le framework. L’abondance de questions, de cours et de littérature sur le web en atteste. D’où l’intérêt d’avoir un Coach Agile ou à défaut un Scrum Master qui veille au respect des essentiels. On arrive alors rapidement sur le terrain du “tu fais du Scrum à la lettre ou bien tu l’adaptes ?”, un thème hautement polémique sur lequel je ne m’étendrai pas aujourd’hui.
Les projets importants sont segmentés en Sprints plus aisément gérables.
Oui et pour être plus précis, Scrum utilise une approche itérative et incrémentale. Cette dernière offre de nombreux avantages non seulement pour les projets importants (en termes de périmètre fonctionnel) mais aussi pour les projets complexes. La page “Les Traducteurs Agiles” résume très bien ces deux approches :
Un processus itératif est un processus dans lequel une série d’opérations est répétée de manière cyclique, avec l’intention de se rapprocher de plus en plus d’un certain résultat désiré.
Source : Les Traducteurs Agiles
Une approche incrémentale pour produire quelque chose peut être définie comme étant une approche permettant de produire davantage chaque fois. C’est un petit peu en contraste avec le concept d’approche itérative, qui est définie comme étant une approche permettant de produire une version améliorée en vue d’obtenir une solution cible. Une approche incrémentale produit quelque chose de nouveau en modifiant une ancienne.
Source : Les Traducteurs Agiles
Les développements sont codés et testés pendant la Revue de Sprint.
Cette phrase ne veut rien dire…Le code et les tests sont effectués pendant le Sprint, par les Développeurs mais pas pendant la Revue de Sprint. Lors de cet évènement, le déroulement du Sprint est discuté par l’équipe et les Stakeholders, puis le résultat du Sprint (l’Incrément) est démontré par les Développeurs. Enfin, la démonstration est l’occasion de déclencher des conversations entre toutes les parties sur les orientations à prendre par la suite. Le Product Backlog est révisé et réajusté sur les nouveaux objectifs décidés.
Scrum fonctionne bien sur les projets de développement rapides.
Pour pouvoir l’affirmer, il faudrait déjà savoir ce que l’auteur définit comme un “Projet de développement rapide”…J’attends encore le jour où quelqu’un me parlera de “projet de développement lent ou tranquille”…L’urgence est quasi-permanente dans ce milieu. Il y a toujours des dates butoir, des “deadlines” imposées par l’organisation et il y aura toujours trop à faire.
Le développement de logiciels étant complexe et incertain les deadlines sont atteintes (quand elles le sont) au prix de nombreuses adaptations, priorisations et autres ajustements de périmètre fonctionnel. La solution viable pour l’équipe se trouve à l’intersection de ce qui apporte de la valeur, de ce qui est faisable, de ce qui est utilisable, et ce pour une portion spécifique de clients et ou d’utilisateurs.
Le futur est imprévisible et le travail se fait pas à pas, par adaptations progressives.
Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
L’équipe a une bonne visibilité sur sa progression grâce aux évènements Scrum.
Oui, c’est à ça que servent les évènements. Chaque évènement est l’occasion de pratiquer Transparence, Inspection et Adaptation. Non seulement l’équipe a une bonne visibilité sur sa progression mais aussi l’ensemble des parties prenantes concernées.
Comme c’est un framework Agile, Scrum permet de se baser sur les retours des utilisateurs et des stakeholders.
Je suis persuadé que de nombreux environnement non agiles se basent aussi sur les retours des utilisateurs et stakeholders…Mais effectivement, dans un mode de fonctionnement incrémental et itératif, il est crucial d’obtenir ces retours à intervalles réguliers pour pouvoir s’adapter aux besoins du marché et vérifier que l’on est bien en train de construire ce qui est attendu. Par opposition, travailler “dans son coin” pendant une période longue sans savoir si l’on avance dans la bonne direction génère souvent de très mauvaises surprises à l’arrivée…
La durée limitée des Sprints permet de pivoter plus facilement selon les retours obtenus.
Oui et c’est un corollaire du point précédent. J’utilise ici le terme “pivoter” qui vient du monde de la startup :
L’entrepreneur va ensuite évaluer les résultats obtenus par son projet et à ce moment là pourra décider de continuer ou de pivoter c’est à dire faire évoluer son projet. Cela peut signifier changer de cible marketing, changer son offre (par exemple passer du produit au service) ou changer profondément son concept.
Source : Schoolab
L’effort individuel de chaque membre de l’équipe est visible durant les réunions de “Daily Standup”.
Possiblement…mais ce n’est certainement pas l’objet du Daily Standup. Ce qui nous intéresse n’est ni d’évaluer la performance individuelle de chacun et encore moins de comparer les membres de l’équipe entre eux. La réunion du Daily Standup “appartient” aux développeurs. C’est lors de cette réunion qu’ils se synchronisent entre eux et qu’ils font le point sur leur avancée vers l’Objectif de Sprint. Pour réaliser leur plan, élaboré lors du Sprint Planning, ils ont la plus grande liberté d’organisation.
Dans le troisième et dernier article, nous aborderons les inconvénients de Scrum, à bientôt !
2 comments on “Scrum : Contresens et Décryptages II”