Décentraliser la prise de décision
—SAFe Lean-Agile Principe #9
Le Product Management dispose d’une autorité de contenu sur le Programme Backlog. Ils sont chargés d’identifier les besoins du Customer, de hiérarchiser les Features, de guider le travail à travers le Program Kanban et de développer la Vision du programme et la Roadmap.
Cet article décrit le rôle que joue le Product Management dans SAFe. Dans certains cas, le Product Management ressemble à un chef de produit pour un train agile (ART), de sorte que ce rôle peut être représentés par un individu ou une petite équipe.
Détails
Les entreprises lean se concentrent sur la fourniture des solutions appropriées aux clients avec la plus haute qualité dans les plus brefs délais. Cela nécessite que les personnes disposant d’une autorité de contenu explicite assument la responsabilité de définir, de hiérarchiser et de valider en permanence les exigences. Travaillant en étroite collaboration avec le développement, dans des cycles d’apprentissage intégrés, la gestion des produits apporte la voix du client aux développeurs et la voix du développement au client.
Suivant le principe n°9, Décentraliser la prise de décision, SAFe offre une autorité de chaîne de contenu à trois niveaux:
- Team – Les Products Owners prennent des décisions rapides concernant le contenu local au nom de l’Agile Team.
- Program – Le Product Management est responsable des décisions relatives au contenu des Agile Release Train (ARTs)
- Large Solution – Solution Management a une autorité de contenu pour les Solution Trains
Product Management priorise le travail à l’aide du Weighted Shortest Job First (WSJF), planifient les fonctionnalités pour la Release en utilisant la Roadmap, valident la réponse du client et fournissent un retour rapide.
Une approche Lean-Agile de la gestion de contenu
Ce que SAFe qualifie de contenu est traditionnellement représenté par un Marketing Requirements Document (MRD), Product Requirements Document (PRD), and System Requirements Specifications (SRS).
Dans le développement traditionnel, ces artefacts étaient généralement réalisés à l’avance, avec l’attente que toutes les exigences puissent être établies avant le début du développement de la Solution. Cependant, cette méthode a eu un succès limité et a été un moteur important des pratiques Lean et Agile.
Nous comprenons maintenant que les hypothèses sur les exigences, la conception et l’architecture doivent toutes être validées par le développement, les tests et les expérimentations de solutions. De plus, les équipes Agiles doivent être ouvertes aux connaissances émergentes pouvant être rapidement réintroduites dans la solution [1]. Dans SAFe, Continuous Exploration est le processus utilisé pour explorer le marché et les besoins des utilisateurs, et pour synthétiser une vision, une feuille de route et un ensemble de fonctionnalités et capacités répondant à ces besoins.
Comme décrit dans la Solution Intent, certaines exigences de la solution sont susceptibles d’être bien comprises et résolues dès le début, tandis que d’autres sont variables et ne peuvent être reconnues que pendant le processus de développement du produit. La gestion de cette nouvelle approche est la responsabilité première du Product Management et du Solution Management. Dans la Lean Enterprise, ces tâches doivent être remplies d’une manière beaucoup plus agile, comme l’illustre le tableau 1.
| Responsabilité | Traditionnelle | Agile |
| Comprendre les besoins du client | En amont et en discontinu | Interaction constante avec le client, notamment Gemba walks (allez voir sur place), entretiens et enquêtes avec les utilisateurs finaux, brainstorming, études commerciales, études de marché |
| Exigences relatives aux documents | Complètement élaborés dans des documents transmis | Vision de haut niveau, affinement constant du produit et des solutions, et communication informelle en face à face avec les équipes |
| Calendrier | Créé au début avec des Roadmap et des Milestones résolument engagés | Un «plan de route» continu à court terme |
| Prioriser les exigences | Pas du tout ou peut-être une seule fois, souvent sous forme de document d’exigences | Re-priorisé à chaque PI via WSJF, triage constant de la portée |
| Valider les exigences | Sans objet, responsabilité de l’assurance qualité (QA) | Le rôle principal impliqué dans l’Iteration et les PI demos, les critères d’acceptation et l’aptitude à l’emploi convenue est bien compris |
| Gérer le calendrier de livraison | Généralement une fois, corrigé longtemps à l’avance | Publication fréquente, chaque fois que la valeur est suffisante |
| Gérer le changement | Changement évité – réunions hebdomadaires de contrôle du changement | Changement adopté, ajusté à chaque PI et d’Iteration |
Tableau 1. Modifications du comportement du Product et du Solution Management dans une entreprise Lean-Agile
Responsabilités du Product Management
La section suivante décrit les principales responsabilités du Product Management dans le contexte d’un seul Agile Release Train (ART).
- Comprendre les besoins des clients et valider les solutions – Le Product Management est la voix interne du client pour l’ART et travaille avec les clients (ainsi que les Product Owners) pour comprendre et communiquer en permanence leurs besoins et participer à la validation des solutions proposées.
- Comprendre et soutenir le travail du portefeuille – Chaque ART vit dans le contexte d’un portefeuille. Par conséquent, le Product Management a la responsabilité de comprendre comment les thèmes stratégiques influent sur les Strategic Themes, de comprendre l’orientation fournie par le Portofolio Canvas, les Lean Budgets et les Guardrails, et les Epic Owners vont développer l’analyse de rentabilisation Lean pour les Epics qui affectent leur ART. Les Guardrails, en particulier, fournissent des indications sur l’allocation de la capacité et des horizons d’investissements qui orientent le Product Management pour les fonctionnalités à explorer.
- Développer et communiquer la vision et la feuille de route du programme – Le Product Management développe et communique continuellement la vision aux équipes de développement et définit les fonctionnalités du système. En collaboration avec les System et Solution Architect/Engenieering, ils définissent et gèrent également les Nonfunctional Requirements (NFR) afin de garantir que la solution est conforme aux normes pertinentes et aux autres exigences de qualité du système. Ils sont responsables de la feuille de route, qui illustre, à un niveau élevé, comment les fonctionnalités doivent être implémentées au fil du temps.
- Gérer et hiérarchiser le flux de travail – La gestion des produits gère le flux de travail à travers le programme Kanban et dans le backlog du programme. Le Product Management est responsable de s’assurer que le Program Backlog contient suffisamment de Features en tout temps. Par exemple, ils ont des critères d’acceptation des caractéristiques qui peuvent être utilisés pour établir qu’ils respectent la définition de Definition of Done (DoD). Et comme la sélection judicieuse et le séquencement des Features sont le principal moteur économique de chaque traitement ART, l’arriéré des tâches est réorganisé en priorité avec le WSJF avant chaque session de Program Increment (PI) Planning.
- Participer au PI Planning – Au cours de chaque session de PI Planning, le Product Management présente la vision qui met en évidence les fonctionnalités proposées de la solution, ainsi que les Milestones pertinents à venir. Ils participent aussi généralement en tant que Business Owners du train, avec la responsabilité d’approuver les PI Objectives et d’établir une business value.
- Définir les versions et les incréments de programme – Posséder le «quoi» signifie que le Product Management est également en grande partie responsable de la définition de la version, y compris des nouvelles fonctionnalités, de l’architecture et des allocations pour la dette technique. Ceci est accompli grâce à une série d’incréments de Program Increment, dont la définition et les objectifs commerciaux sont également déterminés par la gestion des produits. La gestion des produits travaille avec le release management, le cas échéant, pour décider quand suffisamment de valeur a été créée pour garantir une version au client.
- Travailler avec System Architect / Engineering pour comprendre le travail des Enablers – Bien que le Product Management ne soit pas censée guider les décisions technologiques, elle est censée comprendre l’étendue des travaux à venir et faciliter le travail avec les architectes de systèmes et de solutions afin de faciliter la prise de décision et le séquençage des infrastructures technologiques qui hébergeront de nouvel fonctionnalité métier. Pour ce faire, vous définissez généralement une allocation de capacité, comme décrit dans l’article sur les Program et Solution Backlogs.
- Participer aux démos et à l’Inspect and Adapt (I&A) – le Product Management participe activement aux Systems Demos, y compris la démonstration globale à la fin du PI. Ils participent également à l’évaluation des Metrics, y compris à l’évaluation de la valeur commerciale réalisée par rapport au plan, et participent activement à l’atelier d’Inspect and Adapt.
- Construire une équipe de gestion de produit / responsable de produit efficace – Bien que les rôles de Product Owner et de Product Management puissent relever de différentes organisations, la mise en place d’une équipe de Product Management/Product Owner étendue et efficace est la clé d’un développement efficace. Une telle équipe contribue également de manière significative à la satisfaction au travail qui découle du fait de faire partie d’une équipe très performante, qui respecte systématiquement ses engagements en matière de qualité et de vision.
Le Product Management participe à des flux de grande valeur
La section ci-dessus met en évidence le rôle du Product Management dans le contexte de l’ART. Pour les équipes développant de grandes solutions nécessitant plusieurs ART, le Product Management comporte des responsabilités supplémentaires:
- Collaboration avec la Solution management – Au niveau de la Large Solution Level, le Solution Management joue un rôle similaire, mais en mettant l’accent sur les capacités d’une solution plus large. Mais construire une solution efficace n’est pas plus efficace que la collaboration entre les deux rôles. Cela implique la participation au raffinement et à la hiérarchisation de l’arriéré des solutions, ainsi que le fractionnement des capacités en fonctionnalités et NFR, selon le cas.
- Participer au Pre- et Post-PI Planning – Le Product Management participe également au Pre-PI Planning, en collaboration avec les parties prenantes pour définir les intrants, les jalons et les objectifs généraux de la prochaine session de planification de PI. Dans le Post-PI Planning, le Product Management aide à résumer les constatations dans un ensemble convenu d’objectifs PI.
- Participer à la Solution Demo – La direction produit participe à la démonstration de la solution, en démontrant souvent les capacités apportées par leur ART et en examinant les contributions des autres ART, toujours dans l’optique des systèmes et toujours dans le souci de la pertinence.
- Collaborer avec le Release Management – Dans les systèmes à plus grande échelle, le Release Management joue également un rôle important. Le Product Management travaille avec les principales parties prenantes sur les progrès, le budget, la stratégie de publication et la libérabilité de leurs éléments de la solution.
© Scaled Agile, Inc.
