Introduction

Introduction à l’agilité

Pour comprendre l’ampleur de la tâche dévolue au Scrum Master et la difficulté inhérente à cette fonction, il convient au préalable de partager quelques éléments de base concernant la gestion d’un projet.

Contrairement à une séquence d’activités construite comme une succession de processus, un projet repose sur un nombre variable d’actions dont on ne connaît à l’avance ni la teneur ni l’ampleur.

Un projet est donc porteur d’un nombre variable d’événements inconnus à l’avance et parfois imprévisibles. Plus le pourcentage d’événements ou d’actions inconnues est élevé par rapport à ce qui est prévisible, et plus le projet sera complexe à réaliser.

Un projet est donc constitué dans une part plus ou moins variable de problèmes qu’il faudra résoudre. Il s’avère qu’une équipe autonome est plus efficace qu’un seul individu lorsqu’il s’agit d’identifier et de mettre en œuvre des solutions face à ces problèmes.

Mais un projet n’est pas constitué que de problèmes. Il est également porteur d’opportunités, et là encore, nous sommes plus intelligents à plusieurs que tout seul.

Que ce soit pour saisir efficacement une opportunité ou pour régler un problème, la principale difficulté consiste à ne pas perdre de vue les objectifs initiaux du projet, donc à rester focalisé sur le pourquoi.

Pour gérer ces événements inattendus, plutôt que de s’appuyer sur un expert, ressource rare et onéreuse, l’agilité consiste à laisser une équipe autonome trouver les meilleures solutions pour adapter leur plan dans les meilleures conditions. Pour éviter que ces équipes ne s’égarent en chemin, Scrum propose un cadre de travail.

Réunissez un groupe de personnes et posez-leur un problème à résoudre. Naturellement, chacun va imaginer une stratégie de moyens  ; que faut-il mettre en œuvre pour résoudre ce problème ? Comment procéder ? Par quoi commencer ? Le groupe se focalise rarement sur le pourquoi car c’est l’aspect le moins visible. Rapidement...

Les concepts agiles

La terminologie agile a émergé en l’an 2000, regroupant des pratiques communes à plusieurs méthodes de gestion de projet qui remettaient en cause le cycle de développement logiciel séquentiel (en cascade ou en V).

Le manifeste agile commence par cette déclaration : « Nous découvrons comment mieux développer des logiciels par la pratique ». L’approche est donc très pragmatique et plus orientée sur la pratique que sur la théorie.

Fortement inspiré du Lean Management, lui-même issu du Toyota Production System, le manifeste agile repose sur quatre valeurs fondamentales, consistant à valoriser les éléments suivants :

Et il est constitué en second lieu de douze principes :

Le principe d’itérations

Le cycle itératif utilisé en agilité est issu des travaux d’Ikujiro Nonaka et Hirotaka Takeuchi portant sur les sciences cognitives et notamment le phénomène de spirale des connaissances.

D’ailleurs, Jeff Sutherland dédicacera son ouvrage « Scrum Papers » à Takeuchi et Nonaka, qu’il qualifie de « Godfathers of Scrum ». Cet ouvrage est téléchargeable gratuitement sur : https://www.scruminc.com/scrumpapers.pdf

D’après ces deux auteurs, la connaissance se décline en deux catégories, tacite et explicite, et s’accumule dans l’entreprise en provoquant un mouvement perpétuel de combinaison, d’internalisation, de socialisation et d’externalisation.

La connaissance ou l’information explicite peut se transmettre facilement et sans ambiguïté, que ce soit à l’oral ou à l’écrit.

La connaissance tacite ne peut pas se transmettre à l’écrit et difficilement à l’oral. Elle est transmise par la communication non verbale. Ce n’est pas celui qui la possède qui la transmet, mais celui qui désire la posséder qui l’acquiert, par socialisation, au travers d’actes d’observation, de mimétisme et d’essai/erreur. C’est pour accroître le partage de cette connaissance, portant sur les informations du produit, que Scrum recommande que tous les membres de l’équipe occupent un même espace de travail physique, et qu’ils échangent régulièrement des informations concernant le produit, directement avec les parties prenantes.

Exemple d’une information implicite, reposant sur une connaissance tacite, concernant un lancement de produit : « Le directeur fera une annonce à la presse lundi prochain. »

Cela peut signifier que le produit devra être parfaitement prêt lundi prochain, mais cela pourrait également signifier que le directeur annoncera la date de sortie officielle du produit lundi prochain. L’interprétation de cette phrase dépendra de la communication non verbale. Selon que son auteur semble rassuré ou inquiet, le message ne sera pas perçu de la même manière. Un nouveau cycle d’échange d’informations peut être nécessaire pour clarifier la manière dont elle sera assimilée (internalisée) par la personne ou le groupe de personnes.

