• Le piège du plan trop détaillé
• L’idée centrale
• Un bon objectif de sprint aide l’équipe
• SMART ne suffit pas
• De la théorie à la pratique, ou les limites de l’alignement
  • Ultimate, le défi de l’étude suffisamment approfondi sans fermer les portes
  • L’outcome passe avant le Fun
  • Collaborative, l’objectif (presque) atteint, mais pas « Singular » pour un sou
• Ce qu’il faut retenir

Quand nous démarrons, faisons face à une opportunité, ou même lorsque nous avons validé une hypothèse, nous avons rarement toutes les réponses. Nous avançons donc dans le brouillard, en apprenant au fur et à mesure, plutôt qu’en essayant de tout prévoir dès le départ.

C’est dans ces conditions que nous avons besoin d’objectifs clairs : ils donnent une direction claire, sans imposer de solution à l’avance, ce qui aide l’équipe à s’adapter quand la réalité contredit le plan.

C’est Maarten Dalmijn qui a clarifié le concept d’objectif de sprint, notamment dans son ouvrage « Driving Value with Sprint Goals ». Dalmijn est un consultant, formateur et auteur néerlandais spécialisé dans l’agilité, la gestion de produit et le cadre Scrum. Il a particulièrement travaillé sur notre sujet, qu’il considère comme essentiel, pour aligner les équipes et créer de la valeur réelle…

C’est parce que je suis aligné avec lui sur ce sujet, et qu’il m’a beaucoup aidé jusqu’à présent, que je vous partage cet article sur les Objectifs Produit.

§Le piège du plan trop détaillé

Dans un environnement complexe, vouloir tout détailler à l’avance crée souvent plus de confusion que de clarté. Plus on cherche à verrouiller les actions, les résultats et les dépendances, plus on risque de construire un plan fragile, qui casse au premier imprévu.

« Les plans les plus soigneusement élaborés sont déjà déjoués lorsque les événements démentent les prévisions qui servaient de base à ces plans. » Comme disait Mises.

Le problème n’est pas de planifier. Le problème, c’est de croire qu’un bon plan suffit à éliminer l’incertitude. En réalité, les équipes apprennent surtout en essayant, en observant et en ajustant.

§L’idée centrale

Le livre de Maarten Dalmijn insiste sur une idée simple : une équipe Produit doit viser la valeur, pas juste la production de tickets ou de fonctionnalités. Or, Mises nous explique que ce qui apporte de la valeur, c’est ce qui répond aux attentes de l’utilisateur : « Une fin est tout ce que visent des hommes. Un moyen est tout ce que des hommes, en agissant, considèrent comme tel. »

L’objectif nous permet de nous orienter vers ce moyen : il indique

• ce que nous cherchons à obtenir,
• en quoi c’est important,
• et pour qui le faisons-nous.

Autrement dit, nous décrivons le résultat attendu, pas la liste exhaustive des gestes à faire pour y arriver.

§Un bon objectif de sprint aide l’équipe

Quand l’objectif est clair, l’équipe gagne de la liberté. Elle peut choisir la meilleure manière d’atteindre le but, au lieu d’exécuter un plan figé qui ne tient pas compte des imprévus.

C’est aussi ce qui permet de mieux travailler ensemble. Au lieu d’avoir chacun son petit objectif, tout le monde regarde dans la même direction. Dans Scrum, cet alignement est central : l’objectif de sprint sert de fil conducteur pendant le sprint, puis de point d’appui pour la revue et la rétrospective.

§SMART ne suffit pas

Dalmijn ne dit pas seulement de définir des objectifs clairs. Il propose également une version plus vivante des objectifs SMART : FOCUS.

SMART rappelle qu’un objectif doit être clair, mesurable, réaliste, pertinent et limité dans le temps. FOCUS ajoute quelques éléments importants : l’objectif doit être unique, collaboratif, orienté vers le résultat, et compris par toute l’équipe.

• Fun : mémorable, la cerise sur le gâteau grâce à laquelle l’équipe prendra du plaisir à réaliser l’objectif.
• Outcome oriented : la valeur plutôt que le plan.
• Collaborative : impliquer toute l’équipe dans l’élaboration de l’objectif, partager la compréhension et l’attrait contribue au bon résultat.
• Ultimate : pousser la compréhension du besoin (le pourquoi) au maximum donne le maximum de liberté à l’équipe pour atteindre le meilleur résultat possible, y compris si une meilleure solution est trouvée en cours de route.
• Singular : un seul objectif pour toute l’équipe.

