Application réelle, passage à l'échelle et hors développement

Passer à l'échelle et hors du développement

1. Plusieurs équipes : ce que ça change vraiment

   Une équipe Scrum ne dépasse pas dix personnes. Un produit important en exige plusieurs. La question n'est alors plus « comment faire vivre Scrum » mais « comment faire tenir plusieurs Scrum sur un même produit ».

   Le problème de la dépendance

   Deux équipes qui travaillent sur le même module sans coordination se gênent : l'une casse ce que l'autre vient de faire. La parade est un contrat d'interface explicite, testé automatiquement des deux côtés. Le coût est réel et doit être annoncé : plus d'équipes signifie plus de contrats à maintenir, pas seulement plus de production. Cet arbitrage est le point sur lequel les découpages d'équipe se justifient ou s'effondrent.

   Le vocabulaire à employer honnêtement

   Un dispositif qui suggère à plusieurs équipes Scrum un cadre commun — même façon de découper, mêmes conventions, même Definition of Done — est un cadre d'alignement. Les noms commerciaux de ces cadres sont nombreux et changent vite. Ce cours les mentionne pour que les étudiants les reconnaissent, mais ne s'attarde sur aucun : ce qui compte est la structure (qui décide, comment les équipes s'alignent, comment la valeur est priorisée à l'échelle), pas le nom du cadre.

   Le piège de la coordination ajoutée

   Le symptôme d'un découpage raté : les réunions de coordination entre équipes consomment plus de temps que le travail. Le test : si une équipe passe plus de temps en réunion avec les autres qu'en développement propre, le découpage est à revoir.

2. Agile hors développement : ce qui change

   Une partie importante des organisations n'a pas de « développement » au sens strict. L'agilité s'y applique quand le travail doit produire de la valeur par cycles courts et apprenants.

   Le test d'applicabilité

   Trois questions : le travail peut-il être découpé en incréments livrables ? Le résultat peut-il être inspected rapidement par quelqu'un qui connaît le domaine ? L'équipe peut-elle adapter son plan à ce qu'elle apprend ? Si oui aux trois, l'agilité s'applique — qu'il s'agisse d'un marketing, d'un evenement, d'un espace client ou d'une démarche qualité.

   Ce qui ne change pas

   • la Definition of Done : un livrable non conforme ne peut pas être présenté comme terminé ;
   • l'inspection avec les personnes concernées, pas seulement avec la hiérarchie ;
   • la distinction entre estimation et engagement.

   Ce qui change, et beaucoup

   1. l'unité de valeur : ce n'est plus une fonctionnalité logicielle mais un livrable métier — une campagne, un parcours client, une formation ;
   2. le délai de détection d'une erreur : en développement, l'erreur se voit quand l'utilisateur l'utilise. Hors développement, une campagne peut être « terminée » et counterproductive avant d'être analysée ;
   3. la Definition of Done est le point critique, parce qu'il n'existe pas de test automatique : c'est l'avis métier qui fait foi, et il doit être formulé à l'avance, sinon on debate après coup sur ce qui aurait dû être fait.

   L'avertissement honnête

   Adapter Scrum à un travail qui ne s'y prête pas — un chantier physique, une intervention de sécurité — produit des rituels vides et une démotivation. Le critère n'est pas « est-ce agile ? » mais « le cycle court produit-il de l'information que l'équipe n'aurait pas eue autrement ? » Sans réponse, le cycle long est plus honnête.