Le Scrum Master au service de 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 :

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.

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 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 :

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.

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 - 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 ?

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 :

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...