Le Scrum Master au service de l’équipe Scrum

Introduction

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

Dans sa mission auprès de l’équipe, l’accent est mis sur des actions typiques du management participatif ; accompagner, aider. Le guide Scrum dresse une liste de moyens, mais jusqu’à la publication du guide Scrum 2020, l’objectif n’était pas clairement décrit. 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é douze fois supérieure dans une série de cycles courts appelés "Sprint"...

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

La première des choses à faire pour accroître l’efficacité de l’équipe Scrum, 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.

Causer les changements qui augmentent l’efficacité de l’équipe Scrum

Le Scrum Master est un acteur du changement, mais il est surtout la source, l’origine des changements qui amènent l’organisation à devenir chaque jour un peu plus agile. Il n’est pas nécessaire de tout piloter, tout contrôler pour que le changement s’opère.

Si nous reprenons l’exemple de l’équipe qui a identifié qu’installer une machine à café dans sa salle de travail était un facteur d’accroissement de sa productivité, alors à la lumière de cette phrase, nous pourrions penser qu’il est évident qu’il appartient au Scrum Master de se charger de la conduite opérationnelle de ce mini-projet. Il est demandé au Scrum Master de « causer les changements », d’en être à l’origine. Il ne lui est pas demandé de piloter opérationnellement les changements.

Le Scrum Master doit aider l’équipe Scrum à identifier les obstacles qui l’empêchent d’accroître son efficacité, par exemple lors de la rétrospective. Il doit également supprimer les obstacles à la progression des Developers.

Mais il ne lui appartient pas de conduire personnellement les changements nécessaires. Le guide Scrum invite...

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 d’accroître son efficacité.

L’élément clé du Backlog de Sprint, et ayant la plus grande incidence sur l’efficacité de l’équipe, est l’objectif du Sprint.

Lorsque l’objectif du Sprint est clair, qu’il fait sens pour tous les membres de l’équipe Scrum, alors les moyens mis en œuvre seront clarifiés également. Leur priorité et leur importance apparaîtront également clairement aux yeux de tous. Un manager peut impliquer ses subalternes, ce qui favorisera leur motivation individuelle et accroîtra leur efficacité. Un objectif clair et assumé par l’équipe produira une chose qu’un manager ne peut pas fabriquer : un engagement.

Le Backlog de Sprint est également 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 :

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 des Developers, certaines pratiques nécessitent un éclairage particulier. Le point le plus important est que le Product Owner ne peut pas efficacement...

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.

Estimer la complexité

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 :

Le guide parle d’estimations, décrit clairement qui est responsable de ces estimations - les Developers qui effectueront le travail - 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 ?

Donner de la visibilité

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

Le Scrum Master étant redevable de l’efficacité de l’équipe Scrum, il a personnellement intérêt à s’assurer que l’équipe Scrum est en capacité de mesurer son efficacité et surtout de la progression de celle-ci. De nombreuses organisations sous-estiment l’importance du rôle de Scrum Master. En démontrant un accroissement d’efficacité et en corrélant les actions mises en place par l’équipe avec ces progressions, l’équipe Scrum peut démontrer qu’elle n’a pas besoin de la supervision ou du contrôle de dirigeants, et profite davantage du management d’un coach.

L’équipe a également un intérêt à faire preuve de transparence et à démontrer sa progression, car cela lui permet à terme de bénéficier d’une autonomie et d’une liberté de décision accrue.

Ce n’est pas au Scrum Master de donner de la visibilité sur le travail de l’équipe Scrum, mais à l’équipe elle-même. De la visibilité sur ses choix, son organisation et 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 Scrum, 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...

Maximiser la valeur

Nous avons vu que le Product Owner a la responsabilité de maximiser la valeur résultant du travail de l’équipe Scrum 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 des processus entravant leur...