Agile Tour Paris 2011 – Le Product Owner aux commandes des priorités et du scope projet

Le 6 décembre 2011 s’est déroulé l’Agile tour 2011. Mon second compte-rendu (un peu tardif) de cette journée porte sur un retour d’expérience agile à la SGCIB. Cette session était animée par Laurent DUBOST et Henri Darmet, respectivement coach opérationnel à la SGCIB et directeur du développement / leader agile chez Objet Direct. Ils ont partagé ce retour d’expérience en abordant les questions suivantes : – Comment transformer la pratique projet dans les équipes de réalisation et dans les équipes business ? – Comment impliquer le business et l’installer dans ses nouveaux rôles, au centre du projet ? – Comment certaines idées reçues ont été confrontées à la réalité du terrain ?

Product Owner et problématiques

Rappel sur le Product Owner : la théorie

Après une rapide présentation de la SGCIB et du projet, la conférence s’attaque au sujet principal : le Product Owner. Henri nous rappelle les missions de celui-ci :

  • il finance
  • il décide
  • il spécifie
  • il explique
  • il teste
  • il valide

Il met également l’accent sur le fait que le Product Owner vient du métier : ce n’est pas un informaticien !

Les problématiques de l’agilité

4 problématiques classiques que l’on rencontre dans les projets agiles sont évoquées :

  • Le product owner n’est jamais disponible
  • Le client et l’équipe ne se comprennent pas
  • Le client ne s’implique jamais
  • Les utilisateurs changent tout le temps d’avis

Laurent et Henri vont ensuite montrer comment ils ont pu résoudre ces problématiques avec la mise en place de solutions efficaces.

Des solutions efficaces

La chaîne de responsabilité

Le business était en Europe tandis que l’équipe projet était à Paris. Ceci implique une première problématique à résoudre : Comment rendre le Product Owner, issu du business, disponible malgré la séparation physique avec l’équipe projet ?
La solution mise en place est la chaîne de responsabilités. Celle-ci va permettre d’alléger le travail du Product Owner et de déléguer une partie de ses missions à l’équipe.

Voici la composition de cette chaîne :

  • Le product Owner, à l’étranger : Il décide et valide.
  • Le Business Analyst, à Paris : il spécifie et explique. Il soulage le P.O. dans les tâches de création de l’application.
  • L’AMOA (Aide à la maîtrise d’ouvrage), à Paris : il traduit et précise. Il va transformer les spécifications en User Stories.
  • L’équipe Scrum, à Paris : c’est l’équipe qui va réaliser le projet.

Cette solution fait d’une pierre deux coups. En effet, le fait de répartir les missions du P.O. a permis de résoudre deux problématiques : La disponibilité du product owner, et les problèmes de compréhension / langage entre celui-ci et l’équipe développement / réalisation.

Les révélateurs du rôle de Product Owner

Laurent met en avant un point très intéressant : ce que retient le Product Owner de l’apprentissage de son rôle. 4 révélateurs sont exposés : Concret, Progressif, Convergent, Honnête.
Concret, tout d’abord, de part l’information du P.O. par le coach. Celui-ci lui met à disposition une « boite à outils » pour pouvoir mener à bien son projet. Progressif, de part la mise en œuvre d’un projet agile, sa priorisation ainsi que sa planification. Le Product Owner se forme et utilise les outils offerts par le coach agile. Il explique la valeur métier, s’adapte au changement et fait évoluer le produit. Convergent, car toute l’équipe travaille ensemble vers un objectif commun. L’équipe et le Product Owner s’adaptent mutuellement l’un à l’autre, le P.O. applique les méthodes. Honnête enfin, de part le niveau de transparence élevé, la confiance établie entre le P.O et l’équipe qui travaillent main dans la main.

Le product backlog visuel

Henri nous rappelle l’importance du product backlog et de ses avantages, car cela garantit une flexibilité et une adaptabilité accrue face aux changements répétitifs demandés par le client. Le mode de management visuel permet de faire résoudre par le PO les problèmes de changements d’avis par confrontation à la réalité que l’on peut toucher et voir !

Est-ce si facile ?

Henri et Laurent nous mettent en garde toutefois face aux tentations que peuvent avoir les différents éléments de la chaîne de responsabilité. Le Product Owner pourra être tenté d’oublier la gestion du budget, de ne renoncer à rien, de ne pas prioriser. Le Business Analyst, sera tenté de se substituer au P.O, le manipuler, ou faire ce que l’on appelle le “Trop peu, trop tard”, c’est à dire attendre le dernier moment pour donner les informations nécessaires pour le sprint suivant. Enfin l’Aide-MOA, pourrait vouloir “bypasser” le BA, et écrire des spécifications trop légères. Il est donc important de veiller à ce que ces 3 rôles fondamentaux communiquent bien entre eux et que ceux-ci ne dépassent pas leur périmètre décisionnel.

Comment ça se traduit ?

Deux visions sont présentées : la vision dite “scolaire” et la vision “agile”. Ici sont représentées de manière théorique les courbes d’avancement d’un projet, comparées à la courbe d’attente classique de tout client qui se respecte. Le constat de la promesse non tenue du cycle en v est bien souvent rencontré.

Conclusion

La session se termine et les 2 speakers concluent que les résultats sont très positifs, le projet a été un succès et les feedbacks du Product Owner dépassent largement les attentes initiales de l’équipe. J’ai beaucoup aimé cette session, simple et efficace, animée par deux très bons orateurs maitrisant pleinement leur sujet. L’approche très pragmatique de la résolution des problématiques est le gros point fort de cette conférence, en évoquant toutefois et avec honnêteté les risques potentiels de la chaîne de responsabilités. Well done !

Nombre de vue : 59

AJOUTER UN COMMENTAIRE