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 sécurité psychologique

La sécurité psychologique

En tant que Scrum Master, il nous a été demandé d’organiser des workshops avec nos squads respectifs.

Pour mon premier workshop, j’ai choisi de réfléchir au concept de sécurité psychologique.

En réalité, ce concept n’est pas propre à l’entreprise. Il  est inhérent à toute dynamique de groupe, quel que soit le contexte. C’est un sujet qui me semble d’autant plus intéressant et important à traiter.  

Pour moi, les quatre questions à poser durant ce workshop sont les suivantes :

  • A quoi reconnait-on un environnement professionnel sécuritaire ?
  • Que mettre en place pour assurer cet environnement ?
  • Quels sont les avantages de la sécurité psychologique pour l’entreprise ?
  • En quoi la sécurité psychologique est-elle la clé d’une transformation Agile réussie ?

Et bien, commençons !

A quoi reconnait-on un environnement professionnel sécuritaire ? C’est assez simple au final. C’est un environnement dans lequel les individus peuvent exprimer tout leur potentiel, sans avoir peur. Concrètement, ça veut dire quoi ? Ça veut dire que les nouvelles idées sont valorisées ; que la prise de parole est encouragée ; que les différences d’opinions sont acceptées ; que la prise d’initiatives est gratifiée (et ce, même – et surtout – si elle comporte une part de risque) ; qu’il est OK de partager ses difficultés et de demander de l’aide ; qu’il est OK de douter ; qu’il est OK de demander du feedback ou d’en donner (dans la mesure où celui-ci est constructif) ; et surtout, qu’il est OK de se tromper.

En fait, toutes les actions listées ci-dessus sont ce qu’on appelle des actes de vulnérabilité. Prendre la parole, poser une question, donner un avis, exprimer un point de vue différent, prendre une initiative, tenter une expérience, demander de l’aide, se tromper, … On dira donc d’un environnement professionnel qu’il est sécuritaire si les actes de vulnérabilité y sont non seulement acceptés mais également encouragés et valorisés. Chaque employé peut exprimer ses vulnérabilités sans craindre des représailles éventuelles.

Par contre, si ces mêmes actes de vulnérabilité sont systématiquement associés à une punition, un reproche, une brimade, … dans ce cas, on peut parler d’un contexte d’insécurité psychologique.

Découle de cela la question suivante : que mettre en place pour assurer environnement professionnel sécuritaire ? Sur base de ce que j’ai expliqué ci-dessus, c’est assez simple (dans la théorie du moins).

Encouragez les membres de l’équipe à s’exprimer ; veuillez à ce que chacun ait l’opportunité de prendre la parole ; remerciez tout feedback ; recadrez les comportements insécuritaires au sein de l’équipe (moquerie, le fait de couper la parole, …) ; encouragez explicitement la diversité des points de vue ; partagez vos erreurs ; encouragez la prise de risque ; écoutez activement (j’y reviendrai) ; montrez vos vulnérabilités et SURTOUT récompensez les actes de vulnérabilité.

Et nous voilà arrivés à la troisième question : quels sont les avantages de la sécurité psychologique pour l’entreprise ? C’est vrai finalement. Le management de la terreur, ça fonctionne très bien aussi non ? A quoi bon tous ces efforts ?

Une fois de plus, c’est simple. Tout est une question d’énergie. Chaque individu a un capital d’énergie qui lui est propre. Ce capital énergétique, il est utilisé tout au long de la journée. Dans un environnement sécuritaire, il sera utilisé pour partager, grandir, créer, innover, apprendre, performer. Dans un environnement insécuritaire, il sera utilisé pour quoi ? Ben oui, vous avez compris. Il sera utilisé pour se protéger, se cacher, éviter, se défendre. Un individu qui adopte une posture de protection n’est plus dans l’innovation. Un individu qui a peur active instinctivement des réflexes de protection tels que l’auto censure, le désengagement et la fuite. S’améliorer devient trop couteux en cas d’échec. On fait profil bas, on la ferme et on stagne. Dois-je encore vous expliquer l’avantage pour une entreprise de développer un environnement sécuritaire ?

Mais Agile dans tout ça ?

