Qu'est-ce que Scrum ?

Scrum est un cadre de travail pour développer, livrer et maintenir des produits complexes grâce à une collaboration d'équipe efficace. Il fournit un processus léger pour concentrer et coordonner l'activité collaborative basée sur l'équipe pendant que l'équipe Scrum s'attaque à des problèmes adaptatifs compliqués et livre un produit de valeur optimale de manière incrémentale et selon un calendrier prévisible.

Initialement conçu par les professeurs Hirotaka Takeuchi et Ikujiro Nonaka et publié sous le titre "The New Product Development Game" dans la Harvard Business Review en 1986, Scrum a été adapté et popularisé par Jeff Sutherland et Ken Schwaber dans les années 1990. Il est devenu une façon de travailler de plus en plus populaire, s'étendant au-delà du développement logiciel vers de nombreux domaines du développement de produits qui peuvent appliquer et bénéficier d'une approche itérative et incrémentale. Il réussit ou échoue selon la compétence technique et les efforts collaboratifs de l'équipe.

D'un point de vue processus, Scrum offre une approche agile simple et extrêmement efficace pour la livraison de produits. Comme il sera montré plus tard, Scrum n'est pas, et n'est pas destiné à décrire une approche agile de la gestion de projet.  

Le framework comprend trois rôles distincts qui constituent une équipe Scrum, chacun avec des responsabilités clairement définies, cinq événements et trois artefacts. Les règles décrites dans Le Guide Scrum lient ensemble les rôles, événements et artefacts, en guidant leurs relations et interactions.

• Les 5 Événements : Le Sprint, Planification de Sprint, Scrum Quotidien, Revue de Sprint, Rétrospective de Sprint
• Les 3 Artefacts : Product Backlog, Sprint Backlog, Incrément Produit
• Les 3 Rôles : Product Owner, Développeur, Scrum Master.

1. Le Sprint est une boîte de temps, qui peut avoir n'importe quelle durée mais dure généralement 2 à 4 semaines, pendant laquelle un ou plusieurs Incréments de Produit « Terminés » (c'est-à-dire utilisables et au moins potentiellement livrables) sont créés. Le Sprint contient tous les autres événements.
2. La Planification de Sprint est le moment où le travail à effectuer lors du prochain Sprint est planifié par les Développeurs. Ils négocient un Objectif de Sprint réaliste avec le Propriétaire du Produit, sélectionnent les éléments appropriés du Backlog de Produit pour contribuer à cet objectif et planifient le travail pour l'atteindre.
3. Le Scrum Quotidien est une réunion de 15 minutes tenue par les Développeurs de l'Équipe Scrum. Il se tient chaque jour du Sprint et les Développeurs l'utilisent pour réaffirmer leur engagement à atteindre l'Objectif de Sprint et ajuster leurs plans en conséquence.
4. La Revue de Sprint se tient à la fin du Sprint. Son objectif est de rendre visible aux parties prenantes ce qui a été livré lors du Sprint, pour leur permettre d'inspecter formellement et de suggérer des adaptations au Backlog de Produit pour guider le développement en cours.
5. La Rétrospective de Sprint est une opportunité pour l'Équipe Scrum de réfléchir à l'efficacité de leur façon de travailler et de créer un plan d'améliorations à mettre en œuvre lors du ou des Sprints suivants.

Les trois artefacts de Scrum sont conçus pour maintenir l'attention sur la valeur à livrer. Ils sont transparents – c'est-à-dire délibérément visibles – pour quiconque s'intéresse à ce que fait l'équipe Scrum et à la façon dont elle s'y prend pour son travail. Chaque artefact inclut un engagement.

Le Product Backlog est une liste ordonnée de tout ce qui doit être fait pour atteindre son Objectif Produit. C'est la source unique de travail pour l'équipe Scrum. Bien qu'il puisse y avoir plus d'un Objectif Produit, par exemple décrivant une feuille de route produit, un seul objectif à la fois fait l'objet de travail. L'Objectif Produit est l'objectif, l'engagement, que le Product Backlog est conçu pour atteindre.

Le Sprint Backlog inclut l'ensemble des éléments du Product Backlog sélectionnés pour un Sprint et tout le travail nécessaire pour atteindre l'Objectif de Sprint. Bien qu'un ou plusieurs Incréments Produit puissent être livrés pendant le Sprint, il n'y a qu'un seul Objectif de Sprint. L'objectif de Sprint est l'engagement pour le Sprint Backlog et c'est ce que les Développeurs s'efforcent d'atteindre.

