Équipes multiples et Scrum à l’échelle

Scrum avec deux ou trois équipes de développement

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

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 :

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