Agile, c’est aussi et surtout commencer par faire simple avant d’améliorer, d’automatiser et d’optimiser.

Je vous l’accorde volontiers, il ne s’agit pas avec Agile d’oublier que la complexité est bien réelle ni de l’ignorer…

Mais, il faut savoir commencer petit puis apprendre en marchant si l’on veut tirer rapidement bénéfice des avancées même modestes.

Par exemple, vous pouvez trouver acceptable d’avoir des paramétrages codés en dur dans la première version du logiciel, ou bien des capacités réduites de personnalisation, ou encore un seul profil/persona utilisateur…

Ou des choix de coloris limités pour vos premières productions.

CSP est partenaire de DantotsuPM

Devrions-nous adopter certaines des approches de « triage » utilisées dans les services des urgences des hôpitaux pour définir nos MVPs ?

Livre sur Amazon

Darria Long, médecin urgentiste, explique les principales leçons tirées des urgences de l’hôpital sur la gestion du stress, du chaos et de la vie.

Le Dr. Darria Long Gillespie est un médecin d’urgence formé à Yale et Harvard, auteur du livre à succès « Mom Hacks ».

Les billets DantotsuPM.com les plus lus à la rentrée 2019

Comment éviter de stresser tout en utilisant les avantages de l’agilité, telle était la ligne directrice de Septembre.

Déstressez votre équipe projet ainsi que vous-même : 8 choses simples à faire

Ne soyez pas un manager de projet passif face au stress des membres du projet et de ses parties prenantes.

Il y a des actions de prévention simples que vous pouvez initier et mettre en œuvre pour contrer les facteurs de stress.

FDF est partenaire de DantotsuPM

Déstressez votre équipe projet : Clarifiez les rôles et responsabilités de chacun

Ne pas savoir ce qui est attendu de nous est stressant. Ceci est d’autant plus vrai que nous évoluons de plus en plus souvent dans des équipes transverses et multi disciplinaires. Il n’est pas rare que les membres de l’équipe projet aient peu d’occasions de se rencontrer en face à face pour faire connaissance. Voici une source de stress que la ou le manager de projet peut attaquer de front.

CSP est partenaire de DantotsuPM

Comment vous protéger d’énergies négatives en 6 façons puissantes ?

Il n’est jamais facile d’être confronté au négativisme. Mais en plus, cela peut être carrément toxique et nuisible, favorisant une mentalité de cynisme, de fatalisme et même de défaitisme.

Si vous êtes entourés d’énergie négative qui provienne d’un collègue, associé, ami, ou membre de votre famille, vous devez apprendre à vous protéger et à ne pas vous y laisser emporter.

Voici six stratégies que vous pouvez utiliser pour vous protéger !

Comment garder les pieds sur terre en ces  temps agités : 12 habitudes simples et réalisables à tester et adopter ?

Commencez dès aujourd’hui à développer les habitudes et les stratégies qui vous maintiendront bien campé sur vos deux pieds quand  tout autour de vous chavire. Nous travaillons tous toujours plus longtemps et stressons davantage, plus occupés que jamais. Mais il est vraiment possible de manager tout ce qui arrive, de rester les deux pieds sur terre même quand tout autour de nous semble échapper à tout contrôle.

CertYou est partenaire de DantotsuPM

MVE et MVP et MMF : Quelle est la différence ?

Livrer souvent un produit certes incomplet mais utilisable et de valeur c’est Agile !

Personnellement, je ne connaissais ni MVE ni MMF et je trouve que ces concepts sont utiles pour préciser ce que l’on cherche à réaliser et surtout ce que l’on peut ou pas livrer aux clients et utilisateurs. L’idée des spikes sur une journée pour préciser les besoins me parait également très intéressante.

Dans les projets liés à la conception de produits et services, la priorisation est plus Art que Science

Il n’y a pas d’approche de priorisation foncièrement mauvaise ni systématiquement bonne mais il y a des incontournables.

Prioritization is More Art Than Science

http://www.cleverpm.com/2018/10/05/prioritization-is-more-art-than-science/ par The Clever PM

Un challenge très commun chez les managers de produit de tous niveaux d’expérience est de comprendre et mettre en œuvre une certaine forme de processus répétable autour de la priorisation.

Certaines personnes prennent une approche très légère, elles font des décisions basées sur leur propre expérience, données et conviction sur la direction du produit.  D’autres prennent une approche beaucoup plus rigoureuse, appliquant des scorecards et autres mesures « objectives » à travers une pléthore de différentes métriques potentielles.

Je dois ici vous dire qu’il n’y a rien de mauvais avec n’importe laquelle de ces approches, mais il m’est aussi apparu clairement au cours de mes années de  manager de produit qu’il n’y a aucune solution miracle pour vous assurer que vos décisions de priorisation seront bonnes plus souvent que mauvaises.

Trop compter sur des systèmes et des scores aboutit souvent seulement à un faux sentiment de sécurité que « le processus » était bon, quand en creusant vous constaterez que ces “scores objectifs” ne sont rien plus qu’un système avec lequel jouer.

Il y a cependant 3 choses dont je pense que chaque système de priorisation devrait tenir compte.  Aussi, sans plus de cérémonie, discutons valeur, difficulté et instinct

#1 – Prioriser c’est prendre en compte la valeur