Agile ne fonctionne tout simplement pas sans sécurité psychologique. Condamner la vulnérabilité, c’est condamner l’agilité. Rappelez-vous des trois piliers de la méthodologie Agile : Transparence, Inspection et Adaptation. Chaque jour en Daily Scrum, en début de sprint via le Planning meeting ou en fin de sprint via la Rétro, on inspecte et on adapte si nécessaire. Cet exercise n’est possible que si les membres de la Scrum team se sentent suffisamment en sécurité que pour s’exprimer, challenger, poser des questions, donner du feedback, reconnaitre les erreurs éventuelles et explorer les idées nouvelles. Sans processus dialogique collaboratif, pas d’Inspect & Adapt. Et donc, pas d’agilité. Ça n’est pas un hasard si, parmi les déclarations de valeur de l’agilité, on retrouve noir sur blanc la priorité aux individus et à leurs interactions, avant les processus et les outils.

Et pour ceux et celles qui veulent creuser cette thématique passionnante, je conseille l’ouvrage du professeur Amy Edmonson : The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth.

Là dessus, je m’en retourne préparer mon workshop 😉

La patience, mère de toutes les vertus

La patience, mère de toutes les vertus

Dans ma note précédente, j’ai abordé la problématique de l’urgence et de son incompatibilité avec une transformation Agile.

J’ai par ailleurs soulevé la difficulté de trouver sa place en tant que Scrum Master, face au PO et au sein de la Scrum Team.

Bien entendu, j’ai partagé ces considérations autour de moi et la réponse fut systématiquement la même : SOIS PATIENTE !

Aaaahhh la patience, quelle belle vertu.

Les personnes impatientes veulent que la vie se dépêche. C’est joliment dit.

En fait, la capacité à être patient est liée à la notion de frustration. Ou plutôt à la notion de résistance à la frustration. Et par conséquent, au besoin – parfois compulsif – de satisfaction.

Être impatient, c’est tout faire vite. Avec le risque de ne pas vivre dans l’instant présent, de rester en surface, de faire des jugements hâtifs ou d’imposer son rythme à l’autre. L’impatient peut en effet devenir rapidement tyrannique et intolérant.

Attention, il y a aussi des qualités liées à l’impatience : la créativité et l’enthousiasme. L’impatience est un vrai moteur qui aide à passer à l’action et à trouver des solutions rapidement.

A ce propos, j’ai appris un nouveau mot en écrivant cette note : la précrastination, soit le besoin compulsif de rayer une tâche de sa to-do-liste mentale le plus rapidement possible. Avec, comme risque, un manque de concentration et un risque d’épuisement, lié à l’incapacité de canaliser son énergie sur les choses importantes.

Mea culpa, c’est vrai, je l’avoue : JE SUIS IMPATIENTE.

Mais en même temps, qui ne l’est pas aujourd’hui ? L’immédiateté n’est-elle pas devenue un diktat imposé par notre société ?

Rappelez-vous de ma note sur la révolution industrielle 4.0. Nous vivons actuellement une mutation radicale de notre rapport au temps.

Et encore, nous, ça va (par « nous », j’entends « les vieux »). On sait ce que c’est « attendre », ou du moins on s’en souvient vaguement. Mais imaginez les nouvelles générations. Ces générations du « tout, tout de suite », du « zéro frustration ». Ces générations qui ont grandi avec, dans la main, l’icône suprême de l’instantanéité : le smartphone.

Notre société est devenue celle du zapping, du swipe, du fast, des clips et des spots. On est devenu accro à l’immédiateté. On se lasse de tout, à une vitesse V V prime. On fait mille trucs à la fois. Et on développe des troubles de l’attention gros comme des camions.

Et le pire dans tout ça, c’est que l’instantanéité génère une obligation d’instantanéité. Les nouvelles technologies nous ont libérés des contraintes du temps, certes. Mais elles ont également intensifié l’obligation de réactivité et donc, d’immédiateté. Sans oublier la « peur de rater » qui aggrave encore plus la sensation d’urgence (et le stress qui va avec).  

Alors oui, c’est vrai, la patience, ça se travaille. On fait de la pleine conscience, de la méditation, des promenades en forêt. On se met à la couture, à la poterie, au jardinage. On dit NON! à la tyrannie de l’immédiateté et on modifie son rapport à la temporalité.

