Si précieux dans le contexte de la transformation digitale, le mouvement Agile a fait naître une multitude de méthodes et de pratiques. A ce propos, la sémantique fait souvent débat, faut-il parler d’une méthode, d’une pratique ou d’un cadre ?
Là n’est pas le propos ni l’objectif de cet article. Chacune possède un certain nombre d’atouts et sont plus adaptées que d’autres à une situation donnée. Retenons juste que dans le cadre global d’une approche agile, ces méthodes se renforcent mutuellement.
La genèse du mouvement agile remonte à 2001 lors de la parution du manifeste agile. Ce bouleversement a contribué à l’essor d’un nouveau paradigme en gestion de projet, passant d’une gestion de projets classique avec ses lourdeurs et ses rigidités, générant de la contre productivité, vers une mutation de nouveaux modes de développement tout en apportant un nouvel état d’esprit.
En écartant toute hypothétiques rivalités entre les méthodes agiles, s’il en est une qui a su davantage tirer son épingle du jeu, c’est Scrum. Elle doit notamment sa popularité au fait qu’elle aide les équipes à travailler ensemble, sa flexibilité dans le cycle de vie du projet constitue un atout majeur. Tout en étant autogérée, une équipe Scrum apprend de ses succès et de ses échecs afin de s’améliorer en continu. La liste des avantages est longue, l’enquête annuelle réalisée par l’entreprise américaine « Digital AI publié que Scrum est plébiscitée à 58% dans le monde.
Déterminant au sein d’une équipe Scrum, le Product Owner affiche une forme de dualité dans son quotidien. A l’écoute du besoin des parties prenantes, il sait transcrire cette vision auprès de l’équipe de développement. Gardons à l’esprit que la raison d’être du Product Owner est de continuellement chercher à apporter de la valeur au produit, ce qui se traduit par la satisfaction des utilisateurs.
Alors comment faire le lien entre les desiderata du client et une équipe Scrum hyper motivée ?
Donner la bonne vision
Là n’est pas le propos ni l’objectif de cet article. Chacune possède un certain nombre d’atouts et sont plus adaptées que d’autre à une situation donnée. Retenons juste que dans le cadre global d’une approche agile, ces méthodes se renforcent mutuellement.
Une large partie de la réponse tient dans la vision du produit.
Pour l’équipe Scrum, elle constitue un catalyseur de l’enthousiasme, l’investissement de chacun des membres. C’est un facteur clé du succès, la vision donne un sens au produit attendu par les clients, les parties prenantes.
Lorsque le PO est salarié de l’entreprise, qu’il connaît les services, les départements et l’infrastructure du SI, l’approche vision du produit est indubitablement facilitée. Pour le consultant externe qui endosse ce rôle, la vérité est bien différente. Il doit se constituer un réseau suffisamment large pour couvrir le périmètre, glaner tous les livrables et documents déjà rédigés sur ce produit, faire le lien avec les projets adhérents au produit. Bref, le consultant doit collecter tout ce qui concerne le produit afin d’en tirer l’essentiel pour combler ses lacunes.
A mon sens, pour afficher une bonne vision du produit, il faut répondre à cette interrogation directe :
Pourquoi créons-nous ce produit ?
Il est également intéressant de savoir s’il résoudra quelques difficultés et au bénéfice de qui.
Pour aider le PO, la mise en place d’un « elevator pitch » est un très bon outil de communication. En quelques secondes, il doit être persuasif et capter l’attention de l’auditoire. Il permet d’identifier les clients concernés, de fournir une description concise du produit tout en précisant les apports, avantages et autres bénéfices à la clé.
l faut comprendre que la vision du produit est issue d’une volonté collective, le PO, les clients et plus largement les parties prenantes ont le même objectif, développer un produit aligné avec les besoins du métier. Dès lors que la vision est pleinement partagée, le PO élabore une roadmap du produit afin de toujours afficher un maximum de visibilité à la fois pour les parties prenantes, mais également pour l’équipe Scrum qui va délivrer. La roadmap permet d’observer rapidement où nous en sommes et ce qui reste à couvrir. Ce dernier point fera l’objet de la préparation des backlogs pour l’ensemble des sprints.
Focus qualité pour tous les incréments
Une des fonctions essentielles du PO est de collecter la liste des exigences du produit. Quotidiennement il doit s’assurer de leur priorisation au sein de la backlog, l’équivalent d’une traditionnelle « To do » liste, toujours avec cette volonté de fournir de la valeur au produit. Idéalement, il doit suffisamment se projeter afin de préparer une backlog avec 4 à 5 sprints d’avance. Il existe plusieurs techniques de priorisation, permettant de sélectionner les tâches ou stories par critères d’objectivité ou de valeur, notons au passage la technique la plus répandue MoSCoW dont l’acronyme correspond à « Must, Should, Could, Won’t ».
Les sprints sont rythmés par les événements récurrents tel que mentionné dans le Scrum guide, à savoir le sprint planning 1er rassemblement de l’équipe au démarrage d’un sprint, le PO présente et argumente les users stories que l’équipe devra prendre en charge durant l’intervalle du sprint. Le daily scrum permet de balayer l’activité en cours de l’équipe, d’identifier les obstacles et points bloquants. Quant à au sprint review, c’est l’occasion de démontrer aux parties prenantes le résultat obtenu pendant ce sprint et de le comparer aux engagements pris avant le sprint. En toute fin de sprint, la rétrospective permet à l’équipe de s’améliorer ; réservée aux uniques membres de l’équipe Scrum, c’est l’occasion d’identifier les écueils, les difficultés et les erreurs commises durant le sprint, ce qu’il est bon de conserver ou d’écarter afin de toujours être plus qualitatif.
L’incrément fourni par l’équipe en fin de sprint viendra s’ajouter au produit en cours de construction. Ceci implique la correction de potentiels bugs ainsi que d’une période de tests. Chaque sprint apportant de la valeur au produit, l’incrément fournit doit être de qualité et immédiatement exploitable par les utilisateurs. Il est souvent fait référence au MVP (Minimal Viable Product), il s’agit d’une première version du produit à livrer, un « morceau » d’application si le projet consiste en un développement applicatif. Un résultat permettant de valider des hypothèses et d’apprendre sur le produit toujours dans l’objectif de satisfaire le client et de collecter ses opinions afin d’améliorer le produit.
Le PO est pleinement intégré à l’équipe Scrum
Si l’on tente de définir un profil type du PO, c’est une personne qui établit quotidiennement un focus sur l’expérience des utilisateurs et qui pense retour sur investissement du produit à développer. Il a une appétence particulière pour le marketing afin de mettre en valeur le produit. Il s’intéresse également au product management, au marketing digital. Faut-il à nouveau le rappeler, le PO porte activement la vision du produit, il aide l’équipe à définir une stratégie d’approche. Véritable rempart entre le métier et les développeurs, le PO à pleinement sa place dans une équipe Scrum, il met la main à la pâte en aidant à construire le produit, en cherchant des solutions, il est au cœur de l’action.
Garant de l’ordonnancement de la valeur, le PO doit toujours prendre du recul, être prêt à apprendre de ses erreurs. Il faut donner du sens et se demander continuellement quel est l’objectif que l’équipe cherche à atteindre tout en mesurant périodiquement la satisfaction du client.
Le PO doit avoir une vue globale de la chaîne de valeur, de la naissance du projet à la mise en production, il doit maîtriser l’art de minimiser le travail inutile.
Use case d’un chatbot au sein du Cloud
En tant que PO, une de mes récentes contribution fut la mise en place d’un chatbot, un besoin marketing visant à fournir un mode de communication instantané, disponible 24/24 afin d’améliorer la relation client.
Pour répondre à cette requête du métier, le PO prépare sa roadmap en y faisant figurer les étapes clés. Il rédige ses user stories qu’il met à disposition dans sa backlog dynamique. Ce n’est qu’entourée des développeurs de l’équipe qu’ils décomposent ensemble la première version de stories en blocs plus petits pour donner davantage de détails, c’est l’affinage.
Cette réalisation s’est appuyée sur la technologie du Cloud (IaaS), d’abord pour fournir rapidement un produit (time to market), ensuite pour favoriser une montée de version transparente (fin de l’obsolescence). Mon rôle à cet égard fut de préparer ma backlog en établissant une liste la plus exhaustive possible concernant les éléments techniques à livrer.
De la réservation des environnements d’intégration, de préproduction et de production. Des considérations techniques de chaque VM (assisté des Devs) à savoir le nombre de CPU, la taille de la RAM, l’espace de stockage, l’OS, le type de base de données, etc. En passant par des réflexions autour de la haute disponibilité, la continuité de service ou le traitement des vulnérabilités. Tous ces éléments doivent être pris en compte par le PO afin d’apporter une valeur la plus optimale possible tout en restant en conformité avec le budget associé au projet.
Ce cas de figure s’est déroulé sur 10 sprints de 15 jours, toujours en étroite collaboration avec les devs de l’équipe, mais également avec les équipes transverses de la gestion du Cloud, les équipes réseaux ainsi que les équipes DBA. Chaque fin de sprint validait une feature du produit sous le contrôle du client, jusqu’à l’obtention du produit fini.
