---

Une certification Scrum Master économique : votre plan pas à pas

Nous sommes fiers d’annoncer que cet article a été mis à l’honneur…
ICI sur LinkedIn >>>

Depuis que le cadre Scrum est devenu l’un des meilleurs moyens de développer et de livrer des logiciels, tout le monde semble poursuivre le même objectif.

Se réveiller le matin, ouvrir son ordinateur portable et savourer la tranquillité enthousiasmante de posséder quelque chose comme ceci :

Une certification Scrum Master.

C’est le rêve, n’est-ce pas ?

Livrer d’excellents logiciels à vos employeurs et clients.

Mener une carrière formidable grâce à vos compétences et votre savoir-faire dans le processus Scrum et à votre certification Scrum Master.

Pour la plupart des gens, la certification Scrum Master constitue le premier pas dans le cadre Scrum.

Dans cet article, je souhaite pour la première fois partager avec vous un guide approfondi et détaillé, étape par étape, pour vous aider à obtenir votre certification Scrum Master.

À moindre coût, rapidement, en ligne et sans difficulté !

En quatre étapes simples seulement, vous pouvez devenir un excellent professionnel Scrum grâce à votre certification Scrum Master.

Cet article vise à vous montrer comment Scrum peut soutenir votre carrière et améliorer votre efficacité professionnelle, ainsi que les raisons de développer dès maintenant les compétences et capacités d’un Scrum Master.

Définition : qu’est-ce que la certification Scrum Master ?

Vous trouverez la meilleure définition de ce qu’est certification Scrum Master sur International Scrum Institute™de Scrum Master Accredited Certification™.

La certification Scrum Master est la preuve de vos compétences dans le processus Scrum de développement et de livraison de logiciels. La certification Scrum Master reconnaît vos connaissances démontrées et votre expertise remarquable du cadre Scrum après une évaluation formelle par examen à choix multiples.

Le processus de développement logiciel Scrum a apporté d’immenses avantages à des millions de professionnels jusqu’à aujourd’hui. Il n’y a donc aucune raison de ne pas rejoindre ces hommes et femmes accomplis qui ont développé leur carrière et leurs compétences grâce au cadre Scrum.

Si vous vous posez encore la question, je tiens à vous assurer qu’une carrière en progression ne s’envisage plus sans certification Scrum Master. Quels que soient votre rôle, votre titre et votre expérience dans l’écosystème des technologies de l’information (IT) .

Vous n’avez même plus besoin d’être un professionnel informatique pour comprendre ce qu’est Scrum, comment il fonctionne et obtenir une certification Scrum Master.

Quel que soit votre métier, que vous apparteniez ou non à un service informatique, un fait essentiel et indiscutable demeure : les tâches et la valeur professionnelle que vous apportez à votre organisation dépendent de l’informatique, des logiciels et des processus et principes agiles Scrum.

De plus, avec la transformation des modèles d’affaires traditionnels en entreprises fondées sur le logiciel en tant que service (SaaS) ou ce qu’on appelle le mouvement de numérisation, la certification Scrum Master n’est plus un choix facultatif pour un professionnel, au sein ou en dehors du service informatique. Aujourd’hui, obtenir une certification Scrum Master est donc indispensable.

Vous débutez peut-être votre carrière ou êtes déjà un professionnel informatique expérimenté. Peu importe : vous devez obtenir votre certification Scrum Master.

Votre rôle peut comprendre ou non la gestion de personnes et de fonctions. Cela ne change rien : vous avez toujours besoin d’une certification Scrum Master.

Vous portez peut-être un titre comme :

• analyste métier,
• architecte logiciel,
• architecte d’entreprise,
• concepteur logiciel
• concepteur d’expérience utilisateur (UX),
• concepteur d’interface utilisateur (UI),
• développeur logiciel,
• responsable du développement logiciel,
• ingénieur de test,
• spécialiste de l’automatisation des tests,
• responsable des tests,
• spécialiste de l’exploitation des systèmes informatiques,
• administrateur Unix/Linux,
• ingénieur en sécurité de l’information (InfoSec),
• ingénieur réseaux informatiques,
• administrateur de bases de données (DBA),
• chef de projet,
• responsable de programme,
• chef de produit,
• chef d’équipe, responsable, directeur ou dirigeant,
• ou tout autre titre que je n’ai pas cité ici.

Vous devriez découvrir le cadre de développement logiciel Scrum et devenir Scrum Master dès aujourd’hui en obtenant votre certification Scrum Master.

3 sources de chaos et de frustration avant le processus agile Scrum et les certifications Scrum Master

Pour mieux comprendre l’effet du cadre Scrum sur nos pratiques d’ingénierie logicielle et nos entreprises, examinons une journée de travail (ou un projet logiciel).

Je voudrais donc parler brièvement d’un ancien projet logiciel, avant que nous adoptions le cadre Scrum de développement et de livraison de logiciels dans nos organisations.

Quelques jours avant d’écrire ces lignes, j’ai déjeuné avec un ancien collègue avec qui je travaillais il y a près de 20 ans. Cet homme, Marcus, a obtenu ses certifications Scrum Master et Scrum Product Owner auprès de International Scrum Institute™.

Il travaille actuellement comme Scrum Master dans l’une des principales sociétés de logiciels du domaine de la gestion de projet agile.

En tant que Scrum Master, Marcus accompagne aujourd’hui une équipe agile Scrum dont les membres sont répartis dans différentes régions du monde.

Pendant notre déjeuner, Marcus a reconnu que les équipes agiles Scrum distribuées rencontrent de nombreux défis courants. Parmi les problèmes propres à la configuration de son projet logiciel, il a notamment cité :

• Des différences de méthodes de travail entre les membres de l’équipe Scrum,
• Les décalages horaires,
• Les incompatibilités culturelles, et
• Les contraintes linguistiques.

Malgré ces difficultés, Marcus a ajouté que mener un projet logiciel avec le processus agile Scrum est plus agréable, plus productif et plus enrichissant que notre façon de travailler il y a 20 ans. Par rapport à l’époque où nous travaillions sans processus Scrum de développement et de livraison de logiciels.

L’affirmation de Marcus était un témoignage fort en faveur du cadre Scrum, de la part d’un responsable, Scrum Master et Product Owner très accompli et expérimenté.

Merci, Marcus !

Je lui ai ensuite raconté l’un de mes anciens projets logiciels, avant ma découverte du cadre Scrum. Je suis certain que de nombreux Scrum Masters retrouveront dans cette expérience leurs projets précédant leur certification Scrum Master.