Mais bon, dans les faits, ça fait un mois que je suis Scrum Master et que je galère à trouver ma place ! 😉

La théorie, c’est bien. La pratique, c’est mieux #oupas

La théorie, c’est bien. La pratique, c’est mieux #oupas

Bon, ça y est ! Je suis officiellement Scrum Master et ce, depuis le 1er mars 2022 !

Je fais à présent partie d’un Chapter. J’ai rejoint deux nouveaux squads, et par la même occasion une nouvelle Tribe, leadée par un éminent Tribe Lead. Et je collabore au quotidien avec un Product Owner et une Scrum Team. Nous appliquons à la lettre le cadre de travail Scrum et ne ratons aucune des cérémonies mentionnées dans le Scrum Guide. Je prends mon rôle de Servant Leader très à cœur et suis à l’écoute des membres de l’équipe. Bref, tout va pour le mieux, dans le meilleur des mondes.

Honnêtement, tout ce que j’ai énoncé ci-dessus est vrai.

Sauf que… j’ai omis quelques détails.

Je l’ai écrit précédemment, l’Agile est un état d’esprit, une philosophie. Or, changer de mindset prend du temps. C’est vrai pour les individus, et pour les entreprises. J’irais même jusqu’à dire (ça n’engage que moi), que changer de mindset devrait naturellement suivre les 5 étapes du deuil. Vous les connaissez n’est-ce pas ? Déni, colère, marchandage, dépression et acceptation. C’est vrai finalement, on perd quelque chose. Le processus est le même, non ?

Dans son livre « Du désir au plaisir de changer », Françoise KOURILSKY insiste sur le recadrage , comme étape majeure du changement. Mais le recadrage, les copains, ça prend du temps !

Tout ça pour dire quoi ?

Tout ça pour dire que devenir Scrum Master en amorce d’une transformation Agile n’est pas simple.

Être PO, c’est clair, net, précis. C’est stressant, ça demande du leadership et une très bonne connaissance du domaine. Le PO est en première ligne, il essuie les coups. Les fleurs, ça sera pour plus haut. J’ai été Agile Product Owner, je parle donc en connaissance de cause. PO, c’est dur. Mais c’est clair.

Scrum Master… Sur papier, j’adore, j’adhère ! Je suis fan, incontestablement. De la fonction, du profil, des compétences requises, de la mission.

Mais sur le terrain, en pleine amorce d’une transformation Agile, c’est pas si simple, croyez-moi.

N’oublions pas que Scrum Master est un rôle neuf, qui n’existe que dans une méthodologie et un cadre bien précis.

Le PO, qui avait l’habitude de tout gérer seul, avec éventuellement l’aide d’un Project Manager se voit soudainement binômer à un mystérieux Servant Leader.

La première question à se poser est la suivante : le PO (jeté brutalement dans l’eau glaciale de l’agilité) a-t-il envie de partager, de lâcher ? Est-il prêt à cela ? A-t-il intégré le changement, les nouveaux rôles et responsabilités ? Est-il bien conscient de la valeur ajoutée d’un Scrum Master ? Et combien même il ne verrait pas d’inconvénient à s’adapter, lui en laisse-t-on le temps ?

Et quid du cas où le PO (le WHAT) n’est que modérément enthousiaste par l’idée de lâcher une partie de ses responsabilités, au profit du Scrum Master (le HOW) ? Le Scrum Master doit accompagner le PO et l’équipe dans le passage vers un nouveau cadre de travail (Scrum). Il doit veiller à ce que le framework soit compris et appliqué correctement. Mais si, en amont, le PO en face de lui, est réfractaire à l’Agilité… et donc, de fil en aiguille, à sa présence en tant que binôme, on fait comment ?

Autre point important : l’entreprise a-t-elle pris le temps de bien constituer les binômes PO & SM ? C’est fondamental pour moi. Tous les profils ne fonctionnent pas bien ensemble.  On reparlera des états du moi en Analyse Transactionnelle mais, guys, un petit test de ce type prend 20 minutes. N’allez pas taper un Parent Normatif avec un Enfant Adapté Rebelle. Avec toute la bonne volonté du monde, CA NE PEUT PAS FONCTIONNER.

