Accueil Nos publications Blog En quoi Scrum est agile ?

En quoi Scrum est agile ?

Lorsqu’on demande autour de nous ce qu’est l’Agilité, on nous répond souvent que c’est “faire du Scrum”. C’est sans doute parce que c’est la méthode la plus connue et la plus appliquée dans le monde selon le 12th Annual State of Agile Report.

Mais Scrum est-il réellement agile ?

Pour le savoir, il est déjà nécessaire de définir les 2 notions de cette question : Agile et Scrum.

L’agilité est une façon de penser décrite officiellement en 2001 dans le Manifeste Agile. Ce manifeste nous dit que, pour être agile, il faut respecter 4 valeurs en s’aidant des 12 principes qui en découlent. Au final, une organisation agile est une organisation qui sait s’adapter à son contexte et satisfaire ses clients tout en respectant les individus et les interactions qui la composent.

En théorie, une organisation qui a pour objectif de devenir agile se devra de respecter à minima les 12 principes du manifeste agile. Encore faut-il les comprendre et adapter sa manière de travailler. C’est à ce moment là qu’interviennent les méthodes agiles, car elles fournissent des outils et un cadre propices à la transformation agile.

Ce lien valeurs – méthodes peut être expliqué via le Cercle d’or de Simon Sinek, qui explique que tout commence par un “Pourquoi” (pourquoi l’agilité?), auquel on répond par un “Comment” (comment devient-on agile?) et dont l’application concrète se fait par un “Quoi” (quelles méthodes pour appliquer ces principes agiles?).

Scrum, telle que définie dans le Scrum Guide, nous fournit un cadre rigide et clé en main pour mener des projets à bien tout en étant agile. Du moins, en théorie, car qui nous dit que Scrum respecte les 12 principes du manifeste agile?

 

Les principes liés à Scrum

Principe #1

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Scrum Guide

“Scrum (n) : 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.”

“Les équipes Scrum livrent des produits de manière itérative et incrémentale, maximisant ainsi les opportunités de retour d’information.”

Un Sprint est une période de temps fixe durant laquelle l’équipe Scrum travaille sur un incrément de son produit. Cet incrément doit être potentiellement livrable à la fin du Sprint. Un projet Scrum est une succession de Sprints, donc une succession d’incréments terminés sur un tempo régulier. La durée maximale d’un Sprint est d’un mois, ce qui permet un cycle de livraison plus rapide qu’un cycle en V.


Principe #2

Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

Scrum Guide

“ Les exigences ne cessent jamais de changer, de sorte qu’un Backlog produit est un artefact vivant. Les changements de besoins de l’organisation, des conditions de marché ou de la technologie peuvent entraîner des changements dans le Backlog produit.”

À chaque début de Sprint, lors du Sprint Planning, l’équipe Scrum décide de travailler sur les demandes les plus prioritaires du moment, peu importe les prévisions qui ont pu être faites en amont. De même, à chaque fin de Sprint, lors de la Revue de Sprint, l’équipe Scrum fait le point sur ce qui a été fait lors du Sprint et peut décider de garder ou de mettre de côté certains items pour le prochain Sprint. Ces deux événements permettent d’inspecter et de mettre à jour le Backlog Produit.


Principe #3

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Scrum Guide

“Les sprints sont limités à un mois calendaire. Lorsque l’échéance d’un Sprint est trop longue, la définition de ce qui est en cours de construction peut changer, la complexité peut augmenter et le risque peut s’accroître.”

Chaque incrément est potentiellement livrable, ce qui permet de laisser le produit opérationnel. La livraison est cadencée par les Sprints, dont la durée ne doit pas dépasser un mois.


Principe #4

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

Scrum Guide

“Si le travail se révèle différent de ce qui a été prévu, l’équipe de développement collabore avec le Product Owner et négocie le périmètre du Backlog Sprint durant le sprint.“

Les événements permettent aux membres de l’équipe Scrum de communiquer régulièrement au cours du Sprint. Il y en a 4 définis dans Scrum, dont 3 qui mettent en relation le Product Owner, représentant des utilisateurs, et l’Équipe de Développement : le Sprint Planning, la Revue de Sprint et la Rétrospective.


Principe #5

Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

Scrum Guide

“Lorsque les valeurs d’engagement, courage, focus, ouverture et respect sont incarnées et vécues par l’équipe Scrum, les piliers Scrum de transparence, d’inspection et d’adaptation émergent et
consolident la confiance entre tout le monde.”