À la fin des années 1990, je faisais partie d’une équipe d’ingénierie logicielle chargée de construire un système à carte à puce de infrastructure à clés publiquesbasée sur des cartes à puce. Celles-ci protégeaient les clés privées des membres de l’infrastructure ; les clés publiques associées et leurs certificats étaient librement distribués, comme l’indique leur nom.

À l’époque, il s’agissait déjà d’un projet informatique relativement complexe, exigeant plusieurs équipes interdépendantes de génie matériel et logiciel. Nous devions mener d’importants travaux de recherche et développement (R&D) pour construire un système matériel et logiciel pleinement fonctionnel.

Rappelez-vous, c’était avant l’existence du produit minimum viable (MVP) pour expérimenter, créer, apprendre et expérimenter à nouveau.

Si vous souhaitez en savoir plus sur la création d’un MVP avec une méthode agile, consultez cet article de Cleevio, qui vous donnera une meilleure vue d’ensemble de ce processus complexe.

Créer sans Scrum une infrastructure aussi sophistiquée, comprenant de nombreux éléments matériels et logiciels, était un véritable défi.

Voici trois revers importants que nous subissions sans Scrum Masters ni titulaires d’une certification Scrum Master dans nos équipes.

1re source de chaos et de frustration sans certification Scrum Master : nous devions planifier tout le projet avant de comprendre de quoi il s’agissait

Sans Scrum, nos équipes avaient construit et livré des produits logiciels et matériels totalement inadaptés, qui ne répondaient pas aux demandes de notre client.

À certaines périodes de notre vie professionnelle, des entreprises tierces nous imposaient la manière de construire nos produits ou services logiciels.

Capability Maturity Model (CMM), ISO 9001:2008 et d’autres dérivés tentaient d’aider nos entreprises à construire les bons logiciels de la bonne façon.

Leur réussite n’est pas le sujet de cet article. Celui-ci vise à se concentrer sur le processus Scrum et les mérites d’une certification Scrum Master, plutôt qu’à présenter les normes de gestion de la qualité et d’amélioration des processus comme des alternatives disparues à Scrum.

Je dois toutefois ajouter que ces cadres d’amélioration des processus, antérieurs au cadre d’ingénierie logicielle Scrum, étaient mis en œuvre dans nos projets par étapes. Nous utilisions une démarche d’ingénierie logicielle par phases appelée le modèle d’ingénierie logicielle en cascade.

Avec le modèle en cascade, chaque projet logiciel devait commencer par une analyse des besoins, pour comprendre ce dont notre client avait besoin et ce qu’il souhaitait.

Nous concevions ensuite ces besoins, les mettions en œuvre, les testions (vérifions) et les maintenions dans nos environnements de production logicielle. Nous arrivions enfin au terme du cycle de vie de l’ingénierie logicielle.

Mais la réalité ne se déroulait pas ainsi !

Les effets négatifs des retards imprévus survenus pendant une phase du modèle en cascade se répercutaient inévitablement sur les phases suivantes de l’ingénierie logicielle.

C’était la vie avant le cadre Scrum.

Les allers-retours de nos logiciels entre les différentes équipes, sans l’accompagnement de professionnels certifiés Scrum Master, rendaient notre travail bureaucratique, complexe et improductif.

Finalement, le produit n’était pas le seul à en souffrir : le moral des employés et leur engagement envers notre mission organisationnelle étaient eux aussi complètement déstabilisés.

2e source de chaos et de frustration sans certification Scrum Master : manque d’engagement, de gestion du changement et de discipline de collaboration entre les équipes

La principale faiblesse des cadres d’amélioration antérieurs à Scrum était la suivante : Elles se concentraient principalement sur les exigences organisationnelles de la direction, au service de ses propres intérêts.

notamment surveillance, conformité et prévisibilité. Bien servir les clients et améliorer le moral des employés n’étaient absolument pas des priorités.

Les responsables logiciels et autres parties prenantes internes et externes cherchaient donc une date fixe de livraison et un suivi simple des phases d’ingénierie.

Ils pénalisaient les écarts au plan et espéraient résoudre les problèmes émergents avant la date prévue.

De plus, des silos indépendants exécutaient des phases d’ingénierie logicielle complètement séparées. Par exemple, l’équipe de développement était entièrement indépendante de l’équipe de test (vérification) logiciel. La plupart des personnes censées travailler pour la même mission ne connaissaient même pas le nom des autres.

Pourquoi cette mentalité de silo plutôt que des missions métier et la maturité professionnelle des employés ?

La raison est simplement la gestion matricielle. Ce modèle d’organisation et de gestion des employés existe depuis les années 1970. Son idée distinctive paraît intelligente au premier abord.

La direction crée une structure organisationnelle en réunissant les employés dotés de compétences fonctionnelles et techniques similaires dans les mêmes silos ou, au mieux, dans des silos voisins.

À l’époque, les « centres de compétences » étaient très répandus dans nos entreprises, chacun constituant un silo indépendant et autonome.

Un silo de développeurs C++, un autre d’administrateurs de bases de données, un silo qualité complètement séparé à l’étranger, et ainsi de suite. Allez comprendre !

Le plus grand défi de la structure matricielle était le suivant : pour livrer un projet logiciel sans cadre Scrum ni Scrum Masters, les chefs de projet devaient emprunter temporairement des employés aux silos.

Ces employés ne travaillaient même pas physiquement auprès de leurs équipes de projet : ils restaient dans les locaux de leur centre de compétences.

À la fin des projets, ces équipes temporaires étaient dissoutes et les participants passaient à de nouvelles missions sur d’autres projets.

La valeur métier des projets n’était donc jamais la priorité suprême de ces silos indépendants.

Ils voyaient leur travail comme des cases à cocher pour un projet, puis un autre.

Ni la direction ni le modèle matriciel ne leur enseignaient l’engagement professionnel envers ventes, revenus et bénéfices de l’entreprise.

Un article de McKinsey & Company dans McKinsey Quarterly a aussi clairement illustré cette illusion d’optimisation des coûts au-delà de l’organisation matricielle.

L’article source cite une estimation de Gartner sur les dépenses annuelles mondiales de 600 milliards USD pour remettre leurs systèmes informatiques en état après des travaux de maintenance imprévus et des défauts.

Prenons maintenant un instant pour visualiser la manière dont la gestion du changement et des obstacles se déroulait dans les projets logiciels. Dans une configuration de projet fondée sur le modèle en cascade et l’organisation matricielle, sans processus Scrum.

Oui, vous avez raison. La direction et les employés traitaient la gestion du changement, des obstacles et des erreurs comme des exceptions malvenues qui n’auraient jamais dû se produire.