Scrum fonde ses itérations sur le même principe cyclique :

Une partie prenante...

La planification de projet

Bien évidemment, le cycle itératif modifie la manière de planifier un projet, mais également la manière de l’organiser et de le piloter durant sa réalisation et sa maintenance.

Dans un cycle séquentiel, le chef de projet planifie l’activité de développement pour la totalité du produit par rapport à une estimation des charges réalisée très tôt dans le projet et par rapport à un certain nombre de partis pris.

Les spécifications détaillées, souvent rédigées plusieurs mois avant la réalisation des fonctions décrites, indiquent ce qui doit être réalisé et comment. La réalisation de ces activités est planifiée dans un diagramme de Gantt qui détermine qui fait quoi, quand et durant combien de temps.

Lorsque le projet arrive en phase de réalisation, si le « qui » change, l’estimation de charge initiale reste identique. Considérant les individus égaux dans leurs compétences, il n’est pas demandé à la nouvelle personne d’évaluer le temps qu’elle estime nécessaire pour réaliser les tâches qui lui incombent. Lorsque le quoi ou le comment changent, à moins que ce changement ne soit flagrant et qu’il remette visiblement en cause la planification, le pilote reste sur sa planification initiale et contraint l’équipe à la respecter.

Il en résulte fréquemment des défauts de réalisation qui engendreront des surcoûts lors de la maintenance du produit développé. Ces défauts, lorsqu’ils sont invisibles pour l’utilisateur (code redondant, failles de sécurité, problèmes de performances), sont la plupart du temps ignorés, et parfois même tolérés lorsqu’ils sont visibles. On parle alors d’anomalies mineures. Par ailleurs, elles sont décelées en fin de projet, lors de la phase de tests et de recette. Il s’est parfois écoulé plusieurs semaines ou mois entre le moment où le code a été produit et le moment où il faudra le modifier pour corriger une anomalie décelée, et la personne en charge de la correction n’est peut-être même pas l’auteur du code incriminé, déjà affecté à un autre projet.

Enfin, il faut attendre la fin du projet, pour pouvoir constater si le produit répond parfaitement aux besoins des utilisateurs ou des consommateurs. Lorsque c’est un projet interne, il est possible de réaliser ou d’adapter un chantier de conduite du changement. Une conception technique ou une réalisation défectueuses peuvent accroître le budget de cette activité. Là encore, il s’agit d’un coût caché. Est-ce une mauvaise estimation du MOE en charge de la conduite du changement ou bien un problème inhérent au MOE en charge de la réalisation ? Chacun des acteurs opposera des arguments pour ne pas avoir à subir la surcharge de coûts, même s’ils font tous partie de la même entreprise.

Pour un projet à destination du grand public, il faudra apporter des évolutions sous forme de patchs plus ou moins longs et coûteux à réaliser. Généralement, les actions de corrections ou d’évolutions sont regroupées sous forme de lots, car il faut repasser intégralement par une phase de test et recette afin de s’assurer qu’il n’existe pas d’anomalies de régression. Cette phase ayant été conçue initialement pour n’être réalisée qu’une seule fois en fin de projet, n’est que très rarement industrialisée ou automatisée.

S’il s’avère qu’un besoin a mal été capté...

Le conformisme

Lorsqu’un petit groupe de personnes partagent une aspiration commune, ont un objectif commun à atteindre, une équipe se forme. Cette entité est dotée d’une intelligence, on parle d’intelligence collective, mais c’est également une entité émotionnelle. La joie d’avoir accompli quelque chose de difficile ensemble est partagée par tous les membres de l’équipe sans avoir besoin d’un leader pour donner à chacun l’impulsion de ce sentiment collectif. Il en va de même en cas d’échec.

Dans cette illustration, une seule personne a loupé le penalty, mais chaque membre de l’équipe, et même du groupe de supporters, ressent la même émotion au même moment. Ce n’est pas qu’un ressenti, car à ce moment, le taux de dopamine de chaque individu s’effondre. L’effet étant également physique, il est quasiment ingérable par la raison.

Se sentir associé à un collectif est un sentiment si confortable et rassurant que chaque membre cherche à le préserver parfois même de manière déraisonnable.

Un groupe, ou une équipe, est donc défini par les caractéristiques suivantes :

Le changement managérial