En pratique, cela veut dire qu’un bon objectif de sprint n’est pas seulement bien formulé. Il doit aussi donner envie, fédérer et laisser de l’espace à l’intelligence de l’équipe.

§De la théorie à la pratique, ou les limites de l’alignement

Comme dit en introduction, la définition de l’Objectif Produit et de l’objectif de sprint de Maarten Dalmijn m’a beaucoup aidé, pour structurer les opportunités et sprints, dans mon travail. FOCUS m’a fourni une ligne directrice claire vers laquelle tendre.

Cependant, j’ai rencontré des difficultés qui m’ont montré à quel point il y a loin de la coupe aux lèvres.

§Ultimate, le défi de l’étude suffisamment approfondi sans fermer les portes

Dans les faits, au lieu d’apporter plus de liberté à l’équipe, nous réduisions sa marge de manœuvre, car nos investigations visaient plus à lever un maximum de risques et à maîtriser un maximum d’impacts, ce qui réduisait de facto la liberté de choix de l’équipe. L’investigation poussée portait donc moins sur une meilleure compréhension du besoin que sur une meilleure définition de la solution à implémenter.

§L’outcome passe avant le Fun

Le Product Owner se trouve coincé entre le besoin du client, la stratégie de l’entreprise, et les contraintes des développeurs. Dans les faits, nous tentons de répondre aux besoins des clients, tout en naviguant dans la stratégie de l’entreprise, avant de chercher à éviter la frustration des membres de l’équipe. Pour cela, nous avons tenté d’éviter le dépilage des bugs via des objectifs de sprint plus larges, mais quant à savoir si cet objectif sera réellement stimulant, cela dépend vraiment des développeurs qui vont traiter l’opportunité.

§Collaborative, l’objectif (presque) atteint, mais pas « Singular » pour un sou

Définir des objectifs qui vont fédérer toute l’équipe autour d’un même sujet n’est pas toujours possible. Certaines tâches ne peuvent pas être parallélisées, et toute l’équipe n’aura pas forcément l’expertise pour travailler sur le même sujet. D’autre part, j’ai travaillé dans des équipes souvent trop nombreuses, et les sujets à traiter étaient trop nombreux pour que nous puissions avoir un seul objectif à la fois.

Dans les faits, nous avons adopté de façon implicite une organisation se rapprochant de LeSS ou FAST : nous proposions plusieurs Epics (épopées, ou ensemble de récits utilisateurs visant un même objectif) à l’équipe, qui se répartissait alors sur ces objectifs en début de sprint. Le parallèle avec LeSS en particulier va un peu plus loin, vu que nous avions des points pour une Epic donnée, spécifiquement avec les développeurs travaillant sur cette Epic, et nous suivions Scrum et Kanban dans notre organisation.

L’alignement était effectivement très organisationnel, mais très peu technique : j’ai vu plusieurs fois des situations où plusieurs développeurs se retrouvaient impactés par des choix d’autres développeurs, dans le même sprint ou à plusieurs sprints d’écart.

Néanmoins, nous avons observé de nets progrès, dans la motivation de l’équipe: le « Fun » émergeait du fait même d’avoir des objectifs clairs ; le focus et la création de valeur (l’outcome) se sont confirmés par l’augmentation de la qualité du produit (validée par les retours des clients qui s’amélioraient) ; et la collaboration au sein des équipes avec lesquelles j’ai travaillé a toujours été en s’améliorant.

§Ce qu’il faut retenir

Si une équipe passe son temps à tout détailler, elle risque de perdre en agilité. Si elle se contente d’un vague « on verra », elle perd en alignement. L’objectif de sprint sert à trouver le juste milieu : un cap assez clair pour guider, assez souple pour apprendre, tout en gardant le focus sur le besoin de l’utilisateur.

Et c’est probablement là la leçon la plus utile du livre : en Produit, on ne gagne pas en contrôlant tout. On gagne en apprenant vite, en restant aligné, et en concentrant l’équipe sur la valeur réelle pour l’utilisateur.