Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
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. Équipes multiples et Scrum à l’échelle
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

Équipes multiples et Scrum à l’échelle

Prérequis et objectifs

1. Prérequis

Maîtriser les sept premiers chapitres.

Réviser les évènements Scrum.

2. Objectifs

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

Comprendre comment gérer et participer efficacement au développement de produits nécessitant de mobiliser un grand nombre de ressources humaines.

Connaître les pratiques agiles appropriées et les principes de base pour passer d’une à plusieurs équipes de développement travaillant ensemble au sein d’une même équipe Scrum.

Introduction

Scrum recommande de limiter la taille de l’équipe de développement à neuf personnes car au-delà de ce nombre, les interactions entre les individus sont moins fluides, l’équipe s’adapte plus difficilement, les efforts de coordination sont plus importants, en résumé la valeur du travail de l’équipe de développement va stagner ou décroître au lieu de s’accroître à mesure que l’on ajoute des membres.

Cela ne signifie pas pour autant que Scrum soit limité à de petits projets. Il est parfaitement possible de coordonner le travail de deux ou trois équipes, voire beaucoup plus, sur un même produit.

Scrum avec deux ou trois équipes de développement

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

  • Il n’y a qu’un et un seul 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.

  • Quel que soit le nombre d’équipes, le Product Owner peut déléguer de nombreuses activités comme la gestion ou l’affinage de tout ou partie du Backlog de produit, en revanche il reste responsable de ces activités et doit toujours être présent lors des planifications et revues de Sprint. Il ne peut pas 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 reste 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 de temps. 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 reste fixée à huit heures. Généralement, les équipes Scrum 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, il faut plus de temps pour planifier le travail de trois équipes de neuf personnes que pour planifier le travail d’une seule équipe de six personnes.

Afin de maximiser la valeur, il est préférable que les Sprints de toutes les équipes soient alignés chronologiquement. C’est-à-dire qu’ils commencent à la même date pour les deux ou trois équipes et se terminent à la même...

Organisation des équipes

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

  • Il n’existe qu’une seule définition de fini, commune à toutes les équipes.

  • Chaque équipe s’assure que chaque élément de son propre Backlog de Sprint est fini.

  • Chaque équipe s’assure que l’incrément qu’elle délivre correspond à la définition de fini.

  • Toutes les équipes s’assurent conjointement que leurs incréments cumulés s’intègrent et correspondent ensemble à la définition de fini.

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 seconde des Sprints de deux semaines, et la dernière opter pour des Sprints 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 généralement 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. Les axes horizontaux ou verticaux correspondent à l’organisation des logiciels en couches ou strates :...

Performance des équipes multiples

La composition des équipes, sujet qui a déjà été abordé au chapitre Conduire le changement, est donc impactée par le mode d’organisation. Accroître la performance de plusieurs équipes travaillant sur un même produit nécessite de parfaitement maîtriser les bases de la motivation personnelle et de la motivation des équipes.

De prime abord, tout le monde à tendance à penser que l’équipe composée des membres les plus compétents sera forcément l’équipe la plus performante. C’est une erreur. Non seulement ce n’est pas systématique, mais lorsque l’on parle d’équipes, la compétence n’est pas le facteur le plus influent de la performance.

Il y a une dizaine d’années, Emile Servan-Schreiber a démontré, via l’étude de plusieurs dizaines d’équipes différentes, que les équipes disposant du QI le plus élevé ne sont pas celles constituées des individus ayant le QI le plus élevé, mais celles qui ont la communication la plus claire et la plus fluide. Il n’y a pas plus de lien entre la performance individuelle et la performance collective qu’il n’y en a entre l’intelligence individuelle et l’intelligence collective....

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 casser un gros produit en sous-produits indépendants et moins complexes. Cela permettrait d’assigner plusieurs Product Owner à plusieurs produits et d’avoir un rendement optimum 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. En effet, les systèmes d’information qui autrefois reposaient sur quelques gros ordinateurs (mainframe) et un réseau sont constitués aujourd’hui de milliers d’ordinateurs, de plusieurs réseaux et parfois de millions d’applications. Multiplier les applications et les relations entre elles ne simplifie pas la maintenance de ces systèmes déjà complexes.

