Introduction
Prérequis et objectifs
1. Prérequis
Avoir lu le guide Scrum version 2020.
Avoir quelques notions de gestion de projet.
2. Objectifs
À la fin de ce chapitre, vous serez en mesure de :
Comprendre les principes agiles.
Comprendre la philosophie de Scrum.
Connaître les rôles de Scrum.
Connaître les événements de Scrum.
Connaître les artefacts de Scrum.
Comprendre la certification Scrum Master.
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.
![images/img-001.png](https://www.eni-training.com/download/c4783266-7393-4799-80dc-3cd7cd68a5b4/images/img-001.png?id=AAEAAAD%2f%2f%2f%2f%2fAQAAAAAAAAAMAgAAAE1FbmkuRWRpdGlvbnMuTWVkaWFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VuaS5FZGl0aW9ucy5NZWRpYXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAAwdGVzdCB2Ml84IC0gZmZhNjQzOWQtZDZjYi00NzYxLWJhYTMtZWZkZDNiZDcwMWM25rSq0F7p2IgL)
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 :
-
Les individus et leurs interactions plus que les processus et les outils.
-
Des logiciels opérationnels plus qu’une documentation exhaustive.
-
La collaboration avec les clients plus que la négociation contractuelle.
-
L’adaptation au changement plus que le suivi d’un plan.
Et il est constitué en second lieu de douze principes :
1. |
Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. |
2. |
Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client. |
3. |
Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et avec une préférence pour les plus courts. |
4. |
Les utilisateurs, ou leurs représentants, et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. |
5. |
Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. |
6. |
La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. |
7. |
Un logiciel opérationnel est la principale mesure d’avancement. |
8. |
Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. |
9. |
Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité. |
10. |
La simplicité, c’est-à-dire l’art de minimiser la quantité de travail inutile, est essentielle. |
11. |
Les meilleures architectures, spécifications et conceptions émergent d’équipes auto organisées. |
12. |
À intervalles réguliers, l’équipe réfléchit... |
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.
![images/img-002.png](https://www.eni-training.com/download/c4783266-7393-4799-80dc-3cd7cd68a5b4/images/img-002.png?id=AAEAAAD%2f%2f%2f%2f%2fAQAAAAAAAAAMAgAAAE1FbmkuRWRpdGlvbnMuTWVkaWFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VuaS5FZGl0aW9ucy5NZWRpYXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAAwdGVzdCB2Ml84IC0gZmZhNjQzOWQtZDZjYi00NzYxLWJhYTMtZWZkZDNiZDcwMWM25rSq0F7p2IgL)
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 :
![images/img-003.png](https://www.eni-training.com/download/c4783266-7393-4799-80dc-3cd7cd68a5b4/images/img-003.png?id=AAEAAAD%2f%2f%2f%2f%2fAQAAAAAAAAAMAgAAAE1FbmkuRWRpdGlvbnMuTWVkaWFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VuaS5FZGl0aW9ucy5NZWRpYXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAAwdGVzdCB2Ml84IC0gZmZhNjQzOWQtZDZjYi00NzYxLWJhYTMtZWZkZDNiZDcwMWM25rSq0F7p2IgL)
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.
-
Le quoi et le comment sont à la base de la planification par rapport à une double contrainte de budget et de délai.
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.
-
L’adaptation est faible et considérée comme source de risque pour l’ensemble du projet. Pour la réussite du projet, il est préférable de s’en tenir à ce qui a été planifié et contractualisé.
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.
-
Une part importante du coût du projet est cachée. Les coûts de la maintenance applicative et évolutive peuvent s’en trouver grandement accrus. Dans certains cas, les équipes en charge de la maintenance évolutive avouent ne pas pouvoir faire évoluer certaines parties d’un programme, ce qui conduit les dirigeants à envisager une refonte intégrale.
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.
-
Le délai de mise sur le marché du produit initial et de ses évolutions est très long.
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.
![images/img-006.png](https://www.eni-training.com/download/c4783266-7393-4799-80dc-3cd7cd68a5b4/images/img-006.png?id=AAEAAAD%2f%2f%2f%2f%2fAQAAAAAAAAAMAgAAAE1FbmkuRWRpdGlvbnMuTWVkaWFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VuaS5FZGl0aW9ucy5NZWRpYXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAAwdGVzdCB2Ml84IC0gZmZhNjQzOWQtZDZjYi00NzYxLWJhYTMtZWZkZDNiZDcwMWM25rSq0F7p2IgL)
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 :
-
les interactions ;
-
l’émergence de normes ;
-
l’existence de buts collectifs communs ;
-
l’existence d’émotions et de sentiments collectifs ;
-
l’émergence d’une structure informelle ;
-
l’existence d’un inconscient collectif ;
-
l’établissement...
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...
Le Framework Scrum
Scrum est extrêmement simple et peut être résumé en onze points :
-
Trois rôles :
-
Product Owner
-
Scrum Master
-
Developers
-
Cinq événements :
-
Sprint
-
Planification de Sprint (Sprint Planning)
-
Mêlée quotidienne (Daily Scrum)
-
Revue de Sprint (Sprint Review)
-
Rétrospective de Sprint (Sprint Retrospective)
-
Trois artefacts :
-
Backlog de produit (contenant un objectif de produit)
-
Backlog de Sprint (contenant un objectif de Sprint)
-
Incrément (contenant une définition de « Fini »)
Pourtant, il est préférable de lire intégralement le guide Scrum disponible gratuitement sur le site https://www.scrum.org/.
Les rôles Scrum
L’équipe Scrum comprend un Product Owner, des Developers et un Scrum Master.
L’unité fondamentale de Scrum est une petite équipe, la Scrum Team. La Scrum Team se compose d’un Scrum Master, d’un Product Owner et de Developers. Il n’y a pas d’équipe dans l’équipe ni de hiérarchies. Il s’agit d’une seule et même unité stable, composée de professionnels focalisés sur un seul objectif à la fois, l’Objectif de Produit. |
Guide Scrum 2020 |
1. Le Product Owner
Il est redevable de maximiser la valeur du produit résultant du travail de l’équipe Scrum.
Il est également redevable de la gestion efficace du Backlog de produit, en formulant et communiquant les objectifs du produit de manière explicite, mais aussi en ordonnant et en décrivant clairement les éléments du Backlog.
Il représente les intérêts des utilisateurs et doit avoir le pouvoir de prendre toute décision sur le produit. Le Product Owner est une personne physique.
2. Les Developers
Ils sont redevables de créer un Backlog de Sprint et d’en planifier la réalisation afin d’atteindre au mieux l’objectif du Sprint fixé par l’équipe Scrum, tout en respectant la Définition de Fini.
Les Developers doivent se tenir mutuellement responsables...
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.
1. Le Sprint
Le cœur de Scrum est un Sprint, qui a une durée (time-box) d’un mois ou moins au cours duquel des idées seront transformées en valeur.
À l’instar d’un projet, un Sprint est utilisé pour accomplir un objectif. Les Sprints ont une durée de vie constante pour faciliter le travail en ancrant des habitudes. Le Sprint est le conteneur de tous les autres événements Scrum, et un nouveau Sprint commence immédiatement après la conclusion du Sprint précédent.
Durant le Sprint :
|
Guide Scrum 2020 |
2. La planification de Sprint
En début de Sprint, l’équipe Scrum se réunit afin de fixer ensemble un but pour le Sprint et d’identifier les moyens permettant de l’atteindre. Le travail à effectuer est défini et planifié de manière collaborative par tous les membres de l’équipe. La réunion de planification du Sprint dure au maximum huit heures (time-box).
La planification de Sprint se décompose en trois thèmes :
Premièrement : l’identification d’un objectif à atteindre durant le Sprint, permettant d’accroître la valeur du produit.
Deuxièmement : la définition des moyens à mettre en œuvre pour atteindre l’objectif du Sprint. L’équipe Scrum définit le Quoi. Le Product Owner décrit à l’équipe les éléments du Backlog de produit permettant d’atteindre le but du Sprint et répond aux questions de l’équipe. L’équipe doit comprendre la portée de chaque élément et chaque membre doit être capable d’en évaluer la complexité. Seuls les Developers peuvent évaluer ce qu’ils s’engagent à réaliser durant le Sprint à venir, il leur revient donc de sélectionner le nombre d’éléments du Backlog de Produit qu’ils peuvent réaliser afin d’atteindre l’objectif fixé par l’équipe Scrum.
Si plusieurs équipes contribuent au même produit, seuls quelques représentants de chaque équipe participeront à cette thématique.
Troisièmement : les Developers planifient la manière dont ils vont mettre en œuvre les éléments sélectionnés afin de pouvoir délivrer un incrément de produit fini à la fin du Sprint. Ils identifient un certain nombre de tâches à réaliser pour mettre en œuvre chaque élément et s’assurer qu’ils sont individuellement finis et peuvent constituer un ensemble fini avec tous les éléments développés lors des Sprints précédents. Cet ensemble constitue la base du Backlog de Sprint.
Si plusieurs équipes contribuent au même produit, les représentants de chaque équipe reviennent vers leurs coéquipiers pour définir ensemble les éléments de cette seconde phase.
3. La mêlée quotidienne
Cette réunion quotidienne dure 15 minutes au maximum (time-box) et se déroule chaque jour à heure fixe. Elle permet aux Developers de planifier leur travail pour les prochaines 24 heures. Elle optimise la collaboration et la performance de l’équipe et doit permettre d’inspecter formellement le travail effectué depuis la dernière mêlée quotidienne. Elle permet également de planifier le travail qui peut être effectué d’ici la prochaine mêlée. Chaque...
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.
Chaque artefact contient un engagement qui apporte l’information nécessaire à la transparence et au focus rendant possible la mesure de la progression :
Ces engagements existent pour renforcer l’empirisme et les valeurs Scrum au sein de la Scrum Team et ses parties prenantes. |
Guide Scrum 2020 |
1. Le Backlog de produit
Le Backlog de produit est une liste ordonnée et émergente de tout ce qui est connu pour être nécessaire dans un produit. Il constitue l’unique source d’exigences pour tout changement à apporter au produit. Il liste toutes les fonctionnalités, les fonctions, les exigences, les évolutions et les corrections à apporter au produit.
Le Backlog de produit est un artefact vivant qui évolue au fur et à mesure que l’équipe en retire des éléments pour les ajouter dans son Backlog de Sprint et les transformer en incrément fini, mais également au fur et à mesure des retours d’expériences consécutifs aux premières mises en ligne, aux évolutions de marché ou de besoins.
-
Le Product Owner est le seul responsable du Backlog de produit, y compris son contenu, sa disponibilité et son ordonnancement.
-
Il n’y a qu’un et un seul Backlog de produit pour un produit et un seul Product Owner.
-
Tant qu’un produit existe, son Backlog de produit doit être maintenu.
-
Un seul Backlog de produit est utilisé pour décrire le travail à faire sur ce produit, même lorsque plusieurs équipes de développement travaillent sur le même produit.
L’affinage du Backlog de produit (Product Backlog Refinement) sert à affiner et clarifier. Cela peut conduire à ajouter des détails, des estimations et à ordonnancer les éléments du Backlog de produit.
Les éléments du Backlog de produit incluent souvent des descriptions des tests qui prouveront leur complétude lorsqu’ils sont « Finis ». Les premiers éléments du Backlog de produit sont généralement plus détaillés que les suivants. Leur estimation est plus précise en raison d’une plus grande clarté et d’un niveau de détail accru. Ce sont ces éléments qui seront probablement traités dans les Sprints à venir. Les éléments qui occuperont l’équipe Scrum durant le prochain Sprint sont affinés au point que n’importe lequel peut être raisonnablement « Fini » dans un Sprint. Ces éléments sont réputés « Prêts » pour leur sélection durant la planification du Sprint.
a. Engagement du Backlog de produit : l’objectif du produit
L’objectif du produit est généralement le premier élément du Backlog de produit. Il est décomposé, ou affiné, en moyens permettant d’atteindre cet objectif. Très souvent, cet objectif sera matérialisé ou mesuré grâce à un ou plusieurs vecteurs de valeurs permettant de délimiter le périmètre du produit.
b. Transparence du Backlog de produit
À tout moment, la somme de travail restant à faire pour atteindre un objectif peut être calculée. Le Product Owner suit l’évolution de la somme de travail restant à faire au moins à chaque revue de Sprint. Il compare cet indicateur avec ceux des revues des Sprints précédents afin d’évaluer la progression vers l’objectif en fonction des contraintes ou des exigences de délai. Cette information est rendue transparente pour toutes les parties prenantes.
2. Le Backlog de Sprint
Le Backlog du Sprint est constitué de l’objectif du Sprint (le pourquoi), de l’ensemble des éléments sélectionnés pour le Sprint (le quoi) plus un plan pour livrer l’incrément de produit fini et réaliser l’objectif du Sprint (le comment). Afin d’assurer une amélioration continue, il comprend au moins une amélioration de processus identifiée à la précédente rétrospective. La planification du Sprint doit être suffisamment détaillée pour être compréhensible lors de la mêlée quotidienne.
Le Backlog de Sprint évolue tout...
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.
1. Introduction de la notion de redevabilité
Jusqu’à présent, la description des rôles Scrum ne mentionnait que quelques responsabilités, et décrivait une liste de pratiques ou moyens à mettre en œuvre. Dans sa version 2020, le guide Scrum met l’accent sur la redevabilité de chaque acteur.
Le Product Owner est redevable de maximiser la valeur du produit ainsi que de la gestion efficace du Backlog de produit.
Le Scrum Master est redevable de la mise en place de Scrum telle que définie dans le Guide Scrum, mais également de l’efficacité de la Scrum Team ! Le Scrum Master est donc personnellement responsable de l’efficacité de l’équipe Scrum. Il n’en est pas seulement responsable, mais il doit rendre des comptes si l’organisation considère qu’elle n’est pas suffisamment efficace.
Enfin, les Developers sont redevables de la mise en œuvre de quatre pratiques ou processus :
1/ Créer un Backlog de Sprint contenant un plan de Sprint.
2/ Inculquer la notion de qualité en adhérant à une Définition de Fini.
3/ Adapter quotidiennement le plan de Sprint par rapport à l’objectif du Sprint.
4/ Se tenir mutuellement responsables.Mais, c’est toujours toute l’équipe Scrum qui est responsable des succès comme des échecs et qui doit régulièrement s’adapter : « The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint ».
2. Suppression de la notion d’équipe de développement
Jusqu’à présent, l’équipe Scrum était constituée d’un Product Owner, d’une à plusieurs équipes de développement et d’un à plusieurs Scrum Masters. En supprimant la notion d’équipe de développement, le Product Owner appartient de facto à plusieurs Scrum Teams, uniquement lorsque celles-ci travaillent sur le même produit. Il est toujours possible d’avoir un à plusieurs Scrum Masters associés au développement d’un produit.
3. Le rôle du Product Owner
En supprimant la notion d’équipe de développement, l’accent est mis sur l’équipe Scrum, dont le Product Owner fait partie intégrante. Cette modification a des impacts lors du passage à plusieurs équipes contribuant au développement d’un produit unique. Ces impacts ont d’ailleurs été pris en compte dans la publication du guide Nexus 2021.
4. Le rôle du Scrum Master
Historiquement, le Scrum Master devait s’assurer que Scrum était compris et mis en pratique. Cette injonction a souvent été traduite par une mise en œuvre de moyens plus ou moins coercitifs visant à faire adopter les pratiques ou processus décrits dans le guide Scrum et parfois même en dehors de celui-ci. Par exemple, l’usage des User Stories, alors qu’elles n’ont jamais été mentionnées dans Scrum, ou encore, la manière correcte ou incorrecte de les rédiger.
À partir de la version 2017, le Scrum Master devient « responsible for promoting and supporting Scrum...
Obtenir la certification Scrum Master
Il existe deux principaux organismes de formations délivrant un certificat ayant une reconnaissance internationale :
-
Scrum.org
-
Scrumalliance.org
1. Organismes de formation
Scrum.org
Cet organisme est très proche de Ken Schwaber et délivre une certification sur examen. Elle est payante (150 $ à ce jour), valable à vie et peut être réalisée sur Internet sans avoir à se déplacer. Le candidat doit répondre à 85 % des 80 questions à choix multiples dans un délai de 60 minutes pour obtenir la certification.
Scrumalliance.org
Cet organisme très proche de Jeff Sutherland délivre des certifications à toute personne ayant suivi une formation dans un centre agréé par Scrum Alliance. En France, le coût est d’environ 1500 € à ce jour. Cette certification n’est valable que pour une période limitée à deux années au moment où cet ouvrage est écrit. Il est possible d’étendre la période de certification en participant à des événements, généralement payants, en suivant une autre formation dans un centre accrédité (entre 1400 € et 2000 €), ou en acceptant de payer des frais administratifs.
Obtenir une certification auprès de Scrum Alliance ne nécessite aucune préparation préalable, il suffit d’être présent et attentif durant deux jours de formation pour obtenir le sésame. La certification auprès de Scrum.org est un peu plus complexe et nécessite un réel investissement personnel.
2. Structure du référentiel de connaissances Scrum.org
Le domaine de connaissance Scrum est scindé en plusieurs corpus d’éléments de connaissance. Le Scrum Master doit en maîtriser quatorze pour le passage de l’examen PSM I :
1. Comprendre et appliquer Scrum :
-
L’Empirisme & les piliers de Scrum
-
Les valeurs de Scrum
-
Les rôles de Scrum
-
Les événements de Scrum
-
Les Artefacts de Scrum (incluant le but du Sprint)
-
La notion de Fini
-
Scrum à l’échelle (plusieurs questions sont posées dans le cadre du développement des équipes et des personnes ou de la gestion de produit)
2. Le développement des équipes et des personnes :
-
Facilitation
-
Style de management
-
Les équipes auto-organisées
-
Coaching & mentorat
3. Gestion de produits agile :
-
Prévision et planification des releases...
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 :
-
In waterfall, the project team often gets early feedback from customers or markets about the product they are building, so they can act on this feedback on time.
a) True
b) False
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 :
-
When there are multiple Development Teams working on the same product :
a) They should ask the common quality guidance from the Product Owner
b) They should collocate together and integrate their changes every day under the supervision of Scrum Master
c) They should define a definition of « Done » of their own , and make their standards transparent to each other
d) They should mutually define their definition of « Done » so their combined work will be potentially releasable
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 :
-
Which two things are appropriate for a scrum master to do if the development team doesn’t have the engineering tools and infrastructure to completely finish each selected product backlog item? (two answers)
a) Declare the development team not ready for scrum
b) Have the development team establish a definition of « Done » that is actually possible to achieve given current circumstances
c) Refocus the current sprint on establishing the development team’s infrastructure instead of delivering an increment
d) Encourage the product owner to accept partially « Done » increments until the situation improves
e) Coach the development team to improve its skills, tools and infrastructure over time and adjust the definition of « done » accordingly
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...
Validation des acquis : questions/réponses
Si l’état de vos connaissances sur ce chapitre vous semble suffisant, répondez aux questions ci-après.
1. Questions
1 Quelles sont les quatre valeurs fondamentales du manifeste agile ?
2 Sur quel cycle repose l’agilité ?
3 Quels sont les deux types d’informations échangées dans une équipe ?
4 Quand sont planifiées les tâches de réalisation ?
5 Comment est considérée une modification de besoin ?
6 Quel est le modèle managérial qui a inspiré l’agilité ?
7 Quels sont les trois rôles de Scrum ?
8 Qui encadre les Developers durant le projet ?
9 Sur quelle valeur de Scrum le Scrum Master doit-il se focaliser ?
10 Quelle est la durée maximale d’un Sprint ?
11 Quand se termine un Sprint ?
12 Un Sprint commence par quel événement ?
13 Quel est l’objectif de la revue de Sprint ?
14 Un Sprint se termine par quel événement ?
15 Quelle est la durée maximale de la mêlée quotidienne ?
16 Qu’est-ce que le Backlog de produit ?
17 Combien de Backlogs peut avoir un produit ?
18 Qu’est-ce que le Backlog de Sprint ?
19 Qu’est-ce qu’un incrément de produit ?
20 Que permet la définition de « Fini » ?
2. Résultat
Référez-vous aux pages suivantes pour contrôler vos réponses. Pour chacune de vos bonnes réponses, comptez un point.
Nombre de points : /20
Pour le chapitre Introduction, le score minimum est de 15/20.
3. Réponses
1 Quelles sont les quatre valeurs fondamentales du manifeste agile ?
Les individus et leurs interactions plus que les processus et les outils.
Des logiciels opérationnels plus qu’une documentation exhaustive.
La collaboration avec les clients plus que la négociation contractuelle.
L’adaptation au changement plus que le suivi d’un plan.
2 Sur quel cycle repose l’agilité ?
L’agilité repose sur un cycle itératif et incrémental.
3 Quels sont les deux types d’informations échangées dans une équipe ?
Des informations tacites (ou implicites) et des informations explicites.
4 Avec l’agilité, quand sont planifiées les tâches de réalisation ?
Pour la réussite du projet, il est recommandé de ne planifier les tâches de réalisation que pour le Sprint en cours et d’affiner les éléments qui seront prochainement intégrés.
5 Comment est considérée une modification de besoin ?
Une modification de besoin est considérée comme une source d’opportunité pouvant maximiser la valeur du produit.
6 Quel est le modèle managérial qui a inspiré l’agilité ?
Le Lean Management a fortement inspiré les pratiques agiles.
7 Quels sont les trois rôles de Scrum ?
Le Product Owner, les Developers et le Scrum Master sont les rôles définis par Scrum. Aucune hiérarchie n’existe entre les membres de l’équipe.
8 Qui encadre les Developers durant le projet ?
Il n’existe pas de notion d’encadrement ou de hiérarchie au sein de l’équipe Scrum. Tous les acteurs sont responsables de leur activité et fournissent ensemble un effort collaboratif. Chaque Developer peut avoir une relation hiérarchique avec un autre collaborateur de l’organisation...