L'organisation

Passer à l'échelle

Quand un produit dépasse ce qu'une seule équipe peut livrer, il faut plusieurs équipes, et de nouvelles difficultés apparaissent. A Scrum Book propose une suite de patterns pour grandir pas à pas : scinder une équipe devenue trop grande, laisser les équipes se coordonner, accorder les rythmes et donner à la direction un lieu où peser sur les priorités. Le livre commence par un avertissement : la plupart des organisations qui veulent « passer à l'échelle » gagneraient à améliorer d'abord l'équipe qu'elles ont.

Une équipe de onze personnes

Une jeune entreprise édite un logiciel de gestion pour les cantines scolaires. Elle a commencé avec cinq développeurs. La demande croît, et l'entreprise recrute une personne après l'autre. Dix-huit mois plus tard, l'équipe compte onze développeurs.

La réunion quotidienne dure maintenant trente-cinq minutes. Deux groupes se sont formés sans que personne l'ait décidé, l'un autour des menus et des commandes, l'autre autour de la facturation aux familles. Un matin, Léa s'étonne : « Qui a changé le calcul des allergènes ? Mes tests ne passent plus. » Paul lève la main : « C'est moi, mardi. Je ne savais pas que tu t'en servais. » L'organigramme montre une équipe, et le quotidien en montre deux.

A Scaling Sequence : faut-il vraiment grandir ?

A Scrum Book (2019) décrit Scrum sous forme de patterns : chacun expose un problème récurrent, les forces en jeu et une solution tirée de l'expérience. Le texte intitulé A Scaling Sequence (« une séquence pour passer à l'échelle ») introduit les patterns qui suivent et fixe leur ordre, sans être lui-même un pattern.

Son premier message est une mise en garde. On veut en général grandir pour produire davantage, alors que le meilleur moyen d'y parvenir est de lever les obstacles et d'améliorer la façon de travailler. Les auteurs n'admettent qu'un cas légitime : le produit a grandi de lui-même au point que la demande dépasse la capacité d'une équipe déjà très performante, c'est-à-dire stable, régulière et dont les efforts d'amélioration rapportent de moins en moins. Grandir ne sert pas à rattraper un retard : le livre rappelle la loi de Brooks (The Mythical Man-Month, 1975), selon laquelle ajouter des personnes à un projet en retard le retarde encore.