Si nous pensons au problème racine que nous essayons de résoudre avec nos efforts de priorisation, ce devrait être que nous essayons de livrer la plus grande valeur possible, aussi rapidement que possible, en apportant des bénéfices à nos utilisateurs finaux et clients.  Si c’est votre but (et si ça ne l’est pas, honte à vous !), alors l’un des facteurs les plus importants à considérer dans vos efforts de priorisation est la valeur que cette chose apportera vraiment.

Apporter la plus grande valeur possible, aussi rapidement que possible à nos clients.

Certains lui donnent une valeur numérique, d’autres utilisent une valeur monétaire — quoique ce soit qui marche, tant que vous considérez combien de valeur vos efforts vont délivrer.  Cependant, baser vos décisions seulement sur la valeur marchande peut souvent aboutir à une dépriorisation de la dette technique et des investissements d’infrastructure. S’il vous plaît, pour l’amour de toute puissance supérieure en laquelle vous croyez, n’en soyez pas la victime.  Bien que la dette technique et l’infrastructure pourraient ne pas avoir la valeur évidente pour le client, échouer à investir le nécessaire dans celles-ci causera l’échec de votre produit à un certain point critique pour un certain client critique.  Si vous utilisez la valeur pour le client comme unique ou principale métrique, assurez-vous s’il vous plaît que vous avez un groupe de taches séparé pour le travail qui vous permet de rembourser votre dette technique et investir dans des améliorations d’infrastructure.  Ayez confiance en moi, vous respirerez beaucoup plus librement en sachant qu’il n’y a pas un certain item technique inconnu qui va causer un effondrement général au plus mauvais moment possible.

#2 – Prioriser c’est prendre en compte la difficulté

Alors que la valeur pour le client est importante, il est également important que nous comprenions la quantité de travail qui va entrer dans toute nouvelle fonctionnalité ou amélioration de notre produit.  Peu importe combien la valeur client est incroyablement élevée, si vous ne parviendrez jamais en réalité à compléter le travail à temps pour capitaliser sur cette opportunité.  Trop souvent, des managers de produit décident seuls de la difficulté de quelque chose sans impliquer quelqu’un côté développement, support, ou équipes de livraison : C’est une erreur de débutant que même les managers de produit avec plus de 10 années d’expérience font tout le temps (oui, je la fais aussi parfois).

Attention au mirage venu de la seule imagination du manager de produit sans réelle prise en compte de la faisabilité.Évaluer l’effort exigé pour ajouter une  fonctionnalité ou une capacité est plus précis quand réalisé en impliquant les gens qui feront effectivement le travail. Ils connaissent leurs capacités mieux que vous, ils connaissent la technologie mieux que vous, ils connaissent le code existant mieux que vous, etc.  Cela ne signifie pas que vous devez tout décomposer en tâches, ou même en histoires utilisateur mais cela veut dire que vous devez consulter vos équipes techniques pour avoir une meilleure idée de combien une fonctionnalité est « grande », ou combien de temps il leur faudrait pour la produire.  Quand nous devons évaluer la difficulté de résoudre un problème, assurons-nous que nous nous basons sur des experts et n’utilisons pas simplement nos propres opinions qui seront plus souvent fausses que correctes.

#3 – Prioriser c’est aussi suivre son instinct

Des données objectives et quantitatives sont des apports épatants dans tout processus de priorisation et plus de données vous pouvez obtenir, meilleures vont probablement être vos décisions.  Mais il y a aussi un aspect inexprimable à la priorisation qui fait de ce processus tout entier plus un art qu’une science.  Franchement, si tout ce qu’il fallait était des données objectives déposées dans un tableau qui donne un score alors vous n’auriez pas vraiment besoin de managers de produit pour mener vos efforts de priorisation.  Vous auriez un système basé sur l’Intelligence Artificielle qui considère vos idées, prend toute les données disponibles et vous dit exactement que faire et précisément quand le faire.  Heureusement pour ceux d’entre nous qui avons choisi le Management de Produit pour carrière, ce n’est pas le cas.

Il y aura toujours une partie d’analyse subjective quand on regarde les données et prend des décisions sur si vraiment la direction que nous indiquent  les données signifie réellement quelque chose dans le schéma d’ensemble.  J’ai travaillé dans des environnements où les décisions ont été prises par des résultats d’étude Six Sigma, des tableaux, un processus « objectif » de collecte de données et celles-ci ont poussé des fonctionnalités que personne ne voulait ni ne se souciait et en gaspillant des ressources techniques.  L’équipe de Management de Produit savait qu’il y avait de meilleures options, savait qu’il y avait d’autres données subjectives pour soutenir ces efforts, mais a été forcée de se taire et de “laisser marcher le système”.  Mais il n’a pas fonctionné, parce qu’il a ignoré l’expérience globale que de bons managers de produit apportent à la table.  Un bon manager de produit sait quand insérer l’instinct et l’expérience dans l’équation et changer ou réarranger des choix basés seulement sur des données « objectives ».

Sans instinct, sans le ressenti dans ses tripes, seuls les choix apparemment les plus sûrs seront adoptés et l’innovation jetée par la fenêtre.

Comment évaluer les idées de nouveaux produits ?

Voici les 5 questions à poser pour déterminer si une nouvelle idée de produit mérite de le construire.

The 5 questions to ask to determine if a new product idea is worth building.

http://secretpmhandbook.com/how-i-evaluate-product-ideas/ par Nils Davis

Les gens me demandent souvent : “Bonjour, j’ai une idée de produit. Puis-je vous l’envoyer et avoir votre avis ?”

Bien sûr, je réponds positivement.

