Blog ENI : Toute la veille numérique !
Dernière chance (fin le 29/02) : -25€ dès 75€ sur les livres en ligne, vidéos... code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Scrum Master
  3. Le Scrum Master au service de l’équipe de développement
Extrait - Scrum Master Préparation à la certification Professional Scrum Master (examens PSM I et PSM II)
Extraits du livre
Scrum Master Préparation à la certification Professional Scrum Master (examens PSM I et PSM II)
1 avis
Revenir à la page d'achat du livre

Le Scrum Master au service de l’équipe de développement

Prérequis et objectifs

1. Prérequis

Maîtriser les quatre premiers chapitres.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Coacher l’équipe de développement.

Aider l’équipe à accroître sa valeur et la valeur des produits qu’elle développe.

Faciliter les interactions entre les membres de l’équipe de développement.

Faciliter les interactions avec l’équipe de développement.

Introduction

Le guide Scrum dresse une liste non exhaustive des actions que le Scrum Master peut mener pour servir au mieux l’équipe de développement :

  • Coacher l’équipe de développement en matière d’auto-organisation et de pluridisciplinarité.

  • Aider l’équipe de développement à créer des produits de grande valeur.

  • Supprimer les obstacles à la progression de l’équipe de développement.

  • Faciliter les évènements Scrum, tels que demandés ou nécessaires.

  • Coacher l’équipe de développement dans les environnements organisationnels où Scrum n’est pas encore complètement adopté et compris.

Le Scrum Master doit s’assurer que le Product Owner maîtrise certains aspects de sa fonction. En revanche, dans sa mission auprès de l’équipe, l’accent est mis sur des actions de coaching puis il lui est demandé de maximiser la valeur et de faciliter les évènements. Le guide Scrum dresse une liste de moyens, mais l’objectif n’est pas clairement décrit. Sur ce sujet, Jeff Sutherland avait annoncé clairement l’objectif de Scrum : « Le but de Scrum est d’obtenir « l’effet Toyota », c’est-à-dire de fournir quatre fois plus de logiciels avec une qualité...

Coacher l’équipe de développement pour qu’elle se fixe des objectifs ambitieux

La première des choses à faire pour servir au mieux l’équipe de développement et la coacher en matière d’auto-organisation, c’est de l’aider à définir ses propres objectifs et ils peuvent être ambitieux. Fixer des objectifs ambitieux est une recommandation forte de Rensis Likert, initiateur du style de management participatif préexistant à l’agilité.

Dans un premier temps, le Scrum Master peut encourager l’équipe, ou la guider vers deux indicateurs : la vélocité et la qualité. Ils sont facilement mesurables et progressent toujours, ce qui encourage l’équipe à poursuivre ses efforts. De plus, cela encourage les managers à continuer à soutenir l’équipe et à avoir confiance en sa capacité d’auto-organisation. Enfin, des erreurs opérationnelles seront relativisées par les courbes de croissance de la performance. Il est plus facile d’expliquer à un manager qu’il ne doit pas blâmer l’équipe en cas d’échec d’un Sprint, car on progresse plus rapidement suite à un échec qu’en enchaînant des réussites.

1. La vélocité

C’est un indicateur de mesure empirique basé sur la capacité de l’équipe à produire un certain nombre de points de complexité par Sprint.

Chaque élément du Backlog de produit dispose d’une estimation de complexité que l’on peut traduire sous forme d’un entier numérique. À l’issue de chaque Sprint, il suffit de mesurer la somme des points de complexité des éléments finis et livrés dans l’incrément potentiellement publiable en production pour connaître la vélocité de l’équipe. Même si l’équipe a investi 50 % de ses efforts sur un seul élément durant un Sprint, et que cet élément n’est finalement pas considéré comme fini à l’issue du Sprint, ses points de complexité ne sont pas comptabilisés dans la vélocité de l’équipe....

Remplir efficacement le Backlog de Sprint

La maîtrise de cette activité et des techniques ou méthodes permettant de la conduire efficacement et rapidement est un bon moyen pour l’équipe de progresser vers ses objectifs.

Le Backlog du Sprint est l’ensemble des éléments sélectionnés pour le Sprint plus un plan pour livrer l’incrément du produit et réaliser l’objectif du Sprint.

Guide Scrum 2017

Le Backlog de produit est composé d’éléments qui constituent le produit : des user stories, des fonctions, des flux, des corrections...

Le Backlog de Sprint est composé principalement de tâches qui ne nécessitent pas plus d’une journée pour être accomplies.  

