Tips pour la certification PSM I

Tips pour la certification PSM I

Je vous avais promis, dans ma note précédente, quelques tips concernant la certification PSM I. Les voici !

Ce qui m’a posé le plus de problème, ce sont les notions de Sprint Goal, de Sprint Backlog et de Definition of Done :

  • Le Sprint Goal, défini conjointement par la Scrum Team lors du Sprint Planning, peut-il évoluer en cours de Sprint ?
  • Le Sprint Backlog, défini par les développeurs en Sprint Planning, peut-il évoluer en cours de Sprint, avec l’accord du PO ?
  • La Definition of Done, définie par la Scrum Team en Sprint Planning, peut-elle évoluer en cours de Sprint ?

Honnêtement, aujourd’hui, je ne suis toujours pas certaine à 100% des réponses à ces questions. J’ai lu tout et son contraire.

Je partirais là-dessus :

  • Le Sprint Goal est défini par l’ensemble de la Scrum team, durant le Sprint planning. Cet Objectif est fixe
  • Le contenu du Sprint Backlog (comment atteindre le Sprint Goal) peut être clarifié et adapté pendant le Sprint, sans que cela n’affecte l’Objectif de Sprint. On peut donc dire que le Sprint Backlog émerge tout au long du Sprint
  • La Definition of Done peut être adaptée, si nécessaire. Elle est agile, évolutive. Une question reste ouverte : peut-elle être adaptée en cours de Sprint ou la Scrum Team doit-elle attendre la Rétrospective ?

Dites-moi à l’occasion ce que vous en pensez 😉

Pour le reste, voici les grandes idées à bien maitriser avant de passer la certification :

  • Pour un Sprint de quatre semaines, le Sprint Planning dure 8 heures, le Sprint Review 4 heure et le Sprint Retro 3 heures
  • Les trois piliers de Scrum sont la transparence, l’inspection et l’adaptation
  • Les valeurs de Scrum sont le courage, le focus, l’engagement, le respect et l’ouverture
  • Les trois Artéfacts Scrum sont le Product backlog, le Sprint backlog et les incréments
  • L’Agile manifesto date de 2001
  • La première version du Scrum guide a été publiée en 2010
  • L’objectif de Scrum est de générer de la valeur
  • Le Product Backlog est entièrement sous la responsabilité du PO
  • Le PO ne peut pas déléguer la gestion du Product Backlog, sauf lorsqu’il s’agit d’ordonner les tâches
  • Le Product Backlog est une liste qui n’est pas fixe mais qui évolue dans le temps
  • Il n’y a pas d’assignation de tâche par le PO ou par quelqu’un d’autre
  • Seul le PO a le droit d’annuler un sprint, si celui-ci devient obsolète
  • Le Sprint Goal porte sur un sprint, la Definition of Done porte sur un incrément
  • Le refinement ne peut pas prendre plus de 10% du temps de la DEV Team
  • Une telle limitation n’existe pas si on parle du refinement au niveau de la Scrum Team
  • En Scrum, on ne parle jamais de release
  • Scrum est un framework, pas une méthodologie. Agile est une méthodologie
  • En Scrum, plus de project manager ni de release manager
  • 1 produit = 1 PO = 1 Product Backlog (et ce, même si plusieurs équipes bossent sur ce produit)
  • Si plusieurs produits, 1 PO et 1 Product Backlog par produit
  • Pas de sprint 0 dans l’approche Scrum
  • Un incrément produit doit toujours être livré à la fin de chaque sprint mais pas d’obligation de release en fin de sprint (décision du PO)
  • Adapter une Scrum Team diminue la vélocité dans un premier temps
  • Le concept de User stories ne vient pas de Scrum
  • Les Progress monitors, Burn down charts ne sont pas obligatoires en Scrum
  • C’est OK qu’une personne cumule plusieurs rôles
  • Si des tâches du Sprint backlog n’ont pas été traitées lors du Sprint, celles-ci ne passent pas en démo et retournent dans le Product backlog
  • Plusieurs équipes Scrum peuvent avoir les mêmes dates de début et de fin du Sprint mais ce n’est pas obligatoire
  • Le PO reste toujours responsable
  • Le refinement se fait toujours 1 ou 2 sprints à l’avance
  • Les Sprint Reviews sont des réunions informelles, pas de sign-of des stakeholders
  • Si plusieurs équipes, c’est OK d’avoir plusieurs DoD tant que tout puisse être consolidé en un seul incrément
  • Le PO est une personne, pas un comité
  • Il n’y a pas de Sprint zéro, tous les Sprints ont la même structure
  • Le Daily Scrum est pour la DEV team. Le PO et le SM ne doivent pas être présents mais ils peuvent y assister
  • Tout ce qui est dans le Scrum guide est « mandatory », et non pas « à la carte »
  • Si un élément du Product Backlog n’est pas conforme à la Definition of Done, il ne peut pas être publié ni même présenté lors de la Sprint Review. Il est alors renvoyé au Product Backlog pour être replanifié ultérieurement