Ils m’exposent l’idée et c’est d’habitude “une chose technique pour une sorte d’équipe.”

Et ma réponse est, “Bien, cela semble intéressant, mais…” et ensuite je pose quelques questions. Les réponses à ces questions me disent si l’idée est bonne.

Quelles sont ces questions?

  1. A qui est destiné ce produit?
  2. Pourquoi le veulent-ils ? Quel problème résout-il pour eux ?
  3. Comment résolvent-ils ce problème aujourd’hui ?
  4. Qu’est-ce qui ne va pas avec leur solution actuelle ?
  5. Pourquoi votre produit est-il une meilleure solution pour eux ?

Tout d’abord, ils doivent connaitre les réponses à ces questions. Et, idéalement, ils ont parlé à de vrais gens qui rencontrent ce problème pour obtenir ces réponses.

Ces questions les concentrent sur “l’espace problème”. Avant de créer une solution, ils doivent s’assurer qu’il y a bien des personnes qui ont ce problème et qui payeront pour le résoudre.

Avant de dépenser des ressources sur un nouveau produit, assurez-vous qu’il y a de vraies personnes qui sont confrontées au problème que vous voulez résoudre et qu’ils payeront pour une solution.

Mais que je découvre d’habitude qu’ils ne connaissent pas les réponses à ces questions et que les réponses qu’ils fournissent ont été composées par eux-mêmes.

Ce qu’ils ont est “une solution à la recherche d’un problème”. Malheureusement, c’est la meilleure façon de créer une société qui échouera.

Que faire si vous avez une brillante idée de nouveau produit ?

Ma recommandation à quiconque a une idée de nouveau produit : Sortez et obtenez des réponses du monde réel à ces questions.

MVE et MVP et MMF : Quelle est la différence ?

Livrer souvent un produit certes incomplet mais utilisable et de valeur c’est Agile !

Personnellement, je ne connaissais ni MVE ni MMF et je trouve que ces concepts sont utiles pour préciser ce que l’on cherche à réaliser et surtout ce que l’on peut ou pas livrer aux clients et utilisateurs. L’idée des spikes sur une journée pour préciser les besoins me parait également très intéressante.

MVE and MVP and MMF: Defining the Difference

https://blog.gurock.com/mve-and-mvp-difference/  par Catherine Nest

Source : Egg Lighting

La promesse des approches agiles est de livrer quelque chose souvent. Nous livrons, ainsi nous pouvons obtenir des réactions et discuter du reste à faire avec notre client (ou le Propriétaire de Produit / Product Owner). Et, donc nous pouvons évaluer notre processus et notre travail d’équipe tout le temps.

Trop souvent, les gens pensent aux fonctionnalités comme la somme de tout ce qui pourrait être dans ce périmètre. Cependant, nous en avons des alternatives à ce « tout » avec une variété de minimums.

Définissez les divers Minimums

Nous avons beaucoup de « minimums » possibles quand nous pensons aux histoires et plans de travail :

  • MVE, Minimum Viable Experiment – Expérience Viable Minimale : une histoire fournit des réactions pour l’équipe et le propriétaire de produit.
  • MVP, Minimum Viable Product – Produit Viable Minimal : une histoire ou un jeu d’histoires qui apportent assez de fonctionnalités pour que le client puisse les utiliser, même si ce ne sont pas les pleines fonctionnalités.
  • MMF, Minimum Marketable Feature – Fonction Commercialisable Minimale : le plus petit morceau de fonctionnalité qui le client considère de valeur.

Les MVEs peuvent être utiles quand vous voulez savoir si vous devriez même songer à cette partie d’un jeu de fonctionnalités.

Une équipe à la société Acme se débattait avec l’ensemble de fonctionnalités appelé « Rapports ». La fonctionnalité couvrait plusieurs grands rapports : ventes par géographie, par type de produit, agrégées par plusieurs clients et autres.

L’équipe savait qu’elle avait besoin d’une base de données, d’un système de production configurable et de sécurité/protection des données, parce que les clients pourraient accéder directement à certains de ces rapports. Et, chaque client devait avoir ses données protégées. Aucun client ne pourrait voir des données d’autres clients. Ils savaient qu’ils auraient besoin d’au moins deux niveaux de protection pour les clients et en interne à leur organisation.

En essayant d’écrire l’histoire dressant la liste de fonctionnalités des rapports, ils avaient créé plus de 20 histoires, juste pour les rapports client. Ils ont alors décidé qu’ils avaient besoin d’un MVE pour voir ce quels étaient les besoins minimaux pour les rapports clients. Peut-être sur-analysaient-ils le jeu minimal de rapports clients.

Comme ce produit exigeait de la sécurité, tant le MVP que le MMF nécessitaient une base de données avec des fonctionnalités de management de la sécurité. L’équipe savait que pour la base de données, ils auraient probablement besoin de données avant de créer un schéma pour cette base.

Ils ont finalement choisi d’expérimenter avec des données simulées pour voir de quoi les clients auraient vraiment besoin. Puis, ils pourraient élaguer l’arriéré d’histoires.

Les expérimentations créent un accord commun sur ce qui est important

Quand l’équipe a créé son histoire utilisateur originale pour des rapports clients, les membres avaient identifié trois niveaux de sécurité : le vendeur chez le client, le directeur commercial du client (ou tout autre membre de la direction) et les personnels internes de gestion de produit et commercial. Acme avait besoin d’informations sur ses clients et les clients de la sécurité nécessaire pour l’un et l’autre, c’est pourquoi il y aurait des niveaux différents de sécurité.