L'Incrément Produit est ce que les développeurs créent qui répond au besoin décrit par un ou plusieurs éléments du product backlog. C'est une étape tangible vers l'atteinte de l'Objectif de Sprint. Quand plus d'un est livré dans un Sprint, chaque Incrément Produit inclut le précédent. L'engagement est d'atteindre la « Définition de Fini » pour l'Incrément Produit. Cette « Définition de Fini » est une description formelle des standards de qualité nécessaires que le produit doit respecter.

Nous savons grâce au manifeste Agile que les praticiens de l'agilité privilégient les individus et les interactions par rapport aux processus et aux outils – ce qui signifie que bien qu'il y ait une place pour les processus et les outils – et soyons très clairs, Scrum inclut un élément de processus significatif – nous valorisons davantage les personnes et la façon dont elles travaillent ensemble. Les rôles et les responsabilités associées à ces rôles ainsi que les interactions collaboratives entre les individus qui détiennent ces rôles sont fondamentaux pour l'utilisation efficace de Scrum.

Une équipe Scrum est composée d'un Product Owner, d'un Scrum Master et, généralement, de 5 à 9 Développeurs. L'équipe doit être pluridisciplinaire – possédant collectivement toutes les compétences nécessaires pour livrer le produit souhaité et la capacité de collaborer pour atteindre cet objectif. L'équipe s'auto-organise – ne reconnaissant aucune structure hiérarchique et permettant au leadership pour un travail spécifique d'émerger selon les besoins.

Product Owner

Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l'équipe Scrum. Le Product Owner est un individu, non un comité, et représente généralement les besoins de nombreuses parties prenantes, y compris les clients pour qui la valeur est créée. En contribuant au travail de l'équipe Scrum, il est responsable de la gestion efficace du Product Backlog, ce qui inclut :

• Développer et communiquer explicitement l'Objectif Produit.
• Créer et communiquer clairement les éléments du Product Backlog.
• Prioriser les éléments du Product Backlog.
• S'assurer que le Product Backlog est transparent, visible et compris.

Toute partie prenante souhaitant modifier le Product Backlog ne peut le faire qu'à travers le Product Owner.

Développeur

Le rôle de Développeur dans l'équipe Scrum s'applique à toute personne qui collabore activement avec les autres membres de l'équipe pour développer le Produit – même quelqu'un qui occupe également l'un des autres rôles peut être un Développeur. Les compétences nécessaires à un Développeur varient selon le type de travail effectué et ce qui est produit. Les Développeurs travaillant dans une équipe Scrum pour aménager un jardin auront besoin d'un ensemble de compétences très différent de ceux qui préparent un dîner élaboré ou de ceux qui construisent un nouveau jeu pour smartphone. Scrum peut être appliqué dans tous ces environnements de développement.

Dans Scrum, les Développeurs sont toujours responsables de :

• Créer un plan pour le Sprint, le Sprint Backlog ;
• Insuffler la qualité en respectant une Définition de Fini ;
• Adapter leur plan chaque jour vers l'Objectif de Sprint ; et,
• Se tenir mutuellement responsables en tant que professionnels.

Scrum Master

Le Scrum Master est responsable d'établir Scrum tel que défini dans le Guide Scrum. Il le fait en aidant tout le monde à comprendre la théorie et la pratique Scrum, tant au sein de l'équipe Scrum que de l'organisation.

Souvent appelé leader serviteur, le Scrum Master ne détient aucune autorité de commandement – il ne dit pas aux gens quoi faire et comment se comporter, il les aide à comprendre comment Scrum devrait fonctionner et fait ce qu'il peut pour faciliter son adoption. Il fournit un service à :

• L'équipe Scrum – en accompagnant leur adoption de Scrum, en les aidant à trouver des moyens d'améliorer continuellement la façon dont ils délivrent de la valeur et en provoquant la suppression de tout ce qui fait obstacle à cela.
• Le Product Owner – en l'aidant avec la gestion du Product Backlog et en l'aidant à s'assurer que les Objectifs Produit et les éléments du Product Backlog sont correctement façonnés, exprimés et compris.
• L'organisation plus large dans laquelle l'équipe Scrum existe – en l'aidant à comprendre la façon de travailler Scrum et comment elle doit travailler et se comporter pour permettre aux équipes Scrum d'être optimalement efficaces.