Je reste dubitative sur un point… Après la Rétrospective, un point d’action doit-il être ajouté (ou pas) dans le backlog (Product ou Sprint backlog ?). Si je me réfère à la dernière version du Scrum Guide, je dirais « pas obligatoirement » :

La Scrum Team identifie les changements les plus utiles pour améliorer son efficacité. Les améliorations ayant le plus d’impactsont abordées dès que possible. Elles peuvent même être ajoutées au Sprint Backlog pour le prochain Sprint.

Bonne M… pour votre Certification ! Perso, je m’en vais préparer la PSM II 😉

Tout savoir sur la certification PSM I

Tout savoir sur la certification PSM I

Me revoilà !

Désolée pour le silence radio mais j’ai une bonne excuse : je préparais la certification PSM I 😉

Ça y est, je suis certifiée, à raison de 96,3 % (en 41 minutes et 17 secondes).

Je me la pète un peu, j’avoue… Mais vu ce que j’ai souffert pour préparer cette (maudite) certification, j’ai le droit !

Donc, la certification PSM I (Professional Scrum Master) est une certification reconnue partout dans le monde et délivrée par Scrum.org.

Il existe une autre certification officielle appelée CSM (Certified ScrumMaster), délivrée cette fois par la Scrum Alliance, l’organisation historique de Scrum.

La certification CSM de la Scrum Alliance existe depuis 2001. Initialement, celle-ci était délivrée automatiquement à toute personne ayant suivi la formation officielle de Scrum Alliance (2 jours). Tu douillais pour la formation et BAM! tu étais certifié, sans vérification de tes connaissances / compétences. EASY…

Aujourd’hui, la formation reste un prérequisite mais la Scrum Alliance a ajouté l’obligation de réussir un test composé de 50 questions, avec un niveau d’exigence de 70%, à savoir 35 bonnes réponses sur 50. La formation et le quiz doivent être renouvelés tous les deux ans. By the way, j’ai cru tomber de ma chaise en voyant les tarifs : $995 (Early bird $795) pour deux jours de formation en ligne.

Parallèlement à la certification CSM, il y a celle proposée par Scrum.org, créé par Kan Schwaber, cofondateur de Scrum. C’est la certification du pauvre en quelque sorte.  Concrètement : aucune obligation de suivre au préalable une formation hors de prix dans un centre agréé. Juste un test en ligne, accessible pour la modique somme de… 150 dollars ! Et, cerise sur le gâteau, la certification de Kan est… à vie !!!

Franchement, niveau rapport qualité-prix, il n’y a pas photo. Merci Kan ❤

C’est donc la certification PSM I que j’ai passée ce week-end.

