Méthode Agile pour les produits non logiciels
La méthode Agile est davantage connue dans le monde du développement de logiciels, mais de nombreuses organisations trouvent le cadre bénéfique pour les projets non logiciels également. Voici des exemples concrets d’utilisation de la méthode Agile dans des environnements non logiciels :
Finance :
Mike Palazzolo, President of Fintentional, applies an Agile approach to his fee-only financial planning practice. “As a former software engineer, I practiced using some of the Agile predecessors known as evolutionary and spiral software development. I am applying an Agile approach to my fee-only financial planning practice.
« L’un des défauts de l’élaboration d’un plan financier ponctuel est qu’il est souvent obsolète au moment où il est livré au client. Je propose des services de planification financière continue sur la base d'honoraires, où je travaille en collaboration avec mes clients afin de fournir une planification et des conseils tout au long de l’année. Je divise l’année en « sprints » afin que nous ne prenions pas plus que nous pouvons gérer avec chaque sprint. Cela nous permet également de nous réorienter pendant l’année au fur et à mesure que la vie évolue, ce qu'elle fait nécessairement. J’utilise la technologie, comme le " logiciel de gestion de projet de planification financière " pour faciliter le processus. »
Marketing :
Alexander Kariagin, Partner Marketing Director with CloudBerry Lab, uses Agile to manage marketing projects. “We plan and manage two-week Sprints and apply story points, backlog, review, kickoff, and a daily 30-minute stand-up meeting. This Agile approach allows us to spread tasks among ten marketing team members. Each team member feels responsible and informed about what is going on.”
Monica Georgieff, Head of Marketing for Kanbanize, adopted a Lean Agile approach to campaign management. “We map our campaign activity on a Kanban board. We discovered that it works wonders for our efficiency and output. This has helped us deliver quick, high-quality work. For example, an idea today could be a reality next week because we are much more flexible to market changes. It turns out that software methodologies work for marketing, too!”
Christine Bottagaro, CMO at Rogue Wave Software, has also relied on Kanban to execute marketing projects. “We tried a number of Agile ceremonies, but Kanban worked best. It assumes constant work, with no end dates, and allows for real time prioritization. This suits our work pace, ongoing ideas, work in progress, and completed projects. We rely on an online card system to track work across teams and to manage our backlog.”
L’approche itérative adoptée par les cadres agiles s’est avérée applicable à la fois aux produits logiciels et aux produits non logiciels. D'après Hubert Smits, formateur Scrum certifié, « les méthodes Agile/Scrum sont basées sur une réflexion empirique selon laquelle les problèmes complexes sont mieux résolus par petites étapes, celles fournissant les informations les plus importantes étant terminées en premier. »
Comme nous l’avons noté dans les exemples ci-dessus, de nombreux « produits » d’entreprise peuvent tirer un bénéficie de ces petites étapes itératives.
Rôles de la gestion agile des produits
L’intention de la gestion des produits est de travailler en étroite collaboration avec le développement de produits et de gérer l'orientation et les exigences du produit en fonction des études de marché, des commentaires des clients et de la capacité de développement. Malheureusement, les chefs de produit croulent souvent sous les tâches de gestion de projet associées aux versions de logiciels au lieu d’interagir avec les clients et les influenceurs du marché pour créer le meilleur produit à commercialiser.
Dans le monde du développement agile, il existe d’autres rôles qui aident les chefs de produit à s'extirper des activités tactiques et techniques (où ils passent souvent leur temps dans des environnements traditionnels en cascade) pour se recentrer dans un rôle d'interface externe où ils interagissent avec le marché. Cependant, il n’est pas rare que les chefs de produit endossent le rôle du responsable de produit. Ceci, comme vous le lirez ci-dessous, peut finir par surcharger même les chefs de produit les plus expérimentés.
Chef de produit agile : l’objectif du chef de produit agile est de travailler avec les clients et la direction de l’entreprise pour définir l'orientation du produit. Le chef de produit représente la véritable voix du client. La meilleure façon de comprendre pleinement les problèmes des clients est de leur parler, visiter leurs sites, expérimenter leur vie professionnelle quotidienne et interroger leur personnel. Ce faisant, un chef de produit aura un aperçu direct des difficultés du client et sera en mesure de définir des caractéristiques et des fonctionnalités qui atténuent les désagréments rencontrés par ce dernier. Sans interaction directe avec les clients, il est impossible de comprendre pleinement leurs difficultés et leurs besoins.
Les programmes de certification pour devenir chef de produit agile sont proposés par Pragmatic Marketing dans Pragmatic Product Management.
Défis auxquels sont confrontés les chefs de produit : comme n’importe quel autre rôle organisationnel, les chefs de produit font face à des obstacles. Le plus courant est la définition des exigences. Chaque équipe (comme le développement, l'assistance, les services professionnels ou les ventes) a une opinion sur les fonctionnalités qui doivent être incluses dans un produit. Heureusement, avec des informations tangibles recueillies lors des interactions avec les clients, les chefs de produit peuvent étayer leurs récits utilisateur et leur feuille de route de produit avec des données réelles.
De plus, le rôle d’un chef de produit va des activités stratégiques, telles que la définition d'une feuille de route du produit en phase avec les objectifs de l’entreprise, aux activités tactiques des ventes, du marketing et de l'assistance produit. Malheureusement, les chefs de produit se retrouvent souvent bloqués dans des activités techniques et tactiques qui laissent peu de temps pour le travail stratégique : l’équipe de vente veut que les chefs de produit fassent la démonstration du produit, le marketing les pousse à préparer des supports marketing, et le développement les utilise pour gérer leurs projets. En raison de leur connaissance des produits, les chefs de produit sont de bonnes ressources pour toutes ces activités, mais trouver l’équilibre entre stratégie et tactique est essentiel.
Responsable de produit agile : le responsable de produit dans un environnement agile travaille main dans la main avec l’équipe de développement pour clarifier les récits utilisateur, la vision du produit et ses spécifications, gérer les backlogs et optimiser la valeur du produit pour l’entreprise. Le responsable de produit communique les intentions commerciales à l’équipe de développement afin qu’elle comprenne clairement la raison pour laquelle il lui est demandé de faire ce qu’elle fait. Un responsable de produit a un excellent équilibre entre la compréhension technique/du développement et l’intelligence des affaires. Il est en mesure d'avoir une vue d’ensemble : comprendre les besoins de l’entreprise et du client, communiquer avec les équipes de l’entreprise et aligner les activités techniques afin de livrer un produit exceptionnel. Les responsables de produit ont généralement une compréhension basique du développement de logiciels, sont des communicants efficaces et comprennent la nécessité de résoudre les problèmes des clients. Il est courant que les responsables de produits occupent des postes d’analystes d’entreprise avant de devenir responsables de produit.
Les cours de certification sont proposés par la Scrum Alliance pour devenir Responsable de produit certifié Scrum (CSPO). Cette certification est très utile pour la poursuite de votre carrière en tant que responsable de produit, mais aussi pour comprendre clairement le périmètre du rôle de responsable de produit.
Les erreurs des responsables de produit : instaurer le rôle du responsable de produit peut avoir d’énormes avantages dans un environnement agile. Cependant, des erreurs sont faites concernant ce rôle. Pour réussir, un responsable de produit doit :
- Être décisif
- Gagner la confiance de votre équipe
- Comprendre la vision du produit
- Être présent et disponible pour l’équipe
- S'adapter au changement (être agile)
- Éviter la microgestion de l’équipe
Avoir les deux rôles de chef de produit et de responsable de produit au sein d’une organisation agile permet d’équilibrer les responsabilités sans surcharger une unique personne. Imaginez essayer d’interagir avec les clients, communiquer leurs besoins, créer des récits d’utilisateurs, participer à la réunion quotidienne Scrum, permettre les ventes, former le service d'assistance, faire la démonstration du produit, décrire ses fonctionnalités, clarifier les exigences, ainsi de suite. Cela peut être accablant, même pour le chef de produit le plus avancé. Cela sera bénéfique à l’ensemble de l’organisation si le chef de produit et le responsable de produit peuvent partager les tâches et éviter la surcharge à laquelle un chef de produit fait face lorsqu’il fait tout lui-même.
Le tableau ci-dessous décrit certaines des activités courantes effectuées par le chef de produit et le responsable de produit.
Document d'exigences produit
Une question courante consiste à savoir si le document d'exigences produit (PRD) est utilisé dans un monde agile. En fait, le PRD traditionnel n’est pas utilisé dans les environnements agiles ; il est plutôt remplacé par les récits d’utilisateurs (descriptions des besoins de fonctionnalités basées sur les personas). Ces récits d’utilisateur se concentrent sur la valeur pour le client et sont utilisés par l’équipe agile pour collaborer sur les détails afin de planifier les itérations d’un projet.
Confusion fréquente autour des rôles agiles
Scrum master vs chef de produit vs responsable produit : dans Scrum, la méthodologie Agile la plus populaire, le Scrum master est principalement chargé de garder l’équipe Scrum motivée et concentrée. Il les protège également des distractions et leur fournit des conseils et des instructions. Les principales responsabilités du responsable de produit comprennent la gestion du backlog, la communication des récits utilisateur et la détermination des dates et des fonctionnalités des versions. Enfin, le chef de produit est chargé de définir les récits utilisateur en fonction des difficultés des clients, de mener des études de marché et de développer la feuille de route du produit.
D’autres rôles importants à prendre en compte :
- Responsable des fonctionnalités : à la différence du responsable de produit, le responsable des fonctionnalités n’est responsable que d’une fonctionnalité spécifique (plutôt que de l’ensemble du produit).
- Équipe de développement : l’équipe de développement effectue toutes les tâches du développement technique. L’équipe est responsable de l’analyse, de la conception, de la rédaction du code, des tests et de la communication technique.
Chaque organisation agile est différente et par conséquent, les rôles varient. Il n’est pas rare qu’une organisation évoluant de la méthodologie en cascade à la méthodologie Agile convertisse simplement les chefs de produit en responsables de produit. Cependant, cela ne signifie pas pour autant qu’un bon chef de produit fera un bon responsable de produit et vice versa. Ce qui fonctionne pour une organisation peut fonctionner ou non pour une autre et il est probable qu'au fur et à mesure que l’organisation et le produit évoluent, les responsabilités évoluent également. Par conséquent, de nouveaux rôles seront définis afin d’assurer une attention adéquate à toutes les activités associées à la fourniture d’un produit de qualité aux clients.
La feuille de route de produit et le backlog
La feuille de route du produit est développée et maintenue afin d'illustrer la progression prévue d’un produit. Ces feuilles de route sont souvent utilisées pendant le cycle de vente afin de montrer à un prospect que le produit dispose d’un plan de croissance. La feuille de route est généralement gérée par le chef de produit.
Le backlog produit comprend le travail à accomplir afin de mettre en œuvre un sprint ou un récit utilisateur. Le backlog est utilisé pour piloter les activités de l’équipe de développement et est généralement géré par le responsable de produit.
La feuille de route du produit et le backlog sont complémentaires, montrant le plan à long terme (feuille de route) avec les détails tactiques requis pour chaque étape du produit (backlog).
Smartsheet est un outil essentiel pour les chefs de produit et les responsables de produit agiles
Donnez à vos employés les moyens de se dépasser grâce à une plateforme flexible conçue pour répondre aux besoins de votre équipe, et capable de s'adapter quand ces besoins changent. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.