Avant d'ajouter une équipe, il recommande donc d'aider le Product Owner (la personne qui ordonne la liste de ce qu'il faut construire, le Product Backlog) à concentrer l'équipe sur l'essentiel, d'aider le Scrum Master (qui accompagne l'équipe dans sa pratique de Scrum) à lever les obstacles et de renforcer la capacité des développeurs à livrer un travail de qualité. Sans cela, l'organisation multiplie ses dysfonctionnements en même temps que ses équipes.

Le second message est que l'on fait grandir Scrum avec Scrum. Toutes les équipes travaillent à partir d'un seul Product Backlog, sous la responsabilité d'un seul Product Owner, avec la même définition d'un travail terminé, et leur autonomie reste une condition du succès.

Mitosis : scinder une équipe devenue trop grande

Le pattern Mitosis (« mitose », la division d'une cellule en deux) porte une étoile : les auteurs y voient le cœur d'une bonne solution, sans exclure qu'il en existe d'autres.

Le problème. Une équipe doit grandir peu à peu, mais elle finit par devenir trop grande pour rester efficace.

Les forces. Une seule équipe pour un produit est l'organisation la plus simple, car chacun sait comment son travail s'insère dans l'ensemble. Ajouter des personnes une à une étale le coût de leur intégration, mais aboutit à une foule. Recruter d'un coup une seconde équipe coûte cher, car il faut des mois pour que des nouveaux venus connaissent le produit. Le livre distingue enfin l'équipe officielle, celle de l'organigramme, et l'équipe réelle, celle des échanges quotidiens. Quand deux équipes réelles existent, prétendre qu'elles n'en font qu'une n'a pas de sens.

La solution. Quand l'équipe a grandi jusqu'à devenir inefficace, vers sept personnes, elle se scinde en deux petites équipes qui emportent chacune l'expérience et la culture de l'équipe d'origine. Chaque nouvelle équipe réunit tous les métiers nécessaires et peut travailler sur toutes les parties du produit. Chacune a son Scrum Master. Les deux gardent le même Product Backlog, le même Product Owner et le même lieu de travail.

Selon une règle empirique des auteurs, deux équipes formées des mêmes personnes perdent environ 40 % de vélocité (la quantité de travail terminée par Sprint, la période de travail de durée fixe de Scrum) à cause de la coordination. Dans notre exemple, les onze développeurs forment une équipe de cinq et une de six. Ils évitent de suivre la fracture existante entre menus et facturation, pour que chaque équipe reste capable d'intervenir partout.

Le Guide Scrum de 2020 prévoit le même mouvement : une Scrum Team (l'équipe complète) devenue trop grande devrait se réorganiser en plusieurs Scrum Teams centrées sur le même produit, qui partagent le même Product Goal (l'objectif de produit), le même Product Backlog et le même Product Owner. Deux écarts sont à noter. Le Guide situe la taille habituelle d'une Scrum Team à dix personnes au plus, et là où le livre décrit une Scrum Team comprenant plusieurs « Development Teams », il parle de plusieurs Scrum Teams.

Coordonner plusieurs équipes

Scrum of Scrums : les équipes se coordonnent elles-mêmes

Le problème du pattern Scrum of Scrums (« Scrum de Scrums », une étoile) est que des équipes qui travaillent chacune de leur côté se concentrent sur leurs propres soucis et perdent de vue les buts communs.

Les forces. Le livre écarte quatre réponses tentantes. Revenir à un contrôle hiérarchique ajoute des délais. Découper le produit en morceaux indépendants fait apparaître des dépendances imprévues, car optimiser chaque partie n'optimise pas le tout. Fondre tout le monde dans une grande équipe fait exploser le coût de la communication. Confier la coordination à un manager muni d'un plan d'ensemble retire aux équipes leur autonomie et leur engagement. À l'inverse, des équipes autonomes sans alignement partent chacune dans sa direction.

La solution. Les équipes de développeurs reçoivent le droit et la responsabilité de collaborer pour atteindre les buts communs fixés par le Product Owner, et elles choisissent elles-mêmes comment se coordonner. Les moyens habituels sont des Sprints simultanés, une définition commune du travail terminé, des réunions de début et de fin de Sprint tenues ensemble et une rencontre régulière entre équipes, éventuellement quotidienne, après les Daily Scrums (les réunions quotidiennes de chaque équipe). Le livre insiste sur un point : les équipes n'attendent pas cette rencontre pour se parler, et la vraie mesure du Scrum of Scrums est la collaboration spontanée entre elles.

D'après le livre, la pratique a été mise en place pour la première fois chez IDX Systems en 1996, où Jeff Sutherland dirigeait l'ingénierie, et décrite dans une publication en 2001. Le Guide Scrum ne la mentionne pas.

Organizational Sprint Pulse : battre au même rythme

Le problème du pattern Organizational Sprint Pulse (« pouls de Sprint de l'organisation », sans étoile, soit une bonne solution parmi d'autres selon les auteurs) est que l'équipe et le reste de l'organisation ne marchent pas du même pas, ce qui produit des attentes ou des interruptions.

Les forces. Les équipes dépendent des finances, du commerce, du support et des fournisseurs, qui suivent souvent un rythme mensuel. Si les Sprints commencent et finissent à des dates qui ne s'accordent pas, ou si leurs durées diffèrent d'une équipe à l'autre, le travail attend. Imposer une durée commune retire toutefois un peu de liberté à chaque équipe.

La solution. L'organisation adopte un rythme mensuel, et les équipes choisissent des Sprints d'une, deux ou quatre semaines qui s'y emboîtent. Selon le livre, ce rythme commun réduit l'irrégularité et la surcharge, que le Lean nomme mura et muri, et il permet aux équipes de tenir ensemble leurs réunions de Sprint.

Value Areas : organiser les équipes par domaines de valeur

Le pattern Value Areas (« domaines de valeur », sans étoile) concerne un produit qui sert des publics de plus en plus variés.

Le problème. Quand un même produit doit servir plusieurs segments de clientèle, une équipe ne peut pas acquérir assez vite une compréhension profonde de chacun.

Les forces. Agrandir les équipes les ralentit. Découper le produit en plusieurs produits, chacun avec son Product Owner et sa liste, conduit chaque partie à s'optimiser aux dépens de l'ensemble et empêche de traiter d'abord ce qui a le plus de valeur. Organiser les équipes par composants techniques allonge les délais, parce qu'une fonction utile au client traverse presque toujours plusieurs composants.

La solution. Le produit s'organise en Value Areas : des parties du produit qui répondent aux besoins d'un segment de clientèle, mais qui n'ont pas d'existence en dehors du produit. Chaque groupe d'équipes n'a besoin de bien connaître que certains segments, et chaque équipe livre toujours des éléments utiles au client. Il n'y a toujours qu'un Product Backlog et qu'un Product Owner, aidé par des personnes spécialisées chacune dans un domaine. Le livre donne l'exemple d'un fournisseur d'énergie organisé en trois domaines, l'adhésion des nouveaux clients, la facturation et l'assistance, chacun confié à quatre à six équipes.

Les auteurs présentent cette organisation comme provisoire : les équipes devraient à terme redevenir capables de travailler dans tous les domaines. Si le produit s'éloigne trop de sa Vision d'origine, la séquence se termine par le pattern Value Stream Fork, qui le scinde en plusieurs produits et que présente l'article sur le plan de livraison.

MetaScrum : un lieu pour la direction

Le problème du pattern MetaScrum (« méta-Scrum », sans étoile) est que la direction héritée de l'ancienne organisation continue de donner des consignes sur le contenu des produits, ce qui brouille la question de savoir qui décide. Des managers modifient la liste ou interviennent auprès des développeurs en plein Sprint.

Les forces. Les préoccupations de la direction sont légitimes, qu'il s'agisse de la concurrence, des contrats ou des budgets, et elles doivent être visibles. Les mêler aux demandes du marché dans les mêmes réunions crée pourtant de la confusion, et les produits ont besoin de s'accorder entre eux.

La solution. L'entreprise crée un forum régulier, le MetaScrum, qui réunit les Product Owners et la direction générale, dirigeant compris, pour aligner toute l'entreprise derrière les Product Backlogs. Un Product Owner du MetaScrum l'anime. Les équipes y demandent le soutien ou les moyens qui leur manquent, et la direction y défend les changements qu'elle souhaite. À la fin de la réunion, les Product Backlogs sont fermés aux interventions de la direction jusqu'au MetaScrum suivant, et les équipes travaillent entre-temps sans ingérence.

Le livre précise que le MetaScrum ne sert pas à la direction pour piloter les produits, puisque chaque Product Owner garde l'autorité sur le sien. Il reconnaît qu'un MetaScrum très médiatisé a servi à imposer la volonté de la direction. La première description publiée, due à Jeff Sutherland en 2005, concerne l'entreprise PatientKeeper, où le dispositif fonctionnait depuis 2003. Le Guide Scrum ne le mentionne pas.

Limites et pièges

Le premier piège est celui que le livre dénonce lui-même : ajouter des équipes pour sauver un produit en retard ou une équipe qui fonctionne mal. La coordination s'ajoute alors aux difficultés existantes.

Chaque pattern a sa dérive. Le Scrum of Scrums devient une réunion de compte rendu devant un coordinateur. La scission se fait par spécialités et crée des équipes qui dépendent les unes des autres pour la moindre fonction. Les Value Areas provisoires s'installent et deviennent des cloisons. Le MetaScrum tourne au comité de pilotage.

Les chiffres avancés, comme la perte de 40 % de vélocité, sont des règles empiriques données sans mesure publiée. Les exemples viennent surtout d'entreprises où les auteurs ont travaillé, et ils ont valeur de témoignage. D'autres cadres répondent autrement aux mêmes problèmes, notamment LeSS, Nexus, Scrum@Scale et SAFe, que présente l'article L'agilité à l'échelle du corpus Agilité. L'article Critiques et état des preuves revient sur ce que l'on sait de leur efficacité.