L’expérimentation initiale était simple : Sur un petit jeu de produits, comment les clients avaient-ils besoin de visualiser les données ?

L’équipe a pensé à simuler les rapports dans un fichier informatique. Puis, un testeur a suggéré qu’ils créent plutôt les prototypes sur papier car ils seraient faciles à changer instantanément, si nécessaire.

L’équipe (incluant le Product Owner) a passé une heure à créer une variété de prototypes papier et de flux de travail qu’ils pensaient que le client voudrait. Ils ont appelé le chef de produit qui avait rencontré un client la semaine précédente. Ils lui ont déroulé les flux.

Le chef de produit a accepté le premier flux et a rejeté les trois suivants et a expliqué pourquoi. Les explications ont surpris tant le Product Owner que le reste de l’équipe. Ils ont appris beaucoup de cette expérimentation et furent capables de reporter à plus tard un certain nombre d’histoires utilisateurs sur les Rapports – le tout en un seul jour de travail.

Puis, ils ont eu besoin de considérer le schéma de la base de données. Ils savaient qu’ils n’auraient pas de MVP sans la sécurité nécessaire. Cela signifiait qu’ils devaient embarquer non seulement la sécurité, mais aussi sa performance.

Les Spikes ont aidé toute l’équipe à apprendre ensemble

Ndlt : 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é.

Copyright 2000 Don Wells

Cette équipe avait essayé les spikes dans le passé et les avait appréciées.

Ils avaient un flux typique
  • L’équipe entière se rencontre 20 minutes maxi le matin (à 9 :00) pour passer en revue l’histoire. L’équipe a souvent besoin de seulement 5 minutes, mais on y alloue 20 minutes.
  • L’équipe décide comment travailler ensemble. Dans ce cas spécifique, deux développeurs travaillent en paire sur le schéma, deux autres membres de l’équipe sur les tests automatisés et l’autre développeur s’assure qu’il créée des outils pour que les testeurs puissent vérifier les résultats dans la base de données. Ils décident de développer et tester directement dans la base avant l’interface utilisateur.
  • L’équipe est séparée en ses sous-groupes et travaille pendant une heure.
  • Toutes les heures, ils se réunissent 5minutes pour un point rapide. Quelqu’un a-t-il été bloqué ? Tout se passe-t-il comme prévu ? Quelqu’un aurait-il besoin d’aide ? Quelqu’un a-t-il terminé et pourrait aider les autres ?

Leurs réunions n’étaient pas des standups traditionnels, où trop souvent, l’équipe se concentre sur la personne. Ces rencontres ont permis aux membres d’équipe de se concentrer sur le travail.

Au point rapide, l’équipe décide si elle a besoin de modifier les sous-équipes pour améliorer le flux du travail. Ils font ceci à chaque heure (avec une pause déjeuner) jusqu’à 16:00 ou quand ils ont terminé, le premier des deux.

L’équipe s’ arrête à 16:00 pour plusieurs raisons
  1. Ils sont fatigués. Ils se sont concentrés toute la journée sur du travail difficile.
  2. S’ils ne peuvent pas « finir » le spike dans la journée, le travail nécessitait probablement plus que même deux journées. Ils ont besoin de se regrouper et de replanifier.
  3. S’ils ont terminé, ils peuvent expliquer ce qu’ils ont découvert au Product Owner.

À la fin de la première journée, ils se sont rendus compte qu’ils auraient besoin d’autres scénarios pour la performance et la sécurité. Il était le temps de discuter de comment ces aspects fonctionnaient ensemble et séparément avec le Product Owner.

Que pourraient-ils reporter en matière de performance, d’autant plus qu’ils n’allaient pas encore exécuter ces rapports sur de gros volumes ?

Les MVPs fournissent des retours à l’équipe

Produit Viable Minimum (MVP)

Le Product Owner mène la discussion d’équipe sur ce qui constitue un réel MVP. Un MVP signifie que les clients devaient être capables d’utiliser ce que l’équipe a livré. Ils choisissent cinq histoires et créent ce premier MVP centré seulement sur le vendeur interne à la compagnie. L’équipe s’attend à recevoir des réactions du personnel commercial sur les fonctionnalités et la performance. Ils utilisent ces retours pour prévoir les MVPs suivants à destination du personnel commercial de la société.

Dans ce cas, le Product Owner décide quel persona est le plus important à quel moment, pour séquencer les MVPs de manière logique. Il faut trouver la balance entre manager les retours de l’équipe et délivrer de la valeur pour les clients.

Les MVPs permettent de créer un produit commercialisable ou MMF

Il faut plusieurs MVPs pour créer une MMF, une Minimum Marketable Feature (Fonction Commercialisable Minimale). Ce MMF fournit assez de valeur (et de cohérence produit) pour trois personae clés : le personnel commercial interne et leurs managers, ainsi que l’équipe de ventes.

Plus petit votre MMF, plus rapide le flux de travail pour le produire.

Vos minimums sont-ils assez petits ?

Je travaille régulièrement avec des équipes qui pensent qu’un MVE est la même chose qu’un MVP et qu’un MMF. Même s’il est possible que les trois soient identiques, le plus souvent ils sont différents.

Je constate que quand les équipes utilisent des spikes d’un jour, apprenant ensemble pendant cette journée, elles sont mieux à même de faire la différence entre ces divers minimums.

A quel point pouvez-vous minimiser votre travail et en maximiser la valeur pour vos clients ?

