Quand la propriétaire de produit ne pouvait pas dire non
Ceci est un scénario composite; l'équipe et les personnes sont inventées pour illustrer un schéma que nous voyons souvent. Une équipe Scrum répartie, fraîchement passée au télétravail au printemps 2021, avait tout ce que demande le Guide Scrum : un Product Owner, un Scrum Master, des développeurs, un Product Backlog, les événements. Sur papier, c'était un cas d'école. En pratique, les sprints se terminaient sur du travail à moitié fait et un backlog qui changeait de forme tous les deux jours. Le diagnostic a pris du temps, car le problème n'était visible dans aucun événement précis. Il résidait dans la question de savoir qui décidait vraiment de quoi.
Le symptôme
La Product Owner de l'équipe, appelons-la Dana, était consciencieuse et appréciée. Mais chaque décision importante de priorité la contournait. Un directeur principal écrivait directement à un développeur avec une demande « urgente ». Un partie prenante réordonnait le backlog dans une conversation parallèle. Dana rédigeait les éléments et menait les revues, mais elle ne pouvait dire non à personne, si bien que le backlog reflétait celui qui avait parlé à l'équipe le plus récemment plutôt que ce qui avait le plus de valeur. L'équipe était occupée et n'allait nulle part.
Ce que dit réellement le Guide Scrum
Le Guide Scrum est clair : le Product Owner est responsable de maximiser la valeur du produit, et c'est une seule personne, pas un comité. Surtout, il indique que pour que le Product Owner réussisse, toute l'organisation doit respecter ses décisions. Ces décisions sont visibles dans le Product Backlog et dans l'ordre de ses éléments. L'organisation entière peut tenter de modifier le backlog en persuadant le Product Owner — mais elle passe par lui, et non autour de lui. Dana avait la responsabilité sans l'autorité, la façon la plus courante dont le rôle échoue.
Ce qui a changé
Le correctif était organisationnel, non procédural. Il tenait à quelques gestes concrets.
Un seul backlog, une seule propriétaire. Toute demande — quel que soit le rang du demandeur — était acheminée à Dana et reflétée dans l'unique Product Backlog. Plus de canaux parallèles vers les développeurs.
Des décisions rendues visibles. L'ordre du backlog est devenu le registre public des priorités. Si une partie prenante voulait quelque chose plus tôt, elle plaidait sa cause auprès de Dana et le compromis était explicite : autre chose descendait.
La direction l'a appuyée en public. Le directeur commanditaire a dit au groupe des parties prenantes, en termes clairs, que l'ordre de Dana tenait à moins qu'on ne la convainque autrement. Cette phrase a fait plus qu'aucun changement de processus.
Elle a commencé à dire non, avec des raisons. Un vrai Product Owner refuse bien plus qu'il n'accepte. Dana s'est mise à expliquer pourquoi un élément se trouvait là où il était, ce qui a bâti la confiance permettant aux gens de cesser de la contourner.
En quelques sprints, le backlog s'est stabilisé, les sprints ont terminé ce qu'ils commençaient, et le remue-ménage constant s'est estompé. Rien de la technologie ni des compétences de l'équipe n'avait changé. Ce qui avait changé, c'est qu'une personne avait enfin le droit de décider, et que l'organisation acceptait de vivre avec ses décisions. Un Product Owner incapable de dire non n'est pas un Product Owner; c'est le scribe des priorités de tous les autres.
Si vos équipes de livraison ont les rôles Scrum mais pas l'autorité qui devrait les accompagner, le conseil en réalisation de programmes et de projets de XNM peut vous aider à placer de vrais droits de décision là où la responsabilité repose déjà.