Les changements dans un projet logiciel étaient donc synonymes de retards. Ils créaient généralement un effet domino de retards en cascade. Les équipes cherchaient quelqu’un à blâmer et à accuser pour les défauts et les obstacles.

Sans mécanisme pour traiter, corriger et comprendre leurs erreurs, les silos répétaient les mêmes fautes.

De plus, elles continuaient d’augmenter le volume de dette technique tout en tentant passivement de gérer leurs problèmes.

3e source de chaos et de frustration sans certification Scrum Master : les décisions autocratiques primaient sur les décisions démocratiques

Steve Jobs a dit :

« Cela n’a pas de sens d’engager des gens intelligents pour leur dire quoi faire. Nous les engageons pour qu’ils nous disent quoi faire. »

C’est pourtant exactement l’inverse de la manière dont la plupart des directions traditionnelles prenaient leurs décisions avant l’ère Scrum.

Avant l’arrivée du processus Scrum dans nos organisations, les décisions autocratiques des dirigeants primaient sur l’intelligence collective de leurs équipes.

Elles invalidaient la capacité de décision démocratique des groupes chargés du travail réel. sur tout le cycle logiciel, de la conception à l’exploitation.

Plus une décision était éloignée des centres de travail (équipes) qu’elle concernait, plus il était difficile de prendre une bonne décision essentielle à la mission.

Les jugements étaient souvent impulsifs, mal réfléchis, tardifs et hésitants, parfois même prématurés.

Ces décisions autocratiques imposées d’en haut dévalorisaient les employés et empêchaient les solutions créatives et innovantes aux défis concurrentiels et logiciels.

De plus, elles décourageaient les équipes d’ingénierie logicielle d’apporter leur contribution lorsqu’on leur demandait de participer aux décisions.

Voilà un bref aperçu de notre manière de développer et de livrer nos services et produits logiciels avant l’adoption du cadre Scrum dans nos organisations. Voyons maintenant comment nous avons résolu ces sources de chaos et de frustration grâce au processus Scrum.

Qu’est-ce que Scrum ?

Je tiens d’abord à préciser que cette partie de l’article ne prétend pas répondre à toutes les questions sur le cadre Scrum. Son contenu donnera néanmoins une avance approfondie à la plupart des professionnels Scrum de niveau débutant et intermédiaire.

Pour ceux qui cherchent un guide plus avancé, mais toujours pratique, afin d’apprendre rapidement le cadre Scrum, nous avons aussi une solution. Je vous suggère de télécharger notre guide du cadre Scrum via ce lien.

Qu’est-ce que Scrum ? Sans compliquer les choses, on peut définir le cadre Scrum ainsi :

Scrum est un cadre léger qui génère de la valeur grâce à des solutions adaptatives à des problèmes complexes. Le développement logiciel itératif et incrémental en est une application importante.

Bien que les logiciels soient le principal sujet du cadre Scrum, le processus Scrum itératif et agile peut aussi être appliqué, et l’est déjà, en dehors du secteur logiciel.

La plupart des personnes du secteur informatique pensent que le terme « Scrum » a été créé au début des années 2000, parallèlement aux nouvelles tendances agiles de développement et de livraison de logiciels. C’est une information incorrecte !

L’article de la Harvard Business Review de janvier 1986 décrivait une approche du développement de produits antérieure au cadre Scrum. Hirotaka Takeuchi et Ikujiro Nonaka ont signé cet article : The New New Product Development Game. (Oui, deux fois « New »)

Consultez « The New New Product Development Game » pour découvrir comment tout a commencé pour Scrum !

Quand le secteur informatique parle du cadre Scrum, on entend souvent l’expression « Agile Scrum » au même titre que « Scrum ». Certains d’entre nous ont donc cherché les différences entre ces deux termes.

Bonne nouvelle : « Agile Scrum » et « Scrum » désignent la même chose, le processus d’ingénierie logicielle Scrum. Pourquoi ajoutons-nous alors parfois « Agile » devant « Scrum » ?

Parce que le cadre Scrum a pleinement adopté et intégré le Manifeste agile (Manifeste pour le développement agile de logiciels) à son processus central, à ses principes et à sa philosophie sous-jacente. Avant d’approfondir les aspects techniques du processus Scrum, comprenons donc mieux le Manifeste agile et les valeurs de Scrum.

Le Manifeste agile (Manifeste pour le développement agile de logiciels)

Les valeurs du Manifeste Agile :

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

Bien que les éléments de droite conservent une valeur importante, le Manifeste agile accorde plus de valeur et de priorité aux éléments de gauche.

Les éléments privilégiés par le Manifeste Agile ont été soigneusement éprouvés dans le temps et choisis pour :

• Mieux servir les clients et les parties prenantes et créer de la valeur pour eux grâce aux logiciels,
• Faire progresser la profession de l’ingénierie logicielle, quels que soient votre rôle, votre titre et votre niveau de carrière.

Les valeurs du cadre Scrum

J’ai déjà indiqué que le cadre Scrum n’est pas seulement un processus d’ingénierie logicielle. Il repose aussi sur un ensemble solide de principes.

La plupart des domaines professionnels peuvent d’ailleurs appliquer ces principes et en tirer parti.

Obtenir une certification Scrum Master ne suffit pas pour réussir pleinement avec Scrum. Vous devez aussi bien comprendre ses valeurs.

afin de réaliser un excellent travail et des logiciels remarquables que vos clients et employeurs apprécieront. Permettez-moi maintenant de vous en dire plus sur ces principes du processus Scrum.

Courage

Faire ce qui est juste pour apporter le plus de valeur et d’avantages à nos clients n’est pas toujours facile. Dans ces moments, le Scrum Master, le Scrum Product Owner et les membres de l’équipe Scrum doivent se rappeler leur devoir et leur obligation.

Il s’agit de créer les meilleurs produits et services possibles dans leur domaine métier et informatique. Pour dépasser la médiocrité, une équipe Scrum devra tôt ou tard prendre des décisions difficiles qui ne satisferont pas toutes les parties prenantes de son écosystème.

Pour y faire face, tous les membres de l’équipe Scrum doivent se rappeler ce qu’ils ont appris pendant leur formation à la certification Scrum Master.

Ils doivent se rappeler de faire preuve de courage et apprendre à décider et à agir courageusement.

Concentration

Dans le cadre Scrum, quand vous entendez parler de la valeur de focalisation, pensez à deux choses :