Mais revenons au métier de Scrum Master. Ce qu’on ne dit nulle part, c’est que c’est un métier de l’invisible. Tout est dans le ressenti, dans le relationnel. Or, on le sait, dans les relations humaines, il n’y pas de mode d’emploi. Devenir Scrum Master, c’est un peu comme devenir parent : tu fonctionnes à l’instinct. Tu as beau lire tous les livres d’éduction possibles et inimaginables, demander tous les conseils du monde… tu finis toujours par improviser car personne, à part toi, n’aura expérimenté cette configuration unique. Tu déploies tes antennes et tu fais du mieux que tu peux. Et bien Scrum Master, c’est pareil. Et on en revient toujours au même : déployer ses antennes, construire une relation de confiance, … devinez quoi… et bien, ça prend du temps !

Il n’y a pas UN Scrum Master. Ne croyez pas ce qu’on vous dit en formation. Il y en a cent, mille, des millions… Il y en a autant qu’il y a de PO et de Scrum Team. Et pour cette raison précise, je trouve que c’est un métier – certes passionnant – mais très énergivore d’un point de vue émotionnel. L’adjectif qui lui correspond le mieux, je trouve, est « subtil ». Oui, c’est un métier subtil, tout en nuances.

Bref.

Je me trompe peut-être. Ça ne fait que quatre semaines finalement. Mais là, aujourd’hui, je pense fermement que la clé d’une transformation Agile réussie est le temps. Le temps, pour les PO, les SM et les équipes Scrum de comprendre le changement, de l’accepter et de l’intégrer. Le temps d’apprendre à se connaître et de créer du lien. Le temps, pour chacun, de trouver sa place.

L’urgence est, selon moi, le poison de l’agilité (…)

L’agilité selon Spotify

L’agilité selon Spotify

Nous avons Agile, la méthodologie. Nous avons Scrum, le cadre de travail. Reste à trouver un mode d’organisation qui permette à l’entreprise de mettre tout cela en application.

Le modèle de référence est celui que Spotify a mis en place. On parle d’une mise à l’échelle de l’agilité.  

Chez Spotify, les collaborateurs sont répartis en quatre grands groupes : les Squads, les Chapitres (Chapters), les Tribus (Tribes) et les Guildes (Guild).

Le Squad correspond à l’équipe Scrum. C’est la plus petite des quatre structures (maximum 10 personnes). Elle compte un PO, un Scrum Master et une équipe de développement. Elle est autonome et orientée delivery. Son objectif est d’apporter de la valeur au produit.

Plusieurs Squads sont regroupés dans ce qu’on appelle une Tribe. Ensemble, au sein de la Tribe, les Squads travaillent sur un projet global commun. La Tribe est limitée à maximum 10 Squads et 80 collaborateurs. Elle est généralement suivie par un ou plusieurs Agile Coach. Et est leadée par un Tribe Lead, dont le rôle est s’assurer un alignement.

Chaque collaborateur appartient donc à un Squad, qui appartient lui-même à une Tribe. Mais chaque collaborateur appartient également à un Chapter, en fonction de son domaine de compétence. Les Chapters sont des groupes dédiés au partage de connaissances.

Enfin, il y a les Guildes qui s’apparentent à des communautés de pratiques.

Le modèle Spotify fait aujourd’hui office de référence et a inspiré de nombreuses entreprises.

Certaines réserves sont toutefois soulevées par rapport au fait de transposer ce modèle à l’identique dans d’autres entreprises de la même envergure.

Spotify n’a pas inventé « le modèle Spotify » du jour au lendemain. Celui-ci s’est construit année après année, au fur et à mesure de l’expansion graduelle de l’entreprise, par essai erreur. Il s’est construit AVEC les collaborateurs et en tenant compte de la culture d’entreprise. La tolérance à l’échec par exemple fait quasi partie de l’ADN de Spotify. Est-ce le cas de beaucoup d’entreprises ? Chez Spotify, les Squads sont des sortes de mini startups, totalement autonomes. Les managers sont aussi développeurs, Scrum Master ou autre et ce, afin veiller à toujours rester connectés au réel. Cela en demande du lâcher prise, de l’humilité et de la confiance. Est-ce réellement à la portée de toutes les entreprises ?

