Anatomie de l'Objectif de Sprint : Entre Vision et Action
Dans mon récent article « Piloter la valeur par les Objectifs Produit », je rappelais que l’Objectif de Sprint est la pierre angulaire de Scrum. Sans lui, le Daily Scrum perd sa boussole, la revue de sprint n’a pas de cible claire,… et l’équipe s’épuise dans une « feature factory » sans relief.
Pourtant, la théorie se heurte souvent à diverses frictions, dont j’ai été témoin au fil des années : la compréhension du sens même de l’objectif, et l’organisation de l’équipe autour de ces objectifs.
La définition de l’objectif
La méprise entre outcome et output
Le problème prend racine dans une méprise fondamentale sur ce qu’est un objectif. Trop souvent, nous voyons fleurir des objectifs de type « développer l’outil de monitoring ». Ce ne sont pas des objectifs, ce sont des listes de courses : ils se focalisent sur la quantité de fonctionnalités produites (l’output), et non sur leur qualité (l’outcome).
Dans cette configuration, nous ne construisons pas un produit, nous exécutons un plan. J’ai déjà vu des Product Owners, surtout à mes débuts, fournissant des spécifications fonctionnelles… et techniques aux développeurs, avec des jalons à respecter à la lettre… S’ils se comportent comme un chef de projet à l’ancienne, ils auront tendance à définir l’objectif en fonction des tâches qu’ils ont déjà prévues, inversant ainsi la logique même de l’agilité.
Le Sprint comme un Pari stratégique
Pour comprendre l’agilité, il faut percevoir chaque itération comme un pari : nous parions que la fonctionnalité développée va réellement créer de la valeur, être utile (répondre au besoin du consommateur) et être utilisable. L’objectif de sprint est le pont qui relie notre stratégie produit quotidienne aux ambitions à long terme de l’entreprise.
Comme vu dans mon article sur le Product Owner Technique, la synergie entre le Product Owner (PO) et l’équipe technique est alors centrale :
- Le PO apporte sa connaissance du marché et des besoins utilisateurs pour s’assurer que l’objectif améliore la valeur du produit.
- Les Développeurs apportent leur expertise technique pour rendre ce pari réalisable.
Redonner du sens au quotidien
Lorsqu’un objectif est clair, il transforme radicalement la dynamique de l’équipe. Prenons le cas du Daily Scrum : sans objectif, il devient une séance de reporting fastidieuse. Avec un objectif, il retrouve son sens profond : nous ne nous demandons plus « qu’as-tu fait hier ? », mais « où en sommes-nous par rapport à notre pari ? ».
L’objectif commun forge une véritable équipe. Il permet de sortir de la « feature factory » pour entrer dans une démarche empirique où nous cherchons à atteindre l’impact désiré avec le moins de fonctionnalités possible, de la façon la plus efficace. C’est précisément ce découpage par l’objectif qui permet de se concentrer sur la résolution du problème plutôt que sur l’accumulation de code.
Scrum et les grands nombres
L’anatomie d’un éclatement nécessaire
Au fil de mes expériences personnelles, je me suis rendu compte que nous oublions un élément clé : pour être efficace sur un sujet complexe, le focus optimal se situe souvent autour d’un noyau réduit. Même si le Scrum Guide recommande de rester sous la barre des dix personnes, la communication se fragmente vite au-delà de 6 personnes.
Or, j’ai travaillé au sein d’équipes pouvant compter une douzaine de personnes… Dans ces conditions, tenter d’imposer un seul objectif très granulaire revient à forcer une armée à utiliser un seul pinceau pour peindre une fresque : la majorité des membres se retrouvent spectateurs ou s’éparpillent sur des tâches annexes pour « s’occuper ».
Cette situation crée une dette de motivation, car les membres de l’équipe n’arrivent plus à suivre les sujets les uns des autres, alors que tous travaillent sur le même produit… Pour y remédier, j’ai remarqué que nous glissons naturellement vers le modèle prôné par LeSS (Large-Scale Scrum).
Il s’agit d’un cadre d’organisation dont la philosophie est le minimalisme. Il consiste à appliquer Scrum à grande échelle tout en gardant une structure aussi simple que possible, autour de mini-équipes auto-organisées. Celles-ci travaillent sur un seul produit et sont synchronisées par le rythme du sprint. Cela permet de retrouver de l’impact sans sombrer dans le chaos.
De la tâche individuelle à la cohérence système
La documentation de LeSS nous encourage à conserver l’alignement de l’équipe malgré les multiples objectifs. Le défi est donc de ne pas multiplier les backlogs, mais de garder un Product Backlog unique, et un seul Product Owner, pour préserver la vision d’ensemble. Dans la pratique, cela transforme la nature même de l’Objectif de Sprint, que nous avions renommé « sujets de sprint » : au pluriel, vu que nous en avions plusieurs (là où Scrum insiste sur un objectif unique).
Ceux-ci constituent alors une ombrelle sous laquelle se regroupent les contributions des mini-équipes organisées au sein de l’ensemble.
La vision (le pourquoi) reste unique pour le sprint, et les différents sujets s’y raccordent. L’action (le comment), quant à elle, est portée par des cellules autonomes composées de développeurs et ingénieurs Q.A. gérant leurs propres sujets techniques, tout en restant alignées sur le pari commun.
En amont du sprint, Product Owner et responsable du design (ou « UX Designer » lorsque nous travaillons sur une interface graphique) s’accordent avec le binôme développeur/Q.A. sur le sujet qu’ils traiteront durant le sprint : l’implication de l’un et de l’autre avant même le début du sprint est primordiale. Après démarrage du sprint, la collaboration entre les différents métiers continue, notamment lorsque le développeur a besoin de confirmer des points de détail avec le Product Owner ou l’UX Designer. Et après le sprint, tous poursuivent la collaboration sur la validation de la solution.
Synchroniser sans flicage : Le rôle du leader agile
Dans ce contexte, le Product Owner et le Scrum Master ne sont plus des répartiteurs de tâches, mais des jardiniers de l’écosystème. Leur rôle est de s’assurer que :
- La transparence est maintenue : Les mini-équipes ne deviennent pas des silos opaques.
- L’inspection est collective : La revue de sprint doit rester un moment de vérité sur l’incrément global, et non une succession de démos isolées, tandis que la rétrospective doit permettre de mettre en évidence les éventuelles pertes de visibilité ou confusions au sein de l’équipe.
- L’alignement par la valeur : Nous mesurons le succès à l’impact utilisateur produit, et non au nombre de tickets fermés par chaque sous-groupe.
Ainsi, l’équipe reste centrée sur la création de valeur et ne se disperse pas dans la création de fonctionnalités ayant perdu leur sens.
Conclusion
Sans objectif partagé, la confiance s’effrite et le projet dérive. Mais si l’équipe grandit trop, nous pouvons travailler avec plusieurs sujets et plusieurs mini-équipes auto-organisées, comme le recommande LeSS… Mais alors, le Scrum Master et le Product Owner doivent redoubler de vigilance pour maintenir un cadre global unifié autour d’une même vision, et d’un même backlog pour tout le monde.
Tout part du besoin : sans vision partagée, le produit s’égare. L’agilité n’est pas une affaire de taille de groupe, mais de fluidité de communication. Savoir adapter son organisation lorsque le cadre sature est le pas décisif pour cesser de « faire de l’agile » et enfin « être agile ».
Write a comment