Le framework Scrum repose sur la théorie du contrôle de processus empirique, ou empirisme, qui soutient que la connaissance provient de l'expérience et que la prise de décision se base sur ce qui peut être observé. Les piliers du contrôle de processus empirique sont la transparence du processus et des progrès, l'inspection du processus et des progrès et l'adaptation à la fois du produit émergent (l'améliorer à chaque itération et incrément) et des méthodes de travail (améliorer continuellement l'efficacité et la performance de l'équipe).

Il est important de comprendre comment rendre le processus empirique efficace. La Transparence permet l'Inspection, l'Inspection permet l'Adaptation et les Adaptations doivent être Transparentes. Une Inspection sans Transparence est trompeuse et inutile, une Inspection sans intention d'Adaptation est inutile et une Adaptation sans Transparence pour Inspecter son impact rend l'Adaptation risquée.

Les équipes Scrum efficaces vivent et respirent un ensemble de cinq valeurs. Ces valeurs ne sont pas propres à une équipe Scrum, mais en les rendant explicites, elles encouragent un travail d'équipe collaboratif et efficace. Ces valeurs sont l'Engagement, la Concentration, l'Ouverture, le Respect et le Courage.

• Engagement : Les membres de l'équipe Scrum s'engagent à atteindre les objectifs de sprint et à livrer un travail de haute qualité grâce au développement itératif et à la livraison incrémentale. Cela favorise la responsabilité et la redevabilité parmi les membres de l'équipe.
• Courage : Les membres de l'équipe Scrum ont le courage d'aborder ouvertement les défis et les obstacles. Ils sont prêts à prendre des risques et à s'exprimer sur les problèmes qui peuvent affecter le succès de l'équipe.
• Ouverture : Les membres de l'équipe Scrum partagent entre eux les informations, les progrès et les préoccupations, favorisant ainsi la confiance et la collaboration au sein de l'équipe.
• Concentration : Les membres de l'équipe Scrum maintiennent une concentration collective sur les objectifs du produit et du sprint, priorisant leur travail pour optimiser leur livraison de valeur.
• Respect : Les membres de l'équipe Scrum se respectent mutuellement en tant que professionnels, reconnaissant les compétences, perspectives et contributions de chacun dans la livraison du produit. Cela crée un environnement de travail positif et améliore la coopération entre les membres de l'équipe.

Ces valeurs peuvent et doivent être appliquées pour aider à rendre efficace toute méthode de travail agile.

Les valeurs Scrum contribuent collectivement à la capacité de l'équipe Scrum à :

• S'adapter au changement : Scrum est très réactif aux exigences changeantes. Il s'accommode de l'évolution des besoins clients en permettant des ajustements à la fin de chaque sprint, favorisant la flexibilité et une plus grande satisfaction client.
• Collaborer pour prendre des décisions : La nature auto-organisée de l'équipe Scrum et les fondements empiriques de la méthode de travail Scrum encouragent la collaboration. Vivre les valeurs Scrum donne vie au travail collaboratif.  
• S'améliorer continuellement : Scrum intègre des rétrospectives régulières – dont le but est de fournir des opportunités régulières à l'équipe Scrum d'inspecter l'efficacité de leur façon de travailler et d'identifier les domaines d'amélioration. C'est l'amélioration continue en action.
• Adopter une approche centrée sur le client : Scrum met fortement l'accent sur la livraison de valeur au client. Le Product Owner, représentant les intérêts du client, priorise les fonctionnalités, garantissant que le produit s'aligne sur les besoins et attentes du client tout au long de son développement.

Scrum offre de nombreux avantages pour le développement de produits, améliorant l'efficacité, la collaboration et l'adaptabilité :

• Flexibilité
• Mise sur le marché plus rapide
• Collaboration renforcée
• Qualité de produit améliorée
• Satisfaction client accrue
• Productivité plus élevée
• Meilleure gestion des risques
• Transparence
• Équipes autonomisées
• Amélioration continue.

Découvrez-en plus sur les 10 avantages clés de l'utilisation de Scrum, détaillés dans cet article de blog.