• Identifier le bon travail : Quelles tâches sont nécessaires pour atteindre les objectifs de mon Sprint ? Qu’est-ce qui est indispensable pour développer les meilleurs produits et services logiciels pour mes clients, afin qu’ils soient satisfaits de mon travail ?
• Prioriser : Sur quelles tâches dois-je travailler ensuite ?

À tout moment, toute l’équipe Scrum, y compris le Scrum Master et le Product Owner, doit répondre à une question essentielle. Cette question est : « Quelles sont les choses les plus importantes à faire maintenant pour répondre aux raisons pour lesquelles notre employeur nous a recrutés ? »

Le cadre Scrum intègre plusieurs événements (rituels) pour assurer une hiérarchisation raisonnable des User Stories et des tâches. Selon le processus Scrum, leur hiérarchisation doit rester une priorité permanente.

Nous veillons ainsi à ce que l’équipe Scrum travaille sur les bons sujets, dans le bon ordre. Les événements Scrum formels et les pratiques d’affinage associées nous aident à inspecter notre focalisation et à adapter notre travail :

• Réunion de grooming Scrum : L’affinage clarifie, décompose et dimensionne les prochains éléments du Product Backlog et contribue à définir leur ordre. Une réunion est une option pour cette activité continue.
• Réunion de Sprint Planning : Ces réunions montrent les dépendances et le bon ordre du travail pour réaliser nos user stories.
• Réunion de Daily Scrum : Les réunions Daily Scrum (réunions quotidiennes debout) nous aident à donner le ton de la journée de travail à venir. Nous devons concentrer notre attention là où elle est la plus nécessaire.
• Réunion de Sprint Review : La revue de Sprint nous montre indirectement où diriger l’attention de l’équipe Scrum pour mieux réussir les revues suivantes.
• Réunion de Sprint Retrospective : Ces réunions aident l’équipe Scrum à hiérarchiser les aspects de son processus d’ingénierie à améliorer en premier.

Dans cette section, j’ai abordé les rituels Scrum uniquement sous l’angle de la focalisation. Vous trouverez une explication plus détaillée des cérémonies Scrum plus loin dans cet article.

Après cette lecture, vous comprenez maintenant combien la hiérarchisation et la focalisation sont essentielles au cadre Scrum.

Engagement

Sans l’engagement du Scrum Master, du Scrum Product Owner et de l’équipe Scrum, il est impossible d’obtenir des résultats logiciels exceptionnels.

Dans le développement logiciel Scrum, la plupart des gens interprètent l’engagement comme l’accord sur les objectifs des livrables d’un Sprint et l’obligation de s’y tenir.

Cette interprétation est logique, mais imparfaite. Dans le contexte des valeurs Scrum, l’auteur emploie « obsession » pour souligner la détermination liée à l’engagement. Dans la définition de Scrum, l’engagement porte sur les objectifs de l’équipe et le soutien mutuel ; il n’impose ni surcharge de travail ni certitude sur chaque élément prévu.

Pour réussir dans l’ingénierie logicielle, la vie et les affaires, vous devez être obsédé par vos objectifs. Dans le contexte du processus Scrum, vous devez être obsédé par la création de logiciels remarquables qui résolvent les problèmes de vos clients.

Pourquoi l’engagement et l’obsession des objectifs Scrum qui l’accompagne sont-ils si importants ? Sans cette obsession de la mission de l’équipe, qui consiste à construire et livrer d’excellents logiciels, votre travail ralentira puis s’arrêtera chaque fois qu’un obstacle non trivial se présentera.

Le Scrum Master et l’équipe Scrum commenceront alors à expliquer au Scrum Product Owner pourquoi ils ne peuvent pas atteindre les objectifs du Sprint, afin de le justifier et de le légitimer. Les excuses ne doivent plus avoir leur place dans votre équipe si votre objectif est de dépasser le niveau d’une équipe Scrum moyenne.

Seul un dévouement extrêmement élevé rend plus facile et plus gratifiant le fait de résoudre les problèmes de nos clients, de les aider et de créer de la valeur pour eux grâce aux logiciels.

Respect

Quels que soient leur âge, leur genre, leur origine, leurs croyances, leur expérience, leurs compétences, leurs opinions et leurs performances, tous les membres d’une équipe Scrum doivent se respecter et pouvoir compter les uns sur les autres.

Ce respect ne se limite pas à l’équipe Scrum. Toutes les parties prenantes informatiques et métier, internes ou externes, qui interagissent avec elle sont pleinement respectées et accueillies.

Les membres expérimentés doivent veiller à ne pas décourager la volonté de contribuer des membres moins expérimentés.

Il est particulièrement important d’accueillir et de traiter correctement les opinions opposées que la majorité du groupe ne partage pas.

Ouverture

La valeur Scrum d’ouverture distingue souvent une équipe moyenne d’une équipe très performante. Comparez la capacité d’ouverture d’une équipe Scrum à la puissance d’un groupe de personnes ouvertes d’esprit.

Elles sont créatives, innovantes, réfléchies, honnêtes, directes et humbles. Dans le processus Scrum d’ingénierie et de livraison de logiciels, chacun doit pouvoir discuter ouvertement des défis et des points de vue différents. L’ouverture ne rend pas toute décision ou action appropriée : le respect, la qualité et les objectifs de l’équipe restent essentiels.

La seule condition est d’être transparents et de chercher à contribuer à la mission commune de l’équipe Scrum.

Cela ne signifie pas que chaque décision et action doit nécessairement accélérer la production de l’équipe Scrum et aboutir à de grandes réussites.

Grâce aux valeurs d’ouverture et de courage, l’équipe de développement logiciel Scrum n’a pas peur de se tromper. Elle considère ses erreurs et ses résultats imparfaits comme des occasions essentielles d’améliorer réellement sa productivité et sa qualité.

Les principales composantes du cadre Scrum

La Scrum Team comprend un Product Owner, un Scrum Master et des Developers, avec trois responsabilités distinctes. L’expression « Scrum Team Member » employée plus tôt dans cet article désigne le groupe de développement, et non une quatrième responsabilité ou une autre Scrum Team entière.

Outre les autres programmes proposés à ses étudiants du monde entier, International Scrum Institute™ propose trois principaux programmes de formation et de certification pour ces trois rôles.

Ces programmes sont Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™), et Scrum Team Member Accredited Certification™ (STMAC™).

Une organisation Scrum adaptée doit réunir des personnes possédant ces trois ensembles de compétences. C’est particulièrement essentiel pour réussir avec le cadre de développement logiciel Scrum.

