Avec le passage à DevOps, les systèmes que nous construisons ont acquis deux nouvelles qualités importantes : Ils ne finissent jamais et ils fournissent de continuelles rétroactions et opportunités d’apprendre.
Il m’est apparu récemment qu’il y a une transformation radicale dans notre conversation sur le développement de produits numériques en raison du changement (certes lent) mais inévitable vers le management des résultats. Pendant des décennies, la composante « fixe » de nos conversations sur les produits était le produit lui-même. Bien sûr, nous nous sommes peut-être déportés vers les délais, la portée et/ou les choix de conception, mais la question de « allons-nous le livrer ? » n’a jamais été mise en doute. Le produit allait certainement arriver.
Le déploiement du produit n’est plus certain
Avec le passage aux systèmes de déploiement continu, de test et d’intégration continus (alias DevOps), les systèmes que nous construisons ont acquis deux nouvelles qualités importantes :
Ils ne sont jamais finis – Nous travaillons sur nos produits, aujourd’hui, « pour toujours ». Il n’y a pas de date de fin fixe pour les fonctionnalités que nous construisons. Cela semble étrange ? Demandez-vous : « Quand Netflix sera-t-elle terminée ? » Remplacez « Netflix » par n’importe quelle autre entreprise moderne et il devient clair que nos produits et services vivent pour toujours. Il n’y a pas de date de fin explicite. À un moment donné, nous décidons qu’ils ne fournissent plus assez de valeur ou que l’investissement nécessaire pour en extraire plus de valeur n’en vaut pas la peine et nous passons à autre chose. D’ici là, nous devons maintenir et optimiser ces systèmes en permanence.
Ils fournissent une rétroaction continue et une opportunité d’apprentissage – Parce que ces systèmes sont toujours en vol, offrant de la valeur (ou non) et fournissant un service aux clients, nous apprenons continuellement à quel point ils fonctionnent. Nous avons maintenant une opportunité incroyable de déterminer où concentrer au mieux nos efforts pour améliorer continuellement ces systèmes pour nos clients.
Apporter la plus grande valeur aux clients, aussi rapidement que possible.
Ces qualités nous obligent à considérer une mesure de la valeur différente de celle du passé. Nous n’avons plus besoin de nous concentrer sur le fait de savoir si nous avons livré ou non une fonctionnalité spécifique. Au lieu de cela, nous nous concentrons sur ce que nos clients font dans le système. Réussissent-ils ? L’utilisent-ils d’une manière qui leur profite ? Font-ils ce à quoi nous nous attendions ? Autre chose ? Notre obsession n’est plus de savoir si une capacité spécifique a été déployée ou non, mais plutôt de savoir si le système offre de la valeur. Une volonté de « simplement diffuser des fonctionnalités » n’a plus de sens dans ce nouveau contexte.
Le produit est la variable
La nature moderne des logiciels se concentre sur le déploiement de la plus petite quantité de code qui offre la plus grande quantité de valeur. Pourquoi ? Parce que nous devons vivre avec ce code pour toujours. Notre nouvelle mesure du succès est le comportement des clients (ou les résultats). Les comportements et les changements dans ces comportements que nous voulons voir chez nos clients sont nos nouvelles mesures du succès. La façon dont nous réalisons ces changements de comportement devient la variable. Le produit est la variable.
Il existe une combinaison infinie de code, de conception, de proposition de valeur et de modèle commercial qui peut apporter les changements de comportement souhaités. Nous mélangeons, associons et expérimentons différentes façons de rendre notre offre plus précieuse pour nos clients. L’objectif fixé est un changement dans le comportement de nos clients. Nous continuons à ajuster et (espérons-le) à améliorer le produit jusqu’à ce que nous atteignions le niveau souhaité de changement de comportement.
Cela nécessite un nouvel état d’esprit pour le développement de produits
Accepter ce changement dans la façon dont nous manageons nos équipes et nos organisations ne sera pas facile. C’est un profond changement de mentalité. Il est facile de considérer le produit comme l’objectif. Nous pouvons clairement écrire ce que nous croyons qu’il devrait faire, le concevoir pour le faire et le livrer. Malheureusement, cela ne garantit pas notre succès. Cela ne garantit que le déploiement du code (et la dette technique subséquente). La variabilité des produits peut effrayer les parties prenantes. « Qu’est-ce qu’on construit ? », demanderont-ils. En fin de compte, nous devons changer cette question en : « Comment tendons-nous vers les changements de comportement souhaités ? » Cela prendra du temps, mais c’est inévitable. Nos socles technologiques modernes l’exigent.
partagez ce billet avec vos amis, collègues et relations professionnelles
J’ai trouvé ce billet très vrai par rapport à mon vécu personnel sur des projets Agiles qui se sont tellement concentrés sur produire un « Minimum » MVP que leurs premiers livrables n’étaient que très rarement utilisables / « Viables » en situation réelle.
Vos clients détestent les MVPs. Faites plutôt un SLC.
[…]
Les équipes produit ont répété le mantra du MVP (Minimum Viable Product) depuis toute une décennie sans réévaluer si c’est réellement la bonne façon de maximiser l’apprentissage tout en satisfaisant le client.
Eh bien, ce n’est pas le meilleur système !
Cette approche MVP est égoïste et fait mal aux clients.
[…]
La motivation qui dirige le MVP est toujours valable :
Construisez quelque chose de petit, parce que les petites choses sont rapides et peu coûteuses à tester.
Mettez-la rapidement sur le marché, car le véritable apprentissage ne se produit que lorsque de vrais clients utilisent un vrai produit.
Jetez-la ou changez complètement de direction s’il s’agit d’un échec, ou investissez davantage s’il s’agit d’un semis avec du potentiel.
Les MVPs sont parfaits pour les startups et les équipes produit car ils maximisent le plus rapidement possible ce que l’on appelle « l’apprentissage validé ». Et, bien que les entretiens avec les clients soient utiles, vous apprenez de nouvelles choses lorsqu’un client utilise réellement le produit. Mais les MVPs sont un acte égoïste.
Le problème est que les clients détestent les MVPs.
Les startups sont encouragées par le célèbre Reid Hoffman à « lancer le produit assez tôt pour que vous soyez embarrassé par votre version V1.0. ». Mais aucun client ne veut utiliser un produit inachevé qui embarrasse ses créateurs. Les clients veulent des produits géniaux qu’ils peuvent utiliser immédiatement.
Les MVPs sont trop M et rarement V.
Les clients le voient et détestent cela. C’est peut-être génial pour l’équipe produit, mais c’est mauvais pour les clients. Et en fin de compte, ce qui est mauvais pour les clients est mauvais pour l’entreprise.
[…]
Soyez « Slick » (habile et astucieux) !
À partir de ce raisonnement, il y a des années, j’ai nommé ce que je pense être la bonne alternative au MVP : Simple, Lovable/Aimable et Complet (SLC). Nous le prononçons « Slick ». Comme dans : « Quelle est la version (habile et astucieuse) ‘Slick’ de votre idée ? ».
Un autre avantage de SLC devient évident lorsque vous considérez la prochaine version du produit.
Un produit SLC ne nécessite pas de développement continu pour ajouter de la valeur. Il est possible que la V1 évolue pendant des années en une V4, mais vous avez également la possibilité de ne pas investir davantage dans le produit, tout en ajoutant de la valeur. Un MVP qui ne recevra jamais d’investissement supplémentaire n’est qu’un mauvais produit. Un SLC qui n’obtient jamais d’investissement supplémentaire est un bon produit, même s’il est modeste.
Henrik Kniberg, un coach agile et produit de longue date pour Spotify, a créé l’illustration populaire ci-dessus pour donner un exemple à suivre aux équipes produit lorsqu’elles envisagent de livrer un produit minimum viable, ou MVP, à leurs clients.
Une planche à roulettes est un produit SLC. C’est plus rapide que la marche, c’est simple, beaucoup de gens l’adorent, et c’est un produit complet qui n’a pas besoin d’ajouts pour être amusant ou pratique. En même temps, vous pouvez faire évoluer le skateboard en ajoutant une potence et un guidon, pour créer une trottinette (seulement un peu moins simple, et certainement appréciable et complet). Ensuite, vous pouvez faire grandir les roues, ajouter un siège et des pédales, et vous avez un vélo. Encore une fois, moins simple, mais vous avez maintenant un produit avec des avantages massifs de vitesse, de distance et d’efficacité énergétique…
[…]
Avec SLC, les résultats sont meilleurs et vos options pour les prochaines étapes sont meilleures.
Si le SLC échoue, ce n’est pas grave : C’est une expérience ratée. Les SLCs et les MVPs atteindront parfois ce résultat parce que le but est d’ expérimenter. Mais si un SLC réussit, vous avez déjà apporté une valeur réelle aux clients et vous avez plusieurs futurs possibles à votre disposition, dont aucun n’est urgent. Vous pourriez construire une V2, et parce que vous générez déjà de la valeur, vous avez plus de temps pour décider à quoi elle devrait ressembler. Vous pouvez même interroger les clients existants pour déterminer exactement ce que la V2 devrait impliquer, au lieu d’un groupe d’alpha-testeurs qui veulent juste savoir « Quand allez-vous réparer cette chose qui ne fonctionne pas ? »
Ou, vous pouvez décider de ne plus travailler dessus. Tous les produits ne doivent pas nécessairement devenir complexes. Tous les produits n’ont pas besoin de nouvelles versions majeures tous les deux trimestres.
Certaines choses peuvent juste rester Simples, aimables/Lovable et Complètes.
Demandez à vos clients. Ils seront d’accord.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Certains propriétaires de produits (Product Owners) pensent qu’un arriéré de produit (Product Backlog) complet est le meilleur moyen d’atteindre l’objectif du produit et d’être en même temps totalement transparent .
The Expensive Folly of the Oversized Product Backlog par Stefan Wolpers
Apprenez-en davantage sur l’impact négatif d’un Product Backlog surdimensionné sur l’innovation, la capacité de votre équipe Scrum à créer de la valeur et vos relations avec les parties prenantes.
Les effets secondaires coûteux d’un arriéré de produit surdimensionné
Certains Product Owners estiment en effet que tenir un Product Backlog surdimensionné est une stratégie optimale pour atteindre l’objectif du produit et maintenir une transparence totale, garantissant qu’aucune idée de valeur potentielle ne soit perdue. Cependant, construire à l’avance une liste complète de tous les éléments de travail imaginables n’est pas seulement une perte de temps pour une équipe Scrum, un Product Backlog surdimensionné est une erreur coûteuse à long terme.
Voici 8 effets secondaires critiques de cet anti-pattern (contre-modèle ou fausse bonne idée) du Product Backlog.
#1 – Encourage le gaspillage
Un Product Backlog surdimensionné favorise le gaspillage en investissant du temps dans des éléments qui ne seront peut-être jamais développés en raison de la découverte continue de tâches plus précieuses. C’est une violation claire des principes du Manifeste Agile. En particulier, la simplicité – l’art de maximiser le travail non fait – qui est essentielle.
#2 – Augmente les risques du piège des coûts irrécupérables
Les « sunk costs » sont des dépenses non récupérables quoi que l’on fasse ou décide maintenant. Relisez ce billet.
Un important Product Backlog peut favoriser le syndrome des coûts irrécupérables. Les équipes peuvent continuer à affiner et à prioriser des éléments parce qu’elles y ont déjà investi du temps plutôt que parce qu’ils ajoutent une valeur significative. Ce comportement contredit le principe d’amélioration continue et d’adaptation du Manifeste Agile.
#3 – Conduit à la paralysie d’analyse
Un énorme Product Backlog peut provoquer ce que l’on appelle la paralysie d’analyse, où le volume d’items devient écrasant, conduisant à l’indécision et aux retards. L’équipe peut passer trop de temps à évaluer, hiérarchiser et redéfinir les priorités, ce qui nuit à sa capacité à se concentrer sur le développement réel du produit. Cet excès de choix ralentit souvent les processus de prise de décision, ce qui rend difficile pour l’équipe de déterminer par où commencer ou sur quoi se concentrer ensuite. En fin de compte, cela ralentit l’ensemble du projet, détournant l’énergie de la création de valeur pour le client vers la gestion du Product Backlog lui-même.
#4 – Nuit à l’engagement des parties prenantes
Un Product Backlog gonflé présente un défi important en matière de communication efficace. Le grand nombre d’items peut rendre difficile pour les intervenants de comprendre le plan, les progrès et les priorités, ce qui peut entraîner un décalage dans les attentes. Les intervenants peuvent avoir du mal à trouver leurs intérêts spécifiques dans la longue liste, ce qui les rend confus et peut causer un sentiment de détachement.
#5 – Produit un effet d’éviction
Un Product Backlog complet et surdimensionné peut décourager sans le vouloir les parties prenantes et les membres de l’équipe de faire part de leurs réflexions et de leurs idées. L’exhaustivité perçue du Product Backlog pourrait donner l’impression qu’il n’y a pas de place ni de besoins supplémentaires à ajouter, ce qui pourrait faire perdre des idées précieuses.
#6 – Inhibe l’innovation
Un énorme Product Backlog peut involontairement étouffer l’énergie créative au sein de l’équipe Scrum. La longue liste de tâches peut créer une culture de « cocher les cases » où l’équipe se concentre davantage sur compléter des tâches plutôt que sur explorer et innover. L’équipe peut se sentir contrainte, percevant qu’il n’y a pas de place pour de nouvelles idées, ce qui peut limiter leurs compétences créatives en résolution de problèmes et les dissuader de trouver des solutions innovantes. Cet état d’esprit contredit la valeur Scrum de « l’ouverture » et le principe Agile d’exploiter le changement pour le bénéfice business du client.
#7 – Donne un faux sentiment de sécurité
Guide téléchargeable gratuitement
Un Product Backlog exhaustif peut donner un faux sentiment de sécurité, une illusion de contrôle. Il peut sembler que l’équipe Scrum a identifié tout le travail nécessaire, réduisant ainsi le besoin perçu de découverte et d’apprentissage. Ce décalage avec le Guide Scrum, qui préconise l’apprentissage itératif et la découverte, peut être nuisible.
#8 – Encourage l’optimisation précoce
Un Product Backlog enflé peut conduire à une optimisation prématurée. L’équipe peut se sentir forcée de concevoir des systèmes ou des flux de travail qui anticipent l’achèvement des futurs éléments du backlog, ce qui entraîne une complexité inutile, contribuant au gaspillage si ces tâches changent ou sont dépriorisées par la suite. Cette approche entre en conflit avec le principe agile de simplicité (l’art de maximiser la quantité de travail non effectué) et la valeur Scrum de focus, car elle encourage l’effort dirigé vers des besoins futurs incertains plutôt que vers les besoins présents les plus précieux.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Comment contrer au mieux les effets d’un Product Backlog surdimensionné
Heureusement, il existe de nombreuses façons d’éviter de créer un Product Backlog surdimensionné dès le départ. Mieux encore, c’est à l’équipe Scrum de les utiliser à bon escient. Voici 8 tactiques pour commencer :
#1 – Adoptez la simplicité
Tenez-vous-en au principe de simplicité du Manifeste Agile, qui implique de maximiser le travail non effectué. Concentrez-vous sur les articles les plus précieux pour offrir la plus grande valeur client et business.
#2 – Limitez les travaux en cours (Work in Progress : WiP)
Limitez le nombre d’éléments dans le Product Backlog à tout moment. La limite WiP peut éviter la surcharge et encourager l’équipe à terminer les objets avant d’en prendre de nouveaux.
#3 – Affinez régulièrement le Product Backlog
Gardez le Product Backlog gérable en organisant régulièrement des sessions d’affinement pour vous assurer que les éléments sont toujours pertinents, précieux et correctement hiérarchisés.
#4 – Affinez juste-à-temps
Évitez de trop affiner les éléments qui ne sont pas imminents pour le développement. Plus un élément est éloigné de la sélection pour un Sprint, moins il devrait être détaillé. L’équipe Scrum ajoute des détails lors des séances de raffinement juste à temps.
#5 – Hiérarchisez et dépriorisez
Acceptez le fait que tous les éléments du Product Backlog ne seront pas implémentés. Établissez régulièrement des priorités et, si nécessaire, supprimez les priorités ou supprimez les éléments du Product Backlog qui ne correspondent plus à l’objectif du produit.
#6 – Responsabilisez les équipes
Encouragez l’auto-organisation au sein de l’équipe Scrum. Donnez-leur les moyens de proposer et de négocier des éléments dans le Product Backlog, renforçant ainsi leur sentiment d’appartenance et d’engagement. Les meilleurs développeurs challengent toujours leurs Product Owners !
#7 – Faites la promotion un dialogue ouvert
Favorisez une culture de dialogue ouvert et de collaboration entre l’équipe Scrum, les parties prenantes et le Product Owner. Encouragez tout le monde à apporter des idées et à remettre en question celles qui existent déjà, en évitant l’effet d’éviction.
#8 – Favorisez l’apprentissage continu et l’adaptation
Adhérez au processus empirique de « transparence, inspection et adaptation » de Scrum. Apprenez de chaque Sprint, adaptez le Product Backlog en fonction des informations, par exemple, de la revue de Sprint (Sprint Review), et soyez ouvert aux changements.
Pour terminer
Le Product Backlog est un outil essentiel dans le développement de produits avec Scrum. Son efficacité est liée à la simplicité, à la limitation du travail en cours, au raffinement régulier, aux détails juste-à-temps, à la priorisation, à l’autonomisation des équipes, au dialogue ouvert et à l’apprentissage continu.
Tous ces principes fonctionnent ensemble pour garder le Product Backlog concentré, exploitable et aligné sur l’objectif du produit, améliorant ainsi la transparence et favorisant une culture de collaboration et d’amélioration continue.
Comment empêchez-vous un nouveau Product Backlog de devenir surdimensionné ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans sa série de nouvelles en prévision de la rentrée, Mike Cohn de Mountain Goat Software a abordé un problème fréquent : « Comment présenter des user stories à votre équipe ? »
Astuce #1: Commencez par quelques définitions.
Une user story (ou histoire utilisateur) décrit quelque chose qu’un utilisateur veut. L’histoire suit généralement ce modèle: « En tant que [type d’utilisateur], je [veux, j’ai besoin ou je suis obligé de faire cette chose] afin que [je puisse atteindre cet objectif]. »
Une epic (ou épopée) est une grande user story. Voilà. Rien de plus, rien de moins.
Un thème est une collection d’histoires utilisateurs connectées entre elles. Certaines personnes ont introduit le terme de feature (fonctionnalité) pour désigner une histoire utilisateur suffisamment grande pour être livrée ou peut-être assez grande pour que les utilisateurs la remarquent et soient plus heureux.
Toutes ces définitions ne sont utiles que si elles simplifient la discussion sur le produit que vous développez. Pour en savoir plus sur comment et pourquoi utiliser ces termes (et pourquoi les outils ont ajouté à la confusion), consultez Epics, Features et User Stories.
Astuce #2: Ajoutez le bon niveau de détails au bon moment.
Comme Boucle d’or et les trois ours, nous ne voulons pas d’articles dans l’arriéré de produits avec trop peu ou trop de détails. Nous voulons juste le bon niveau de détails.
Si un Product Owner écrit une user story qui inclut trop peu de détails, les développeurs n’en sauront pas assez lors de la planification du sprint pour comprendre ce qu’il faut construire. Lorsque des détails excessifs sont inclus, le temps et l’argent dépensés à ajouter ces détails inutiles sont gaspillés.
Il est peu probable que le product backlog (l’arriéré de produit) d’une équipe soit parfaitement détaillé dès le départ. Cela signifie que l’équipe devra probablement itérer pour aller vers la bonne quantité de détails.
Je trouve qu’il est beaucoup plus facile pour les membres de l’équipe de trouver le bon équilibre lorsqu’ils commencent avec trop peu de détails. Commencez donc par remplir le modèle d’histoire utilisateur avec le strict minimum de fonctionnalités et de détails du produit, et partez de là.
Astuce #3: Apprenez la méthode SPIDR pour découper les histoires
L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper les histoires utilisateurs. Je parie que vous avez eu du mal avec cela, parce que je l’ai certainement connu au début. C’est pourquoi j’ai trouvé un acronyme facile à retenir pour détailler les cinq facteurs différents qui pourraient vous aider à diviser une histoire.
J’espère que ces conseils vous aideront, vous et votre équipe, à réussir avec agile,
* Spike : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Vos clients ou parties prenantes viennent-ils parfois vous voir et font pression pour un changement immédiat ? Je suis sûr qu’au moins quelques-uns d’entre eux le font. Les miens l’ont toujours fait.
J’ai remarqué quelque chose à ce sujet, cependant.
La plupart du temps, lorsque les gens insistent : « Nous avons besoin de cela maintenant », ils le font parce qu’ils ont appris que c’est la meilleure façon d’attirer notre attention. S’ils peuvent augmenter la gravité afin que nous agissions immédiatement à la demande, ils savent qu’ils obtiendront le changement.
Ces clients et parties prenantes ont appris au fil des ans que s’ils ne parviennent pas à obtenir notre attention immédiate, la demande disparaîtra dans le puits sans fond des demandes et ne sera jamais faite.
Un réel avantage de travailler de manière agile est que nous pouvons changer la conversation avec ces personnes. Au lieu de tout laisser tomber pour répondre à leur besoin immédiat, nous pouvons plutôt leur expliquer que notre équipe évite d’introduire des changements dans une itération, mais sera heureuse de planifier ce nouveau travail dans la prochaine itération.
J’ai eu beaucoup de succès en répondant quelque chose comme ceci
Cela semble important et j’aimerais que nous nous y mettions. Mais nous travaillons par blocs de temps de deux semaines que nous appelons itérations [ou sprints] et nous en sommes au milieu d’une itération en ce moment. Nous essayons vraiment d’éviter d’ajouter un nouveau travail à l’un de ces blocs de temps, car cela affecte notre capacité à tenir les promesses que nous avons pu faire aux autres parties prenantes. Nous avons une nouvelle itération qui commence la semaine prochaine. Que se passe-t-il si je m’engage à planifier cette demande dans cette itération et à vous la donner quelques jours après [ou à la fin de l’itération] ?
Faire comprendre aux utilisateurs et aux parties prenantes qu’ils n’ont plus besoin d’attirer notre attention en insistant sur le fait que tout est nécessaire « maintenant » peut représenter une énorme victoire.
Cela permet aux équipes de mieux planifier leurs itérations et d’avoir moins d’interruptions. Ceci vous aidera à réussir avec agile.
PS: Le management des parties prenantes est quelque chose que Mountain Goat Software couvre dans les cours CSM et CSPO. En tant que Scrum Master, vous apprendrez à minimiser les conflits et à éviter les perturbations lors de réunions clés telles que le daily scrum. Et en tant que Product Owner, vous apprendrez à communiquer efficacement entre les parties prenantes et l’équipe pour apporter constamment de la valeur. Vous pouvez trouver les détails des deux cours ici.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Pour de nombreux professionnels de projet, la gestion d’un arriéré d‘histoires utilisateurs dans un projet agile peut se faire sans nécessiter de profonde réflexion. Mais qu’est-ce qui détermine la priorité et comment cela contribue-t-il à produire les bénéfices escomptés ?
Prioritisation in Agile: Focus on the Benefits par Quay Consulting
L’un des principes clés de la livraison de projet agile est la flexibilité de permettre une approche plus itérative et acceptant le changement en ce qui concerne le contenu, garantissant que les éléments les plus à valeur ajoutée sont livrés en premier.
Ce n’est pas une approche exempte de contraintes, loin s’en faut. Les équipes de projet agiles adoptent une vision stricte du temps et des coûts, appelée time-boxing, et reconnaissent que les limites de ressources et de temps permettent à l’équipe de se concentrer sur la répartition et la priorisation du contenu pour s’assurer qu’un bénéfice est livré.
Relisez ce billet
Le rôle du propriétaire du projet est essentiel à la réussite, compte tenu des responsabilités qu’il assume dans la définition, la hiérarchisation et l’approbation ou le rejet du travail fourni par l’équipe. Faire un « bon travail » est rarement suffisant pour garantir un bon résultat, et le rôle que joue le propriétaire du produit est très difficile à bien faire.
Lorsque les processus agiles sont bien suivis et selon des normes élevées et alignées, une approche agile peut maximiser le potentiel de retour sur investissement et offrir les bénéfices recherchés par un projet. Lorsque ces processus sont moins bien exécutés, le risque de ne fournir aucune valeur est très réel.
Alors, quels sont les défis qu’un propriétaire de projet peut rencontrer et comment mettent-ils les avantages en péril ?
Contraintes de priorisation
Le time-boxingest une technique qui permet à un projet de disposer de ressources limitées pour fournir la liste de la portée souhaitée. Il est courant de démarrer un projet avec plus de portée qu’il n’y a de financement pour la réaliser, et même si cela ne commence pas avec cela comme défi initial, l’opportunité créée en construisant de plus petits morceaux de contenus dans les itérations permet à l’équipe d’identifier de nouveaux éléments avec des bénéfices potentiellement plus importants.
Le diagramme illustre l’incidence des contraintes sur l’arriéré de produit lorsqu’une ligne est tracée entre ce qui est prioritaire et qui entre dans l’enveloppe de financement et ce qui n’est pas prioritaire ou pas financé.
Le propriétaire du produit est responsable de la priorisation, en pratique, de décider ce qui est au-dessus ou au-dessous de la ligne. La capacité de prendre les bonnes décisions en matière de priorisation nécessite une compréhension approfondie des besoins, des préférences et des points faibles des clients, ainsi que des buts et objectifs de l’entreprise. Cela nécessite également d’avoir une vision claire du produit.
Mais comment prennent-ils les décisions concernant ce qu’il faut promouvoir et ce qu’il faut dé-prioriser ?
Facteurs de priorisation
Qu’un projet utilise l’agilité ou non, de nombreux facteurs doivent être pris en compte lorsqu’un propriétaire de produit choisit ce qu’il faut prioriser et ce qu’il ne faut pas prioriser.
Par exemple :
Impact utilisateur : Réfléchissez à l’impact de l’histoire utilisateur sur l’expérience de l’utilisateur final. Cela améliorera-t-il leur expérience ou résoudra-t-il un problème important ?
Complexité : Tenez compte de la complexité de l’histoire utilisateur. Est-ce une tâche simple, ou cela nécessite-t-il beaucoup d’efforts et de ressources de développement ? Ce facteur est plus utile lorsqu’il est considéré en conjonction avec la valeur business.
Dépendances : Tenez compte des dépendances de cette histoire utilisateur vis-à-vis d’autres histoires ou fonctionnalités. Sera-t-il plus facile de terminer cette histoire avant ou après une autre ? Cette histoire est-elle nécessaire dans le cadre d’un ensemble pour offrir une expérience significative ?
Risque : Tenez compte du niveau de risque associé à l’histoire utilisateur. Implique-t-elle des risques techniques ou business qui pourraient avoir une incidence sur la réussite du projet ? Y a-t-il des risques de remaniement ou d’utilisation excessive de temps et de ressources qui, si cela se produisait, diminuerait la valeur de l’histoire ?
Temps et coût : Tenez compte du temps et du coût nécessaires pour compléter l’histoire utilisateur. Peut-elle être achevée dans les délais et le budget impartis, et offre-t-elle un retour sur investissement significatif ?
Valeur business : Tenez compte de la valeur commerciale de l’histoire utilisateur. Apporte-t-elle une valeur significative au client ou à l’utilisateur final ? Répond-elle à un besoin ou à un problème critique ? Est-ce que le fait de la terminer rapproche le projet de son objectif ?
Comme la portée est divisée en de nombreux petits éléments de contenu dans les projets agiles, il peut devenir très difficile de déterminer dans quelle mesure chaque élément contribue aux bénéfices globaux que le projet cherche finalement à produire.
Le processus de priorisation et le contexte
Il existe une théorie autour du changement qui sous-tend un projet, y compris les projets agiles. Les bénéfices sont un résultat positif obtenu en fournissant le contenu souhaité.
Il y a un peu plus…
Généralement, un projet commence par des buts et des objectifs, qui sont traduits en portée et livrables. La relation entre les facteurs et le contexte fourni par les buts et objectifs du projet sont des ingrédients importants dans le processus de priorisation car ils aident à donner plus de sens à chaque histoire utilisateur.
Considérons ce que chaque composant représente :
Objectifs : Décrivez les résultats ou les avantages de haut niveau que le projet vise à atteindre ou à impacter; par exemple, un projet vise à améliorer l’expérience client globale de 10 %.
Cibles : Cibles précises, mesurables et limitées dans le temps qui doivent être atteintes pour atteindre les buts du projet. Elles sont souvent décomposées en étapes plus petites et réalisables. Par exemple, si l’objectif du projet est d’améliorer l’expérience de 10%, une cible pourrait être d’améliorer la vitesse de traitement des commandes et leur précision afin de réduire les plaintes des clients de 25%.
Portée : Établit les limites de ce que le projet inclura ou exclura. Elle définit les caractéristiques, les fonctions et les tâches qui feront partie du projet. Par exemple, la portée d’un projet de développement de site Web pourrait inclure la conception et la construction d’un site Web, mais exclure la création de matériel de marketing.
Livrables : Livrables ou résultats tangibles et mesurables qui sont produits à la suite de l’achèvement des travaux du projet. Les livrables peuvent être des produits, des services, des documents ou des rapports. Par exemple, les produits livrables du projet de développement de sites Web pourraient inclure un site Web fonctionnel, des formulaires clients, des articles de connaissances connexes et des services de chat.
Il existe de nombreuses considérations qu’un propriétaire de projet doit prendre en compte lorsqu’il décide de l’arriéré de produit d’un projet agile et celles-ci doivent être faites dans le contexte des buts et de la définition objective du projet. Ceci devrait permettre au propriétaire du projet de peser le mérite de chaque facteur et de déterminer la valeur de chaque histoire utilisateur et comment elle contribue aux bénéfices.
Maintenir un focus laser sur les bénéfices et le retour sur investissement
Les Product Owners doivent solliciter les commentaires, les retours et la collaboration des parties prenantes pour mieux comprendre l’impact ou les conséquences potentiels de la façon dont ils priorisent les histoires utilisateur ou les groupes d’histoires. Cela peut également fournir une perspective sur la complexité ou le coût de leur mise en œuvre et donner un aperçu du point de vue ou de la compréhension des parties prenantes de ce qui est attendu en termes de retour sur investissement.
La nature interdépendante de ces éléments démontre qu’il n’y a jamais de processus linéaire ou simple dans la hiérarchisation des priorités; Les histoires utilisateur et la façon dont elles sont priorisées ne peuvent pas être prises isolément sans effet sur les résultats. Des composants à valeur ajoutée pourraient être livrés, mais pas fusionnés dans une solution cohérente.
Il est essentiel que les propriétaires de produits soient en mesure de se concentrer sur les bénéfices et le retour sur investissement dans la façon dont ils prennent des décisions sur comment ils décomposent le contenu et décident quelles histoires d’utilisateurs sont incluses ou dé-priorisées.
partagez ce billet avec vos amis, collègues et relations professionnelles
La septième édition du Guide PMBOK® définit une structure de répartition du travail (WBS) comme une « décomposition hiérarchique de la portée totale du travail à effectuer par l’équipe projet pour atteindre les objectifs du projet et créer les livrables requis ».
Bien que cette définition permette de bien comprendre ce qu’est une WBS, elle ne fournit pas de conseils sur la façon d’organiser la structure d’une WBS. Ceci est utile car cela donne aux équipes la flexibilité nécessaire pour déterminer quel est le moyen le plus approprié de le faire dans le contexte de leur projet.
Bien qu’il existe une variété infinie de projets, j’ai trouvé 3 approches utilisées par la plupart des équipes qui développent des WBS.
Axée sur les livrables – Chacun des composants de niveau supérieur de la WBS représente un livrable clé, et les niveaux suivants se concentrent sur la décomposition de ces livrables à un niveau de détail approprié.
Axée sur les phases – Chacune des composantes de niveau supérieur de la WBS représente une phase ou une étape du cycle de vie du projet, et les niveaux suivants se concentrent sur la décomposition des extrants de chacune de ces phases ou étapes.
Axée sur la responsabilité – Chacune des composantes de haut niveau de la WBS représente une partie prenante contribuant à l’exécution du projet, et les niveaux suivants se concentrent sur la décomposition des extrants produits par chacune de ces parties prenantes.
Une approche axée sur les livrables
Aide à concentrer l’équipe sur tout ce qui est nécessaire pour réaliser chaque livrable sans se soucier à ce stade de qui le fait ou quand cela serait fait. Cela peut bien fonctionner pour les projets où toute la portée d’un projet peut être décomposée dès le début, mais peut être difficile lorsqu’une approche par vagues (rolling waves) est adoptée, à moins qu’il n’y ait une identification claire des parties de planification qui doivent être élaborées à une date ultérieure.
Une approche axée sur les phases
Livre sur Amazon
Fonctionne bien avec une approche par vagues, car l’équipe n’a qu’à se concentrer sur ce qui sera achevé dans la phase à venir.
Cependant, il existe un risque que l’équipe manque des éléments clés de la portée pour des livrables spécifiques, car elle ne se concentrera pas sur la décomposition d’un seul livrable à la fois.
Une approche axée sur la responsabilité
Fonctionne bien lorsqu’il y a plusieurs parties prenantes et qu’il est nécessaire d’avoir une séparation claire des responsabilités en matière de planification et d’exécution. Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.
Sondage auprès des professionnelles et professionnels du management de projet
57 % utilisaient une ventilation axée sur les livrables
28 % une approche axée sur les phases
9 % une approche axée sur la responsabilité
Les 6 % restants ont indiqué qu’ils utilisaient une autre approche, mais lorsque j’ai examiné les commentaires que ces participants avaient soumis, il semble qu’ils utilisent simplement une combinaison de ces méthodes plutôt que quelque chose d’entièrement nouveau.
Bien que le WBS soit un outil couramment utilisé avec des projets suivant un cycle de vie prédictif, cela ne signifie pas que ceux qui suivent un cycle adaptatif ne peuvent pas en bénéficier. Si nous considérons une user story map*, il s’agit simplement d’une WBS limitée entre deux et quatre niveaux et élaborée de manière progressive. Avec une Story Map, la structure peut être orientée persona (rôle des utilisateurs) ou thème/capacité.
Quelle que soit la façon dont votre équipe choisit de décomposer la portée du travail sur ses projets, une WBS ou une variante de celle-ci doit être considérée comme un instrument précieux dans sa boîte à outils.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
* Une user story map est un outil puissant qui permet à une équipe agile de préparer son backlog de produit et de planifier plus efficacement les versions de produits. Une user story map capture le parcours d’un client avec le produit, y compris les activités et les tâches qu’il effectue avec le système.
partagez ce billet avec vos amis, collègues et relations professionnelles
En 2003, Barry Boehm et Richard Turner ont inventé l’acronyme C.R.A.C.K. pour nous rappeler les caractéristiques clés d’un Product Owner efficace !
Collaboratif – Est-il capable et disposé à négocier avec les parties prenantes sur les besoins, les souhaits et les priorités afin de définir un contenu de produit optimal ?
Livre référence sur Amazon
Représentatif – Est-il capable de « se mettre dans les chaussures » d’une partie prenante donnée pour aider les membres de l’équipe et d’autres personnes à comprendre le contexte derrière un besoin particulier ?
Autorisé – Est-il habilité à prendre la majorité des décisions de priorisation sur le produit sans avoir besoin de demander l’approbation de ses supérieurs ?
Comitted (engagé) – A-t-il pleinement adhéré à la vision du produit et a-t-il une capacité suffisante pour s’acquitter de ses responsabilités en tant que Product Owner ?
Knowledgeable (Connaissance) – Possède-t-il une connaissance suffisante du domaine du produit, mais aussi a-t-il le savoir-faire organisationnel pour savoir qui engager, influencer ou persuader ?
Cet acronyme me semble s’appliquer également fort bien aux responsables de Project Management Office (PMO), les bureaux de projets, ainsi qu’aux portefeuilles de projets (PPM) !
Visitez le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici un billet que j’ai trouvé très intéressant sur la réelle valeur des story points et les raisons pour lesquelles ils créent des conflits dans vos projets Agiles.
L’estimation du travail agile fait l’objet de débats dans les organisations depuis des années. Il existe plusieurs techniques d’estimation, mais les story points, en particulier, peuvent être un mystère pour beaucoup. Bien qu’il s’agisse d’une méthode couramment utilisée, certains peuvent questionner son efficacité. Cet article décrit le but des story points et pourquoi ils peuvent être sujets à controverse.
Qu’est-ce qu’un Story Point ?
Un story point est une unité de mesure d’une user story basée sur des facteurs tels que la complexité, l’effort, l’incertitude et le risque. Les story points peuvent être utilisés dans des approches agiles comme Scrum lors de la planification du sprint en attribuant une valeur en points à une user story.
Le story-pointing est un moyen rapide d’estimer le travail à l’aide d’outils tels que Planning Poker ou le modèle de Fibonacci. Par exemple, l’équipe peut attribuer un 1 ou un 2 à une histoire qu’elle considère comme nécessitant peu d’effort. L’objectif est d’aider les équipes Scrum à avoir un dialogue ouvert pour acquérir une compréhension commune du travail relatif à toutes les histoires utilisateurs dans l’arriéré de produit, le product backlog.
Relisez ce billet sur « pourquoi Fibonacci ? »
Toute l’équipe (ceux qui font le travail) discute des éléments et des composants impliqués dans le développement de l’histoire utilisateur et parvient à un consensus sur l’estimation en story points. Certaines équipes établissent une base de référence convenue pour l’histoire d’effort le plus faible avec le nombre de story points le plus bas. Si une user story a un nombre très élevé de points, l’équipe décompose l’histoire en histoires plus petites puis les estime.
Comment les story points sont-ils utilisés dans les sprints ?
Une fois que la planification du sprint est terminée et que l’équipe a décidé de ce à quoi elle peut s’engager dans le sprint, elle a alors son nombre total de points d’histoire, de story points, engagés. À la fin du sprint, l’équipe aura consommé tous les story points qui répondent à leur définition de terminé, done. Toutes les histoires qui ne sont pas complètes sont alors soit déplacées dans le backlog, peut-être affinées et ré-estimées, soit reportées au sprint suivant : c’est une décision d’équipe.
L’équipe répète ce processus pour chaque sprint. Au fil du temps, les membres développent leur vélocité, qui est une moyenne du nombre total de story points complétés à la fin de chaque sprint. Les story points terminés peuvent varier à chaque sprint en fonction de la capacité de l’équipe (temps disponible pour chaque sprint). Les facteurs qui pourraient avoir une incidence sur la capacité comprennent le nombre de membres de l’équipe travaillant dans le sprint en raison d’un congé personnel ou d’une maladie, d’une formation ou de conférences, d’événements imprévus, de distractions externes ou peut-être d’un sprint lourd en réunions (pensez aux réunions de département ou d’organisation).
Pourquoi les story points peuvent-ils être sujets à controverse ?
Étant donné que les story points sont une valeur nébuleuse et arbitraire, certaines organisations peuvent ne pas comprendre l’unité réelle de cette mesure des histoires utilisateur. Elles peuvent mal interpréter leur objectif, et il est difficile d’associer systématiquement les points d’histoire au délai de livraison. Prenons la vélocité, par exemple. Elle est considérée comme une mesure clé dans Agile, mais elle peut être utilisée à mauvais escient lors de la mesure de la productivité d’une équipe. Les dirigeants peuvent poser des questions sur la vélocité de l’équipe et vouloir savoir combien de points d’histoire ils achèvent à chaque sprint. Cet état d’esprit de la vélocité en tant que mesure de productivité utilisant des story points ne donne pas une bonne idée de la productivité ni du temps qu’il faudra à l’équipe pour livrer une fonctionnalité.
Disons que l’équipe prend en charge et complète 20 story points dans le sprint 1. Dans le sprint 2, ils prévoient 40 story points mais ne complètent que 30 story points. Dans le sprint 3, ils embarquent et complètent 30 points d’histoire. Cela ne signifie pas que l’équipe est plus ou moins productive de sprint en sprint. Cela fait partie du processus de planification de l’équipe pour déterminer ce qu’elle peut engager dans chaque sprint compte tenu de son expérience du dernier sprint. Étant donné que les user stories présentent différents degrés de complexité et d’incertitude, l’équipe a peut-être appris que ses estimations lors de la planification du sprint étaient trop élevées ou trop basses et s’ajuste en conséquence à chaque sprint.
La capacité de l’équipe est une autre raison pour laquelle les story points peuvent fluctuer. Peut-être qu’ils n’ont pas pu en terminer autant qu’ils l’avaient prévu en raison d’une personne malade dans l’équipe ou d’un autre événement inattendu.
Les story points sont également utilisés à mauvais escient comme métrique pour comparer une équipe à une autre. L’équipe A peut avoir une moyenne de 40 story points tandis que l’équipe B peut avoir une moyenne de 80 story points. Le management peut mal interpréter cela comme signifiant que l’équipe A est deux fois plus productive que l’équipe B. Il n’y a pas deux équipes égales. Leurs membres peuvent avoir des compétences différentes, la taille des équipes peut être différente et les définitions d’un story point peuvent varier. La comparaison des équipes nuit à leur processus d’estimation, crée des estimations gonflées et démoralise l’équipe.
Trouvez un équilibre
Il est compréhensible que les organisations aient besoin de savoir à quel point les équipes sont productives et elles ont besoin de quelque chose de tangible pour mesurer leur performance. Cependant, il est erroné de supposer que les story points et la vélocité sont des mesures d’évaluation de la productivité. Les story points sont utilisés par l’équipe Scrum à des fins de planification et ne doivent pas être considérés comme une unité de productivité par la direction. La vélocité en tant que métrique doit être utilisée par l’équipe Scrum comme point de référence pour les aider dans leur prise de décision pour les engagements de sprint.
Les apprentissages continus et l’expérience de l’équipe donnent la possibilité à l’équipe Agile d’améliorer ses estimations au fil du temps.
Grâce à l’inspection et à l’adaptation, les membres de l’équipe deviennent plus prédictifs et capables de prévoir les délais pour les fonctionnalités. Ce qui compte dans l’agilité, c’est un dialogue ouvert et productif sur le travail, la progression vers l’objectif du produit et la création fréquente de valeur pour les clients.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Nous savons que l’agilité n’est pas une méthodologie ni un ensemble de processus ou de techniques. L’agilité est le comportement et les attitudes qui permettent aux individus et aux organisations de se déplacer rapidement et facilement.
Au niveau individuel, cette capacité conduit à l’innovation, à la créativité, à l’adoption rapide de nouvelles méthodes de travail.
Au niveau organisationnel, ce comportement est démontré par des améliorations continues, la recherche de nouveaux apprentissages, la volonté d’adopter de nouvelles approches et, en fin de compte, une mise sur le marché de nouveaux produits et services aux clients plus rapide et plus créative.
Les comportements agiles sont soutenus par de nouvelles façons de planifier et de hiérarchiser le travail, mais ils ont besoin d’un environnement qui encourage et récompense leur utilisation.
Les leaders sont les principaux acteurs dans la création de cet environnement.
Les leaders ne sont pas limités à ceux qui ont un pouvoir hiérarchique au sein de leurs organisations.
Un leader est quelqu’un que les autres suivent volontiers.
Je travaille avec de nombreuses organisations à différentes étapes dans l’agilité, et j’ai observé un groupe central de comportements travaillant ensemble, qui permettent aux processus et techniques agiles de s’épanouir :
Imaginez l’état futur
Faites évoluer votre vision
Identifiez les petites étapes
Vivez dans l’incertitude
Prenez des décisions
Sollicitez l’avis des autres
Abandonnez le contrôle
Si vous occupez un poste de leadership, j’ai écrit un document qui vous donnera l’occasion de comparer votre propre comportement à l’excellence agile et d’identifier les domaines à améliorer.
Si vous êtes manager de projet/programme, PMO ou Product Owner, cela vous donnera beaucoup d’idées sur ce dont il faut discuter avec votre sponsor.
Le Sprint est l’un des concepts de base de Scrum. En fait, c’est l’un des cinq événements de Scrum (avec Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective).
Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé. Pour le comprendre, vous devez comprendre le but d’un sprint et pourquoi il est timeboxé (réalisé sur une période de temps limitée).
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Qu’est-ce qu’un sprint ?
Un sprint est l’unité de temps fondamentale dans Scrum. Il s’agit d’une timebox (une durée spécifique et forcée) pendant laquelle une équipe Scrum tente de créer un ou plusieurs incréments de produit. Tous les événements Scrum (Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective) se déroulent au sein d’un sprint.
Il n’y a pas d’activité en dehors du sprint.
Une fois qu’un sprint se termine, le sprint suivant commence immédiatement et le cycle de sprint recommence. Il n’y a pas de sprints spéciaux comme « sprint zéro », ou « sprint de consolidation » ou « sprint de release ». A chaque sprint, l’équipe est destinée à déplacer certains éléments du backlog produit vers Done (Terminé) et à livrer un incrément de produit.
Et surtout, un sprint est strictement limité dans le temps, généralement deux semaines, bien qu’il puisse durer jusqu’à un mois.
Pourquoi est-il timeboxé ?
La limite de temps de sprint est très importante. Les équipes doivent accepter la timebox et la respecter, c’est-à-dire mettre fin au sprint et commencer un nouveau sprint une fois la timebox terminée.
Il est parfois tentant pour une équipe de laisser un sprint « traîner » un ou deux jours de plus, pour essayer de finaliser certains éléments, mais cela va à l’encontre de l’essentiel !
Si une équipe commence à faire cela, elle peut continuer à le faire, et le faire de plus en plus. Cela remonte à l’époque des méthodes prédictives dites en cascades, où les livraisons sont repoussées toujours plus tard car les équipes veulent mettre tout le contenu de leur périmètre fonctionnel dans une unique livraison ou release. Avant que vous ne vous en rendiez compte, vous pouvez revenir à une release tous les 6 mois !
La timebox stricte garantit qu’il existe un modèle régulier simple, une cadence, où une équipe s’arrête et inspecte son dernier livrable (dans la revue de sprint) et l’équipe elle-même (dans la rétrospective de sprint).
Quand un sprint est-il terminé ?
La réponse courte et simple est qu’un sprint est terminé lorsque la timebox de sprint se termine ! (Quelle que soit la cadence choisie par l’équipe pour les sprints, c’est-à-dire deux semaines, un mois, une semaine, etc.).
Une équipe peut choisir de changer la durée de ses sprints (c’est-à-dire que l’équipe peut choisir de passer de sprints de deux semaines à des sprints d’une semaine ou vice versa), mais ce n’est pas un changement ponctuel. Cette nouvelle timebox devient la timebox standard pour tous les sprints à partir de là (jusqu’à la prochaine fois que l’équipe voudra changer la timebox).
Un sprint n’est pas terminé lorsqu’un incrément de produit est créé ou livré. L’équipe continue simplement à travailler sur d’autres éléments de l’arriéré de produit ou product backlog. Elle peut même produire un autre incrément de produit dans ce sprinte (Il n’y a rien dans Scrum qui dit que vous ne puissiez livrer qu’un seul incrément de produit par sprint !).
Un sprint n’est pas non plus terminé lorsque l’objectif de sprint a été atteint. Dans la situation heureuse où il reste encore un peu de temps dans le sprint, l’équipe peut choisir d’effectuer le travail qu’elle veut dans le temps restant. Il peut s’agir de travailler sur d’autres éléments du product backlog, rembourser une dette technique, examiner certains éléments d’amélioration continue, etc.
L’important est que la timebox régulière soit respectée.
De quelles autres façons un sprint peut-il se terminer ?
Il n’y a que deux autres façons dont un sprint peut se terminer.
La première est si le Product Owner décide d’annuler le sprint en cours. C’est un cas extrême qui ne devrait arriver que très rarement. La seule raison donnée pour cela dans le Guide Scrum est que l’objectif de sprint est devenu obsolète. Cela peut se produire pour diverses raisons, mais elles ne devraient pas arriver souvent. Il est presque toujours plus bénéfique pour l’équipe de continuer et de terminer le travail qu’elle a prévu pour ce sprint.
Il n’y a pas d’autres moyens mentionnés dans le Guide Scrum. Le seul auquel je puisse penser est un exemple encore plus extrême et, espérons-le, rare. C’est si le produit ou l’équipe elle-même cesse d’exister. Si une équipe est au milieu d’un sprint et que, pour une raison quelconque, l’organisation décide d’arrêter tout travail sur le produit ou d’arrêter de financer l’équipe, alors évidemment ce sprint se termine.
L’organisation peut vouloir financer l’équipe pour le reste du sprint, mais si le produit lui-même est obsolète ou n’est plus financé, elle peut vouloir économiser de l’argent en ne terminant pas le travail en cours dans le sprint.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les équipes Scrum se réunissent pour décider des éléments de travail de leur prochain sprint lors de la réunion de planification du sprint. Mais est-ce le début de la conversation pour le sprint à venir, ou y a-t-il des choses à faire avant ?
Priorisez le Product Backlog, l’arriéré de produit
La première et la plus importante considération est d’avoir un product backlog vivant qui est à jour et hiérarchisé pour suivre l’évolution des besoins de l’entreprise. Le propriétaire de produit doit avoir un œil constant sur l’ajout, la suppression, la modification et la mise à jour d’éléments dans le product backlog. Lorsque le temps vient de planifier le sprint suivant, le chef de produit doit apporter à la table une liste des éléments de valeurs les plus élevées que l’équipe puisse choisir.
Détaillez les fonctionnalités
Étant donné que la plupart des exigences agiles sont courtes, soit sous la forme d’histoires utilisateur (User Stories) ou simplement de phrases listant les fonctionnalités nécessaires, elles nécessitent d’être détaillées pour pouvoir être implémentées. Le propriétaire de produit doit passer du temps à rechercher chacune des fonctionnalités et à essayer de présenter en termes simples le besoin réel que chacune exprime. Utilisez des listes à puces ou des phrases simples, pour expliquer la fonctionnalité en détail. Nous voyons cela se produire principalement pendant ou après la réunion de planification du sprint, mais si des exigences sont connues avant la réunion, le propriétaire de produit peut avoir une longueur d’avance.
Décidez d’une définition de done
Au cours d’une réunion de planification de sprint, l’équipe choisit généralement ce qu’elle fera et livrera à la fin de cette itération de sprint. Il est impératif que les membres de l’équipe connaissent et conviennent d’une définition de done pour chaque histoire utilisateur ainsi que chaque tâche de chacune. Qu’il s’agisse d’une tâche de développement, d’une tâche de conception ou d’exécution de test ou d’une tâche de revue de livrable, tout le monde doit s’accorder sur une compréhension commune de ce que signifie « done » afin d’assurer une livraison fluide et aucun conflit à la fin du sprint.
Soignez les user stories
Chaque histoire utilisateur qui est mise en avant pour la planification du sprint doit être soignée, développée et détaillée avec les connaissances et les commentaires de l’équipe entière.
Lorsque les testeurs, les développeurs et le propriétaire de produit s’assoient ensemble et discutent d’une nouvelle fonctionnalité, de nombreuses nouvelles questions peuvent survenir de la part de l’équipe. Les questions portent souvent sur l’intégration avec les fonctionnalités existantes, le comportement de la fonctionnalité dans des cas spécifiques ou la manière dont le comportement doit être adapté pour différents types d’utilisateurs. Les cas spéciaux font également partie des critères d’acceptation définis dans l’histoire utilisateur pour la rendre complète.
Quelles que soient les questions, il est préférable de les poser au plus tôt et d’y répondre avant de choisir l’histoire utilisateur. Fondamentalement, cela signifie qu’une conversation doit avoir lieu pour chaque user story, afin que l’équipe puisse se comprendre et décider des critères d’acceptations définis et agréés par tous.
Ces sessions de « toilettage d’histoires » doivent avoir lieu avant la réunion de planification du sprint afin que pendant la planification, l’équipe sache exactement ce qui est requis de cette fonctionnalité et puisse donner de meilleures estimations et story points en fonction de sa complexité.
Commencez par le design
De nombreuses histoires utilisateur ont besoin de storyboards visuels ou de maquettes de l’interface utilisateur, et dans ces situations, les concepteurs d’expérience utilisateur ou UX designers peuvent avoir besoin d’être impliqués. Ces histoires doivent être sélectionnées un sprint à l’avance et allouées d’abord aux UX designers, afin qu’ils puissent construire les maquettes ou les images d’écran prêtes avant que la fonctionnalité ne soit sélectionnée pour le développement dans le sprint suivant. Cette approche facilite la communication et évite les retards pendant le développement.
De même, certaines histoires utilisateur peuvent nécessiter une recherche sur une nouvelle approche, une nouvelle technologie ou un nouvel outil avant de commencer, ou il peut être nécessaire de créer un design d’architecture complet pour une certaine partie avant de se lancer dans sa mise en œuvre. Dans de tels cas, la tâche de conception ou de R&D doit être créée et démarrée dans un sprint précédent, puis allouée au développeur ou à l’architecte principal au sein de l’équipe pour préparer les designs et résultats de recherche pertinents. Ils peuvent ensuite partager ces informations avec l’équipe afin que tout le monde soit prêt à commencer à travailler sur la mise en œuvre dans le sprint suivant.
Un propriétaire de produit doit être constamment à l’affût des histoires utilisateur qui peuvent nécessiter un travail de conception ou de recherche avant de les commencer, et avoir ces user stories distribuées aux personnes concernées avant le sprint pour s’assurer que la mise en œuvre sera fluide et que la livraison pourra avoir lieu à temps.
Nishi est une formatrice en entreprise, une passionnée agile et une testeuse dans l’âme ! Avec plus de 11 ans d’expérience dans l’industrie, elle travaille actuellement chez Sahi Pro en tant qu’évangéliste et responsable des formations. Elle est passionnée par la formation, l’organisation d’événements et de rencontres pour une communauté de test, et a été conférencière lors de nombreux événements et conférences de test.
Consultez son blog où elle écrit sur les derniers sujets dans les domaines Agile et Testing.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.
Notre équipe se donne des objectifs trimestriels, que nous décomposons en exigences dans des sprints bimensuels. En tant que paradev (un paradev iest quiconque dans une équipe de développement ne fait pas que programmer) dans mon équipe, je travaille étroitement avec notre Product Owner pour écrire et déterminer la priorité de ces exigences.
Nous avons à l’origine commencé par utiliser la méthode de MoSCoW pour déterminer la priorité de nos exigences : Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.
Nous avons rapidement commencé à remarquer que la terminologie (Must have, Should have, Could have, et Won’t have) ne marchait pas idéalement dans notre contexte et nous pensions que cela causait beaucoup de frictions sur comment nous donnions la priorité et la communiquions à l’équipe. Il ne semblait pas naturel de classifier des choses comme, Must, Should, Could, Won’t car non corrélées à ce sur quoi nous devrions (Should) travailler.
En quelques sessions nous avons inventé nos propres groupements pour nos exigences en nous basant sur quand nous voudrions les voir dans notre produit : Maintenant, Ensuite, Plus tard, Jamais. Nous avons continué à utiliser ces quatre termes et nous avons constaté qu’ils ont été très bien adoptés par l’équipe car il est très naturel pour nous de penser avec ces groupements.
Le plus grand avantage à utiliser Maintenant, Ensuite, Plus tard, et Jamais, est qu’ils se transfèrent naturellement dans notre plan de produit et dans la planification de sprint.
J’ai fait quelques recherches en écrivant ce billet et j’ai trouvé Maintenant, Ensuite, Plus tard comme une approche de ThoughtWorks datant de 2012, mais je n’ai pas trouvé de lien qui contienne Jamais que nous avons trouvé très utile pour lister ce que nous reconnaissons que nous ne ferons pas.
Comment abordez-vous l’établissement de la priorité de vos exigences ?
La tendance à supposer avec confiance que les autres partagent notre mode de pensée, nos attitudes et nos croyances est connue sous le nom de biais de projection.
Un effet connexe que nous avons déjà abordé sur ce blog est le biais de faux consensus qui pousse cette tendance un peu plus loin en nous faisant croire que les autres « sont également d’accord » avec nos points de vue.
Ce biais nous laisse de plus penser que nos habitudes et préférences resteront les mêmes au fil du temps. Nous projetons nos préférences actuelles dans l’avenir comme si nos goûts futurs correspondraient à nos goûts actuels.
En quoi sommes-nous concernés dans nos projets ?
Il y a des moments dans nos projets où il devient important de décider pour l’avenir. Et nous ne prenons pas toujours la meilleure décision. Le biais de projection devient un problème lorsque nous laissons les décisions prises en fonction de nos ressentis et préférences actuels affecter nos objectifs à long terme.
Lorsque vos commanditaires définissent leurs exigences impératives au début du projet, ils doivent anticiper à quel point celles-ci auront probablement évolué d’ici la fin du projet dans 3, 6 ou 18 mois par exemple. Se sont-ils projetés dans le futur ? En sont-ils capables ?
Le biais de projection peut aussi amener ces personnes à demander plus de fonctionnalités et de changements qu’elles ne peuvent en absorber sur la période. Cela revient à commander leurs desserts (des fonctionnalités non impératives) en début de repas alors qu’elles n’auront plus faim bien avant la fin du plat de résistance (les fonctionnalités critiques).
Comment éviter le plus possible ce travers ?
La priorisation des besoins et exigences est critique, que ce soit en approche prédictive comme en approche Agile. Il s’agit de ne pas prévoir plus de travail que réellement nécessaire, de prioriser le livrable qui va vraiment apporter des bénéfices concretsrapidement sur d’autres plus annexes. Il reste vrai qu’avoir la vue à long terme des changements que va apporter le projet est absolument critique et va guider le séquencement des travaux et l’échelonnement des livrables.
Ce biais peut-il nous être utile ?
Votre expérience de manager de projet peut vous aider grandement à utiliser les faiblesses de ce biais pour faire réfléchir vos clients et futurs utilisateurs de vos livrables ou votre product owner. De simples questions de votre part peuvent les amener à reconsidérer leur priorisation et à réfléchir à leur future situation.
Par exemple :
J’entends bien que cette fonctionnalité dans le portail client est aujourd’hui impérative car c’est notre principal parcours pour les utilisateurs Business to Business (B2B). Mais ne pensez-vous pas que l’arrivée des Application Programmable Interfaces (APIs) et des interfaces vocales pourraient changer la donne d’ici 12 mois ? Quels en seraient les impacts sur le parcours du client B2B ?
Nos processus de vente sont aujourd’hui très centrés sur des rencontres en face à face entre nos prospects et clients et nos vendeurs. La priorisation du déploiement de couteuses tablettes à notre force de vente est donc aujourd’hui particulièrement attractive pour accroitre leur productivité. Si la pandémie devait durer plusieurs semestres ou années et que les rencontres en face à face soient de moins en moins fréquentes, investiriez-vous toujours autant sur ces technologies ?
FDF est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Si vous saviez qu’il existe une approche structurée pour essayer des améliorations possibles, obtenir des retours rapidement et le faire d’une façon qui vous permette d’apprendre dans un environnement contrôlé et de construire sur vos succès, vous seriez probablement intéressés, non ?
Et bien cette approche existe ! Et c’est quelque chose que vous pouvez facilement apprendre et enseigner à votre entourage.
J’ai souvent rencontré des équipes qui aiment les longues Histoires Utilisateur. Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ? Les histoires plus grosses signifient une meilleure efficacité, non ? Pas nécessairement.
la propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.
Quand on parle de direction du développement d’un produit et de garantir que vous construisez ce dont l’utilisateur a en réalité besoin, le propriétaire de produit est la personne la plus importante pour l’équipe. Trouver la bonne personne pour ce rôle est crucial au succès du produit.
Il y a juste un problème : un bon propriétaire de produit peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici cependant trois qualités auxquelles vous devriez donner la priorité dans votre recherche.
Hexagon est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Les caractéristiques qui font un propriétaire de produit de qualité sont difficiles à lister, mais voici trois compétences ou attitudes auxquelles donner la priorité dans votre recherche.
Quand il s’agit de diriger le développement d’un produit et de s’assurer de vous construisez ce dont l’utilisateur a réellement besoin, le/la propriétaire de produit est la personne la plus importante pour l’équipe. Il y a juste un problème : un bon product owner peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici trois qualités auxquelles vous devriez donner la priorité dans votre recherche.
Cela peut sembler excessivement simpliste, mais généralement les produits réussissent ou échouent en fonction de l’efficacité du propriétaire de produit dans l’équipe. Cela arrive principalement parce que nous sous-estimons l’importance (et la difficulté) des différents aspects du Product Ownership dans le processus de création de produit.
Le rôle d’un propriétaire de produit couvre tout le spectre, de la découverte à la livraison et plus et donc le choix de la bonne personne pour ce rôle est beaucoup plus important que le coach Agile ou autres membres d’équipe.
la propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.
Cependant, nous avons tendance à penser aux logiciels comme étant des objectifs principalement techniques. Notre focus est trop souvent placé sur la qualité et la capacité des ingénieurs, l’architecture et la conception et nous dépensons un temps disproportionné sur les processus, l’optimisation et l’efficacité. Nous avons tendance à oublier que l’échec le plus commun et le plus répété de tous les produits logiciels (peu importe leur qualité, optimisation et efficacité, ou combien les ingénieurs sont qui les ont construits sont doués) est que si vous construisez le mauvais article, ce sera un échec.
Un produit parfaitement conçu mais inutilisé n’est d’aucune valeur.
L’histoire est pleine de grands produits qui ont raté l’objectif. Combien d’applications avez-que vous téléchargées sur votre téléphone que vous avez arrêté d’utiliser après les trente premières secondes ? Sans mentionner les innombrables produits qui échouent à jamais d’atteindre les mains de clients et dont nous n’avons jamais entendu parler.
Les produits de l’informatique interne de l’entreprise sont souvent coupables d’une idée erronée: L’assomption semble être que comme les clients seront forcés d’utiliser le produit, nous ne devons pas vraiment leur demander ce qu’ils veulent ni comment ils l’utiliseront. Aussi, nous finissons souvent par construire de « bons » produits qui ne répondent pas au besoin réel de l’utilisateur.
CertYou est partenaire de DantotsuPM
Considérez cette citation de Peter Drucker : “Il n’y a sûrement rien d’aussi inutile que de faire avec une grande efficacité ce qui ne devrait pas être fait du tout.”
Quand on parle de direction du développement d’un produit et de garantir que vous construisez ce dont l’utilisateur a en réalité besoin, le propriétaire de produit est la personne la plus importante pour l’équipe. Trouver la bonne personne pour ce rôle est crucial au succès du produit.
Il y a juste un problème : un bon propriétaire de produit peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici cependant trois qualités auxquelles vous devriez donner la priorité dans votre recherche.
1. La capacité à différencier ce qui est nécessaire de ce qui est voulu
Une partie significative du rôle de propriétaire de produit est d’identifier ce qui est nécessaire pour résoudre les problèmes des utilisateurs, répondre à leurs besoins, leur permettre d’être meilleurs dans leur travail, ou maximiser leur amusement ou relaxation. Le rôle consiste avant tout en la compréhension du problème et la création d’une vision de comment ce problème pourrait être résolu. Pas la solution technique, mais le vrai besoin.
La raison pour laquelle cette compétence est si complexe est que les utilisateurs savent rarement de quoi ils ont besoin. Typiquement la vision d’un utilisateur est contrainte par ce qu’il fait actuellement. En conséquence, beaucoup de produits reviennent à retravailler un système papier existant ou une vieille approche.
Un faible propriétaire de produit donne aux clients ce qu’ils veulent ou ce qu’ils ont demandé mais un bon propriétaire de produit écoute et observe et peut mélanger veut et doit pour résoudre le problème du client et lui donner ce dont il a vraiment besoin.
Ce point nous mène à une citation intéressante par Henry Ford : “si j’avais demandé aux gens ce qu’ils voulaient, ils auraient répondu des chevaux plus rapides.”
Nous voyons souvent des arriérés de produits pleins d’histoires utilisateur qui sont vraiment juste des demandes client non filtrées. Il est plus facile de faire ce que le client demande que de trouver ce qui est en réalité nécessaire. Car cela exige typiquement de l’expérimentation, des retours utilisateurs, des conversations et de l’observation.
Cela peut aussi se produire quand les managers de département décident ce dont leur équipe a besoin ou veut sans impliquer les membres dans la discussion. Mais un bon propriétaire de produit passera du temps avec les utilisateurs du produit et verra comment ils l’utilisent. Un propriétaire de produit avec créativité, initiative et vision pour créer un grand produit vaut son pesant d’or.
2. La compréhension de ce qui exigée pour créer une application réussie
Peut-être à cause de l’accent placé sur le point numéro un, les sociétés choisissent souvent quelqu’un du côté business ou métier pour devenir le propriétaire de produit, car on voit leur connaissance du business comme primordiale et, dans des nombreux cas, la seule et unique qualification pour le rôle. Et pire encore, on leur demande souvent de tenir ce rôle en plus de leur travail habituel.
Cependant, les excellents propriétaires de produit comprennent quoi construire, mais sont aussi familiers avec le processus de développement. Ils comprennent les flux, les implications de la dette technique, l’automatisation et les tests. Ils comprennent aussi à quel point il est crucial de mettre le logiciel entre les mains d’utilisateurs aussitôt que possible.
En général, des propriétaires de produit « business » manquent souvent de cette connaissance et de cette expérience et ils suivront par erreur le désir d’un produit entièrement fonctionnel plutôt que d’apprécier la valeur de retours rapides. Beaucoup essaient d’inclure chaque fonction imaginable plutôt que de travailler vers un jeu de fonctions minimal pour obtenir des retours et tirer de la valeur le plus tôt possible.
Que préfèreriez-vous avoir ? Un propriétaire de produit expérimenté avec zéro connaissance business, ou un expert business avec zéro expérience de livraison de logiciel ? Avant que vous ne répondiez, considériez ceci : la connaissance business peut être obtenue par une discussion efficace, l’observation et les retours. Cependant, la compréhension d’un bon cycle de développement logiciel agile est beaucoup plus difficile à apprendre et il n’y a rien qui remplace l’expérience.
Typiquement les meilleurs produits résultent d’expériences, de tests et de retours, avec une volonté à être flexibles dans les réponses. Les propriétaires de produit posent des priorités et interprètent la vision, donc ils ont plus d’influence sur la création de produit que qui que ce soit d’autre. Leurs choix de priorités peut profondément impacter la valeur et la qualité du produit. S’ils manquent de compréhension sur l’importance des tests, des retours utilisateurs et des bons principes de développement logiciel, ils peuvent entrer en conflit et semer le désaccord dans une équipe.
Hexagon est partenaire de DantotsuPM
3. Une communication efficace avec les parties prenantes tant techniques que business
Pour terminer, il y a un énorme besoin de communication efficace. L’importance ne peut pas en être exagérée.
Les excellents propriétaires de produit écoutent, observent, explorent et réfléchissent. Ils demandent des retours, lisent entre les lignes et observent le langage corporel. Quand il s’agit de comprendre l’utilisateur, ils portent une grande attention aux détails et recherchent attentivement des points de douleur et de satisfaction. Ils cherchent les meilleures façons de servir leurs utilisateurs.
La plupart d’entre nous pensent à la communication comme à une conversation, mais pour un propriétaire de produit, l’observation et l’écoute sont aussi très importantes. Avoir de l’empathie avec l’utilisateur et le client est critique. Il est impératif de comprendre leur domaine et d’utiliser leur vocabulaire pour communiquer. Si vous ne comprenez pas certains termes, il est essentiel de développer une attitude attentive et de poser des questions pour montrer votre intérêt, votre envie d’apprendre et votre engagement.
Un grand propriétaire de produit apprend à dire non avec respect et d’une manière qui indique qu’il comprend ce qui est demandé. Grâce à cela, on ne devrait pas voir un bon propriétaire de produit comme un obstacle ou une barrière, mais un guide vers de bonnes décisions. Le mot « Non » devrait être délivré d’une façon qui laisse le client confiant que cette décision est juste, même si ce n’est pas ce qui a été initialement voulu et que le propriétaire de produit livrera le meilleur produit en fonction de tous les paramètres.
Au contraire, si le propriétaire de produit choisit de dire oui, il devrait être capable d’en transmettre les implications. Les propriétaires de produit devraient avoir un certain nombre d’outils qui peuvent aider les gens à comprendre leurs décisions.
Le propriétaire de produit doit aussi communiquer avec l’équipe de développement et doit comprendre des termes techniques de développement pour qu’ils puissent avoir une pleine compréhension de la mise en œuvre technique, même s’ils n’ont pas d’autorité sur comment les choses sont faites. Autrement dit, ils devraient avoir un fort intérêt dans la compréhension du processus.
Ils doivent aussi être capables de communiquer des besoins business et des termes métier d’une façon qui donne du sens à l’équipe de développement. Être respectés et compris tant par le business que l’équipe technique est un exploit majeur et comme nous le savons, tout groupe parle dans le jargon que seuls ses membres comprennent. Ces signes verbaux que l’on doit expliquer à un étranger peu familier peuvent démoraliser l’équipe. Il est important de ne pas sous-estimer cette capacité.
Les propriétaires de produit ont aussi besoin de créativité pour communiquer des idées de design, ou, si les idées viennent d’autres, la capacité de comprendre cette créativité et de la transmettre aux équipes business et techniques. Il en va de même pour les parties prenantes principales (mis à part les utilisateurs). Ce groupe finance généralement le produit et ils veulent voir la progression et un bon management de leur investissement, donc ils peuvent demander des prévisions et insister même sur des engagements fermes.
Et si un produit doit être vendu, il est probable que le propriétaire de produit devra être impliqué avec les ventes et le marketing, ce qui amène tout un train d’autres compétences et de problèmes de communication, y compris la compréhension des implications sur le marché.
En prenant tout ceci en considération, nous avons maintenant chargé notre propriétaire de produit du besoin de communiquer avec les gens expérimentés qui prennent des décisions financières, d’exprimer les risques et les prévisions de façon concise, mais significative et transparente, informative et confiante. Un propriétaire de produit devrait tenir bon sur sa position et parler vrai face aux autorités et au pouvoir.
Bref, un grand propriétaire de produit est un maître communicateur, a un désir insatiable de connaissance et cherche toujours à comprendre et à être compris.
Recherchez et appréciez les bons Propriétaires de Produit
Le jeu de compétences d’un bon propriétaire de produit est large et diversifié, cependant les bons font paraître cela facile. Si vous avez un état d’esprit de propriétaire de produit, il est probable que vous avez déjà de bonnes compétences de communication et que vous aimez en apprendre davantage dans de nombreux domaines.
Il est aussi probable que vous êtes le genre de personne qui donne tout pour livrer un produit et se délecte des réactions, aime la flexibilité et le changement et ne se démotive pas à la pensée de devoir refaire quelque chose pour l’améliorer.
La résolution de problèmes est un challenge et être capable de voir au-delà de l’évident, d’aller chercher l’information chez les utilisateurs et présenter ensuite quelque chose de grand peut être une joie. Cela ne signifie pas, cependant, que ce n’est pas incroyablement difficile, accablant de temps en temps, tristement inapprécié et peut-être sous-payé. Mais un grand propriétaire de produit réussira malgré ces points douloureux.
Le propriétaire de produit est la clé de voute d’un grand produit et nous devrions les rechercher et les utiliser convenablement. Vous serez stupéfié de ce qui peut être réalisé avec la bonne personne dans ce rôle.
FDF est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Quand nous manageons des projets en une approche de livraison prédictive, l’identification des dépendances et leur suivi est fait lors de la grande planification amont en utilisant les activités après décomposition des tâches et la sagesse collective des membres de notre équipe et des principales parties prenantes. Si un changement majeur d’approche ou de portée de solution est identifié, on considère les impacts et nouvelles dépendances lors de l’analyse de la demande de changement.
Matchware est partenaire de DantotsuPMVoici le diagramme du Modèle Scrum
Mais sur ces projets qui suivent un cycle de vie adaptatif, cela devient un peu plus compliqué. Étant donné la nature émergente des exigences et du design, nous sommes seulement capables de voir les dépendances dans la lumière « des phares » de notre équipe et ceux-ci pourraient seulement nous montrer les deux semaines à venir de travail. Une équipe pourrait avoir considéré “Toutes les dépendances ont-elles été identifiées et capturées ?” dans sa définition de Ready (prêt) mais cela ne signifie pas toujours qu’il est possible de satisfaire cette dépendance dans les temps.
CertYou est partenaire de DantotsuPM
Nous nous efforçons toujours de construire une équipe qui possède toutes les compétences et l’autorité nécessaire pour délivrer la pleine portée du produit ou du projet.
Mais parfois, nous avons besoin d’un expert du sujet pour un petit sous-ensemble des fonctionnalités du livrable et si nous n’identifions pas ce besoin assez tôt, nous ne serons pas capables de livrer ces fonctions au bon moment. De plus, construire une équipe complète dans de grandes organisations est souvent difficile car il y a des équipes en place avec lesquelles travailler pour construire et livrer des fonctionnalités spécifiques, mais elles ne seront pas nécessairement disponibles à la demande.
Une façon de réduire les risques associés aux dépendances qui seraient identifiées trop tard est une combinaison de revue des User Stories avec une planification avancée.
La revue des User Stories fournit une occasion de rassembler les partenaires clés de livraison et de contrôle pour considérer les histoires à un haut niveau avec le Product Owner et l’équipe de développement. Cette revue donne aux partenaires externes une chance d’indiquer quelles histoires les intéressent et aidera l’équipe à savoir avec qui elle doit se synchroniser pour compléter l’une de ces histoires. En fonction de combien ces histoires remontent dans la Story Map, ils comprendront comment elles pourraient devoir être engagées. Les membres de l’équipe peuvent aussi commencer à identifier et capturer les interdépendances entre plusieurs histoires individuelles pour aider le Product Owner dans la priorisation du Product Backlog.
Comme les histoires avec des dépendances commencent à remonter dans le product backlog priorisé, l’équipe peut activement entrer en contact avec les partenaires externes pour demander leur participation un sprint ou deux à l’avance.
La planification est une activité récurrente dans les approches adaptatives car sans cela, un partenaire externe dont votre équipe a besoin va probablement répondre par le vieux cliché : “un manque de planification de votre part ne constitue pas un cas d’urgence de ma part.”
partagez ce billet avec vos amis, collègues et relations professionnelles
Négocier sur le séquencement des livrables est souvent préférable à dire non d’emblée à une nouvelle demande de changement.
Idem au niveau du portefeuille de projets
Est-ce le bon moment pour lancer un nouveau projet ? Devrions-nous renoncer à un projet ? Ou devrions-nous temporiser un peu et positionner ce projet dans le portefeuille de projets à venir ?
Hexagon est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Je ne sais pas pour vous, mais j’ai remarqué que nous indiquons rarement une date ou raison de péremption sur nos besoins utilisateurs et autres user stories…
Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.
Qu’en pensez-vous et comment traitez-vous ce problème ?
Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?
Est-ce périodiquement lors de grands « ménages » saisonniers ?
Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Ils ne sont jamais finis – Nous travaillons sur nos produits, aujourd’hui, « pour toujours ». Il n’y a pas de date de fin fixe pour les fonctionnalités que nous construisons. Cela semble étrange ? Demandez-vous : « Quand Netflix sera-t-elle terminée ? » Remplacez « Netflix » par n’importe quelle autre entreprise moderne et il devient clair que nos produits et services vivent pour toujours. Il n’y a pas de date de fin explicite. À un moment donné, nous décidons qu’ils ne fournissent plus assez de valeur ou que l’investissement nécessaire pour en extraire plus de valeur n’en vaut pas la peine et nous passons à autre chose. D’ici là, nous devons maintenir et optimiser ces systèmes en permanence.
Ils fournissent une rétroaction continue et une opportunité d’apprentissage – Parce que ces systèmes sont toujours en vol, offrant de la valeur (ou non) et fournissant un service aux clients, nous apprenons continuellement à quel point ils fonctionnent. Nous avons maintenant une opportunité incroyable de déterminer où concentrer au mieux nos efforts pour améliorer continuellement ces systèmes pour nos clients.
La nature moderne des logiciels se concentre sur le déploiement de la plus petite quantité de code qui offre la plus grande quantité de valeur. Pourquoi ? Parce que nous devons vivre avec ce code pour toujours. Notre nouvelle mesure du succès est le comportement des clients (ou les résultats). Les comportements et les changements dans ces comportements que nous voulons voir chez nos clients sont nos nouvelles mesures du succès. La façon dont nous réalisons ces changements de comportement devient la variable. Le produit est la variable.
Il existe une combinaison infinie de code, de conception, de proposition de valeur et de modèle commercial qui peut apporter les changements de comportement souhaités. Nous mélangeons, associons et expérimentons différentes façons de rendre notre offre plus précieuse pour nos clients. L’objectif fixé est un changement dans le comportement de nos clients. Nous continuons à ajuster et (espérons-le) à améliorer le produit jusqu’à ce que nous atteignions le niveau souhaité de changement de comportement.
Accepter ce changement dans la façon dont nous manageons nos équipes et nos organisations ne sera pas facile. C’est un profond changement de mentalité. Il est facile de considérer le produit comme l’objectif. Nous pouvons clairement écrire ce que nous croyons qu’il devrait faire, le concevoir pour le faire et le livrer. Malheureusement, cela ne garantit pas notre succès. Cela ne garantit que le déploiement du code (et la dette technique subséquente). La variabilité des produits peut effrayer les parties prenantes. « Qu’est-ce qu’on construit ? », demanderont-ils. En fin de compte, nous devons changer cette question en : « Comment tendons-nous vers les changements de comportement souhaités ? » Cela prendra du temps, mais c’est inévitable. Nos socles technologiques modernes l’exigent.
Limitez le nombre d’éléments dans le Product Backlog à tout moment. La limite WiP peut éviter la surcharge et encourager l’équipe à terminer les objets avant d’en prendre de nouveaux.
Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.
DantotsuPM.com 