Il s’agit de questions à choix multiple. En gros, vous devez répondre à 80 questions, en 60 minutes maximum, avec un niveau d’exigence de 85%. Il s’agit d’un test en ligne que vous passez directement sur le site Scrum.org. Pour y avoir accès, vous devez vous inscrire sur le site et acheter un code qui vous permettra de passer le test.

C’est un test à livre ouvert. Et là, vous vous dites : EASY ! Sauf que 45 secondes par question, ça ne vous laisse pas beaucoup de temps pour potasser. Il est donc vraiment important de s’y préparer. Bien maîtriser le sujet vous permettra de répondre super rapidement à 90% des questions… et de faire appel à un ami (Google pour ne pas le citer 😉 ) pour répondre aux 10% restants.

Alors, comment se préparer à la certification PSM I ? Première chose à faire : lire, relire, rerelire et rererelire le Scrum Guide et l’Agile Manifesto. Chaque mot a son importance. Je vous conseille de lire d’abord ces documents dans votre langue maternelle, avant de passer rapidement aux versions anglaises. Ah oui, je ne vous ai pas dit : la certification PSM I n’existe qu’en anglais. Et ça joue pas mal sur les mots… attention, soyez préparés. Should, Could, Can et Must, c’est pas pareil !

Ensuite, testez-vous ! Vous trouverez sur Scrum.org ce qu’ils appellent des open assessments. Ces tests blancs de 30 questions vous donneront une idée du QCM et de l’ambiance de l’examen final. Faites-en autant que possible. N’hésitez pas à passer également les Product Owner open assessments, ça élargira votre horizon.

Mais ce n’est pas suffisant… Je vous conseille de trouver d’autres simulateurs d’examen.

Personnellement, j’ai utilisé Certifagile.com (9,99 euros pour une semaine) et l’application Scrum Master Certification d’examsnet (1,59 euros, ça va, on n’est pas volé).

Il y a également pas mal de bouquins sympas disponibles sur Amazon, qui préparent à la certification PSM I. Je recommande « Scrum Master and Product Owner Certification Practice Exam Preparation » de Dan Tousignant. Attention, quelle que soit la source que vous choisissez pour réviser, veillez bien à ce que celle-ci soit conforme à la dernière version du Scrum Guide (celle de 2020). C’est super important, au risque de jeter votre argent par la fenêtre et de rater bêtement votre certification.

Voilà, j’ai tout dit. Enfin, non, j’ai plein de conseils pratiques et de tuyaux pour réussir la certification PSM I. Mais pour ça, vous devrez attendre la prochaine note 😉 

See you ! 

PS : Vous aurez noté le « I » dans « PSM I ». En effet, je ne parle ici que de la première des trois certifications Professional ScrumMaster. Scrum.org propose trois niveaux de certification  (PSM I, PSM II,PSM III), avec à chaque fois un niveau de complexité supplémentaire. Mais bon, un jour à la fois comme ils disent chez les Alcooliques Anonymes 😉 Je reviendrai sur les certifications PSM II et PSM III en temps voulu.  

PS 2 : Notez que Scrum.org propose d’autres certifications que celles de Professional Scrum Master. On a également en magasin : PSPO pour Professional Product Owner ; PSD pour Professional Scrum Developer et SPS pour ScaledProfessional Scrum. Qui sait, un jour peut-être…

La neutralité du Scrum Master

La neutralité du Scrum Master

Comme expliqué dans ma note précédente, j’ai – en tant que PO – côtoyé deux Scrum Masters dont les profils étaient diamétralement opposés.

Ceux-ci avaient toutefois un point commun : ils reportaient tous les deux à un management purement IT. Alors que mon management à moi était purement business.

Ça se comprend, vu que la méthodologie Agile est issue initialement du monde informatique. Cela dit, aujourd’hui, le Manifeste Agile est devenu LA bible pour toutes les méthodologies de gestion de projet dites Agiles et s’applique bien au-delà du domaine IT.