Allez, je termine cette note par des mots qui ne sont pas de moi mais que je trouve redoutablement justes : Le « modèle Spotify » a évolué au fil du temps dans une logique d’amélioration continue. C’est donc le résultat d’un processus d’apprentissage mené par les employés et partenaires de Spotify afin de mettre en place une organisation utile pour les aider (et pas votre organisation) à atteindre leurs propres objectifs (et non les vôtres). Vous ne pouvez donc pas copier tout ou partie de ce que Spotify a fait et vous attendre à ce qu’il fonctionne dans votre entreprise. Vous devez mener vos propres expérimentations, garder ce qui fonctionne et continuer à essayer jusqu’à ce que vous optimisiez votre propre modèle organisationnel. Source https://indeed.ailancy.com

Une fois de plus, à voir sur le terrain 😉

Spotify Engineering Culture – part 1 from Spotify Training & Development on Vimeo.

Spotify Engineering Culture – part 2 from Spotify Training & Development on Vimeo.

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/

Le concept de résilience

Le concept de résilience

Dès que vous vous intéressez à la méthodologie Agile, un mot revient en boucle : la résilience.

Alors, c’est simple, tout le monde doit être résilient : le marché, les entreprises, le management, les employés, …

La résilience, c’est un peu comme une formule magique, le saint graal de toute transformation Agile.

Sauf que la résilience, je m’y intéresse depuis fort longtemps. Et que c’est bien plus que ça.

Initialement, la résilience est un terme utilisé en physique qui signifie « revenir à sa forme initiale après un choc ».

Dans les années 50, des psychologues américains s’intéressent à ce concept, l’adaptent et l’appliquent à la psychologie.

Mais c’est Boris Cyrulnik, éminent neuropsychiatre français, qui vulgarise la résilience auprès du grand public grâce à son livre « Un merveilleux malheur », sorti en 2001 : « On s’est toujours émerveillé devant ces enfants qui ont su triompher d’épreuves immenses et se faire une vie d’homme, malgré tout. Le malheur n’est jamais pur, pas plus que le bonheur. Un mot permet d’organiser notre manière de comprendre le mystère de ceux qui s’en sont sortis. C’est celui de résilience, qui désigne la capacité à réussir, à vivre, à se développer en dépit de l’adversité. En comprenant cela, nous changerons notre regard sur le malheur et, malgré la souffrance, nous chercherons la merveille. »

Pour Cyrulnik, la résilience est la capacité à se reconstruire après un traumatisme. J’entends par trauma un deuil, un abandon, de la maltraitance, de la violence sexuelle, un contexte de guerre ou de génocide.

C’est la faculté qu’ont certains êtres humains à surmonter les épreuves de la vie et à rebondir en toutes circonstances.  « C’est l’art de naviguer dans les torrents » comme le disait si joliment Francis Bacon.

Ce qui rend la résilience intéressante et complexe, c’est que cette capacité à s’adapter et à aller de l’avant n’est pas donnée à tout le monde. En effet, nous ne sommes pas tous égaux face à la résilience. Celle-ci dépend de différents facteurs qui sont à la fois biologiques, psychologiques, sociaux  et culturels. Il y a donc autant de résilience que de personnes.

Par ailleurs, la résilience, comme le deuil, est un processus dynamique d’adaptation. On ne peut pas dire à quelqu’un : « Allez, sois résilient, maintenant ! » C’est un non-sens.

Voilà pourquoi l’utilisation du concept de résilience en entreprise et plus spécifiquement dans le cadre d’une transformation Agile me crispe un peu. J’y préfère de loin les termes de flexibilité ou d’adaptabilité.

A lire :
« Un merveilleux malheur » de Boris Cyrulnik

La révolution industrielle 4.0

La révolution industrielle 4.0

Dans mes deux précédentes notes, j’ai insisté sur l’importance d’être agile dans un environnement en constante mutation.

La période que nous traversons actuellement, appelée la révolution industrielle 4.0, est particulièrement fluide et dynamique.

Celle-ci suit trois autres grandes périodes d’avancées technologiques.

La première remonte à la moitié du 18ème siècle (1750) et est liée à la vapeur. La fabrication, jusque-là artisanale, devient mécanique.