Chaque responsabilité Scrum doit être assumée. Les responsabilités restent distinctes ; un Product Owner ou un Scrum Master peut aussi contribuer en tant que Developer lorsqu’il travaille sur le Sprint Backlog, sans perdre ses autres responsabilités.

Plusieurs Scrum Teams travaillant sur un même produit partagent un Product Owner, un Product Goal et un Product Backlog. Chaque équipe assume la responsabilité de Scrum Master et a besoin d’un soutien efficace ; Scrum n’impose pas qu’une personne n’accompagne qu’une seule équipe.

Ne sous-estimez pas l’importance de comprendre le but et la fonction de ces rôles et de les confier à des personnes adaptées. Nous avons souvent observé que les difficultés d’une équipe Scrum viennent soit d’une mauvaise compréhension de ces rôles, soit de leur attribution aux mauvaises personnes.

Parlons maintenant de ces trois rôles.

Trois rôles Scrum — Le Scrum Product Owner

Le Scrum Product Owner ordonne le Product Backlog pour maximiser la valeur du produit et travaille avec les parties prenantes aux décisions de produit et de livraison. Les Developers sélectionnent le travail qu’ils prévoient pour un Sprint ; les modalités de livraison dépendent du contexte du produit. Elle représente les exigences fonctionnelles et non fonctionnelles des utilisateurs finaux.

Son rôle est bien plus large que les fonctions traditionnelles de chef de projet, de responsable de programme ou de responsable produit.

Ce rôle réunit des tâches de gestion de produit et de projet et est étroitement intégré au développement et à la livraison de logiciels.

Les principales tâches d’un Scrum Product Owner sont :

• Gérer et clarifier les exigences du projet,
• Guider les livraisons et assurer le retour sur investissement (ROI),
• Travailler étroitement avec l’équipe Scrum,
• Gérer les parties prenantes.

Trois rôles Scrum — Le membre de l’équipe Scrum

L’équipe Scrum met en œuvre le logiciel. Les Developers choisissent la quantité de travail qu’ils prévoient pouvoir terminer pendant un Sprint. Le Sprint est un événement à durée fixe ; le résultat produit utilisable créé pendant celui-ci est un Increment qui respecte la Definition of Done.

Une équipe Scrum très performante réunit généralement la plupart des compétences d’ingénierie logicielle. Développeurs, architectes, testeurs, administrateurs de bases de données et membres de tous les autres rôles travaillent ensemble.

Ensemble, ils construisent et livrent un excellent logiciel que leur client paie.

Les membres de l’équipe Scrum n’appartiennent plus à un silo fonctionnel d’une organisation matricielle. Les développeurs ne relèvent plus de centres de compétences en développement logiciel, les testeurs ne relèvent plus d’un centre de compétences en test logiciel, et ainsi de suite.

Quelle que soit leur ancienne place dans l’organisation, les membres d’une équipe Scrum appartiennent à leur projet Scrum. Leur travail consiste désormais à construire le meilleur logiciel possible pour répondre aux exigences de leur Scrum Product Owner.

Les équipes Scrum présentent les caractéristiques suivantes :

• Habilitées à agir,
• Autonomes,
• Pluridisciplinaires,
• Auto-organisées,
• De petite taille,
• Des participants suffisamment disponibles (la participation à temps plein est un choix organisationnel courant),
• Capables de collaborer étroitement, sur place ou à distance,
• Un pour tous, tous pour un.

Trois rôles Scrum — Le Scrum Master

Le Scrum Master aide tous les participants au projet Scrum et les parties prenantes externes à comprendre et à appliquer correctement le cadre Scrum. Elle accompagne l’équipe pour exécuter le processus Scrum avec succès et améliorer continuellement sa productivité et ses performances.

Le rôle du Scrum Master est d’instaurer le processus Scrum, cette nouvelle façon de penser et d’agir.

Le Scrum Master agit aussi comme agent du changement. Elle coache l’équipe pour créer de nouvelles normes et pratiques d’équipe. Elle reste accessible ; la proximité physique peut aider, mais Scrum ne l’exige pas.

Les principales responsabilités du Scrum Master comprennent :

• Instaurer Scrum dans son écosystème métier et informatique,
• Coacher l’équipe pour comprendre et vivre les valeurs Scrum,
• Assurer une collaboration étroite entre le Scrum Product Owner et l’équipe Scrum,
• Lever les obstacles,
• Diriger en servant,
• Soutenir des événements Scrum efficaces et les faciliter si nécessaire, tout en préservant la maîtrise du Daily Scrum par les Developers.

Product Backlog (Backlog Scrum)

Le Product Backlog (Scrum Backlog), ou Scrum Product Backlog, est l’élément central pour gérer toutes les exigences connues d’un projet Scrum.

Il comprend toutes les exigences client et tous les éléments de travail nécessaires pour mener et terminer un projet réussi. Les exigences regroupent les exigences fonctionnelles, non fonctionnelles et les autres fonctionnalités liées à l’expérience utilisateur et l’interface utilisateur la conception.

Le Product Backlog contient les demandes de fonctionnalités et leurs user stories. Il peut aussi inclure des exigences préalables ou complémentaires du projet, comme la création d’environnements de test et de développement. D’autres User Stories destinées à corriger des bugs connus, réduire la dette technique ou améliorer certaines fonctionnalités logicielles y ont également leur place.

Chaque produit a son Product Backlog. Le Scrum Product Owner est responsable de sa création, de sa maintenance et de son affinage. Le Product Backlog ne répond pas, et ne doit pas répondre, à la question de savoir comment ces exigences seront développées et livrées.

C’est le rôle de l’équipe Scrum. Elle décide et documente dans les Sprint Backlogs les tâches nécessaires pour répondre à ces exigences. Le Product Backlog et le Sprint Backlog sont des artefacts distincts, mais pas nécessairement des documents ou outils physiquement séparés, même si les éléments du Product Backlog alimentent le contenu du Sprint Backlog.

Le Product Backlog est un document vivant. Comme le logiciel s’améliore progressivement, le Product Backlog évolue avec l’apprentissage de l’équipe, par des ajouts, des suppressions et des changements d’ordre. Le cadre Scrum n’impose pas de processus distinct de gestion du changement. Le Scrum Product Owner crée les premières versions du Product Backlog à partir de sa meilleure compréhension initiale du produit.

En observant attentivement l’évolution du produit de Sprint en Sprint et en approfondissant sa connaissance des besoins client, elle ajoute, supprime et affine les exigences du Product Backlog.

Le Scrum Product Owner hiérarchise les exigences du Product Backlog. Plus un élément du Product Backlog est prioritaire, plus il doit être détaillé. L’équipe Scrum peut ainsi comprendre facilement ces exigences prioritaires et créer les tâches nécessaires à leur réalisation.