Livre sur Amazon

Cet article a été écrit par Johanna Rothman. Johanna, est connue comme la “Pragmatic Manager” qui fournit des avis honnêtes sur vos problèmes.

Son dernier ouvrage est “Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.”

 

L’art et la science de la priorisation de l’arriéré de produit (« Product Backlog ») par Kiron Bondale

Comment prendre en compte les multiples facteurs en compétition pour trouver le meilleur équilibre ?

The art and science of backlog prioritization

https://kbondale.wordpress.com/2018/04/08/the-art-and-science-of-backlog-prioritization/ par Kiron Bondale

Une responsabilité clef des « Product Owners » / Propriétaires de Produit est de s’assurer que la priorisation des articles de travail dans un arriéré de produit réalise au mieux les buts et la vision pour le produit. À la différence des portefeuilles de projet où les choix ou décisions de priorisation sont souvent prises par un comité de direction, avec un arriéré de produit, la responsabilité de la réussite business ou de l’échec du produit repose sur les épaules du Propriétaire de Produit.

Cette activité tient autant de la science que de l’art.

On doit prendre en compte de multiples facteurs en compétition et trouver un équilibre

  • Valeur d’affaires
  • Alignement avec la vision originale
  • Dépendances
  • Contraintes
  • Réduction de risque

L’évaluation du coût de retard ou du Weighted Shortest Job First (Travail Pondéré le Plus court en Premier) peut injecter cohérence et objectivité dans l’activité, mais cela demande aussi beaucoup d’apprentissage et d’efforts. Si bien utilisé, de telles approches d’évaluation devraient être utilisées pour guider le processus décisionnel plutôt que le remplacer.

Relisez ce billet sur le Weighted Shortest Job First

Le Propriétaire de Produit doit collaborer efficacement avec les parties prenantes clefs pour valider que les livrables ne satisferont pas seulement les besoins des uns ou des autres. Cette collaboration exige une volonté de la part du Propriétaire de Produit de reculer la sortie de certaines fonctions « très très demandées » si cela aboutira à un meilleur produit d’ensemble.

Quand il travaille avec une nouvelle équipe, le Propriétaire de Produit doit activement écouter pendant les discussions de revue de l’arriéré avec les membres d’équipe car certains pourraient manquer du courage d’ouvertement défier une décision peu éclairée. Une façon d’aider à surmonter ce risque est de demander activement à l’équipe au fur et à mesure que les articles sont classés s’ils voient des défauts dans l’ordonnancement ou s’ils pensent qu’un article pourrait devoir être abordé plus tôt. La priorisation peut être un bon sujet à considérer pendant des rétrospectives afin d’inspecter et adapter régulièrement le processus.

différentes perspectives

Le Propriétaire de Produit voudra naturellement maximiser l’obtention de valeur business tandis que les propriétaires de solution voudront aborder des incertitudes sur la solution ou adresser l’adaptabilité ou la flexibilité dès le début. Une saine priorisation devrait ressembler à une lutte à la corde entre les représentants pour chaque facteur d’influence.

Un bon Propriétaire de Produit devrait mettre son ego de côté lors de l’activité de priorisation car son but n’est pas de démontrer son omniscience sur le séquencement du développement du produit, mais plutôt de livrer le meilleur produit possible.

SMPP est Partenaire de DantotsuPM

Weighted Shortest Job First (WSJF) est un modèle de priorisation des exigences dans les projets

WSJF est utilisé pour séquencer les travaux dans l’optique de générer un bénéfice maximal: Fonctionnalités, Epics et User Stories Scrum.

Le Weighted Shortest Job First est calculé en divisant le « coût du retard » par la taille de la tâche à réaliser pour répondre au besoin, à l’exigence.

Ce « coût du retard » est la somme de trois estimations :

  1. la valeur pour le business et les utilisateurs,
  2. la criticité temporelle et
  3. la réduction de risques ou création d’opportunités.

WSJF est donc utilisé pour prioriser l’arriéré de produit en calculant le coût du retard par rapport à la taille de la tâche (à défaut de durée).

L’utilisation du WSJF à chaque planning de Release et de Sprint maintient les priorités des arriérés de produit à jour en prenant en compte la valeur pour les utilisateurs et le business, les impacts de délais, les risques et opportunités ainsi que les efforts à fournir pour répondre à  l’exigence.

Deux vidéos pour aller un peu ou beaucoup plus loin (en 3 et 20 minutes)

2 pages utiles

CertYou est partenaire de DantotsuPM

C’est dans la comparaison relative des WSJF des différents items de l’arriéré de produit et dans la transparence de la priorisation que réside la force de cette technique.

Il me semble qu’il reste aussi à intégrer dans la priorisation les dépendances entre les besoins ou réponses aux besoins qui peuvent grandement influencer le séquencement des travaux.

Florilège de billets et vidéos sur le célèbre MVP (Minimum Viable Product)

Voici 2 vidéos et 3 billets que j’ai trouvés intéressants sur ce sujet qui se trouve au cœur même de l’agilité.

L’approche MVP (Minimum Viable Product) est une stratégie de conception par la réalisation d’une version produit simplifiée. Elle permet à une équipe de recueillir de manière itérative et incrémentale une quantité maximale de retours validés par des « early adopters ». Elle permet aussi de répondre très vite au besoin client et de le satisfaire à terme bien mieux qu’avec les méthodologies classiques.

En langue anglaise: A minimum viable product is a great way of building user centric digital services in a fraction of the time. It will also lead to big cost savings.