Plusieurs techniques permettent de construire un « bon » Backlog de Sprint :

  • Affiner les éléments du Backlog de produit jusqu’à un état « prêt ».

  • Intégrer des éléments permettant la mise en œuvre de l’amélioration d’au moins un processus identifié lors de la précédente rétrospective de Sprint.

  • Planifier l’activité pour le Sprint à venir.

L’affinage des éléments du Backlog de produit a déjà été abordé au chapitre Le Scrum Master au service du Product Owner, mais du point de vue de l’équipe de développement, certaines pratiques nécessitent un éclairage particulier. Le point le plus important est que le Product Owner ne peut pas efficacement découper les éléments du Backlog de produit sans le concours de l’équipe de développement. Il existe plusieurs raisons à cela, mais la principale est liée à la complexité de chaque sous-ensemble. Il est vivement recommandé d’avoir une estimation cohérente de la complexité pour tous les éléments « prêts », et celle-ci doit idéalement s’échelonner entre 1/10 et 1/6 de la vélocité de l’équipe (cf. INVEST). Cette cohérence permet de créer de la régularité et la régularité simplifie les processus et accélère...

Livrer un produit fini

Pour une fois, nous ne nous appuierons pas sur le guide Scrum en premier lieu pour comprendre les enjeux et donc envisager les moyens à mettre en œuvre, mais sur une publication de Jeff Sutherland (auteur de Scrum) datant de 2012. Ce document, traduit en français, a le mérite d’expliquer en détail les raisons qui ont amené Ken Schwaber et Jeff Sutherland à recommander certaines pratiques de Scrum, dans le but de maximiser les chances de pouvoir livrer un produit fini.

Pour livrer efficacement un produit potentiellement livrable à la fin du Sprint, l’expérience a montré que :

1. Il doit y avoir un Product Owner qui fournit à l’équipe une liste claire de priorités cohérentes et figées pour la durée d’un Sprint. Des décennies d’expérience en ingénierie logicielle ont montré que donner à une équipe de développement plusieurs priorités ou changer les priorités pendant une itération entraîne des décisions retardées et des retouches excessives. La réduction de plus de 50 % de la productivité de ces équipes est la norme. De nombreuses équipes de développement ont doublé leur productivité au cours du premier mois de mise en œuvre de Scrum en résolvant ce problème.

2. Le Product Owner doit avoir un Backlog de produit de fonctionnalités ordonnancé, en s’appuyant entre autres sur une valeur commerciale.

3. Le travail requis pour implémenter les fonctionnalités doit être estimé par l’équipe qui implémentera les fonctionnalités. La recherche a montré que si les experts peuvent estimer avec précision le temps qu’il leur faudrait pour mettre en œuvre une fonctionnalité, il leur est impossible d’estimer les connaissances techniques et de domaine de l’équipe de livraison, les priorités concurrentes d’autres projets qui ont un impact sur la productivité de l’équipe, les facteurs humains dans une équipe tels que la motivation, la résolution des conflits, l’esprit d’équipe qui varient dans le temps, ou la perte ou l’ajout de personnel à une équipe...

Estimer la complexité

Les éléments du Backlog de produit ont pour attributs : une description, un ordre, une estimation et une valeur.

Guide Scrum 2017

Selon le guide Scrum, chaque élément présent dans le Backlog de produit doit présenter au moins ces quatre attributs, dont une « estimation ». Le guide Scrum précise que :

L’équipe de développement est responsable de toutes les estimations. Le Product Owner peut influencer l’équipe de développement en l’aidant dans sa compréhension et le choix des compromis, mais les personnes qui effectueront le travail ont le mot final sur les estimations.

Guide Scrum 2017

Le guide parle d’estimations, décrit clairement qui est responsable de ces estimations - l’équipe de développement - mais sans préciser ce qui est estimé, ni comment. S’agit-il d’une estimation de charge exprimée en jour-homme, de durée exprimée en heures, d’une estimation d’effort ou de complexité ? Rien ne l’indique, les raisons de ces estimations sont implicites, mais ne sont pas non plus décrites de manière explicite. Enfin, les moyens pour y parvenir sont totalement libres.

L’objectif de ces estimations est également induit sans être exprimé de manière explicite. Cela doit permettre de rendre la planification plus précise. Si nous parlons d’effort, plus l’effort nécessaire à la production de chaque élément du Backlog de produit est affiné, et plus la planification de ces éléments est précise. En clair, que les éléments soient évalués en charge, en durée, en effort, en complexité, ou en haricots ne change absolument rien. Alors pourquoi réaliser des estimations en points de complexité ou story points ?

  • Pour éviter l’effet Parkinson que nous détaillerons au chapitre Le Scrum Master au service de l’organisation.

  • Pour casser l’ancien système d’évaluation de charge avec lequel il s’est avéré que tout le monde prenait de la marge « au cas où »…

