En théorie, un seul Product Manager est responsable du backlog d’une équipe Agile. Mais dans la réalité, en fonction des organisations des sociétés, il peut arriver que plusieurs Product Managers se partagent un même backlog et donc une même équipe. Cela peut être le cas dans une organisation de type “centre de services”, où plusieurs produits se partagent une même équipe de développement, avec un Product Manager par produit. On retrouve aussi ce dilemme lorsque le produit a une complexité métier trop importante pour qu’un seul Product Manager puisse être responsable de l’ensemble du produit, ou lorsqu’un seul Product Manager n’a pas la capacité à alimenter l’ensemble de l’équipe. Dans ces situations, comment s’assurer que les développeurs n’auront pas à faire eux-même le travail de priorisation ? Comme garantir que les User Stories apportant le plus de valeur seront bien traitées en priorité ?
Le Kanban du Ready
Idéalement, il faudrait être en mesure scinder votre équipe afin de revenir au grand principe “1 Backlog = 1 Product Manager”. Mais dans bien des cas, cela ne vous sera pas possible : équipe trop petite, dépendance sur un profil technique ou simplement culture d’entreprise sont autant de raisons qui font que vous allez devoir composer avec cette situation.
Si vous êtes plusieurs Product Managers sur un même backlog, il y a fort à parier que vous percevez l’équipe de développement comme un goulet d’étranglement. Vous avez probablement chacun vos propres objectifs, contraintes et deadlines. Afin d’éviter de découvrir les sujets de vos collègues en sprint planning et que cette cérémonie ne vire à la foire d’empoigne, vous allez devoir vous donner un maximum de visibilité en amont, pendant toute la phase de maturation des User Stories. Et quoi de mieux qu’un Kanban pour piloter un flux à plusieurs ?
L’objectif de votre Kanban doit être d’aboutir à un colonne “Ready for dev”, où toutes les User Stories dans cette colonne sont priorisées (quel que soit le Product Manager qui l’a rédigée) et répondent à la “Definition of Ready” de votre équipe.
Pour construire les autres colonnes de votre Kanban, inspirez-vous de votre processus de rédaction des User Stories. Vous pouvez notamment faire figurer la rédaction (en Gherkin) de vos US, la rédaction des critères d’acceptance, la création des wireframes et des maquettes… Tout dépend de votre produit.
Chaque ligne de nage de votre Kanban représente l’activité d’un Product Manager. Lors de chaque Daily Scrum, en tant que Product Manager, vous disposerez ainsi d’un support physique vous permettant de présenter l’avancement de vos activités en-dehors du sprint en cours. Ainsi, non seulement vous pourrez donner à l’ensemble de l’équipe une vision exhaustive de votre travail, mais cela devrait aussi favoriser les discussions d’alignement entre Product Managers.
Ce Kanban du ready présente également un autre avantage : celui de pouvoir réguler le flux de rédaction des User Stories, afin de vous assurer que l’équipe est suffisamment alimentée, sans pour autant créer plus d’User Stories qu’elle n’est capable d’en traiter. Vous allez ainsi fonctionner en “flux tiré”, ce qui signifie que c’est la capacité de développement de l’équipe qui permettra de déterminer le nombre d’User Stories à rédiger, d’ateliers de conception et de grooming à effectuer, etc… Une fois le “débit” de votre équipe déterminé, vous pourrez mettre des limites hautes et basses sur chacune de vos colonnes. Et si jamais un Product Manager se retrouve limité dans son travail de conception suite à ces restrictions, il pourra toujours prêter main forte pour les tests par exemple. C’est ce qu’on appelle le “swarming”.
Grâce à ce Kanban, vous devriez arriver à un consensus entre Product Managers à l’issu du processus de maturation des User Stories. Si toutefois ce consensus n’est pas établi, il vous faudra arbitrer entre vous l’importance des User Stories, en utilisant des techniques qui ne se basent pas nécessairement sur valeur (notion assez propre à un produit donné) telle que le coût du délais.
Si vous ne deviez retenir qu’une chose, c’est que si vous vous retrouvez dans cette situation, il vous faudra à tout prix communiquer. Même si la mise en place d’un Kanban pour visualiser le flux de maturation des User Stories pourra vous aider, n’oubliez pas que “Les individus et leurs interactions sont supérieurs aux processus et aux outils”. Il est primordial que tout le monde partage bien la même vision et soit animé d’un fort esprit d’équipe. N’hésitez pas également à mettre en place une communauté de pratique au sein des Product Managers afin de renforcer votre alignement et partager vos expériences.
Et vous, avez-vous été confronté à cette situation ? Quelles actions avez-vous mis en place ?
Pour aller plus loin : télécharger notre livre Les Clés du Product Management