Retrouvez ces billets précédemment publiés sur DantotsuPM.com

1. pensons Produit Minimum Viable (MVP)

Un livre de référence sur ce sujet disponible sur Amazon

Un des buts atteint par Eric Ries’ Lean Startup’ et porteur du plus de valeur est de populariser le terme de « Minimal Viable Product » (MVP), ou Produit Minimum Viable en français. Bien sûr, le concept n’est pas nouveau. Nous utilisions l’idée de « Minimal Marketable Feature » (MMF) depuis les tous premiers jours de Kanban et elle était basée sur la même façon de penser.

2. Vaut-il mieux un livrable parfait et en retard qu’acceptable et dans les temps ?

Dans la plupart des sociétés et organisations la réponse est « acceptable et dans les temps ». Aussi, comme le prônent les méthodes Agile et les concepts tels que le Produit Minimum Viable (MVP), respecter un délai sans être paralysé par la recherche de perfection est-il vital pour l’entreprise.

3. Projet Maximum Faisable

Pour finir, Seth Godin nous challenge un peu sur cette « évidence » de l’agilité…

Les Lean entrepreneurs parlent de MVP (minimum viable product: produit viable minimal), mais bien plus important est le Projet Maximum Faisable.

Étant donné les ressources à votre disposition (vos moyens, votre temps, votre patience), quel est le plus gros résultat que vous pensez pouvoir atteindre ?

regardons ensemble une technique pour nous aider à prioriser notre arriéré de produit

Bien prioriser les items dans l’arriéré de produit est l’une des difficultés que nous rencontrons très souvent.

A technique to help Prioritise your Backlog

http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ par Sam Laing

En tant que Propriétaire de Produit (« Product Owner ») pensez-vous jamais que …. ?

  • vous avez trop de travail et pas assez de temps.
  • vous avez trop de demandeurs criant pour que leurs besoins passent en premier.
  • vous n’avez jamais de temps pour adresser la dette technique ni l’innovation parce que le directeur commercial continue d’exiger de nouvelles fonctionnalités.
Livre sur Amazon

Bien prioriser les items dans l’arriéré de produit est l’une des difficultés que nous rencontrons très souvent. Avoir un arriéré correctement ordonné apporte de la valeur. Cela garantit que votre équipe travaille sur les articles les plus importants pour le business et que votre produit évolue dans la bonne direction. Votre travail le plus important de Propriétaire de Produit est de décider comment utiliser au mieux la capacité de votre équipe.

Nous avons une technique que nous enseignons aux Propriétaires de Produit pour les aider à accorder la bonne priorité aux différentes parties prenantes.

Le schéma ci-dessous montre une façon de représenter tout le travail possible sur 2 axes : le temps et qui le travail aide le plus.

Selon notre expérience, il est plus facile de faire tomber d’accord vos parties prenantes sur le fait que (par exemple) les fonctionnalités pour supporter les nouveaux clients devraient consommer au plus 50 % de votre bande passante ou qu’un item spécifique de la dette technique est plus important qu’une fonctionnalité client donnée. Une fois que vous avez un agrément sur le pourcentage de capacité à dépenser dans chaque secteur, vous pouvez demander aux parties prenantes de chacun des quadrants de donner leurs priorités par quadrant sur la meilleure façon d’utiliser leur part de la capacité disponible.

Faire l’exercice avec l’équipe puis élargir à d’autres

Passé et Business (Support)

Passé se réfère ici aux fonctions existantes ou aux clients existants. Business se réfère aux parties prenantes qui se préoccupent d’articles dont les clients se soucient le plus. Les articles de ce quadrant sont d’habitude appelés des articles de support ou de soutien. Cela pourrait être les corrections à des erreurs signalées par des clients, ou des améliorations mineures à une fonctionnalité déjà livrée pour rendre la vie plus facile au client existant. Les articles de ce quadrant ne vous font pas gagner de nouveaux clients, mais ils ont un impact sur la conservation et la satisfaction des clients existants. Aussi ce quart de cercle est-il souvent financé par la maintenance et des contrats de support, et peut en fait être un quadrant qui génère effectivement du revenu.

Futur et Business (Nouveau Business)

résultatsCe quadrant est souvent le seul sur lequel les gens se concentrent, particulièrement s’il y a une grosse pression pour gagner de nouveaux clients. Les articles de ce quadrant ont pour objectif d’aider à attirer plus de clients dans l’avenir. Ce pourraient être de nouvelles fonctionnalités, permettre une montée en volume, ajouter une plate-forme supplémentaire destinée à servir un nouveau type d’utilisateurs.

Passé et Technique (Dette Technique)

C’est un quadrant trop souvent négligé. Essentiellement, ce sont les articles qui impactent l’équipe technique. La dette technique en est un bon exemple. Par exemple, une fonctionnalité pourrait avoir été mal écrite et être donc très fragile, générant des bogues chaque fois l’équipe travaille dessus. Habituellement, ces articles ne génèrent pas de revenu additionnel mais, si on les choisit bien, ils peuvent être de gros économiseurs de dépenses. Un autre exemple dans ce secteur pourrait être une chose qui fera gagner beaucoup de temps à l’équipe de support. Par exemple si votre personnel de support doit résoudre des problèmes complexes, capturer des informations complémentaires lors de la connexion pourrait être quelque chose qui les aidera à réduire le temps qu’ils dépensent dans leurs investigations.

