Scrum à l'échelle

Scrum et SAFe

En France, le Product Owner est confronté à une réelle difficulté lorsqu’il cherche à acquérir les compétences nécessaires pour gérer des produits nécessitant d’impliquer plusieurs équipes. Ces difficultés sont accrues s’il souhaite faire valider ses compétences par une certification Scrum.

La principale difficulté réside dans le fait qu’il est rare de pouvoir pratiquer véritablement en entreprise les théories recommandées par Scrum. La plupart des entreprises ont mis en place une méthode ou une organisation personnalisées reposant plus souvent sur SAFe que sur Scrum. Dans ce contexte, il est fréquent de constater d’importantes divergences entre ce qui est recommandé par Scrum et ce qui est réellement pratiqué par des organisations disant avoir adopté Scrum.

Cette complexité est renforcée par le fait que les deux auteurs de Scrum ont créé chacun leur propre approche pour mettre Scrum à l’échelle :

Chaque approche dispose de sa propre sémantique, de ses propres processus et de sa propre vision de la mise à l’échelle adaptée à l’organisation des entreprises.

Enfin, comme si ce n’était pas suffisant, il existe d’autres cadres de processus (frameworks) permettant de faire du Scrum à grande échelle, comme ScrumOfScrum, SSwS, LeSS ou DaD, pour ne citer que les principaux.

Mettre Scrum à l’échelle de plusieurs équipes impacte l’organisation et sera donc un processus contraint par les règles régissant cette dernière.

Organisation des équipes multiples

Lorsque deux équipes ou plus sont affectées au développement d’un même produit, plusieurs organisations sont envisageables, mais il faut toujours s’assurer des points suivants :

Même si c’est généralement conseillé, il n’est pas obligatoire que toutes les équipes affectées au développement d’un même produit aient des durées de Sprint équivalentes. Une équipe peut avoir des Sprints d’une semaine, une autre de deux semaines et une autre encore d’un mois. En revanche, il est indispensable qu’il y ait une synchronisation des évènements au moins une fois par mois.

Il existe actuellement deux modes d’organisation des équipes de développement : une organisation horizontale, habituellement désignée sous le terme anglo-saxon de Component Team, et une organisation verticale, la Feature Team. Ces approches diffèrent sur la manière de décomposer le produit en composants, puis en éléments et enfin en tâches. L’axe horizontal correspond à l’organisation des logiciels en couches ou strates :

Scrum avec deux ou trois équipes

Dans cette organisation, il faut respecter quelques règles.

Il n’y a tout d’abord qu’un responsable du produit : le Product Owner. C’est cette personne et elle seule qui est responsable de l’ordonnancement du Backlog de produit et de la clarté des éléments qui le composent. 

Pour le Product Owner, le passage à deux ou trois équipes est un réel défi car la capacité de production est décuplée, mais il n’y a toujours qu’un Product Owner pour recueillir les besoins, les affiner, les décomposer en éléments digestes et faisant sens avec les objectifs du produit, et enfin ordonnancer tout cela dans le Backlog de produit.

À partir de deux équipes, le Product Owner a donc fortement intérêt à apprendre à déléguer certaines activités comme la gestion ou l’affinage de tout ou partie du Backlog de produit. Attention, il reste responsable de ces activités et doit toujours être présent lors des planifications et revues de Sprint. Il ne peut en aucun cas déléguer cette activité.

La définition de « Fini » doit être commune à tous les membres de toutes les équipes de développement travaillant sur le produit.

Tous les évènements Scrum doivent avoir lieu et conservent les mêmes règles. La durée maximale demeure inchangée, et les mêmes types de participants sont obligatoirement présents.

Il est préférable que chaque équipe de développement ait un Scrum Master dédié, surtout si l’entreprise a adopté l’agilité depuis peu. S’il y a trois équipes, il peut donc y avoir trois Scrum Masters.