Pour aider l’organisation à devenir plus agile, le Scrum Master doit comprendre que les responsables informatiques doivent gérer à la fois des applications et un SI de plus en plus complexe.

Si et seulement si l’organisation se trouve dans l’impossibilité d’ajouter une équipe de développement à cause d’un rendement trop faible, et qu’elle ne peut pas décomposer le produit à cause d’un SI déjà trop complexe, alors il faut envisager de passer à l’échelle supérieure. Dans tous les cas, le fait d’impliquer plus de trois équipes en parallèle engendrera des efforts de coordination et de communication entre les équipes qui réduiront forcément le rendement global. Il est donc préférable de s’assurer au préalable qu’aucune autre alternative n’est possible.

Premier point de contrôle : pourquoi...

Conclusion

Mettre Scrum à l’échelle de produits volumineux nécessitant d’impliquer plusieurs dizaines ou centaines de ressources humaines est une activité très complexe, nécessitant de solides connaissances en organisation et gouvernance des entreprises. Ce passage à l’échelle implique d’intégrer de nombreux processus de coordination et de communication inter-équipes qui seront très structurants pour l’organisation.

La décision d’opter pour un framework ou une méthode particulière est généralement prise par le management exécutif ou la direction de l’entreprise.

En tant que Scrum Master, il faut être vigilant sur ces aspects avant d’engager l’organisation vers une solution. Elle peut sembler parfaitement adaptée au niveau local, mais s’avérer moins efficace qu’une autre du point de vue global.

Lorsque vous commencez à mettre Scrum à l’échelle, soyez particulièrement attentif à la transparence. Procédez pas à pas, n’hésitez pas à revenir en arrière lorsqu’il est avéré que la mesure des indicateurs n’est pas à la hauteur des objectifs initialement fixés, ou dévie trop fortement. Il est indispensable d’avoir plusieurs années d’expérience...

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 Une organisation décide d’utiliser Scrum durant 15 mois pour développer un produit impliquant une équipe de douze personnes, ce qui est supérieur aux recommandations de Scrum. Que peut faire le Scrum Master ?

2 Combien de Product Owners et de Scrum Masters sont nécessaires pour animer efficacement trois équipes affectées au développement d’un produit ?

3 Trois équipes de huit personnes sont impliquées sur le développement du même produit et proposent de tenir leur mêlée quotidienne au même endroit et en même temps. Que doit faire le Scrum Master ?

4 Suite à une rétrospective, les trois équipes de développement ont identifié trois moyens radicalement différents pour améliorer un même processus. Tous s’accordent à dire qu’il n’est pas possible de mener les trois solutions en même temps. Quelle est la meilleure approche pour aider les équipes à s’organiser ?

5 Une des trois équipes affectées au développement du même produit se plaint que la définition de fini est trop dure à atteindre et qu’elle ne parvient jamais à réussir ses Sprints. Lors d’une rétrospective, elle propose de réviser la définition de fini de tout le monde le temps qu’elle monte en compétence.

6 Quels sont les deux modes d’organisations les plus utilisés pour répartir le travail sur plusieurs équipes de développements ?

7 Quelles sont les informations qui vous semblent les plus urgentes à faire assimiler à une nouvelle équipe rejoignant deux équipes travaillant déjà sur un produit, pour qu’elle puisse être efficace le plus rapidement possible ?

8 Si vous travaillez pour une compagnie ayant adopté le framework SAFe, quelle organisation des équipes recommanderiez-vous ?

9 Dans quel cas plusieurs Product Owners peuvent-ils collaborer...