Comment ne pas passer pour une dinde quand on pratique Agile Scrum ?

C’est l’histoire d’une dinde. Le premier jour, le fermier lui apporte du grain. La dinde est méfiante mais décide finalement de manger le grain. Le 2ème jour, même scénario, la dinde se méfie toujours mais un peu moins. Les jours se suivent, la dinde grossit et l’expérience lui a montré qu’elle pouvait faire confiance au fermier pour assurer son avenir.

Mais la dinde se trompe, car un jour le fermier arrive avec un couteau à la place du grain.

La morale de cette histoire c’est que les approches empiriques (acquisition de la connaissance par l’expérience) ne permettent pas toujours d’adresser des situations complexes.

Dans son livre « Bienvenue en incertitude »*, Philippe Silberzahn part de ce constat pour affirmer que les pratiques agiles sont intéressantes pour s’adapter dans un contexte donné mais qu’elles sont inutiles face aux disruptions fortes. L’agilité cantonnerait les entreprises à une posture réactive sans leur permettre d’être proactive face à leur environnement.

Un bon Product Owner aurait permis à la dinde de s’en sortir

Tout d’abord il est vrai que Scrum positionne l’empirisme comme point central de son cadre : « [rien] ne remplace l’importance de l’empirisme. Dans des environnements complexes, ce qui va se passer est inconnu. Seul ce qui s’est passé peut être utilisé pour la prise de décision prospective » **.

En plus de cette logique fortement présente en Scrum, on retrouve des éléments du cadre grandement focalisés sur l’empirisme : le fonctionnement en sprint, les sprint review, les rétrospectives…

Alors quoi ? Les pratiquants de Scrum seraient condamnés à glouglouter ?

Ce serait oublier le rôle de Product Owner, rôle essentiel du cadre Scrum. On restreint souvent le rôle à collecter les besoins des clients, les hiérarchiser et les inscrire dans le backlog de produit. C’est vrai, mais le rôle va plus loin que ça.

Plus qu’une simple oreille vis-à-vis des clients et un secrétaire du backlog, le Product Owner se doit également d’user de sa matière grise pour proposer des évolutions de son produit. Connaissant à la fois le métier, les enjeux de l’entreprise et son produit, il doit porter une vision. En plus de répondre aux besoins de ses clients, il peut faire évoluer son produit de manière proactive face à son environnement par des innovations et des évolutions qui peuvent transformer les processus métiers.

Le cadre Scrum est un outil que l’on peut utiliser aussi bien en réaction qu’en proaction

Une fois que le Product Owner est positionné au bon niveau, il a toutes les clés en main avec le cadre Scrum pour pouvoir développer ses idées proactivement.

Le backlog, l’auto-organisation de l’équipe de développement, les sprints, le fait que l’on développe des produits potentiellement livrables à la fin de chaque sprint sont autant d’outils qui permettent de prioriser et mettre en œuvre rapidement des idées innovantes. La vision du Product Owner peut donc se retranscrire rapidement et concrètement dans les réalisations de l’équipe Scrum.

Une fois que ces innovations auront été réalisées, l’aspect empirique de Scrum pourra reprendre la main : on pourra ainsi s’assurer que ce qui a été réalisé rencontre bien son marché et délivre de la valeur. Si ce n’est pas le cas, le cadre Scrum permet de s’adapter à moindre coût et donc de changer de direction ou même de revenir en arrière si besoin.

Donnez les clés à votre Product Owner, il vous emmènera loin

Finalement les seules limites sont la capacité du Product Owner à porter une vision et la place que l’on veut bien lui accorder.

Sur la capacité de vision : tout dépend du profil du Product Owner en question. Si vous appliquez Agile Scrum sur un produit stratégique de l’entreprise (application cœur de métier, transformation d’entreprise, …), il est fortement recommandé de placer quelqu’un qui aura toute latitude pour bien conduire son produit : connaissance du métier, de ses clients, de son marché, capacité à prendre du recul et à sortir du cadre… C’est pourquoi on préconise souvent de choisir des Product Owners côté métier plutôt que côté technique.

Concernant la place confiée au Product Owner, repartons déjà du guide Scrum : « Pour que le propriétaire de produit réussisse, toute l’organisation doit respecter ses décisions. »**. Il y a une tendance à croire que le Product Owner est soumis à ses clients alors qu’il est également là pour les challenger et proposer des changements. Ses clients sont très souvent plongés dans leurs contraintes opérationnelles et ne voient donc parfois que des évolutions du produit à court terme qui répondent à leurs besoins immédiats. Le Product Owner a la chance et la responsabilité de sortir la tête du guidon et de proposer des évolutions du produit qui sortent du cadre et qui potentiellement viendront impacter fortement le métier de ses clients.

En résumé, pour des produits stratégiques, donnez les moyens (organisationnel, sponsorship, …) à vos Product Owners pour qu’ils puissent adopter une posture disruptive. Parfois, l’opposition de la vision du product Owner avec ses clients pourra faire des étincelles, mais c’est cette posture qui vous permettra de trouver le bon équilibre entre petites adaptations et changements franchement innovants.

*Bienvenue en incertude ! Principes d’action pour un monde de surprises – Philippe Silberzahn

**Guide Scrum officiel – https://www.scrum.org/resources/scrum-guide

#agile #DSI #Scrum