Priorisation des tâches : Maintenant, Ensuite, Plus tard, Jamais (améliorons le MoSCoW)

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.

Now, Next, Later, Never (improving MoSCoW)

https://watirmelon.blog/2019/10/14/now-next-later-never-improving-moscow/ par Alister Scott

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.

Méthode MoSCoW sur Wikipedia

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 ?

Bien plus qu’un outil de gestion de projet
Découvrir l’ERP de gestion de projet

Biais Cognitif – Le biais de projection

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 concrets rapidement 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

billets les plus lus en Octobre 2020 sur DantotsuPM.com : PDCA, User Stories et Product Owner

L’agilité à retenu votre attention en Octobre ainsi que le très classique cycle d’amélioration continue Plan/Do/Check/Act.

Rappel de ce qu’est le « Plan Do Check Act », Cycle PDCA pour l’amélioration continue.

plan do check actSi 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.

FDF est partenaire de DantotsuPM

La magie d’histoires utilisateur courtes (User Stories)

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.

CertYou est partenaire de DantotsuPM

3 qualités difficiles à trouver et qui font un(e) excellent(e) Propriétaire de Produit (Product Owner)

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

 

3 qualités difficiles à trouver et qui font un(e) excellent(e) Propriétaire de Produit (Product Owner)

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.

3 Elusive Qualities of a Great Product Owner

https://www.agileconnection.com/article/3-elusive-qualities-great-product-owner par John Yorke

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

les « burndown Charts » et Agile: Quoi et pour quoi faire ?

Le Scrum Trainer professionnel Ralph Jocham décrit les Burndown Charts et se concentre sur le travail dans un sprint puis dans une release.

Ralph explique comment et pourquoi ils sont utilisés et fournit des conseils sur les moyens de les exploiter au sein de vos équipes.

Voici aussi comment les Burndown Charts peuvent être utilisés dans la planification et les prévisions des releases.

CertYou est partenaire de DantotsuPM

Management proactif des dépendances avec les approches agiles

La planification est une activité récurrente dans les approches adaptatives et les dépendances entre User Stories doivent y être identifiées.

Proactive dependency management with agile approaches

https://kbondale.wordpress.com/2019/04/07/proactive-dependency-management-with-agile-approaches/ par Kiron Bondale

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 DantotsuPM
scrum methodologie agile
Voici 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.

Certes il faut apprendre à dire NON, mais ce n’est pas toujours la meilleure approche dans le management de projet.

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

Commençons bien l’année, faisons un peu de ménage dans notre « product backlog » !

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

1,2,3… Professional Scrum Product Owner / PSPO

1,2,3… Scrum.org ajoute un nouveau niveau de test d’évaluation de certification de propriétaire de produit Scrum professionnel : Professional Scrum Product Owner

 

PMGS est partenaire de DantotsuPM

La semaine dernière, Scrum.org a annoncé des changements aux évaluations de certification PSPO.

Une nouvelle évaluation de PSPO II et des modifications sur le PSPO II actuel pour qu’elle devienne PSPO III.

Cela complète la famille d’évaluations et de certifications du PSPO en ajoutant un niveau distinguished en plus des niveaux fondamentaux et avancés fournis par le PSPO I et le PSPO II.

En restructurant ses évaluations et certifications Professional Scrum Product Owner (PSPO), et en ajoutant un niveau supplémentaire, Scrum.org permet aux professionnels de démontrer leur compréhension, leur connaissance et leur pratique du rôle du propriétaire de produit Product Owner avec Scrum.

Ces certifications attestent de leur capacité à maximiser la valeur offerte par le produit.

Pour en savoir davantage (en Anglais)

CertYou est partenaire de DantotsuPM

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 ».