Fin du 19ème siècle (1890), l’électricité entre dans l’équation et rend possible le travail à la chaine et la production de masse. L’automatisation de substitue à la main d’œuvre.

La troisième révolution date du milieu du 20ème siècle (1970) et repose sur l’informatique et les nouveaux moyens de communication. On parle de révolution numérique.

La quatrième révolution industrielle, nous sommes en plein dedans ! Et ce, depuis 2015 environ. C’est la révolution marquée par l’émergence de technologies novatrices et leur fusion. On parle de Big Data, d’Intelligence Artificielle, de robotique, d’internet des objets, de véhicules autonomes, d’impression 3D, de blockchain, de nano technologies, de bio technologies ou encore d’informatique quantique.

Le calcul est vite fait : un siècle et demi pour la première révolution industrielle ; un siècle pour la seconde; et un demi-siècle pour la troisième. Le temps (nous) presse !

Avec la quatrième révolution industrielle, on passe à la vitesse supérieure. Comparée aux révolutions précédentes, celle-ci évolue à un rythme exponentiel et non plus linéaire.

Mais la révolution industrielle 4.0 n’est pas uniquement différente de par sa vitesse. Elle l’est également de par sa portée et son impact.

En effet, pour la première fois en trois siècles, tous les secteurs d’activité sont concernés et ce, partout dans le monde. Le secteur public, le secteur privé mais également le monde académique et la société civile. L’impact s’étend aux citoyens, bouleversant leur manière de vivre et leurs habitudes de consommation.

Un tsunami d’avancées technologiques renforcé par… je vous le donne en mille… LA CRISE SANITAIRE !

Vous l’aurez compris, le vitesse à laquelle apparaissent les innovations actuelles est sans précédent. Face à un environnement en constante mutation, les entreprises doivent se montrer agiles, résilientes.

La résilience, encore un concept que j’adore. J’y reviendrai !

Image : http://ordinal-software.com
Ou, quand et comment est née la méthodologie Agile ?

Ou, quand et comment est née la méthodologie Agile ?

Maintenant que la transformation Agile n’a plus de secret pour vous ;), passons aux origines de l’Agile.

Comment est née cette méthodologie ? Qui l’a inventée ? Quels sont les documents de référence ?

Le terme « Agile » a été officialisé en 2001. A l’époque, aux Etats-Unis, dix-sept éminents spécialistes du développement de logiciels se réunissent pour discuter des problèmes auxquels l’industrie informatique est confrontée. Leur objectif ? Révolutionner les processus de développement.

De cet événement, connu aujourd’hui sous le nom de « sommet Snowbird » (en référence à la ville de Snowbird, dans l’Utah) nait un guide de référence : Le Manifeste Agile, rédigé et co-signé par les 17 experts.

Ne vous attendez pas à un document savant et/ou kilométrique. L’approche Agile se résume purement et simplement à 68 mots, 4 valeurs et 12 principes fondateurs.

Voici les quatre valeurs de l’agilité:

  • Les individus et leurs interactions plus que les processus et les outils.
  • Un logiciel fonctionnel plus qu’une documentation exhaustive.
  • La collaboration avec les clients plus que la négociation contractuelle.
  • L’adaptation au changement plus que l’exécution d’un plan.

En gros, on donne de l’importance et de l’autonomie aux équipes ; les clients / les utilisateurs sont placés au cœur du projet ; les développeurs se concentrent sur la production de fonctionnalités et non sur la rédaction de documentation ; et enfin, on accueille le changement et on fait preuve de flexibilité.

De ces quatre valeurs découlent les 12 principes fondateurs suivants :

  1. Satisfaire le client en priorité
  2. Accueillir favorablement les changements
  3. Livrer le plus souvent possible des versions opérationnelles de l’application
  4. Assurer une coopération permanente entre le client et l’équipe projet
  5. Construire des projets autour d’individus motivés
  6. Privilégier la conversation en face à face
  7. Mesurer l’avancement du projet en termes de résultats
  8. Faire avancer le projet à un rythme soutenable
  9. Porter une attention continue à l’excellence
  10. Raire preuve de rigueur au quotidien pour fournir un produit à forte valeur ajoutée en sortie
  11. Responsabiliser les équipes
  12. Ajuster à intervalles réguliers son comportement et ses processus pour être plus efficace

