Aujourd’hui, un article un peu différent sur ce blog, car il n’est pas écrit pas un(e) PO ou un(e) PM de Thiga. Je n’ai jamais exercé ce métier et suis même plutôt de l’autre côté de la force, celui des fonctions support. J’ai depuis peu rejoint le cabinet au poste de Growth Officer, qui englobe des responsabilités Training, RH et plus particulièrement de recrutement. Mon rôle va notamment consister à donner envie à des Product Owners de nous rejoindre, à présenter les activités de Thiga et à savoir parler du Product Management sans pour le moment l’avoir jamais expérimenté. En effet, si avant Thiga j’ai été pendant 2 ans « recruteuse » dans un cabinet de conseil en IT, les consultants avec qui j’échangeais travaillaient rarement en mode Agile, et avec une vision centrée sur le projet en cours.
L’objectif
de l’article est de partager mon avis de novice sur l’agilité suite à mon immersion d’une semaine au sein d’une équipe de développement et en accompagnement d’une Product Owner dans ses activités quotidiennes. Le but était clair : découvrir le fonctionnement d’une équipe Agile et les méthodes et outils qu’elle utilise.
L’équipe que l’on m’a proposé de suivre travaille depuis les bureaux de Xebia Studio sur les produits digitaux d’un acteur du pari en ligne. Xebia Studio est une entité de Xebia qui réalise les produits web/mobiles de ses clients en constituant des petites équipes agiles de développeurs expérimentés. Thiga faisant partie de l’Alliance Xebia, il a semblé très naturel que je descende les quelques étages qui séparent nos locaux du Studio pour ma semaine d’immersion.
Chaque équipe est constituée de développeurs de Xebia Studio et d’un Product Owner (PO) de Xebia qui travaille en binôme avec le Product Owner du client. Pour qu’il n’y ait pas de confusion entre les deux, Xebia a décidé de qualifier son PO de “proxy”-PO... L’équipe que j’ai intégré est composée d’une proxy-PO, Meriem, et de 8 développeurs. Chaque développeur travaille sur un périmètre donné : iPad, iWatch, iPhone, Android sur tablette ou mobile. Et chaque développeur ayant besoin de tester ses développements, l’équipe dispose de tout le matériel nécessaire, i.e. un tiroir plein d’ iWatch, iPad, tablette samsung et autre matériel.
Ce fut clairement la première et agréable surprise pour moi de voir que tous les outils nécessaires au bon déroulement du projet étaient à disposition des développeurs au quotidien. En effet, j’avais souvent entendu auparavant des consultants se plaindre de n’avoir pas les bons outils et il semble que cela ne soit pas le cas chez Xebia ! Le fait que les développeurs sont également les testeurs des solutions qu’ils développement explique aussi le bon équipement dont ils bénéficient.
Deuxième agréable découverte : l’efficacité des « réunions ». Si elles ne s’appellent pas ainsi, mais plutôt Standup daily, Rétrospective, Story Reviews, Copil ou encore Sprint planning, les cérémonies agiles m’ont dès le lundi matin surprises par l’investissement de chaque membre de l’équipe, qu’il soit de Xebia ou du client. En effet, chacun y connaît l’ordre du jour, la durée de réunion prévue est respectée (voire raccourcie si tous les points ont été évoqués et réglés), de réelles décisions sont prises lorsque le sujet s’y prête, et on ne remet pas tout aux prochaines calendes grecques. Pour moi qui avait connu les réunions pour préparer les réunions auxquelles on avait été invité sans bien comprendre pourquoi, ce fut une révélation. En fonctionnement Agile, la priorisation se fait par la valeur. Chaque partie prenante au projet, clients comme développeurs, démontre son travail régulièrement lors de cérémonies dont l’objectif est clair, et ne souhaite donc pas gaspiller son temps dans des réunions à rallonge.
Ce qui m’amène à un autre élément positif selon moi dans la méthodologie Agile, et qui m’a tout autant surprise : la critique (constructive s’entend) est la bienvenue. En effet, j’ai pu assister à deux rétrospectives lors desquelles chaque membre de l’équipe a pu, librement et sans contrainte m’a-t-il semblé, exprimer son avis, positif comme négatif sur l’avancée du projet, le fonctionnement de l’équipe, ou encore les relations avec le client. Ce qui est intéressant, c’est que chaque voix compte, à égalité, et a normalement vocation à être prise en compte pour s’améliorer pour les sprints suivants. De la même manière que pour les réunions, l’effet de surprise est lié pour moi à mes expériences passées, où il y avait souvent une voix qui prédominait dans les projets : celle du supérieur hiérarchique ou du chef de projet. C’est l’inverse que j’ai pu observer pendant ma semaine, et j’ai l’impression que c’est ce qui permet l’amélioration continue et la progression de l’équipe dans son mode de fonctionnement, et donc du produit qu’elle crée par effet de capillarité.
Un autre bon point pour la méthodologie Agile est la capacité qu’elle offre à l’équipe et au client de suivre très régulièrement (à chaque fin de Sprint soit toutes les 2 semaines pour l’équipe) l’avancée du produit, de le tester et ainsi d’éventuellement réajuster la date d’atterrissage prévue. Cela se fait lors de cérémonies dédiées. C’est une méthodologie qui permet la flexibilité, ne vise pas à tout prévoir 3 ans en avance et qui rend donc possible les changements de « planning ».
Toutefois,
tout n’est pas parfaitement rose avec l’agilité. En effet, j’ai remarqué que la relation client/fournisseur n’est pas complètement effacée par la méthodologie. Et si le contexte d’une mission est dit “Agile”, il n’est par rare que parfois le fonctionnement interne du client le soit moins, ce qui est le cas pour l’équipe que j’ai suivi. La responsabilité stratégique du produit revient au client, ce qui est normal. Mais ce dernier subit des lourdeurs hiérarchiques peu compatibles avec le fonctionnement optimal de la méthodologie Agile. Cela a pour conséquence que les développeurs, bien qu’écoutés et respectés, ont du mal à faire entendre leurs voix sur certains aspects stratégiques du produit. Par exemple, sur le projet que j’ai suivi, l’iWatch était vue comme un sujet stratégique par le top management du client. Les métiers avaient donc comme objectif que les développements sur ce support soient réalisés en priorité, malgré leurs difficultés techniques et le manque de cohérence produit que cela pouvait engendrer. Le développeur en charge de cet outil a eu beau expliquer qu’il n’adhérait pas à toutes les demandes du client, sa voix n’a pas été écoutée tant la demande du client sur son produit était forte. Il semble alors que le choix d’utiliser la méthodologie Agile ne garantisse pas que la voix de l’équipe de développement soit entendue dans tous les contextes clients.
Une autre difficulté, plus propre au projet suivi, est que les équipes de développement ne travaillent pas physiquement dans les locaux du client. Le projet est développé dans les locaux de Xebia Studio. Malheureusement, il m’a semblé que l’effet de la distance physique n’était pas totalement comblé par les nombreux échanges téléphoniques organisés. En effet, toutes les équipes ne travaillaient pas nécessairement de manière parfaitement synchronisée et l’absence d’un membre de l’équipe côté client a par exemple perturbé la compréhension de User Stories, et donc leur validation et intégration dans le sprint. Dans le prolongement de cet obstacle, il semble que certains clients soient atteints de « réunionnite aiguë », ce qui bloque parfois l’avancement de certains sujets. A titre d’exemple, une des PO a eu beaucoup de mal à positionner un Workshop de création des visuels des User Stories car elle avait de nombreuses réunions positionnées dans son agenda. Cela a donc ralenti la création des User Stories (US), alors que l’équipe de développement était en avance et avait du temps à accorder à de nouvelles US dans son prochain sprint. Il ne semble alors pas toujours facile d’avancer de manière synchrone quand les contraintes subies par développeurs et les clients ne sont pas les mêmes.
Dernier élément découvert pendant la semaine : l’intérêt du rôle de Proxy Product Owner/Scrum Master, tenu par Meriem. En effet, au début de la semaine, je ne comprenais pas complètement comment une personne qui n’est pas développeur, n’est pas hiérarchiquement « supérieur » aux développeurs mais doit s’assurer de la tenue de la cadence de livraison et qui fait le lien avec les POs et le client; pouvait s’intégrer dans l’équipe. Mais à la fin de la semaine, il m’est apparu que son rôle, en tout cas sur ce projet, était indispensable. En effet, les développeurs se doivent d’être concentrés sur leurs développements, ils connaissent en général parfaitement le périmètre du produit mais pas ce dernier dans son intégralité, et ils n’ont pas forcément envie de perdre du temps à régler tous les problèmes clients qui peuvent survenir. Et c’est là que le rôle de Meriem prend tout son sens. En effet, c’est elle qui connaît, côté Xebia Studio, le produit dans son intégralité, est capable de répondre aux questions techniques du client car elle dialogue quotidiennement avec les développeurs, elle sait aussi bien parler « technique » que « marketing » et sa double compétence est nécessaire à l’avancement du projet. Elle est LE lien entre les équipes techniques et les équipes clientes, et en particulier avec la PO côté client. Cette dernière a une connaissance technique moindre mais une vision stratégique et marketing du produit plus approfondie. La PO et la PPO travaillent donc à l’unisson pour porter la vision produit.
En conclusion,
Je dirais que, au regard de la semaine passée au Studio, il m’est apparu que la méthodologie Agile est un choix de gestion de projet/produit pertinent, efficace et qui responsabilise toutes les parties prenantes. Ce n’est toutefois pas une recette miracle qui fait disparaître toutes les contraintes et tous les obstacles à l’avancement d’un projet. Le PPO dans cette méthodologie a un rôle de facilitateur très efficace côté technique, et je pense que, notamment dans le cadre de développement réalisés hors les murs du client, son travail est essentiel.
Plus concrètement pour mon quotidien de “recruteuse”, ma semaine m’a été utile car elle me permet de mieux comprendre le métier de PO, d’en appréhender le vocabulaire, les grandes étapes du quotidien, de mieux cerner les subtilités du métier, et donc de mieux qualifier les candidats que je rencontre et d’avoir des échanges plus constructifs et pertinents avec eux.