Tant que l’activité de la majeure partie des entreprises était industrielle, le style de management autoritaire était le plus efficace. Les théories d’Adam Smith, de Frederick Taylor, puis Henri Ford rendent ces entreprises de plus en plus performantes. Les activités nécessaires à la réalisation d’un bien de consommation, d’un produit, sont connues à l’avance et précisément décrites sous forme de processus. Dans son ouvrage, The principles of scientific management, Taylor décrit de manière très claire les responsabilités des ouvriers et des managers. Le premier exécute sans avoir besoin d’autres connaissances que celles qui lui sont transmises par le management. Il doit rester focalisé sur sa tâche et l’ensemble des tâches ne doit plus être coordonné par des groupes d’ouvriers, mais par des managers. La performance de ces entreprises est liée à la qualité de leurs processus, la rigueur avec laquelle ils sont mis en œuvre et la productivité des employés, c’est-à-dire la vitesse à laquelle ils sont capables de réaliser une succession de tâches.

Le problème dans un projet, c’est justement qu’il est porteur d’un grand nombre de variables inconnues. S’inspirant du modèle industriel, durant cinquante ans les méthodes de conduite de projet qui se sont succédé ont tenté de réduire ce nombre d’incertitudes.

Toyota, en prenant le contre-pied de ces démarches, a modifié son organisation en profondeur et est devenue la compagnie automobile la plus performante au monde. Dans les années 60, il fallait attendre jusqu’à six mois pour prendre possession d’une Ford commandée dans un garage contre soixante jours pour une Toyota. Il en allait de même pour une Chrysler ou une voiture commandée chez General Motors. Qui plus est, il fallait débourser 30 % de plus pour acquérir un véhicule d’origine US comparé à un concurrent nippon. Le délai de paiement des fournisseurs, alors communément...

Les rôles Scrum

L’équipe Scrum comprend un Product Owner, des Developers et un Scrum Master.

Les événements Scrum

Les événements prescrits sont utilisés par Scrum pour créer de la régularité et minimiser le besoin de réunions non définies par Scrum. Idéalement, tous les événements se tiennent à la même heure et dans le même lieu pour réduire la complexité. Tous les événements sont limités dans le temps ; en boîte de temps (time-box), de telle sorte que chaque événement a une durée maximale.

Une fois qu’un Sprint commence, sa durée est fixe et ne peut être écourtée ou prolongée. Les autres événements peuvent se terminer dès que leurs objectifs sont atteints, tout en assurant qu’il y a eu suffisamment de temps accordé pour ces événements sans pour autant permettre le gaspillage dans les processus.

Les artefacts Scrum

Un artefact est un élément créé par l’homme, ayant des propriétés uniques. Les artefacts définis par Scrum sont spécifiquement conçus pour maximiser la transparence des informations clés afin que chacun ait la même compréhension de l’artefact.

Les changements du guide Scrum 2020

Les auteurs du guide Scrum ont cherché dans l’édition 2020 à revenir à des fondamentaux et à s’éloigner du monde informatique en devenant plus génériques. Ces changements ont un impact sur certaines croyances ou pratiques qui se sont progressivement diffusées dans la communauté agile.

Obtenir la certification Scrum Master

Il existe deux principaux organismes de formations délivrant un certificat ayant une reconnaissance internationale :

Préparer la certification PSM I de Scrum.org

Il faut commencer par lire attentivement le guide Scrum disponible gratuitement sur le site Scrum.org. En français si nécessaire, mais il faudra rapidement passer à la version américaine, car les 80 questions sont en anglais et font référence à une terminologie anglo-saxonne avec laquelle il est préférable d’être familiarisé.

Il est inutile d’apprendre par cœur le guide Scrum, mais il faut impérativement le comprendre, c’est-à-dire être capable d’imaginer ce que telle ou telle phrase implique concrètement dans le quotidien d’un Scrum Master.

Par exemple, concernant les moyens de servir le Product Owner en tant que Scrum Master, il est écrit à la page 7 du guide Scrum : « Helping find techniques for effective Product Goal definition and Product Backlog management; ».

Le Scrum Master doit aider le Product Owner à trouver des techniques. Il ne se positionne pas en tant que mentor, délivrant un savoir exclusif au travers de solutions éprouvées, mais en tant que coach qui aide le Product Owner à identifier les meilleures techniques. Le guide Scrum 2020 ne fait que 15 pages, dont 12 de contenu réel, mais chaque mot est important. Par exemple, dans la version 2010, le Backlog de produit était défini comme une liste priorisée, alors qu’il est défini aujourd’hui comme une liste ordonnée. Ce n’est qu’un changement d’adjectif, mais chacun peut comprendre aisément l’incidence de ce seul adjectif sur la manière dont le Product Owner organisera son travail.

Après une première lecture approfondie, il est possible de passer un examen blanc et gratuit sur le site Scrum.org, dans la rubrique « open assessments », l’examen SCRUM OPEN est dédié aux fondamentaux de Scrum.

Il faut alors répondre à 30 questions à choix multiple en 30 minutes.