Scrum, peut présenter plusieurs défis et inconvénients. Lors de la mise en œuvre de Scrum, comme pour toute nouvelle façon de travailler, il peut y avoir une résistance au changement. Les équipes peuvent avoir des difficultés avec le niveau de collaboration et de communication nécessaire pour que Scrum fonctionne efficacement. Des rôles comme le Scrum Master ont également des responsabilités spécifiques qui diffèrent des rôles traditionnels, et une mauvaise compréhension de ces rôles peut mener à la confusion et à l'inefficacité. Une fois Scrum mis en place, il reste encore des défis à relever, les risques ou inconvénients courants incluent :-

1. Support inadéquat de la direction : Comme pour toute initiative de changement sans un soutien fort de la direction au sein de l'organisation, l'adoption de Scrum rencontrera de la résistance ou fera face à des défis pour surmonter les barrières organisationnelles. Le manque de compréhension du changement culturel nécessaire et un engagement faible à ce niveau aux échelons supérieurs peut sévèrement limiter la valeur que Scrum peut apporter comme façon de travailler.
2. Courbe d'apprentissage : Les perturbations et ajustements initiaux peuvent impacter la productivité alors que les membres de l'équipe s'adaptent aux nouveaux rôles, événements et processus collaboratifs introduits par Scrum. L'adage selon lequel les choses peuvent empirer avant de s'améliorer est souvent vrai. La clé est d'allouer du temps pour l'apprentissage et d'identifier des personnes ayant un historique de réussite dans ce domaine ailleurs qui peuvent aider.
3. Sur-engagement :  Les équipes peuvent faire face au risque de s'engager excessivement dans le travail lors de la planification de sprint, menant à l'épuisement professionnel ou à des compromis dans la qualité des livrables. Équilibrer le désir de progression rapide avec une définition d'objectifs réalistes est crucial pour maintenir des pratiques de développement durables. Il est important d'établir un rythme durable – attendez-vous à échouer dans l'atteinte des Objectifs de Sprint pendant que l'équipe détermine ce qui peut être accompli.
4. Accent excessif sur les objectifs à court terme : L'accent mis sur des sprints courts et de durée fixe dans Scrum peut parfois mener à une vision myope, où les équipes priorisent les objectifs immédiats au détriment des objectifs stratégiques à long terme. Dans un environnement purement produit, un bon Product Owner devrait être capable de communiquer et maintenir un focus approprié à long terme. Face à la complexité, quelque chose de plus peut être nécessaire…
5. Problèmes d'intégration du travail de multiples équipes pour des projets plus grands et plus complexes : Scrum est efficace lorsqu'il est appliqué à des équipes uniques mais extrêmement faible lorsque le travail à accomplir dépasse la capacité des « 10 personnes ou moins » dans l'équipe à l'atteindre. Dans cette circonstance, un cadre plus large pour gérer l'échelle et/ou la complexité est recommandé.

Pour une échelle extrême dans un contexte produit – où des centaines de développeurs sont nécessaires – un cadre à grande échelle tel que SAFe peut être conseillé. Pour des problèmes à plus petite échelle – jusqu'à 100 développeurs, par exemple – et/ou où la complexité de la solution d'affaires globale s'étend sur plusieurs produits, services et autres activités, alors un cadre de projet agile tel qu'AgilePM répondra au besoin.  

S'appuyant sur la question de mise à l'échelle mentionnée ci-dessus, dans cet épisode de la série 'Level Up' d'APMG, des experts en gestion de projet agile répondent à des questions sur la gestion de projet agile et scrum. L'une des questions clés abordées est la différence entre ces approches.  Des sujets tels que la planification de sprint, la durée idéale d'un Sprint et la valeur des réunions quotidiennes debout sont discutés.

L'Agile Business Consortium a fait évoluer son approche de gestion de projet Agile de renommée mondiale (AgilePM) pour fournir une version conçue spécifiquement pour fonctionner avec Scrum. AgilePM for Scrum offre un cadre unique pour la livraison de solutions métier complètes. Il traite explicitement des solutions qui englobent plusieurs produits ou services, nécessitant l'effort de développement combiné de plusieurs équipes Scrum, ou une combinaison d'équipes Scrum et non-Scrum. Avec des techniques pour gérer la planification et la coordination agiles inter-équipes, le leadership du point de vue de la vision métier, de l'architecture de solution et de la gestion de projet, la gouvernance, les risques, et plus encore, cela vaut vraiment la peine d'être considéré pour cette situation de projet plus complexe.