Je défends l’idée que, pour rester objectif, le Scrum Master doit avoir une certaine neutralité par rapport aux membres de l’équipe Scrum. Son management doit être spécifique à son corps de métier. Il ne doit être ni du côté du business, ni du côté de l’IT.

Le faire dépendre des Ressources Humaines me semble être la meilleure des options possibles.

A voir sur le terrain 😉

Le Scrum Master, ou Servant Leader

Le Scrum Master, ou Servant Leader

Aux côtés du Product Owner, il y a le Scrum Master. J’aime bien les voir comme un tandem.

Le PO porte la vision du produit et est la voix du client. Le SM, quant à lui, est le garant au sein de l’équipe de la méthodologie Agile et du framework Scrum.

Le Scrum Master aide l’équipe à mettre en pratique l’agilité, entre autres par le biais des événements Scrum.

Mais ce n’est pas tout. Le Scrum Master a également le rôle délicat d’assurer un climat de confiance et de sécurité au sein de l’équipe. Il veille à l’harmonie et tente de créer du tissus social entre les gens.

Il a par ailleurs un rôle de facilitateur. C’est à lui que va s’adresser les membres de l’équipe Scrum en cas d’obstacles (les fameux « impediments »).  

On dit qu’il y a autant de façons d’être Scrum Master… que de Scrum Masters.

Pas faux. En trois ans, j’ai collaboré avec deux Scrum Masters dont les profils étaient diamétralement opposés.

Le premier, dominant, agissait comme un gendarme. Autoritaire et directif, il connaissait toutefois extrêmement bien le domaine et pouvait donc challenger les équipes. Ce qui est un plus, surtout dans le cadre de projets techniques très complexes. Le second, plus en retrait, compensait une moins bonne connaissance du domaine par une attitude empathique et bienveillante. De laquelle a découlé une vraie cohésion de groupe.

Sans hésitation, je pense aujourd’hui, avec le recul, que c’est le second profil qui correspondait le mieux au concept de « Servant Leader ». Ou du moins, le profil qui correspondait le mieux à mes valeurs et à mon mode de fonctionnement.

Les rôles Scrum : le Product Owner

Les rôles Scrum : le Product Owner

Bon, je vous ai parlé des artefacts et des événements de Scrum, reste à aborder les rôles et responsabilités.

Scrum prévoit trois rôles, ni plus, ni moins : le Product Owner (PO), le Scrum Master (SM) et les membres de l’équipe de développement.

Je propose de commencer par ce que je connais le mieux, pour avoir occupé ce poste les trois dernières années : le Product Owner.

Le Product Owner est chargé de maximiser la valeur du produit. D’un côté, il est en première ligne auprès des requestors. De l’autre, il est celui qui va porter la vision du produit au sein de l’équipe Scrum.

C’est au Product Owner que revient la responsabilité de gérer le backlog produit. Il crée les stories, les documente, les ordonne et s’assure que l’équipe de développement ait bien compris les différentes demandes business.

C’est également à lui que revient la responsabilité de définir l’objectif produit de chaque sprint et de le partager avec les membres de l’équipe Scrum.

Les critères d’acceptation par sprint sont également sous sa responsabilité, ainsi que le fait de valider les différentes stories.

Pour le dire plus simplement : le PO s’occupe du WHAT. L’équipe de développement, elle, s’occupe du HOW.

Dans le Scrum Guide, il est stipulé que le PO peut déléguer les tâches ci-dessus à d’autres membres de l’équipe Scrum. Mais que, quoi qu’il en soit, il reste redevable.

Le Product Owner a donc un rôle central. Par contre, il n’y a aucun lien hiérarchique entre lui et les autres membres de l’équipe Scrum.

D’ailleurs, de manière plus générale, il n’y a aucun lien hiérarchique du tout au sein de la Scrum Team. Tout le monde est au même niveau et collabore à une objectif commun : maximiser la valeur du produit.  

Pour être honnête avec vous, c’est ce que personnellement j’ai trouvé le plus compliqué à gérer en tant que PO : avoir les désavantages du chef, sans en avoir les avantages.