En tant que Scrum Master, si l’on parcourt la littérature...

Donner de la visibilité

Donner de la visibilité consiste à accroître la transparence. Pour rappel :

Des aspects importants du processus doivent être visibles à tous ceux qui sont responsables du résultat. La transparence exige la définition d’une norme commune pour ces aspects, afin que les observateurs partagent une compréhension commune de ce qui est observé…/…

Scrum repose sur la transparence. Les décisions pour optimiser la valeur et contrôler le risque sont prises en se basant sur l’état perçu des artefacts. Dans la mesure où la transparence est complète, ces décisions ont une base solide. Dans la mesure où les artefacts ne sont pas totalement transparents, ces décisions peuvent être faussées, la valeur moindre et le risque accru.

Guide Scrum 2017

Ce n’est pas au Scrum Master de donner de la visibilité sur le travail de l’équipe de développement, mais à l’équipe de développement elle-même. De la visibilité sur ses choix, son organisation et sur sa progression. Il ne s’agit pas de justifier ou de rendre compte, mais simplement d’informer.

Chaque membre de l’équipe doit informer en premier lieu et en priorité les autres membres de l’équipe de développement, y compris lorsqu’il y a plusieurs équipes engagées sur un même produit. Ensuite, avec le même niveau de transparence, informer le ou les Scrum Master et le Product Owner, et enfin toutes les parties prenantes.

Une autre vertu majeure de la transparence consiste à réduire les boucles de rétroaction pouvant faire dériver les projets, ou impacter la vitesse de déploiement de l’agilité. Les boucles de rétroaction, très connues en climatologie, ont été largement documentées dans Kanban. Il existe des rétroactions positives et négatives. Par exemple, si la température atmosphérique augmente, le taux de vapeur d’eau augmente également. Comme la vapeur est un puissant gaz à effet de serre, l’effet de serre augmente, donc la température continue d’augmenter. C’est une rétroaction positive, puisqu’elle amplifie...

Maximiser la valeur

Nous avons vu que le Product Owner a la responsabilité de maximiser la valeur résultant du travail de l’équipe de développement et que le Scrum Master doit le soutenir, le guider ou l’aider à le faire. Nous avons également vu plusieurs moyens génériques pouvant s’appliquer à une grande variété de produits. L’accroissement de la vélocité de l’équipe de développement est un indicateur de mesure fiable que la plupart des équipes arrivent à multiplier par quatre entre leur premier Sprint et leur rythme de croisière. Ce qui va faire la différence entre un accroissement d’un facteur 1 à 4 et un accroissement d’un facteur 1 à 10, c’est la capacité de l’équipe à inspecter et adapter ses propres processus : l’amélioration continue.

Déléguer à une machine toutes les tâches que l’on peut transformer en algorithmes simples à mettre en œuvre est un excellent moyen d’y parvenir. Un exemple typique consiste à industrialiser les tests récurrents et les processus de contrôle, mais les équipes de développements regorgent d’idées pour améliorer leurs performances dès lors qu’on les laisse faire au lieu de leur imposer...

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 trois principales actions que le Scrum Master entreprend pour servir au mieux l’équipe de développement ?

2 Quels sont les deux indicateurs que l’équipe de développement doit mettre rapidement en place ?

3 Comment estimer la capacité de progression sous forme mathématique ?

4 Comment est mesurée la vélocité réelle de l’équipe de développement ?

5 La vélocité peut-elle être utilisée comme indicateur de contrôle de performance de l’équipe ?

6 Citez au moins un indicateur de mesure de la qualité de l’équipe.

7 En s’appuyant sur l’empirisme, comment peut-on dire qu’un Sprint est un succès ou un échec ?

8 De quoi est composé un Backlog de Sprint ?

9 Quelle est la taille idéale d’un élément « prêt » du Backlog de produit ?

10 Pourquoi les éléments réputés prêts doivent-ils tous être d’une taille ou d’une complexité quasiment identique ?

11 Citez un processus que l’équipe est obligée de suivre pour remplir son Backlog de Sprint.

12 À quoi sert le plan que l’équipe de développement doit produire à chaque Sprint Planning ?

13 Si un membre de l’équipe de développement est persuadé qu’il n’aura pas assez de travail dans le Sprint à venir, que doit faire le Scrum Master ?

14 Quel est le livrable attendu à la fin d’un Sprint ?

15 Qui est responsable de déterminer ce que l’équipe de développement peut produire durant un Sprint ?

16 Qu’est-ce qui est indispensable pour que l’équipe puisse délivrer un incrément de produit fini ?

17 À quoi servent les estimations (de complexité) de l’équipe de développement ?

18 À quoi sert un Burndown chart ?

19 Quels sont les trois types...