De plus, en utilisant une méthode d’estimation comme les Story Points, l’équipe Scrum estime régulièrement les exigences du Product Backlog. Ces estimations doivent être affinées et améliorées pour les User Stories prioritaires afin de les préparer à la planification du Sprint.

Sprints

Dans le cadre Scrum, toutes les activités de mise en œuvre des exigences se déroulent pendant les Sprints. Les Sprints sont des cycles d’activités visant à développer des Incréments de produits ou de services logiciels livrables. Les Sprints sont aussi parfois appelés itérations.

Voyez les Sprints comme des microprojets. Comme le terme « Sprint » le suggère, un Sprint ne dure pas longtemps : un mois ou moins. Les Sprints de quatre semaines sont un exemple courant, et non la durée calendaire maximale exacte du cadre.

Contrairement à une course, l’équipe Scrum ne doit pas être à bout de souffle et d’énergie à la fin d’un Sprint. Elle doit au contraire rester fraîche et commencer le suivant avec énergie.

Le cadre Scrum de développement et de livraison de logiciels n’a pas vocation à créer de la pression et du stress pour ses membres. Il est bien connu que les personnes donnent le meilleur lorsqu’elles peuvent travailler concentrées, sereines et sans distraction. Correctement appliqués, les Sprints nous aident à y parvenir.

Chaque Sprint commence par une Planification de Sprint. Pendant la réunion de planification, l’équipe Scrum décide quelles exigences elle mettra en œuvre pendant ce Sprint et en quelle quantité. Elle commence ensuite les activités nécessaires pour les livrer.

Daily Scrum (réunion quotidienne Scrum) a lieu chaque jour ouvré du Sprint, à la même heure et au même endroit. Les Developers l’utilisent pour inspecter la progression vers le Sprint Goal et adapter leur plan pour le lendemain. Les membres de l’équipe Scrum peuvent aussi demander l’aide du Scrum Master pour lever les obstacles susceptibles de ralentir ou de bloquer la progression d’un Sprint.

L’équipe Scrum termine un Sprint par une revue et une rétrospective de Sprint. La réunion de revue de Sprint permet à la Scrum Team et aux principales parties prenantes d’inspecter les résultats du Sprint et la progression vers le Product Goal, puis de discuter des adaptations à venir. C’est une séance de travail, et non une étape d’approbation par le Product Owner.

Pendant le Réunion de Sprint Retrospective, l’équipe Scrum réfléchit à sa façon de collaborer, à son utilisation du cadre Scrum et aux améliorations possibles.

L’équipe Scrum tient ainsi compte collectivement de ces pistes d’amélioration et retours lors de la prochaine planification du Sprint. Les Sprints permettent ces boucles de retour sur de courtes périodes avec de petits lots de travail. C’est l’une des principales raisons pour lesquelles le cadre Scrum aide les équipes et les organisations à s’améliorer continuellement.

Scrum : inspecter et adapter

Le concept Scrum « inspecter et adapter » est simple à comprendre, mais très difficile à bien mettre en œuvre et à maîtriser.

Les entreprises ont fini par constater qu’aucun de leurs chefs de projet ne pouvait prévoir entièrement la vue d’ensemble de systèmes complexes. Ils ne pouvaient pas planifier de bout en bout de façon fiable. Il était évident qu’il fallait essayer autre chose.

Avec la production lean (aussi appelée mouvement lean), les entreprises devaient développer un processus pour renforcer leur capacité d’action stratégique. Elles avaient besoin d’une procédure opérationnelle standard pour apprendre et corriger leur trajectoire pendant leurs projets et même leurs opérations.

Ce fut la naissance du Toyota Improvement Kata, qui offre une comparaison utile avec l’inspection et l’adaptation dans Scrum. Ces démarches d’amélioration ont des objectifs proches, mais Toyota Improvement Kata n’est pas simplement un autre nom des piliers empiriques de Scrum. Selon « Scrum : inspecter et adapter » :

• Étape 1. Inspecter : Nous faisons de notre mieux pour comprendre l’état actuel du projet avec nos connaissances et notre compréhension du moment.
• Étape 2. Adapter : Nous définissons une direction et une vision pour les prochaines étapes du projet, puis établissons une stratégie et mettons cette vision en œuvre.
• Étape 3. Apprendre : Nous observons attentivement, apprenons et nous enseignons mutuellement pendant ce processus. Tout au long du travail, nous consignons ce qui fonctionne et ce qui ne fonctionne pas.
• Étape 4. Recommencer : Reprendre à l’étape 1.

Les quatre étapes ci-dessous sont une analogie pédagogique, et non une définition terme à terme des événements Scrum. L’inspection, l’adaptation et l’apprentissage ont lieu tout au long du Sprint.

• Étape 1. Inspecter correspond par analogie aux revues et rétrospectives de Sprint.
• Étape 2. Adapter correspond par analogie aux réunions de planification du Sprint.
• Étape 3. Apprendre correspond par analogie aux réunions Daily Scrum.
• Étape 4. Recommencer correspond par analogie à la clôture d’un Sprint et au début du suivant.

L’auto-organisation

L’équipe Scrum s’organise elle-même. Ses membres décident par consensus des tâches à réaliser pour atteindre les objectifs d’un Sprint. Une équipe auto-organisée n’a pas besoin d’un responsable ou d’un chef d’équipe.

L’auto-organisation dans le cadre Scrum est très disciplinée.

Sprint Backlog et Réunions de Daily Scrum favorisent l’autogestion. Un Sprint Burndown Chart est une option pour rendre la progression visible.

Organiser elles-mêmes leur travail demande une phase d’apprentissage à la plupart des équipes. Des Scrum Masters compétents et certifiés les aident à exceller rapidement en auto-organisation.

L’auto-organisation comprend aussi la capacité de collaborer malgré les divergences d’opinions et les conflits possibles entre membres. Elle exige d’adhérer aux décisions collectives et de faire confiance aux processus qui les produisent.

Ces processus décisionnels Scrum comprennent notamment la planification, l’estimation, la mise en œuvre, le reporting et la revue du travail dont l’équipe est collectivement responsable.

Événements Scrum et affinage continu du Backlog

Événement Scrum 1. Sprint Planning (pourquoi, quoi et comment)

Pendant le Planification de Sprint, l’équipe Scrum construit un Sprint Backlog réalisable qui définit les exigences qu’elle mettra en œuvre pendant le Sprint.

