La plupart du temps, les projets dans un contexte aussi complexe sont gérés avec une gestion en cycle en V. Très puissante dans les années 80 pour les livraisons de logiciels, cette façon de travailler est beaucoup plus séquentielle qu'itérative.   

Loin de la méthode du cycle en V, faire partie d'une équipe Scrum en tant que Product Owner pourrait être l'un des plus grands défis que vous pourriez avoir dans une entreprise liée aux nouvelles technologies. Bien sûr, cela implique de travailler sur des projets ou des produits compatibles avec le cadre Scrum. Mais cette compatibilité se répand de plus en plus en dehors du domaine du développement logiciel.  

Qu'il s'agisse d'une petite introduction au Scrum et précisément au métier de Product Owner, ou d'une piqûre de rappel pour tout Product Owner avisé et confirmé passant par-là, voici 6 erreurs à éviter si vous travaillez comme Product Owner dans une équipe Scrum.  

 L’environnement Scrum  

Alors pourquoi utilisons-nous Scrum ? Qu'est-ce que c'est ?   

Pour tous ceux qui connaissent le rugby, Scrum signifie “mêlée” en anglais. Une mêlée signifie aller en bloc le plus loin possible pour gagner de plus en plus de terrain et prendre l'avantage sur l'autre équipe. Il n'y a plus de rôles, d'ailiers, d'avants ou d'arrières, mais une pile de joueurs unis ensemble et marchant dans la même direction.   

Cela peut paraître étonnant de parler de rugby dans un article technique sur le développement de logiciels, mais le cadre Scrum est directement issu de ce terme et de cette approche.  Dans les années 1990, il était très difficile de développer et de maintenir un produit pour le grand marché du développement de logiciels, en particulier en travaillant avec le cycle en V. Les solutions logicielles doivent évoluer pour rester à jour. Elles doivent évoluer pour conserver leurs fonctionnalités et leurs exigences. Le cycle en V est un outil puissant pour la gestion de projet, mais il nécessite également un besoin fortement défini, et est beaucoup plus limité lorsque des évolutions sont nécessaires au milieu du projet. La plupart des projets de cette époque ont été initialisés, planifiés, lancés et, au cours du processus de qualité, annulés. Le temps nécessaire pour finaliser les différentes actions était trop long pour que l'entreprise puisse tirer profit de la valeur créée. Les spécifications évoluaient constamment et le produit final livré n'était souvent pas conforme aux nouvelles normes demandées par le client.  

Conscient de ce problème majeur, un petit groupe de personnes a décidé de créer un cadre unique, dans la philosophie Agile : Scrum. 

“Agile est une approche itérative de la gestion de projets et du développement qui aide les équipes à apporter de la valeur aux clients plus rapidement et plus facilement. Plutôt que de tout miser sur un lancement majeur, une équipe Agile livre son travail par petits incréments exploitables. Les exigences, les plans et les résultats sont évalués en continu. Les équipes disposent donc d'un mécanisme naturel pour répondre rapidement au changement. “  
Source  : Présentation d'Agile | Atlassian 

Chaque rôle a ses propres responsabilités dans l'ensemble du processus des produits livrables sans aucune sorte de hiérarchie entre eux. La plupart des décisions sont prises en équipe, y compris la définition de la durée d'un sprint, le moment où une fonctionnalité du produit doit être considérée comme terminée et diffusable, ou encore l'estimation du temps des tâches. L'architecture globale du projet ressemble à ce qui suit : 

Un esprit de leader est essentiel. La communication est également nécessaire. Ces qualités ne sont pas véritablement obligatoires pour l’environnement Scrum. Cependant, le guide Scrum mentionne les points suivants :      

“Le Product Owner est le seul responsable de la gestion du Backlog Produit (Product Backlog). La gestion du Backlog Produit comprend [...] : L’assurance que le Backlog produit est visible, transparent et clair pour tous, et montre sur quoi l’équipe de développement travaillera prochainement.” 

Source :Source: The Scrum Guide (scrumguides.org)

Numéro 1 : Partager les rôles 

Comme le définit le cadre Scrum, un Product Owner peut également faire partie de l'équipe de développement. Parfois, Product Owner sont partagés entre différents produits ou sous-produits.  Cela peut très bien fonctionner si cela a été convenu avec l'équipe Scrum, mais doit être fait avec précaution et en accord avec les managers.   

Être un Product Owner signifie être au point d'entrée du développement Scrum de nouvelles fonctionnalités importantes. La principale qualité du Product Owner avec les parties prenantes est l'analyse du problème.   

Albert Einstein a dit un jour :   

 “Si j'avais une heure pour résoudre un problème, je passerais 55 minutes à réfléchir au problème et 5 minutes à réfléchir aux solutions.” 

En tant que membre de l'équipe Scrum, l'une des valeurs sur lesquelles vous vous engagez est d'améliorer l'équipe et le produit en même temps et au même niveau.   

L'analyse des problèmes, le tri du backlog, les explications pour l'équipe de développement et la préparation des événements demandent du temps. Certains managers pourraient voir dans le Product Owner un travail à temps partiel, que ce soit le cas ou non. Le temps passé en tant que Product Owner est directement lié au produit lui-même.   

Il est nécessaire de connaître le temps à allouer à vos activités en tant que Product Owner. Il est important de réfléchir de temps en temps au temps que vous avez pour travailler en tant que Product Owner et remplir toutes les fonctions requises par le rôle. Etant une source de stress, le fait de ne pas disposer de suffisamment de temps dans votre rôle influence directement l'ensemble de l'équipe Scrum et entraînera davantage de difficultés pour le projet.