Autre aspect difficile à gérer : le côté paratonnerre de la fonction. Le PO est responsable d’absolument tout, vis-à-vis d’absolument tout le monde. Il faut avoir les épaules larges pour être Product Owner… et surtout avoir cette capacité à ne rien prendre personnellement.

Enfin, l’épanouissement du Product Owner est, pour moi, fortement lié à un autre grand principe de Scrum : l’auto-gestion et l’absence de micro management. Le Scrum Guide stipule que pour que les Product Owners réussissent, toute l’organisation doit respecter leurs décisions. Et j’ajoute, en gras souligné : y compris (et surtout) le management. Sans cela, le PO risque de perdre toute légitimité au sein de l’équipe Scrum (…)

Les artefacts Scrum

Les artefacts Scrum

Les artefacts, encore un terme alambiqué.

Les artefacts Scrum sont au nombre de 3 : le Product Backlog, le Sprint Backlog et l’Incrément Produit.

OK, mais ça ne me dit toujours pas ce qu’est un artefact.

« Le mot artefact désigne, de manière générale, un produit ayant subi une transformation, même minime, par l’homme et qui se distingue ainsi d’un autre provoqué par un phénomène naturel. »

Bon, arrêtons d’essayer de comprendre ce que signifie artefacts et entrons dans le vif du sujet.

Le Product Backlog est la liste de toutes les fonctionnalités intervenant dans le développement d’un produit.

C’est au Product Owner que revient la responsabilité de recueillir les besoins du client, de les transformer en user stories (ou fonctionnalités) et de construire/prioritiser/maintenir le Product Backlog.

Cette liste n’est pas figée, elle est enrichie régulièrement par le Product Owner et évolue sprint après sprint. Autre élément important : elle est accessible par tout le monde. On en revient aux trois piliers de Scrum : la transparence, l’inspection et l’adaptation.

Passons maintenant au Sprint Backlog.

Le Product Owner a également la responsabilité de prioritiser le Sprint Backlog. Lors du Planning Meeting, il va présenter les fonctionnalités qu’il ou elle aimerait voir développer en priorité dans le time slot prévu pour le Sprint.

La liste des tâches (ou user stories ou fonctionnalités) prioritisées par Sprint est appelée le Sprint Backlog.

Dans les deux cas, Product ou Sprint Backlog, un objectif clair doit être défini au préalable.

Le Backlog est l’unique source du travail de la Scrum Team.

Et en ce qui concerne l’Incrément Produit, troisième et dernier artefact Scrum, je vous renvoie à me note précédente : Empirisme, incrément et itération.

Empirisme, incrément et itération

Empirisme, incrément et itération

Quand on s’intéresse à la méthodologie Agile et à la méthode Scrum, on découvre des termes savants qu’il est bon de clarifier.

La premier, l’empirisme. On dit de Scrum qu’il est un processus empirique.

En philosophie, l’empirisme s’oppose au rationalisme. Pour les philosophes rationalistes, les idées sont innées. La seule source de connaissance est la raison. Ils défendent la toute-puissance de l’esprit et de la logique.

Pour les partisans de l’empirisme, opposés aux rationalistes, la connaissance n’est pas innée mais dérive de l’expérience. Toute connaissance est acquise a posteriori, par le biais de l’observation et de l’expérience sensible.

Si on applique cette définition à Scrum, on peut affirmer qu’il s’agit d’une méthode de gestion de projet qui privilégie les faits mesurables, l’observation et l’expérience. Plutôt que les plans fictifs (comme c’est le cas dans des projets développés selon la méthode « Waterfall »).

Ce concept d’empirisme se retrouve dans les trois piliers de la méthode Scrum. Rappelez-vous : la transparence, l’inspection et l’adaptation. A la fin de chaque Sprint, on inspecte ce qui a été développé et on l’adapte si nécessaire. Donc, forcément, avec Scrum, on apprend en expérimentant.