Scrum nous dit que pour que l’application de la méthode fonctionne, il faut travailler avec des personnes capables de respecter ses valeurs (engagement, courage, focus, ouverture et respect). Un des rôles du Scrum Master est de s’assurer que les événements Scrum sont respectés, car ils offrent un cadre verrouillé avec des mini objectifs, qui permettent de construire un environnement rassurant pour l’Équipe Scrum.


Principe #6

La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

Scrum Guide

“Ces événements sont spécifiquement conçus pour permettre la transparence et l’inspection. Ne pas inclure l’un de ces événements entraîne une transparence réduite et constitue une occasion perdue d’inspection et d’adaptation.”

Le Sprint Planning, la Revue de Sprint et la Rétrospective sont des moments privilégiés d’échanges entre le Product Owner et l’Équipe de Développement. Le Daily Scrum Meeting permet à l’équipe de développement de partager, chaque jour, sur les moyens mis en œuvre pour atteindre l’objectif du sprint sur les prochaines 24h.


Principe #7

Un logiciel opérationnel est la principale mesure d’avancement.

Scrum Guide

“ À la fin d’un Sprint, le nouvel incrément doit être « Fini », ce qui implique qu’il doit être dans un état publiable (…).”

L’incrément produit en fin de sprint doit être opérationnel car potentiellement publiable.


Principe #8

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Scrum Guide

“ Si l’équipe de développement détermine qu’elle a trop ou pas assez de travail, elle peut renégocier les éléments du Backlog Produit choisis avec le Product Owner.”

Le fait de travailler en petites itérations (Sprints) permet d’avoir un rythme constant. Lors du Sprint Planning, l’équipe définit grâce à son expérience ce qu’elle va être capable de faire, cela lui garantit un rythme soutenable. La Rétrospective à la fin du sprint permet à l’équipe de prendre une pause avant de repartir de plus belle !


Principe #9

Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.

Scrum Guide

“Au fur et à mesure que les équipes de Scrum mûrissent, on s’attend à ce que leurs définitions de « Fini » se développent pour inclure des critères plus stricts pour une meilleure qualité. ”

L’Equipe de Développement doit être auto-organisée et pluridisciplinaire. Elle est donc capable de décider des meilleures solutions techniques pour remplir l’objectif du sprint et dispose de toutes les connaissances nécessaires.

Chaque incrément potentiellement livrable doit être fonctionnel : cela implique une excellence technique et une bonne conception,

La Definition Of Done permet également d’appliquer des critères de qualité à la validation de cet incrément.


Principe #10

La simplicité _c’est-à-dire l’art de minimiser la quantité de travail inutile_ est essentielle.

Scrum Guide

“Les événements prescrits sont utilisés par Scrum pour créer la régularité et minimiser le besoin de réunions non définies par Scrum.”

On parle ici de l’essence même de Scrum. Un cadre simple avec le strict minimum à respecter pour remplir un objectif : Événements, Artefacts et Rôles.


Principe #11

Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.

Scrum Guide

“Les équipes Scrum (Scrum Teams) sont auto-organisées et pluridisciplinaires.”

Une Equipe Scrumest auto-organisée et dispose de tout ce qu’il lui faut pour maîtriser au mieux son produit.


Principe #12

À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Scrum Guide

“La rétrospective de Sprint (Sprint Retrospective) est une opportunité pour l’équipe Scrum de s’auto-inspecter et de créer un plan d’améliorations à adopter au cours du prochain Sprint.”

Quoi de mieux qu’une Rétrospective à la fin de chaque sprint pour essayer de s’améliorer en prenant des actions concrètes ?

Conclusion

Ce qui est certain, c’est que le Scrum Guide suivi à la lettre permet bien de respecter les 12 principes du manifeste agile. Ouf, nous voilà rassurés !

En réalité nous en étions à peu près convaincus avant de rédiger l’article, cependant nous savons par expérience que Scrum n’est que rarement appliqué à 100%, car les équipes font souvent le tri et piochent ce qui leur plaisent dans le Scrum Guide.

Nous espérons qu’à travers cet article vous saurez quel principe vous fait le plus défaut et quelle partie du Scrum Guide vous aurez le plus à travailler.

N’oubliez pas que Scrum définit le strict minimum pour réussir. Si respecter une des règles vous paraît trop compliqué, commencez par chercher ce qui rend les choses si difficiles. Peut-être avez-vous par exemple introduit des complications qui peuvent être retirées ?

Enfin on vous rassure, ce n’est pas parce que vous ne faites pas du Scrum que vous n’êtes pas agiles, si tout va bien chez vous il n’y a pas de raisons de changer, bravo !