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 traite des problèmes adaptatifs compliqués et livre un produit de valeur optimale de manière incrémentale et selon un calendrier prévisible.

Conçu à l'origine 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 plus en plus populaire de travailler, s'étendant au-delà du développement logiciel vers de nombreux domaines de 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 nous le verrons 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 composent une équipe Scrum, chacun avec des responsabilités clairement définies, cinq événements et trois artefacts. Les règles décrites dans The Scrum Guide lient ensemble les rôles, événements et artefacts, guidant leurs relations et interactions.

• Les 5 événements : le Sprint, la planification de Sprint, le Scrum quotidien, la revue de Sprint, la rétrospective de Sprint
• Les 3 artefacts : Product Backlog, Sprint Backlog, incrément de produit
• Les 3 rôles : Product Owner, développeur, Scrum Master.

1. Le Sprint est une période délimitée dans le temps, qui peut avoir n'importe quelle durée mais dure généralement 2 à 4 semaines, durant 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 l'endroit où le travail à effectuer dans le prochain Sprint est planifié par les Développeurs. Ils négocient un Objectif de Sprint réaliste avec le Product Owner, sélectionnent les éléments appropriés du Product Backlog pour contribuer à cet objectif et planifient le travail pour l'atteindre.
3. Le Daily Scrum est une réunion de 15 minutes tenue par les Développeurs de l'Équipe Scrum. Elle a lieu 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é dans le Sprint, pour leur permettre d'inspecter formellement et de suggérer des adaptations au Product Backlog pour guider le développement en cours.
5. La Rétrospective de Sprint est une opportunité pour l'Équipe Scrum de réfléchir sur l'efficacité de leur façon de travailler et de créer un plan d'améliorations à mettre en œuvre lors du prochain Sprint 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 toute personne qui s'intéresse à ce que fait l'équipe Scrum et à la façon dont elle s'y prend pour accomplir 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 d'un 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é valorisent les individus et les interactions plus que les processus et les 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 occupent 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 des tâches spécifiques 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 d'une gestion efficace du Product Backlog, qui comprend :

• 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 soit transparent, visible et compris.

Toute partie prenante souhaitant modifier le Product Backlog ne peut le faire que par l'intermédiaire du 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 requises par 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 ;
• Instiller la qualité en adhérant à une définition de terminé ;
• Adapter leur plan chaque jour vers l'objectif du 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 chacun à 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 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 cadre Scrum s'appuie 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 (en l'améliorant à chaque itération et incrément) et des méthodes de travail (en améliorant 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 aux équipes 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 du 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é entre 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, en 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, les perspectives et les 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 rendre efficace toute méthode de travail agile.

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

• S'adapter au changement : Scrum répond efficacement aux exigences changeantes. Il accommode 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 le fondement empirique 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'examiner l'efficacité de leur façon de travailler et d'identifier les domaines d'amélioration. Il s'agit de 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, s'assurant 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é supérieure
• Meilleure gestion des risques
• Transparence
• Équipes autonomes
• Amélioration continue.

Découvrez davantage sur les 10 avantages clés de l'utilisation de Scrum, détaillés dans ce blog.

Scrum peut présenter plusieurs défis et inconvénients. Lors de la mise en œuvre de Scrum, comme pour toutes les nouvelles méthodes de travail, 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 conduire à de la confusion et à de l'inefficacité. Une fois Scrum mis en œuvre, il y a encore des défis à relever, les risques ou inconvénients courants incluent :-

1. Soutien inadéquat de la direction : Comme pour toute initiative de changement sans un soutien solide 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 supérieur peuvent sévèrement limiter la valeur que Scrum peut apporter comme méthode de travail.
2. Courbe d'apprentissage : Les perturbations et ajustements initiaux peuvent impacter la productivité tandis 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 déjà réussi à faire fonctionner cela ailleurs et qui peuvent aider.
3. Surengagement : Les équipes peuvent faire face au risque de s'engager excessivement dans le travail lors de la planification de sprint, conduisant à l'épuisement professionnel ou au compromis sur la qualité des livrables. Équilibrer le désir de progrès 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 soutenable – 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'attention portée aux sprints courts et de durée fixe dans Scrum peut parfois conduire à une vision myope, où les équipes priorisent les objectifs immédiats au détriment des objectifs stratégiques à long terme. Dans un environnement produit pur, un bon Product Owner devrait être capable de communiquer et maintenir une orientation appropriée à long terme. Face à la complexité, quelque chose de plus peut être nécessaire…
5. Problèmes d'intégration du travail de plusieurs équipes pour des projets plus importants et plus complexes : Scrum est efficace lorsqu'appliqué à des équipes uniques mais extrêmement faible lorsque le travail à accomplir dépasse la capacité des « 10 personnes ou moins » de l'équipe à le réaliser. Dans cette circonstance, un cadre plus large pour traiter 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 évolutif tel que SAFe peut être conseillé. Pour des problèmes d'échelle plus petite – jusqu'à 100 développeurs, par exemple – et/ou lorsque la complexité de la solution métier 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 aux 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, de la gouvernance, des risques, et plus encore, cela vaut vraiment la peine d'être considéré pour ces situations de projet plus complexes.

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 cadres Agile de premier plan. Richard pose des questions clés, visant à fournir des perspectives sur le cadre, notamment sa portée, la logique derrière son développement, et qui est le plus susceptible de bénéficier de ce cadre. De plus, nous explorons le programme de formation et de certification accrédité soutenant ce cadre.

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

Cependant, elle n'est pas sans défis... Ken Schwaber et Jeff Sutherland déclarent dans leur Guide Scrum 2020 que « Le cadre Scrum, tel que décrit ici, est immuable. Bien qu'il soit possible d'implémenter seulement 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 nombreux secteurs différents, 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, ScrumBut risque l'échec. ScrumBut 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 des spécifications », « nous ne définissons pas d'Objectif de Sprint », etc. Schwaber et Sutherland ont développé Scrum, ont supervisé son évolution graduelle et minutieuse 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 de 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 vos préoccupations s'étendent au-delà du pur développement de produits, alors, de manière autonome, Scrum peut s'avérer insuffisant.

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, 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 à constituer des équipes de développement efficaces, à agir comme un 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 epics et les thèmes en user stories exploitables.

Le premier jour des formations Scrum Master et Product Owner est identique – parlez à votre organisme de formation APMG de la possibilité de suivre cette journée comme formation autonome idéale 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 la plus reconnue au monde (AgilePM) pour offrir un cadre unique pour la livraison de solutions métier complètes où un développement itératif et incrémental 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.