Dans cette vidéo, Richard Pharro, PDG d'APMG International, et moi-même discutons d'« AgilePM for Scrum ». Ce nouveau cadre fusionne les forces de deux frameworks Agile de premier plan. Richard pose des questions clés, visant à fournir des éclairages sur le cadre, notamment sa portée, la logique derrière son développement, et qui bénéficierait le plus de ce cadre. De plus, nous explorons le programme de formation et certification accrédité soutenant ce cadre.

Scrum a ouvert une voie significative pour l'agilité dans le développement de produits logiciels et constitue une approche très populaire et polyvalente à juste titre, étant parfaitement adaptée pour livrer des produits qui ravissent les clients face à des exigences complexes et évolutives. Elle tire parti des avantages d'équipes transversales et collaboratives pour fournir de la valeur plus rapidement et efficacement que leurs homologues moins agiles.

Ce n'est pas sans défis, cependant... Ken Schwaber et Jeff Sutherland déclarent dans leur Guide Scrum 2020 que « Le cadre Scrum, tel qu'exposé ici, est immuable. Bien qu'il soit possible de n'implémenter que certaines parties de Scrum, le résultat n'est pas Scrum. Scrum n'existe que dans son intégralité… »

Scrum est un cadre agile simple, élégant et efficace pour la livraison de produits. Cela a été prouvé maintes et maintes fois partout dans le monde dans de nombreuses applications différentes à travers de nombreuses industries différentes, mais seulement lorsqu'il est utilisé dans son intégralité. Si vous omettez un élément de Scrum, cela ne fonctionnera tout simplement pas correctement. Scrum fonctionne, ScrumMais risque l'échec. ScrumMais décrit une situation où « nous utilisons Scrum mais nous ne faisons pas ceci ».  Pour « nous ne faisons pas ceci », insérez ce que vous voulez… « Nous ne faisons pas de Scrum quotidien », « nous ne collaborons pas », « nous n'avons pas de Scrum Master, nous avons un manager », « nous n'avons pas de backlog produit, nous avons une spécification », « nous ne définissons pas d'objectif de Sprint », etc. Schwaber et Sutherland ont développé Scrum, ont supervisé son évolution progressive et soigneuse depuis le milieu des années 1990 – acceptez leur sagesse et faites-le correctement.  

Si votre domaine est le développement de produits, alors il est facile de voir comment apporter l'agilité à ce domaine en appliquant et en améliorant continuellement l'application de Scrum pourrait fournir un bénéfice considérable. Mais si votre préoccupation s'étend au-delà du pur développement de produits alors, utilisé seul, Scrum pourrait s'avérer inadéquat.

La formation, l'éducation et l'encouragement et le soutien continus des équipes Scrum sont nécessaires pour tirer parti du succès de Scrum. APMG propose les certifications suivantes pour les rôles clés.

Ce cours vous apprend à exceller en tant que Scrum Master, en améliorant le développement de produits et de solutions en utilisant Scrum. Les apprentissages clés incluent une compréhension approfondie du Framework Scrum, des principes Scrum, et du rôle de Scrum Master. Vous apprendrez également à créer des équipes de développement efficaces, à agir en tant que leader-serviteur, à faciliter les événements Scrum, à aider les Product Owners dans la gestion du backlog, et à promouvoir l'adoption de Scrum.

Dans ce cours, apprenez à maximiser la valeur des produits livrés par les équipes Scrum. Acquérez une compréhension approfondie du Framework Scrum et du rôle du Product Owner Scrum. Maîtrisez les principes Scrum et apprenez à construire et prioriser un backlog produit axé sur la valeur, en décomposant les épopées et thèmes en user stories exploitables.

Le premier jour des formations Scrum Master et Product Owner est identique – parlez à votre prestataire de formation APMG de la possibilité de dispenser cette journée comme un cours autonome idéal pour les membres d'équipe et les parties prenantes. Elle couvre tout ce qui se trouve dans le Guide Scrum – et ils ont besoin de tout connaître.   

AgilePM for Scrum combine Scrum avec l'approche de gestion de projet agile leader mondial (AgilePM) pour offrir un cadre unique pour la livraison de solutions métier complètes où un développement itératif et incrémentiel est requis. Cette certification vous dote des compétences nécessaires pour intégrer Scrum avec la Gestion de Projet Agile. Les cours abordent les principes et la théorie qui sous-tendent le cadre Scrum – dispensés par des prestataires accrédités APMG et Agile Business Consortium.

L'image du 'Scrum Framework' a été créée par l'Agile Business Consortium. Copyright © 2024, Agile Business Consortium. Tous droits réservés.