Futur et Technique (Innovation Architecturale)

Ce quadrant est une projection dans le futur d’une vue technique. Souvent les architectes peuvent proposer des idées pour ce secteur. Peut-être qu’une nouvelle technologie est disponible qui simplifiera significativement votre produit. D’autres items pourraient être des mises à niveau de technologies existantes avant que celles que vous utilisez ne soient dépassées. Par exemple, mise à niveau sur la dernière version Java. Ces articles peuvent parfois rapporter du revenu additionnel, parce qu’ils attirent les clients, mais le plus souvent ce sont des réducteurs de coûts : la nouvelle technologie devrait rendre les développements plus faciles pour votre équipe.

Et ci cela pouvait aussi s’avérer utile comme approche générique pour prioriser un portefeuille de projets ?

SMPP est Partenaire de DantotsuPM

C’est une technique que nous utilisons dans notre livre “Growing Agile: A Coach’s Guide to Mastering Backlogs”.

Comment manager des parties prenantes et membres d’équipe difficiles

Recommandations pour manager les gens difficiles et adresser avec succès les inévitables conflits

Dealing with Difficult Stakeholders and Team Members

http://www.romanpichler.com/blog/conflict-resolution-tips-product-managers-product-owners/ Par Roman Pichler

Les désaccords et conflits font partie de notre travail de propriétaires de produit et chefs de projets. Nous travaillons avec une grande variété de personnes de départements différents et il est tout simplement naturel que nous ne soyons pas toujours d’accord et parfois nous confrontions. Mais naviguer sur les conflits de manière constructive peut être stimulant. Cet article partage mes recommandations pour manager les gens difficiles et adresser avec succès les conflits.

C’est un challenge on ne peut plus courant

“Vous ne parvenez pas à vous décider. Je regrette vraiment que cette fois, vous ne nous ayez pas donné de priorités claires.” a dit Jane de manière accusatrice à la fin de l’atelier en sortant de la pièce. [1] Je ressentis ceci comme une gifle, une attaque délibérée. Comment pouvait-elle dire quelque chose d’aussi faux ?

Cette histoire vous semble-t-elle familière ? Je constate que en tant que chefs de produit et propriétaires de produit, nous devons parfois composer avec des parties prenantes et membres d’équipe stressés, agressifs, inutiles, ou avec des personnes qui sont juste difficiles.

Si nous réfléchissons à la nature de notre travail, cela ne devrait pas nous surprendre : le management de produit est autant une affaire de personnes que de produits. La friction et le conflit apparaissent généralement quand des personnes  de départements différents travaillent ensemble. Qui plus est, l’innovation et la collaboration efficaces sont seulement possibles si nous pouvons tirer parti du conflit et du désaccord. [2]

CSP est partenaire de DantotsuPM

N’ignorez pas le conflit

Il serait facile de mettre la question de côté et oublier ce que Jane a dit. Avec tant de choses réclamant votre attention, devriez-vous vraiment vous inquiéter de la remarque de Jane ? Mais qu’arriverait-il vraiment si vous ignoriez le conflit ?

Image courtesy of Ambro / FreeDigitalPhotos.net

Les chances sont grandes que vous gardiez du ressentiment envers Jane, même si vous n’en êtes pas pleinement conscient. La prochaine fois, quand vous vous rencontrerez, cela pourrait vous faire dire quelque chose que vous regretterez plus tard et qui ne ferait qu’empirer les choses. Qui plus est, tolérer un mauvais comportement crée un précédent et une atmosphère de travail malsaine: le manque de respect invite le manque de respect.

Donc, n’ignorez pas le conflit. Voyez-le comme une opportunité d’améliorer votre pratique de management de produit et vos capacités de leadership. Bien sûr, ceci est parfois plus facile à dire qu’à faire : Aborder le sujet exige du courage. Jane pourrait être une personne puissante ou influente comme une partie prenante sénior. De plus, vous devez réfléchir honnêtement à vos propres intentions et actions et être ouverts à l’idée de changer votre comportement.

Regagnez votre maîtrise de vous

Quand je suis exposé à un comportement hostile, cela peut être difficile pour moi de ne pas perdre mon calme. Mais avant de répondre à Jane et lui dire ce que vous pensez, arrêtez-vous et réfléchissez. Prenez conscience de votre propre état, de comment vous vous sentez. Êtes-vous déçu, vexé, ou fâché ? Si c’est le cas, c’est OK. Mais prenez en compte que vos pensées négatives et vos émotions altèrent votre perception; elles rendront malaisé d’avoir une conversation constructive avec Jane.

Qui plus est, la négativité affecte votre propre bien-être; elle vous rend malheureux. « S’accrocher à son irritation a dit une fois un homme sage, ressemble à saisir un charbon ardent dans l’intention de faire mal à quelqu’un d’autre : la seule chose certaine est que vous serez brûlé.«  [3] Même si la colère, la crainte, ou les soucis semblent avoir une forte emprise sur vous, ils s’affaibliront et partiront si vous ne les alimentez pas. Reconnaissez-les, mais ne ne les suivez pas et ne vous identifiez pas à eux.

De plus, pensez aux qualités positives de la personne difficile. Jane ne peut sûrement pas être toute méchante et mauvaise. Pensez aux moments où vous avez vu Jane aider d’autres personnes, apporter une contribution constructive, ou commettre d’autres actes de bonté. Rappelez-vous que quelqu’un qui agit mal doit être profondément malheureux à l’intérieur. Cela vous aidera à faire preuve d’empathie avec la personne difficile et développer de la compassion, plutôt que de diaboliser l’individu et lui tenir rancune. Finalement, dites-vous que comme ces personnes, nous avons tous agi de façons inopportunes et avons dit des choses hostiles; je ne suis certainement pas parfait.