Autre terme rébarbatif, beaucoup utilisé en Scrum : l’incrément.

Un incrément est, basiquement, « ce qui vient s’ajouter ». Un ajout, une rallonge si vous préférez.

En Scrum, l’incrément est une partie du produit à délivrer, une étape concrète vers l’objectif final.

L’incrément du produit est composé de tâches appelées User Stories (US). A la fin de chaque sprint, un incrément est délivré par l’équipe Scrum et vient enrichir les incréments délivrés précédemment.

La somme des différents incréments compose le produit à délivrer. Chaque incrément apporte de la valeur au produit final.

Enfin, il y a le concept d’itération. Initialement, je pensais qu’itération et incrément étaient deux synonymes. En fait, non.

« Un processus itératif est un processus dans lequel une série d’opérations est répétée de manière cyclique, avec l’intention de se rapprocher de plus en plus d’un certain résultat désiré. »

Donc, Scrum est un processus itératif vu qu’il fonctionne par cycles courts de développement, appelés sprints. Et ce qui est produit à la fin de chaque de ces cycles (sprints) est appelé un incrément, à savoir une partie du produit final. Par ce fait, Scrum est également un processus incrémental vu qu’il préconise une approche dont l’objectif est de produire davantage de valeur à chaque cycle (sprint).

Allez, c’est limpide ! On peut passer à la suite…

PS : un autre terme me questionne, celui d’Intelligence collective. J’y reviendrai plus longuement, promis !

Les événements Scrum

Les événements Scrum

Dans la méthode Scrum, les événements (entendez les réunions récurrentes) sont super importants. C’est eux qui permettent l’application des trois piliers empiriques que sont la transparence, l’inspection et l’adaptation. Et tout est hyper cadré.

Dans un premier temps, il y a le Sprint. C’est le conteneur de tous les autres événements.

Le Sprint dure entre 1 et 4 semaines. Durant cette période de temps, l’équipe Scrum s’engage à délivrer un incrément de valeur (comprenez une partie du projet global).

Durant le Sprint, aucun changement n’est permis, qui pourrait remettre en cause l’objectif de Sprint.

Le début du Sprint est marqué par un événement appelé le Sprint Planning. Durant le Sprint Planning, l’équipe définit l’incrément à délivrer au terme du Sprint.

Le Sprint Planning est limité dans le temps à un maximum de huit heures pour un Sprint d’un mois.

Au sein d’un Sprint, chaque jour, l’équipe fait le point sur ce qui a été délivré la veille et sur ce qui sera réalisé ce jour. En quelque sorte, l’équipe inspecte la progression vers l’objectif du Sprint. Cette réunion quotidienne est limitée à 15 minutes et s’appelle le Daily Scrum.

Ces mêlées quotidiennes ont comme objectif d’améliorer la communication au sein de l’équipe, d’aider à identifier les obstacles éventuels, de favoriser la prise de décision rapide et de supprimer les autres réunions. 

A la fin du Sprint a lieu ce qu’on appelle la Sprint Review. C’est l’avant-dernier événement du Sprint. Cette réunion consiste à présenter l’incrément de valeur développé pendant le Sprint, à l’inspecter et à l’adapter si nécessaire. Il s’agit d’une session de travail dont la durée est fixée à quatre heures pour un Sprint d’un mois.

C’est la Sprint Rétrospective qui clôture le Sprint. Elle est limitée à un maximum de trois heures pour un Sprint d’un mois. Durant cette réunion, les membres de l’équipe Scrum vont faire le point sur le Sprint qui s’achève, l’inspecter et voir ensemble ce qui pourrait être amélioré.

Et tout ça, en boucle ! Un Sprint est à peine clôturé que commence le suivant. Et là, c’est rebelotte : Sprint Planning, Daily Scrum, Sprint Review et Sprint Retrospective.