Les responsabilités des différents rôles Scrum pendant le Sprint Planning sont les suivantes :

• Le Product Owner propose pourquoi le Sprint pourrait apporter de la valeur. Toute la Scrum Team collabore sur un Sprint Goal et les Developers choisissent les éléments du Product Backlog qu’ils prévoient pouvoir terminer.
• La Scrum Team identifie les tâches nécessaires et leurs estimations. Les Developers décident quels éléments et combien ils prévoient terminer dans le Sprint, en s’appuyant sur les performances passées, la capacité et la Definition of Done.
• Le Scrum Master facilite la réunion. Elle veille à préserver l’auto-organisation et la capacité de décision autonome de la Scrum Team.

La présence du Scrum Product Owner est obligatoire pendant le Sprint Planning. Elle peut ainsi répondre aux questions de la Scrum Team et clarifier les exigences et leurs critères d’acceptation.

La Scrum Team peut inviter d’autres personnes, comme des utilisateurs finaux ou des responsables, pour apporter des conseils au Sprint Planning. Les personnes invitées apportent leurs conseils sans s’approprier les décisions des Developers sur la manière de réaliser le travail.

Événement Scrum 2. Daily Scrum (réunion quotidienne debout)

Le Daily Scrum est une réunion de 15 minutes maximum. Elle a lieu chaque jour ouvré à la même heure et au même endroit. Il est préférable de disposer d’un accès direct au Sprint Backlog et au Sprint Burndown Chart. L’équipe peut ainsi conduire le Daily Scrum à partir des faits et des progrès visibles par tous.

Le Daily Scrum vise à soutenir l’auto-organisation de l’équipe Scrum et à identifier systématiquement les obstacles.

Le Daily Scrum est destiné aux Developers. Un Product Owner ou Scrum Master qui travaille sur des éléments du Sprint Backlog y participe comme Developer. Toute autre participation doit préserver leur focalisation et leur autogestion ; Scrum n’exige pas la présence de tous les rôles ou parties prenantes.

Les Developers choisissent une structure utile, centrée sur le Sprint Goal et un plan concret. Les trois questions suivantes constituent un format facultatif courant, et non des questions prescrites par le Scrum actuel.

• Daily Scrum — Question n° 1. Quelles activités ai-je réalisées depuis le dernier Daily Scrum ?
• Daily Scrum — Question n° 2. Quelles activités prévois-je de réaliser avant le prochain Daily Scrum ? Quel est mon plan d’action ?
• Daily Scrum — Question n° 3. Ai-je rencontré ou prévois-je un obstacle susceptible de ralentir ou de bloquer la progression de mon travail ?

Les Développeurs conduisent leur Daily Scrum. Le Scrum Master aide les Developers à en comprendre le but et l’efficacité si nécessaire. L’événement reste limité à 15 minutes ; le format des trois questions est facultatif.

Le Daily Scrum n’a pas pour objectif de prendre des décisions chronophages ou de résoudre des problèmes. Pour s’accorder sur des décisions et résoudre des problèmes, l’équipe Scrum peut organiser des réunions séparées selon les besoins. Elles se tiennent généralement à la suite du Daily Scrum.

Le Scrum Master consigne les obstacles identifiés et leurs dates dans un journal, un tableau papier ou un rapport distinct accessible à l’équipe. Je trouve très utile de faire rapidement le point sur les obstacles ouverts à la toute fin du Daily Scrum.

Événement Scrum 3. Revue de Sprint

Le Revue de Sprint a lieu à la fin du Sprint. Une revue d’une à deux heures peut convenir à certaines équipes ; le maximum officiel est de quatre heures pour un Sprint d’un mois, et les événements sont généralement plus courts pour des Sprints plus courts. Selon le logiciel et l’infrastructure disponible, la revue se tient en salle de réunion, en laboratoire ou dans les locaux de l’équipe Scrum.

La revue de Sprint vise à examiner l’incrément de produit livrable créé pendant le Sprint et à rendre transparent le processus de développement du produit.

L’équipe Scrum présente les résultats de son travail. La Scrum Team et les parties prenantes discutent de ce qui a été accompli et des changements dans l’environnement. Elles inspectent les résultats et envisagent la suite ; la revue n’est pas un contrôle de conformité à une liste fixe de tâches promises.

La revue de Sprint permet à la Scrum Team et aux parties prenantes d’inspecter les résultats du produit et d’adapter le Product Backlog. Toute la Scrum Team collabore ensuite sur le prochain Sprint Goal. Ainsi, les revues de Sprint sont une application formelle et pratique de l’inspection et de l’adaptation.

L’équipe Scrum, le Scrum Product Owner et le Scrum Master participent à la revue de Sprint. Toutes les autres parties prenantes, comme les utilisateurs finaux, clients ou représentants métier, peuvent également y participer.

Ils peuvent y donner leur avis sur l’incrément de produit présenté. L’équipe Scrum peut ainsi recevoir des retours directs et non filtrés des parties prenantes pour lesquelles elle construit le logiciel.

Événement Scrum 4. Rétrospective de Sprint

Le Réunion de Sprint Retrospective suit la revue et conclut le Sprint. Sa durée maximale est de trois heures pour un Sprint d’un mois ; elle est généralement plus courte pour les Sprints plus courts.

La rétrospective de Sprint vise à améliorer la collaboration des membres de l’équipe Scrum et l’application du processus Scrum.

Les rétrospectives de Sprint améliorent ainsi la productivité, les performances des membres de l’équipe et la qualité des logiciels.

Une rétrospective de Sprint est en pratique un mini-bilan pour définir les pistes d’amélioration et lever les obstacles liés aux processus. Voici quelques exemples que nous observons souvent dans nos projets :

• Adopter des pratiques de développement logiciel agile comme l’extreme programming (XP) ou le développement piloté par les tests (TDD).
• Définir de nouvelles normes et de nouveaux principes d’équipe, ou
• Accroître la disponibilité du Scrum Product Owner.

Sans exception, l’équipe Scrum organise une rétrospective à la fin de chaque Sprint. Ce n’est qu’ainsi que ces réunions lui permettent d’adapter et d’améliorer systématiquement son utilisation du processus Scrum aux particularités de son projet.

Pratique associée : affinage du Product Backlog (grooming)

Scrum Les réunions d’affinage du Backlog (grooming) visent à maintenir le Product Backlog à jour. Il reflète ainsi les meilleures connaissances et la compréhension actuelle de l’équipe sur le projet.