Méta Projets Management est partenaire de DantotsuPM

Mettez les choses en perspective

Demandez à vous pourquoi vous percevez la personne comme difficile. Qu’est-ce qui rend cette personne si difficile à gérer ? Pourquoi avez-vous répondu de la façon dont vous l’avez faite ? Pourquoi la remarque de Jane vous a-t-elle fait vous sentir fâché ou blessé, par exemple ? Était-ce purement à cause de ce que Jane a dit, ou cela a-t-il plutôt à faire avec vous ?

Je remarque que ma propre réponse à un comportement inadéquat est particulièrement forte quand mes opinions et croyances profondes sont mises en cause. Si je me considère comme quelqu’un de décisif et qui sait ce qui est bon pour son produit, je vais probablement être plus affecté par les remarques de Jane indépendamment de son intention. De même, je constate que quand je suis stressé ou tendu, tout mauvais comportement est plus mal ressenti que quand je suis détendu et relax.

Finalement, regardez les faits et considérez calmement ce qui est en réalité arrivé. La remarque de Jane pourrait avoir ressemblé à une gifle. Mais a-t-elle eu l’intention d’être désagréable ? Avez-vous contribué au conflit d’une quelconque façon ? Y-avait-il eu quoi que ce soit de négatif que vous pourriez avoir dit ou fait à Jane, intentionnellement ou involontairement ? Cela n’excuse pas le comportement de Jane, bien sûr. Mais ça aide à mettre les choses en perspective et à passer de mettre le blâme sur Jane à résoudre le conflit.

Répondez habilement

Quand vous rencontrez Jane pour aborder la question, approchez la réunion dans l’intention de comprendre et réconcilier, pas de gagner. La résolution de conflit n’est pas prendre le dessus sur l’autre personne; c’est développer une perspective partagée sur ce qui est arrivé, convenir des changements exigés et reconstruire la confiance.

Partagez votre perspective et votre expérience de façon constructive et soyez gentil : Jane  peut ne pas être (pleinement) consciente de ses actions et leur impact sur vous. En même temps, soyez honnête et ferme. Utilisez la première personne « Je »; décrivez ce que vous avez vu et entendu et comment ceci vous a affecté. Par exemple, “Je t’ai entendu questionner ma capacité à donner les priorités et prendre des décisions de produit efficaces; puis j’ai constaté que tu es partie sans me donner le temps de répondre. Je me suis par conséquent senti fâché et déçu.”

assomptionSéparez la personne de la question. Ne blâmez pas ni attaquez l’autre personne, ne généralisez pas (“c’est typique de toi”), ne parlez pas de ce que d’autres gens peuvent avoir dit (“John le dit aussi”), ne spéculez pas (“c’est probablement parce que tu n’as pas obtenu ce que tu voulais à la réunion précédente”). Écoutez avec un esprit ouvert et essayez de suspendre toute forme de jugement. Nous détenons tous un morceau de la vérité.

Offrez votre aide et faites des suggestions constructives pour résoudre le problème. Suggérez des changements que vous êtes prêts à faire, comme, “je t’inviterai dorénavant aux ateliers de planification produit pour que tu comprennes mieux la totalité des contraintes dont nous devons tenir compte en priorisant l’arriéré de produit,” ou “j’écouterai plus soigneusement tes suggestions ainsi tu ne te sentiras plus ignorée ni sur la touche.”

Exposez les changements positifs que vous souhaitez, par exemple, “cela m’aiderait vraiment si tu essayais d’être plus patiente et compréhensive,” ou “ce serait top si tu pouvais me faire savoir plus tôt si tu estimes que l’on n’entend pas assez ton avis.”

Souvenez-vous : Bien que vous vouliez être gentil et bienveillant, vous n’êtes pas responsable des pensées et des sentiments de l’autre personne. Vous pouvez encourager une autre personne à changer. Mais vous ne pouvez pas faire changer son attitude et comportement à qui que ce soit.

Passez à autre chose

trop difficile = abandonSi tout marche, vous avez composé avec Jane et avez convenu d’une manière d’avancer. Il reste alors à renforcer la relation et rétablir entièrement la confiance qui pourrait avoir été perdue. C’est en travaillant ensemble aussi bien qu’en socialisant, par exemple, prenant le café ou déjeuner ensemble, que cela se produira.

Si la conversation s’est mal passée, considérez quelles sont les prochaines étapes. Devriez-vous parler de nouveau à Jane ? Devriez-vous impliquer quelqu’un qui peut servir d’intermédiaire ? Devriez-vous faire remonter le problème ? Parler à votre manager ou ScrumMaster / Coach pourrait vous aider à choisir l’action appropriée.

Notes

[1] Jane est un caractère factice. Je suppose que le conflit peut être résolu par les gens impliqués contrairement aux transgressions sévères comme la violence ou le harcèlement sexuel. Dans le doute, impliquez votre manager et le département des ressources humaines.

[2] Le modèle de construction d’équipe de Tuckman, par exemple, suggère que les gens doivent gérer le conflit avec créativité pour être capables de travailler ensemble efficacement.

[3] Cette citation est souvent attribuée à Bouddha mais elle pourrait provenir en réalité de Buddhaghosa.