Agile et Scrum, deux mots qui, de nos jours, sont à la fois encensés et décriés.
Souvent (mal) utilisés comme synonymes l’un de l’autre.

Lors du Shared Community nous avons commencé par un workshop. Pourquoi expliquer quelque chose en tant que présentateur alors que votre public peut apprendre plus par la pratique.

AGILE

Agile se compose de 4 valeurs et 12 principes que l’on peut trouver sur Internet (Manifeste pour le développement Agile de logiciels (agilemanifesto.org)), en réalité plus une grande page web qu’un site web. Pourtant, des fleuves d’encre ont coulé sur ces mots, des amitiés se sont formées et brisées sur leurs interprétations.

Les 4 valeurs sont:

• Les individus et leurs interactions plutôt que les processus et les outils
• Des logiciels opérationnels plutôt qu’une documentation exhaustive
• La collaboration avec les clients plutôt que la négociation contractuelle
• L’adaptation au changement plutôt que le suivi d’un plan

Les valeurs de droite sont importantes, mais les valeurs de gauche le sont davantage. Vous avez donc besoin des deux pour réussir un projet ou un produit, mais dans la bonne proportion.

Les 12 principes sont:

• Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
• 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.
• Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
• Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
• 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.
• 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.
• Un logiciel opérationnel est la principale mesure d’avancement.
• 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.
• Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.
• La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
• Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
• À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Les 12 principes soutiennent les 4 valeurs et reviennent en fait à utiliser votre bon sens.

Laissez les personnes compétentes gérer leur propre travail, assurez-vous que l’IT ait beaucoup de contact avec le Business et les utilisateurs potentiels afin qu’il y ait beaucoup de retours sur ce que le client souhaite et le produit (logiciel, service…) que l’IT fournit. Livrez en petites quantités afin de pouvoir toujours faire des ajustements selon les souhaits de votre client ou si le marché change.

C’est si simple, et pourtant de nombreuses entreprises ont encore du mal à mettre en œuvre Agile correctement.

Considérez Agile comme une philosophie vers laquelle vous aspirez, qui est un guide pour vous aider à rendre une entreprise résiliente et agile sur le marché actuel, mais comme toute philosophie, vous ne pouvez pas l’implémenter directement, vous devez mettre en œuvre des actions qui soutiennent votre philosophie.

Ces actions sont représentées dans Agile par les frameworks Agile, avec le framework Scrum responsable de 80% de toutes les réalisations Agile.

D’autres frameworks Agile sont eXtreme Programming (XP), Dynamic System Development Method (DSDM), Crystal, Feature Driven Development (FDD), Cynefin et des centaines d’autres.

SCRUM

Scrum est le framework Agile le plus utilisé. Vous pouvez tout trouver à ce sujet dans le Guide Scrum (Home | Scrum Guides). La version actuelle du Guide Scrum fait 14 pages, 12 pages si vous ne comptez pas la page de titre et la page d’index.
Scrum est un cadre léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes. En bref, Scrum nécessite un Scrum Master pour favoriser un environnement où:

• Un Product Owner ordonne le travail pour un problème complexe dans un Product Backlog.
• L’équipe Scrum transforme une sélection de ce travail en un Incrément de valeur pendant un Sprint.
• L’équipe Scrum et ses parties prenantes inspectent les résultats et s’adaptent pour le prochain Sprint.
• Répétez.

Les 3 responsabilités sont:

• Scrum Master: responsable d’enseigner Scrum aux Développeurs, au Product Owner et à l’Organisation.
• Product Owner: voix du client, responsable de maximiser la valeur du produit.
  
• Développeurs: Les personnes engagées à créer tous les aspects d’un Incrément utilisable à chaque Sprint.

Les 5 événements sont:

• Sprint: Le Sprint est le conteneur de Scrum dans lequel tous les autres événements ont lieu. Les Sprints ont une durée fixe d’un mois ou moins. Un nouveau Sprint commence immédiatement après la fin du Sprint précédent.
• Sprint Planning: La Sprint Planning lance le Sprint en définissant le travail à effectuer pour le Sprint. Le plan résultant est créé par le travail collaboratif de toute l’équipe Scrum.
• Daily Scrum: Le but du Daily Scrum est d’inspecter les progrès vers l’objectif du Sprint et d’adapter le Sprint Backlog si nécessaire. C’est un événement de 15 minutes pour les Développeurs.
• Sprint Review: Le but est d’inspecter le résultat du Sprint et de déterminer les adaptations futures. L’équipe Scrum présente les résultats de leur travail aux parties prenantes et les progrès sont discutés.
• Sprint Retrospective: Le but est de planifier des moyens d’augmenter la qualité et l’efficacité. L’équipe Scrum inspecte comment le Sprint s’est déroulé en ce qui concerne les individus, les interactions, les processus et les outils.

Les 3 artéfacts avec leur engagement sont:

• Product Backlog avec Product Goal: Le Product Backlog est une liste vivante et ordonnée de ce qui est nécessaire pour améliorer le produit. C’est la seule source de travail effectué par l’équipe Scrum.
• Sprint Backlog avec Sprint Goal: Le Sprint Backlog est composé de l’objectif du Sprint (pourquoi), l’ensemble des éléments du Product Backlog sélectionnés pour le Sprint (quoi), et un plan actionnable pour livrer l’Incrément (comment).
• Incrément avec Definition of Done: Un Incrément est un pas concret vers l’objectif du produit. Chaque Incrément s’ajoute à tous les Incréments précédents et est minutieusement vérifié pour s’assurer que tous les Incréments fonctionnent ensemble. Pour créer de la valeur, l’Incrément doit être utilisable.

Comme vous pouvez le voir, Scrum est un cadre incomplet (ou un crochet) qui ne comprend que le minimum en termes de rôles, de réunions et de produits.
Tout le reste doit être ajouté par l’équipe Scrum elle-même, avec l’aide du Scrum Master. Cela est fait délibérément afin que chaque version d’une mise en œuvre de Scrum puisse être parfaitement adaptée aux besoins spécifiques d’une équipe.
Certains ajouts sont tirés d’autres frameworks, comme par exemple eXtreme Programming (Test Driven Development, continuous integration/continuous deployment, test automation), Kanban (Work In Progress, Cycle Time, Work Item Age, Throughput) ou de pratiques de développement (ingénierie des exigences, analyse d’affaires, tests, devops…).

Quelle que soit ce que vous ajoutez à votre interprétation de Scrum, utilisez la philosophie Agile comme guide pour que votre framework personnel soit Agile.

Écrit par: René G.