La durée maximale d’un Sprint reste d’un mois et celle de la planification de Sprint de huit heures. Généralement, les Scrum Teams cherchent à réduire cette durée afin de maximiser la valeur produite par l’équipe de développement, et c’est une bonne pratique. Lorsqu’il y a plusieurs équipes, ce n’est pas forcément le meilleur moyen de maximiser la valeur. À durée de Sprint égale...

Scrum à plus grande échelle

Dans certains cas, l’organisation peut être amenée à considérer que même avec trois équipes, le produit n’est pas délivré suffisamment rapidement. Pourtant, en ajouter une quatrième (+33 %) n’accroît généralement la vélocité globale que de 15 %. La valeur ajoutée de l’équipe supplémentaire est alors très faible. Le rendement n’est que d’environ 50 %.

De prime abord, il semblerait plus simple de découper un gros produit en sous-produits indépendants et moins complexes. Cela permettrait d’assigner plusieurs Product Owners à plusieurs produits et d’avoir un rendement optimal sur les ressources investies. L’inconvénient, c’est que cette approche complexifie la maintenance globale du SI, qui la plupart du temps est déjà très difficile à cartographier.

Face aux nouveaux et nombreux problèmes que le Product Owner aura à gérer, il ne faut passer à plus grande échelle que s’il n’existe pas d’alternative. Si le Product Owner mesure que la performance baisse tandis qu’une équipe a été ajoutée, alors il faut immédiatement revenir en arrière et chercher une autre solution.

En effet, passer à plus grande échelle implique un plus grand effort de coordination, d’organisation et surtout de transparence de la part du Product Owner. De plus, il doit étendre ses connaissances en développement logiciel afin de mieux réaliser ces activités, notamment en matière de couplage applicatif et de gestion des dépendances.

Organisation du Backlog de produit

En accroissant le nombre d’éléments devant être dans un état « Prêt » avant le prochain Sprint, le Backlog de produit perd en lisibilité. Pour en comprendre le sens, il faudrait parfois lire une centaine de petits éléments destinés à alimenter jusqu’à dix Scrum Teams.

Là encore, le Product Owner doit s’appuyer sur les bénéfices du management visuel. Utiliser une carte à cases (Treemap) permet de faire émerger une information visuelle.

Ici sont présentés trois services composés de plusieurs éléments du Backlog de produit. Les éléments en noir sont prêts à être embarqués dans le prochain Sprint. Notez qu’idéalement, au lieu des identifiants (#1 à #15), il serait préférable d’indiquer la description des éléments.

Cette représentation graphique permet de voir clairement quelles sont les grandes fonctions qui sont bientôt prêtes à être déployées. Nul besoin d’aller voir le détail de chaque élément pour comprendre ce sur quoi l’équipe travaillera prochainement. Cela donne également de la visibilité sur l’état d’avancement.

Lorsqu’il est possible d’afficher...

Déléguer efficacement

Avec plusieurs équipes, le Product Owner doit déléguer une partie de ses activités. La délégation est toujours difficile à entreprendre et souvent mal réalisée, par manque de confiance ou de savoir-faire.

Commencez par déléguer des tâches simples, facilement mesurables et rapides à exécuter, et faites le point avec la personne à qui vous avez délégué le plus tôt possible. Progressivement, vous pourrez accroître la complexité ou le nombre de tâches déléguées.

Ne déléguez pas à une seule personne, mais essayez de répartir équitablement la délégation sur l’ensemble des membres et des équipes. En revanche, ne déléguez jamais la même tâche à deux personnes différentes. Il faut impliquer le plus grand nombre de personnes, mais pas sur la même activité. 

Utilisez la planification de Sprint pour identifier les membres à qui vous pourrez déléguer une partie de vos activités.

Établissez une définition de « Fini » avec le délégataire afin qu’il sache à quel moment il sera sûr d’avoir bien rempli sa mission. Même si cette définition est sommaire...