L’affinage peut avoir lieu selon les besoins ou lors de discussions programmées. Deux séances hebdomadaires de 30 minutes sont un exemple pratique, et non une fréquence ou une limite imposée. Le Product Owner et les Developers collaborent, avec le Scrum Master et d’autres contributeurs selon les besoins.

Pendant les réunions d’affinage du Backlog Scrum (grooming), les participants améliorent le Product Backlog par les actions suivantes :

• Ajouter des stories selon les exigences nouvellement découvertes.
• Retirer les stories qui ne sont plus nécessaires.
• Affiner leurs estimations.
• Actualiser leurs priorités.
• Découper les très grandes stories en petites unités assimilables et les prioriser.

Quatre étapes simples pour obtenir votre certification Scrum Master

Obtenir votre certification Scrum Master est simple, rapide et entièrement en ligne.

Grâce à International Scrum Institute™, vous pouvez désormais obtenir votre certification Scrum Master plus vite et à moindre coût que jamais.

Voici quatre étapes simples pour obtenir votre certification Scrum Master sans perdre de temps ni d’argent et sans difficulté.

• Étape n° 1. Inscrivez-vous en ligne

  Inscrivez-vous en ligne à votre certification Scrum Master via votre page d’inscription à la Scrum Master Accredited Certification™.

  Après votre inscription, International Scrum Institute™ vous fournira instantanément votre code d’accès à l’examen en ligne.

  Le lien suivant vous permet de vous inscrire à votre programme de certification Scrum Master.

• Ouvrir l’image en taille réelle ↗

  Étape n° 2. Étudiez en ligne

  Préparez votre certification Scrum Master en ligne grâce à votre guide d’étude Scrum, The Scrum Framework™.

  The Scrum Framework™ est conçu pour être entièrement axé sur la pratique. Son contenu vous aidera donc à relever vos défis quotidiens dans votre travail et votre carrière de Scrum Master talentueux. Il regorge d’études de cas et d’exemples pratiques illustrant le quotidien des Scrum Masters les plus performants.

  Le lien suivant vous permet de Demandez votre exemplaire gratuit de The Scrum Framework™.

• Étape n° 3. Passez votre examen de certification Scrum Master en ligne

  Après avoir lu, étudié et assimilé attentivement votre guide d’étude Scrum, The Scrum Framework™, vous devriez être prêt ! Vous devriez maintenant aborder votre examen de certification Scrum Master en toute confiance.

  Le lien suivant vous permet de Accédez à votre examen de certification Scrum Master.

• Étape n° 4. Recevez votre certification Scrum Master

  Dès votre réussite à l’examen, nous vous fournissons immédiatement votre certification Scrum Master.

  Vos employeurs et clients peuvent vérifier l’authenticité de votre certification grâce à votre outil de validation des certifications Scrum pour les employeurs. Le lien suivant vous permet d’y accéder à votre outil de validation des certifications Scrum pour les employeurs.

Ma conclusion sur la certification Scrum Master

Il est temps de récapituler. Si vous n’avez pas pu lire chaque mot de ce guide pas à pas pour devenir Scrum Master, voici mes réflexions sur les avantages et les inconvénients de cette certification.

Les avantages

Avantages pour les salariés, indépendants, coachs et formateurs

• Une certification Scrum Master reconnaît vos compétences et votre savoir-faire à jour dans le domaine Scrum.
• Une certification Scrum Master vous aidera à dépasser vos pairs qui ne se perfectionnent plus. Elle vous aidera à décrocher l’emploi de vos rêves comme Scrum Master certifié et accompli.
• Une certification Scrum Master élargira votre perspective et ouvrira davantage votre esprit à l’apprentissage continu. Elle vous aidera à obtenir plus de responsabilités et de belles opportunités professionnelles.
• Une certification Scrum Master vous apportera de nouveaux outils pour livrer d’excellents produits et services que vos clients et employeurs apprécieront.

Avantages pour les organisations et les employeurs

• Les certifications Scrum Master réduiront les coûts en améliorant l’efficacité de vos équipes, activités et processus.
• Les certifications Scrum Master vous aideront à remporter, avec vos employés formés et compétents, des projets que vous n’auriez pas pu gagner autrement.
• Les certifications Scrum Master amélioreront la satisfaction et l’engagement des employés en les encourageant à se former et à développer leurs compétences.
• Les certifications Scrum Master amélioreront la qualité de vos livrables, la satisfaction client et, à terme, la réussite et la rentabilité de votre organisation.

Les inconvénients

• Une certification Scrum Master ne doit pas mettre fin à votre apprentissage. N’oubliez pas qu’elle n’en est que la première étape.

  Dans l’esprit « inspecter et adapter » appris avec le cadre Scrum, il reste de votre devoir et de votre responsabilité d’expérimenter, d’observer et d’apprendre continuellement.

• Aucune solution universelle ne convient à toutes les organisations du monde. Le cadre Scrum de développement et de livraison de logiciels ne fait pas exception.

  Nous avons observé que la plupart des organisations qui n’arrivaient pas à tirer les meilleures performances du cadre Scrum avaient un point commun : elles n’avaient pas su adapter Scrum à leurs propres écosystèmes métier et informatiques.

  Toujours dans l’esprit « inspecter et adapter », ne voyez donc pas le cadre Scrum comme une recette garantissant le succès à 100 %. Ne sous-estimez pas votre capacité de réflexion pour l’adapter aux dynamiques propres à votre entreprise et à son informatique. En tant que professionnel rémunéré, c’est précisément votre rôle pour obtenir le meilleur débit et les meilleurs résultats métier grâce au cadre Scrum.

• Scrum n’a pas résolu tous nos problèmes informatiques. Continuez à apprendre avec les nouveaux processus de développement et de livraison de logiciels, comme DevOps.

  Pour mieux comprendre les limites connues du cadre Scrum et la façon dont DevOps y répond, consultez plus tard cet excellent article : Quelles sont les 6 PRINCIPALES différences entre DevOps et Scrum ?

En conclusion, une certification Scrum Master est un excellent point de départ pour les pratiques agiles de développement et de livraison de logiciels.

Selon une étude de Gartner « Becoming a Better Scrum Master » publié en 2019, l’article prévoyait pour 2023 que 92 % des entreprises mondiales et 96 % des entreprises américaines adopteraient les pratiques agiles Scrum. Il s’agit de la prévision rapportée dans l’article original, et non d’un taux actuel d’adoption mesuré.

Il n’y aura donc pas de meilleur moment que maintenant pour

• Commencez à apprendre gratuitement le cadre Scrum et
• Obtenez votre certification Scrum Master aux tarifs très abordables d’International Scrum Institute™.

La seule question restante est : quand commencerez-vous ?