Ces quatre événements Scrum sont décrits dans le Scrum Guide comme des boîtes de temps ou timebox.

Scrum pour les nuls (ou les pressés)

Scrum pour les nuls (ou les pressés)

Mais que dit le Guide Scrum ?

On va faire court.

Scrum repose sur trois piliers : la transparence, l’inspection et l’adaptation. Ca n’est pas étonnant compte tenu de la nature même de la méthodologie Agile qui consiste à être flexible et à s’adapter en permanence. En Scrum, régulièrement, on s’arrête sur ce qui a été fait, et on en parle. Et si besoin, on adapte. Et cela, en toute transparence.

Les valeurs de Scrum sont les suivantes : l’engagement, le focus, l’ouverture, le respect et le courage. C’est ce qui doit orienter en permanence le travail, les actions et l’attitude de la Scrum Team.

Ah, la Scrum Team, justement ! C’est l’unité fondamentale dans laquelle il ne doit y avoir aucune hiérarchie. Tous les membres sont au même niveau. Il s’agit d’une équipe pluridisciplinaire qui doit se suffire à elle-même. Celle-ci est composée d’un Product Owner (PO), d’un Scrum Master (SM) et de développeurs. Dix membres max, c’est important pour conserver une bonne dynamique.

La Scrum Team a un seul et même objectif : créer un incrément qui a de la valeur. Et ce, sprint après sprint.

Ah oui, les sprints. Ce sont des périodes de temps (deux semaines dans mon cas, mais ça peut aller jusqu’à quatre semaines) durant lesquelles l’équipe Scrum produit de la valeur. A chaque fin de sprint, l’incrément de valeur est partagé, inspecté et, si nécessaire, adapté.

Car ne l’oublions pas, la méthode Scrum – tout comme la méthodologie Agile d’ailleurs – défend une approche itérative et incrémentale de gestion de projet. Le tout, fondé sur l’empirisme, ou sur l’expérience / l’essai-erreur si vous préférez.

Voilà, vous avez maintenant une bonne vision générale de ce qu’est la méthode Scrum.

Reste à vous détailler les rôles de chacun, les événements et les artefacts.

Scrum et son guide de référence

Scrum et son guide de référence

Je l’ai écrit dans une note précédente, l’Agile est une méthodologie. On pourrait même parler d’état d’esprit (mindset) ou de philosophie.

Bien entendu, ça ne suffit pas. Pour pratiquer l’Agile, il faut un cadre de travail (framework). Un mode d’emploi si vous préférez.

Dans ce blog, je parlerai principalement de la méthode Scrum, car c’est celle que je connais le mieux pour l’avoir expérimentée en tant que Product Owner. C’est par ailleurs le cadre Agile le plus éprouvé et le plus documenté, après Kanban.

La méthode Scrum a été développée début des années 90, par Ken Schwaber et Jeff Sutherland. Pour aider à la compréhension de ce framework, ceux-ci ont par la suite régigé un guide officiel, le Scrum Guide.

Là non plus, comme pour l’Agile Manifesto, ne vous attendez pas à un guide kilométrique. Le guide de référence de Scrum fait – en tout et pour tout / purement et simplement – 13 pages : « Scrum est simple. Essayez‐le tel qu’il est et, déterminez si sa philosophie, sa théorie et sa structure aident à atteindre les objectifs et à créer de la valeur. Le cadre de travail Scrum est volontairement incomplet, ne définissant que les parties nécessaires pour mettre en œuvre la théorie Scrum. Scrum repose sur l’intelligence collective des personnes qui l’utilisent. Plutôt que de fournir aux gens des instructions détaillées, les règles de Scrum guident leurs relations et leurs interactions. »

Depuis sa première publication en 2010, le Guide Scrum évolue régulièrement. La dernière mise à jour date de 2020. Il s’agit de la sixième édition.

A lire :
Le Guide Scrum – Le guide de Référence de Scrum – Les règles du jeu : https://scrumguides.org/