Dans un premier temps, l’objectif n’est pas d’avoir 100 % de bonnes réponses, mais d’identifier les points sur lesquels vos connaissances sont insuffisantes. L’essentiel est donc d’analyser les mauvaises réponses et de comprendre pourquoi vous vous êtes trompé. Apprendre la bonne réponse par cœur ne sert à rien, vous n’avez qu’une chance sur 500 ou 1000 de retrouver cette question lors de l’examen réel. Il faut essayer de comprendre ce que vous n’avez pas encore compris, ou réapprendre ce qui a été...

S’organiser pour la certification Scrum.org

Vous allez devoir répondre à 80 questions en 60 minutes avec un taux de bonnes réponses de 85 %. Il faut donc répondre à chaque question en moins d’une minute. Idéalement, il faut planifier son temps en consacrant en moyenne 30 secondes pour chaque question ce qui permet de conserver 20 minutes en fin d’examen pour revenir sur les questions les plus complexes.

Certaines questions sont très simples, l’énoncé est rapide à lire et il n’existe que deux réponses possibles, par exemple :

La réponse correcte est b).

Mais certaines questions seront plus complexes, soit par la longueur de l’énoncé, soit par l’ambiguïté de choix dans les réponses proposées :

Si la bonne réponse n’apparaît pas très rapidement (réponse d), il faudra répondre ce qui vous semble le plus juste et revenir sur cette question durant les 20 minutes qui resteront à la fin de l’examen.

Enfin, certaines questions peuvent réellement prendre plus de 30 secondes pour les comprendre et identifier les meilleures réponses :

Pour identifier les bonnes réponses le plus rapidement possible, il faut procéder par élimination.

La proposition c) peut être éliminée d’office. Il est inconcevable d’envisager un Sprint qui ne permettrait pas de livrer un incrément, puisque c’est l’objet même d’un Sprint.

La réponse a) peut également être éliminée car Scrum ne requiert aucun prérequis d’outils ou d’infrastructure pour démarrer.

Il reste donc b), d) et e).

La réponse d) est acceptable, mais cela aurait pour conséquences d’accroître la dette technique et le nombre d’éléments...

Préparer la certification PSM II de Scrum.org

Préparez-vous à répondre à des questions bien plus complexes et toujours en anglais. Cette fois, vous disposez d’une heure trente pour répondre à trente questions. Vous avez donc plus de temps pour répondre à moins de questions, mais ne vous égarez pas en route : elles sont toutes longues à lire, il faut souvent s’y reprendre à plusieurs fois pour bien en saisir les subtilités et dans certains cas, toutes les réponses proposées sont bonnes, il faut choisir quelle est la meilleure.

Il est donc plus difficile de procéder par élimination jusqu’à trouver la bonne réponse et les questions auxquelles il n’était possible de répondre que par vrai ou faux n’existent plus.

La meilleure approche consiste à changer de point de vue, c’est-à-dire à se placer du point de vue des Developers, du Product Owner, et des parties prenantes. Si vous optez pour ce choix, comment ces personnes seront-elles susceptibles de réagir ? Est-ce que cela facilite les interactions à long terme ? Est-ce que cela accroît l’autonomie et la pluridisciplinarité ? N’est-ce pas un moyen de régler le problème à court terme, mais qui risque d’engendrer d’autres problèmes...

Préparer la certification PSM III de Scrum.org

Cette certification ne repose plus exclusivement sur des questions à choix multiples, mais intègre une grande partie de questions ouvertes, impliquant que vous formuliez vous-même la réponse, avec vos propres mots. Le résultat de cet examen ne vous parviendra d’ailleurs qu’une à deux semaines après son passage, car un examinateur doit étudier vos réponses et leur affecter une note.

Contrairement aux certifications PSM I et PSM II, il n’existe aucune formation permettant de vous préparer à cet examen, une expérience réelle de trois à cinq années en tant que Scrum Master est donc vivement recommandée.

Cet examen dure deux heures. Il faut donc être capable de vous isoler durant ce laps de temps. Sortez votre chien, mangez modérément, hydratez-vous, et allez aux toilettes avant de commencer, ce n’est pas en plein milieu de l’examen qu’il faut se rendre compte que votre vessie, ou celle de votre animal de compagnie, est pleine, ou bien que vous avez un petit creux.

La fatigue et le stress seront vos pires ennemis. Reposez-vous, calmez votre mental, faites le vide en pratiquant du yoga, de la méditation, ou en écoutant de la musique et surtout, détendez-vous. Ce n’est pas un concours de littérature et vous ne serez jugé ni sur l’orthographe, ni sur la grammaire, mais sur la pertinence de votre réponse tant qu’elle est compréhensible.

Il faut donc répondre sur le cœur du sujet et ne pas se noyer dans les détails. Pour cela, il faut comprendre la nature de la question...