Aujourd’hui, vingt ans plus tard, le Manifeste Agile reste LA bible pour toutes les méthodologies de gestion de projet dites agiles. Et il s’applique bien au-delà du domaine IT !

Plus qu’une méthodologie, Agile est une philosophie, un état d’esprit. Il implique un changement profond de la culture d’entreprise. Et qui dit changement, dit résistance… on y reviendra.

A lire :
Manifesto for Agile Software Development : http://agilemanifesto.org/

Qu’est ce qu’une transformation Agile ?

Qu’est ce qu’une transformation Agile ?

Si vous regardez dans le dictionnaire, l’agilité est « la capacité à se mouvoir avec légèreté et souplesse ».

Et bien, tel est l’objectif d’une transformation Agile !

Une entreprise adopte la méthodologie Agile afin de gagner en flexibilité et en réactivité.

Par rapport à la méthode de gestion de projet traditionnelle, appelée « en cascade », la méthodologie Agile offre l’opportunité pour les entreprises de s’adapter en permanence aux changements rapides du marché et des technologies..

Avec « Waterfall », tout le projet est défini en amont, dans les moindres détails. Comme son nom l’indique, il s’agit d’un processus séquentiel dans lequel les progrès se déroulent en plusieurs phases, de haut en bas, à la manière d’une cascade. Les phases dépendent bien entendu de la nature du projet mais dans mon cas, il s’agirait de l’analyse UX, du design, de l’intégration, de l’analyse technique, du développement, du publishing et du testing.  Ce n’est que lorsqu’une phase est terminée que la suivante peut commencer. Et ce n’est que lorsque toutes les phases sont finalisées que le projet, dans sa globalité, est délivré au client.

En fonction de la nature du projet, le processus global peut prendre plus ou moins de temps. Durant ce laps de temps, le client n’a aucune vue sur le développement (c’est ce qu’on appelle l’effet tunnel). Avec le risque que le delivery final ne soit pas totalement à son goût, ou qu’il ne réponde plus aux besoins du marché, ou qu’ils ne soit plus compétitif, ou que sais-je. Dans ce cas, c’est reparti pour un tour !

Par ailleurs, ce processus séquentiel ne laisse aucune place à l’adaptation ou à la rétroaction. Ca ne pose pas de problème dans un environnement prévisible et stable. Mais dans un monde comme celui que nous connaissons aujourd’hui, où la technologie évolue d’une manière exponentielle et où tout ce qui nous entoure gagne en volatilité, en incertitude, en complexité et en ambiguïté, c’est extrêmement risqué.

Au contraire, la méthodologie Agile est basée sur une approche itérative et incrémentale. En gros, l’équipe va se fixer des objectifs à court terme. A chaque fois qu’un objectif sera atteint, elle passera au suivant. Par ce fait, le projet ne se présente plus comme une longue ligne droite mais plutôt comme la succession de sous-projets, jusqu’à l’accomplissement de l’objectif final.

Les avantages de cette manière de procéder sont multiples :

  • le client est impliqué tout au long du projet vu qu’il valide chacune des itérations
  • le scope du projet peut être adapté si nécessaire, sans devoir attendre le delivery final
  • le pilotage du projet est sécurisé compte tenu de la meilleure visibilité de l’avancement des développements
  • la gestion des risques est plus optimale
  • la réactivité aux différentes fluctuations du marché / de l’environnement est rendue possible
  • les délais de livraison sont fluidifiés

Si on en croit les chiffres, un projet mené en Agile aurait 3 fois plus de chances de réussir qu’un projet qui suit une méthodologie de gestion classique.

Ce n’est pas un hasard si les plus grands ont adopté cette méthodologie : Amazon, Google, SAP, PayPal, Yahoo, Spotify, Twitter, IBM, Microsoft, Spotify, …

Je reviendrai d’ailleurs sur le modèle Spotify, la référence en matière de transformation Agile.

Bref, vous comprenez mieux à présent ce qu’est une transformation Agile et l’importance pour une entreprise de « se mouvoir avec légèreté et souplesse » 😉

Image : https://www.easyredmine.com