Pourquoi Scrum ?

Nous aimerions préciser que le but de cet article n’est pas de vous convaincre d’utiliser Scrum, encore moins de vous le vendre. La meilleure façon d’être convaincu, c’est d’expérimenter par soi-même. David et moi avons eu une discussion intéressante sur le sujet et nous estimons qu’elle a suffisamment de valeur pour que nous la partagions, car la question titre de l’article revient assez souvent dans nos interventions en mandat.

Voici donc la teneur de nos échanges :

David : Au fait Nedjma, pourquoi Scrum ?

Nedjma : Et pourquoi pas Scrum ? (rires)

David : Oui (rires), je veux dire pourquoi ce framework est autant poussé et reconnu comme le cadre Agile de référence?

Nedjma : Scrum nous fournit un cadre pour découvrir l’Agilité ; le cadre est simple à comprendre et, par ses artéfacts, évènements et règles, il véhicule les valeurs et les principes du manifeste Agile.

David : O.K., et ?

Nedjma : Il y a peu de règles, et tout se déroule à rythme fixe avec des réunions bien définies qui sont planifiées toujours dans le même ordre. Scrum est simple à expliquer ; il suffit de 17 pages dans le guide Scrum pour expliquer ses règles.

La simplicité n’est pas la réponse complète à la question. Scrum est un framework qui a fait ses preuves aujourd’hui dans différents contextes, car il permet de produire de la valeur rapidement, en s’appuyant sur une équipe pluridisciplinaire et auto-organisée. Aucun plan fixe n’est établi en avance. L’équipe Scrum est à la recherche constante de la meilleure façon de produire ce qui a le plus de valeur pour l’utilisateur final.

David : Tout ça semble intéressant. Et j’ajouterais deux points à ce que tu dis : la livraison rapide de valeur est rendue possible grâce à la démarche itérative incrémentale de Scrum, qui permet de livrer un logiciel fonctionnel régulièrement. La démarche maximise les occasions de recevoir le feedback des parties prenantes pour avoir un produit de qualité.

La qualité, mon deuxième point, est très importante dans Scrum. Effectivement, à chaque fin d’itération, une équipe Scrum livre un incrément du logiciel qui doit être le plus proche possible de la qualité nécessaire pour la mise en production.

Nedjma : Le développement logiciel est une activité complexe, et Scrum permet de faire face à cette complexité.

David : Oui, et donc pourquoi Scrum ?

Nedjma : Tu ne m’as pas laissé terminer ! Scrum permet de faire face à la complexité par l’empirisme ; un élément fondamental du framework Scrum.

Un processus empirique veut dire qu’on se base sur l’expérience pour prendre des décisions, et pour cela on a besoin de transparence. Dans Scrum, tous les aspects importants doivent être visibles pour pouvoir les inspecter et prendre des décisions permettant de limiter les risques.

Prenons l’exemple du Daily Scrum. La mêlée quotidienne permet, en se basant sur le travail de la veille, d’adapter le plan du jour pour s’approcher de l’objectif. Le Sprint Review permet quant à lui d’inspecter l’incrément de produit réalisé, de recevoir le feedback et de collaborer avec les parties prenantes en fonction de l’état d’avancement pour déterminer le travail ayant plus de valeur à effectuer durant le prochain cycle.

Cela ne concerne pas que le développement logiciel. Scrum permet de faire face à des problèmes complexes, c’est écrit dans le guide Scrum. Laisse-moi revoir la définition exacte :

« Un cadre de travail permettant de répondre à des problèmes complexes et changeants, tout en livrant de manière productive et créative des produits de la plus grande valeur possible. »

Dans la définition, j’aime beaucoup l’adjectif « créative », car si on revient au développement logiciel, je pense qu’il s’agit d’une activité créative qui nécessite une façon créative de l’aborder.

David : Je te rejoins ; sur le premier point, il est vrai qu’il est plus simple de découvrir l’empirisme par les pratiques du cadre de Scrum. On peut voir cela aussi par les rétrospectives de fin de sprint ; l’équipe trouve des moyens concrets d’ajuster son fonctionnement, sa communication et ses pratiques en se basant sur les apprentissages faits pendant l’itération.

Je pense que le plus important, c’est de développer un esprit Agile. Le modèle Shuhari décrit bien cela. Il faut d’abord respecter les règles pour développer le bon état d’esprit, puis transcender le tout. Le cadre Scrum permet à chacun de débuter son voyage dans l’Agilité.

L’aspect créatif du développement logiciel me parle beaucoup aussi ; pour moi un développeur est avant tout un artiste.

Nedjma : Tout à fait ! Comme tu te plais à le dire souvent, il y a une différence entre faire de l’Agilité et être Agile. Au passage, j’ai lu ton dernier article sur ce sujet ; très intéressant. Je pense en effet que l’une des bonnes manières d’arriver à développer son esprit Agile c’est de commencer par utiliser Scrum.

David : Revenons à notre question de départ. Je pense que l’une des réponses importantes à la question, c’est la motivation de l’équipe. Je m’explique : Scrum prône la mise en place d’une équipe pluridisciplinaire, auto-organisée, focalisée et de moins de 10 personnes. Avoir une équipe pluridisciplinaire pourrait être un défi pour l’organisation, car cela nécessite éventuellement de casser des silos. Cependant, c’est une vraie source de motivation, car cela donne à l’équipe une meilleure visibilité sur les objectifs et ça donne aussi un sens à son travail.

L’équipe est ainsi responsabilisée. Elle collabore avec le client ou son représentant dans la réalisation d’une partie du produit à chaque itération. Elle s’engage à suivre son avancement et prend des décisions au quotidien pour trouver le meilleur moyen d’atteindre son objectif. Le résultat est une équipe motivée et performante.

Nedjma : Je vois dans ce que tu dis la déclinaison dans Scrum de la première valeur du manifeste Agile. La réussite des projets Scrum est clairement liée à l’engagement, à la communication et à la collaboration entre les différents rôles, facilités par les règles de la démarche.

David : Parlant du manifeste Agile, on peut facilement associer la plupart des valeurs et principes aux différents éléments de Scrum. C’est un cadre typiquement Agile ; sujet qui pourrait d’ailleurs être l’objet de notre prochaine discussion et de notre prochain article.

Nedjma : Avec plaisir pour la discussion…

Essayons de résumer nos différentes réponses à la question. On choisit Scrum, car :

• Il est léger et simple à comprendre, ce qui permet de démarrer rapidement en Agilité.
• Ses règles permettent de répondre à la complexité.
• Il se base sur une démarche itérative et incrémentale et permet de créer rapidement des incréments de produit fonctionnels et de qualité en mettant l’accent sur un objectif clair à chaque itération.
• Tout cela est réalisé par une équipe responsabilisée, focalisée et engagée qui s’appuie sur les règles de la démarche pour collaborer.
• Au-delà d’apprendre à faire de l’Agilité, Scrum aide à être Agile. C’est une question d’amélioration continue avant tout pour faire face au changement.

Je n’ai rien oublié, cela résume les points que nous avons soulevés ?

David : Parfaitement. Cela dit, malgré tous les points positifs de Scrum que nous avons évoqués, on ne peut pas toujours l’utiliser.

Il y a des situations où on ne peut clairement pas tirer profit de Scrum. Je pense aux équipes qui travaillent en flux continu comme le soutien. Dans ce cas, les méthodes comme Kanban ou encore Agile-Lean seront plus efficaces à mon avis. Par contre, ces méthodes sont à mes yeux moins encadrantes que Scrum et demanderont plus de rigueur et de responsabilité lors de leur mise en place.

Nedjma : Je partage l’idée que Scrum n’est pas adapté à toutes les situations. Tu me fais penser aussi à quelques combinaisons intéressantes entre les méthodes Agiles, comme Scrum et XP. Je trouve que l’utilisation des pratiques d’Extreme Programming dans Scrum (dans le cadre du développement logiciel) a une vraie valeur ajoutée dans le travail de l’équipe. Je pense par exemple au TDD, au Refactoring, au Pair Programming et à l’intégration continue.

David : Donc, si nous sommes capables de définir un cadre de manière Agile, nous n’avons pas besoin de Scrum ?

Nedjma : Pas forcément ! du moment où le nouveau cadre est Agile…