Janvier 2019 : Les événements et rencontres sur le management de projet

Voici tous les événements en management de projet que je vous recommande en ce mois de Janvier 2019.

Tous sont liés au management de projet, gestion du changement ou leadership et pourront à ce titre vous rapporter des PDUs si vous êtes certifiés du PMI.

Mardi 8 – PMI Webinar – Conflict Resolution  (1 PDU)

Manage conflict in a structured way, apply principled negotiations effectively to focus on winning a resolution. Learn to identify their preferred style in influencing others and managing conflict and understand additional strategies that you may need to use to successfully resolve the conflict situation.

Mercredi 9 – PMI Webinar – Backlog / Story Grooming (1 PDU)

Attendees will learn how to work the process to achieve fine-grained requirements that are ready just in time. The key to success is leveraging tools and techniques as well as the expertise of your team to refine requirements iteratively.

CertYou est partenaire de DantotsuPM

Mercredi 9 – APMG – London – New Habits That Last

Organisational and Personal Change Mastered : A new year often also signals the start of a new you – a new focus and desire to change long established habits or practices that maybe restricting your health, wealth and general fortune. But how do you stay the course when on average over 50% of new years resolutions are broken within the first fortnight of the new year. What can we learn about the steps to mentally prepare ourselves for forming new habits and how can we extend them to organisational change.

Jeudi 10 – PMI – Luxembourg – Introducing SAFe 4.6 for Lean Enterprises and General assembly

Scaled Agile Framework web site

Lundi 14 – PMI – Montréal – Gestion organisationnelle – Encore Agile… pourquoi pas!

La mise en place des concepts Agile dans les organisations est loin d’être une nouveauté. Plusieurs vagues ont eu lieu jusqu’à présent s’appuyant sur diverses méthodologies, pratiques, buzzword, etc. Le Mouvement Desjardins, comme plusieurs organisations, veut profiter des avantages que devrait apporter une transformation vers l’Agilité et elle met les efforts nécessaires pour y parvenir.

Mardi 15 – PMI Morocco – Casablanca – Mise en place de projets agiles Big Data dans un contexte bancaire innovant

issam el alaouiL’analyse de donnée est un domaine particulier où les standards classiques de la gestion de projets ne s’appliquent pas toujours. L’agilité étant une clé de ce type de projet, il faut imaginer des moyens souples et flexibles pour mener à bien un projet de Big Data / datascience tout en gardant le plus possible des contraintes de planning et de faisabilité.

Mardi 15 – QRP – Luxembourg – PRINCE2 Tailoring: “PRINCE2 on A4” and PRINCE2 for complex projects

Tailoring can be applied to processes, themes, roles, management products and terminology: tailoring is concerned with the appropriate use of PRINCE2 in any given situation. This 1 hour workshop will show you how to apply PRINCE2 for very simple projects (“PRINCE2 on A4”) and for bigger projects that will require a more complex PRINCE2 tailoring.

QRP International est Partenaire de DantotsuPM

Mardi 15 – PMI – Montpellier – PM Café (1PDU)

Nous sommes une communauté de chefs de projets de sociétés diverses et nous nous retrouvons régulièrement pour améliorer nos pratiques lors de conférences et de cercles de discussion. Nous souhaitons continuer à créer du lien entre nous, à échanger, à réseauter, à apprendre des autres. Bref à faire vivre et grandir la communauté des chefs de projets de Montpellier.

Mardi 15 – PMI – Paris Saclay – La naturopathie au service des managers de projets (1PDU)

Une session animée par Marie Ros-Guézet

La naturopathie est un art vivre dans le respect de la physiologie de son organisme, pour être en bonne santé, éloigner le risque de pathologies graves et ainsi se sentir bien tout au long de sa vie. Les postes de managers de projet, de cadres, de managers… peuvent vous amener à vivre des moments de pression, parfois sur la durée, et avec des difficultés à trouver un équilibre entre vie professionnelle et vie privée. Cette conférence vous apportera quelques clés de compréhension des besoins de votre organisme, des informations pour vous permettre de détecter des moments à risques et des conseils pour y faire face.

Mardi 15 – ScrumPulse – Webinar – Ask A Professional Scrum Trainer – Martijn van Asseldonk

Some examples of topics you may think of asking:
– How can I resolve conflicts within the Scrum Team or organization?
– How could I help Scrum Team members to broaden their skills sets?
– How shall we deal with dependencies and remove impediments?

CertYou est partenaire de DantotsuPM

Mardi 15 – SMP – Lausanne – Retour sur une migration « Business Agile »

Il y a 5 ans, Nagra/Kudelski a décidé de migrer son système de télévision à péage vers le monde connecté comme Netflix.

Après 6 mois de travail acharné et inutile de planification et de budget, le management a décidé d’appliquer le ‘’Business Agile’’. Au lieu de demander des garanties aux projets et aux équipes avant de commencer à travailler, le management garantit les moyens et fait confiance aux équipes pour livrer de la valeur à un business émergeant et mouvant.

Jeudi 17 – PMI – Webinar – How to Facilitate Productive Planning Meetings (1PDU)

Why is planning for your project so important and similarly, how to plan for a high-quality meeting ?

How do you prepare for and facilitate the project kickoff meeting ?

What are the impacts of culture on team dynamics ?

Jeudi 17 – PMI – Lyon – un futur modèle de management par le sens ? (1,5 PDU)

Livre sur Amazon

Dans un monde toujours plus complexe et changeant, une (r)évolution des modes de management est aujourd’hui nécessaire pour une transformation par le sens. L’élément humain reste le facteur clé de succès de tout projet. Le chef de projet est-il alors devenu un coach et un Team Builder ?

Plusieurs outils pratiques et opérationnels de management et de coaching inspirés des travaux de Vincent Lenhardt, seront présentés et nous nous interrogerons sur la place de modèle du Project Management dans cette (r)évolution.

CSP est partenaire de DantotsuPM

Jeudi 17 – PMI – Versailles – Coopération et rivalité dans les projets : les leçons de Game of Thrones (2 PDUs)

une ressource mal alignée peut sévèrement impacter les résultats de toute l’équipe

Pour parvenir à transformer une organisation, il faut cesser de croire que tout le monde est aligné !

Il est nécessaire d’accepter les divergences pour mieux les dépasser.

Les Lannester et les Stark, dans la série Game of Thrones, en fournissent une bonne illustration.

Vendredi 18 – PMI – Webinar – The Agile Enterprise: From Agile Teams to Agile Organization (1 PDU)

This webinar looks at Agility at the Enterprise level from a Project Manager perspective, explaining the difference between the new Agile Enterprise (a top down Agile approach) and Enterprise Agile (the bottom up Agile transformation) that is scaling popular Agile frameworks from team level to organisation level.

SMPP est Partenaire de DantotsuPM

Mardi 22 – PMI – Zurich – Leadership Tai Chi

The Co-Active Leadership Model offers five different dimensions, or five different ways to lead: Leader Within, Leader in Front, Leader Behind, Leader Beside, and Leader in the Field. Every leader can potentially operate from all five dimensions at different times, shifting from one to the other depending on their leadership style and the needs of the moment.

Mercredi 23 – IIBA – Paris – 1er Hackathon de la Business Analyse en France

inscriptions en ligne

Le métier de business analyste est un métier transverse, au cœur de l’entreprise et des nouvelles technologies, en éternel mouvement, demandant de repenser les solutions constamment. Devenir un business analyste requiert un large panel de compétences, qu’elles soient techniques, comportementales, technologiques et une capacité affutée à maitriser les enjeux métier.

Vendredi  – PMI Sénégal – Dakar – La problématique du financement de projets (2 PDUs)

Obtenir un financement approprié est une étape cruciale pour garantir la réussite de vos projets professionnels et personnels. Le PMI Sénégal a le plaisir de vous informer qu’il organise une table ronde animée par des panélistes reconnus dans leur domaine d’expertise qui vous permettra d’obtenir des réponses concrètes à vos interrogations et de nouer des contacts utiles.

Lundi 28 – PMI – Webinar – Beyond the Triangle: Delivering Value in an Agile World (1 PDU)

Two practices can position a project to deliver value: Design Thinking and Benefits Mapping. A large scale study to compare predictive and agile methodologies found that combining predictive and agile practices into a hybrid approach can produce good outcomes.

Mardi 29 – ScrumPulse – Webinar – Evidence-Based Management (EBM) to Measure Value

Get the guide

Net Health, a healthcare software company, had been practicing Scrum for several years and more recently has scaled Scrum in their organization using the Nexus framework. As they continued using Nexus, they started to face some challenges related to how they were measuring the value they were delivering, including:

  • A desire to increase value, but a lack of clarity on what value meant for them as an organization
  • Not being able to improve what they couldn’t measure and from an evidence-based standpoint
  • Lack of understanding of what it meant to be agile by management and leadership
  • Uncertainty on the progress they have been making since adopting Scrum and agile practices

How did they manage these ?

CertYou est partenaire de DantotsuPM

Mardi 29 – PMI – Paris – Restitution Livre Blanc « PMBoK® et cycles de vie » (2 PDUs)

Version française sur Amazon

Une simple interrogation est à l’origine de ce livre blanc : Les groupes de processus décrits dans le PMBoK® Guide sont-ils suffisamment universels pour gérer n’importe quel projet ?

Autrement dit, comment se fait-il que des entreprises aient décidé de consacrer des efforts pour construire des cycles de vie détaillés qui leur conviennent davantage ?

Mercredi 30 – PMI – Webinar –Killer Requirements Generation Using Design Sprints (1PDU)

Lire les détails sur wikipedia

Design Sprint methods can be used to help project managers and teams at-large ensure alignment between current problem/challenge, scope of work and requirements for the project overall.

In many cases their is a direct link between scope and requirements, hence requirement definition impacts project scope.

Every project benefits by having a well defined project scope that helps define boundaries for the project, the primary outcome/goal/deliverable to be achieved and success metrics (what does « done » look like »)

Mercredi 30 – Webinar – Applying Gemba Kaizen and CI Principles in Non-Kaizen Enterprises (1 PDU)

Livre sur Amazon

While this presentation is not in any way meant to be a thorough discussion or analysis of Gemba Kaizen, it touches on how to apply specific Kaizen techniques and processes towards ANY project, and more importantly how to have a Kaizen mindset to improve policies, processes, and morale while, or through, the act of reducing waste (Muda).

PMI and PMBoK are registered marks of Project Management Institute, Inc.

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

Rendez-vous du management de projet – Fin Décembre 2018

Voici vos dernières chances de l’année de participer à des sessions informatives et qui peuvent apporter des PDUs aux certifiés du PMI.

Mardi 18

Webinar – Scrumpulse – What’s My Product? How to Rationalize Demand and Delivery

Ask A Professional Scrum Trainer – Chad Beier. How to rationalize my demands (where the work comes from) and my deliveries (the people doing the work) to inform our decisions on how to organize our teams and backlogs ? How many backlogs should my department or organization have? Is a single backlog feasible?

Mercredi 19

Jeudi 20

Dickens sur Amazon

Project management can learn a surprising amount from Charles Dickens. Our practices extend back to the time he was writing, as the industrial revolution took hold. And some of those practices have not shaken off the mantle of that legacy. An exploration of our world through the eyes of a very different one.

Rendez-vous du management de projet – 10 au 16 Décembre

Cette semaine est placée sous la thématique des retours d’expérience sur des projets très différents à Paris, Toulouse,Lausanne et Montréal.

Mardi 11

 

Défendant le droit à l’information dans les situations où il est le plus mis à mal (conflits, sortie de crise, transition), les situations de travail de la Fondation Hirondelle sont par nature fragiles, instables politiquement et du point de vue de la sécurité, faibles économiquement et fragmentées socialement. Comment dans ces conditions gérer un projet, de l’analyse des besoins à la mise en œuvre, de l’évaluation à la mesure de l’impact ?

Mercredi 12

Pour ce meetup animé par Thibo LESUR, nous porterons notre attention sur le rôle du Produt Owner au sein de l’équipe Scrum. Des avis, un peu de méthodologie et des exemples « de la vraie vie ».

Jeudi 13

En 2016-2017, un programme de rappel sur des disjoncteur PK 735 et 315kV exigeait le remplacement de 310 disjoncteurs sur le réseau de transport d’Hydro-Québec. Retour d’expérience sur « Comment passer de l’impossible à un succès de grande envergure avec l’implantation de la gestion par programme de projet ». Il sera démontré comment les échéanciers de réalisation de travaux en période de retrait ont été ramenés de 8 à 4 semaines et comment les coûts ont également été diminués de 162M$. Et cela, grâce à l’utilisation d’un outil de la gestion de projet et à l’implantation de la gestion par programme de projets.

PMI is a registered mark of Project Management Institute, Inc.

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.

Foire aux questions sur les Histoires d’Utilisateur (User Stories) #Scrum

Frequently Asked Questions About User Stories

https://www.scrumalliance.org/community/articles/2016/april/frequently-asked-questions-about-user-stories par Sandeep Paudel

Les membres des équipes Scrum, participants aux formations, collègues et parties prenantes diverses impliquées dans des projets de mise en œuvre Agiles/Scrum posent souvent les mêmes questions sur les histoires d’utilisateur (User Stories). Ci-dessous, une liste de questions et réponses que je partage avec vous. J’espère que ces informations seront utiles à quiconque veut en apprendre davantage sur les histoires d’utilisateur.

Q: Que sont les histoires d’utilisateur (User Stories) ?

Une histoire d’utilisateur est une brève description de tout besoin fonctionnel. Elle est écrite d’une perspective utilisateur pendant ou avant la priorisation de l’arriéré de produit (Product Backlog) ou une session de planification de Sprint (Sprint Planning). Une histoire peut inclure, mais n’est pas limitée à, une fonctionnalité avec ses caractéristiques et ses règles de gestion, des demandes d’amélioration, des corrections de bogue, l’installation d’infrastructure, ou une documentation technique. Les histoires d’utilisateur peuvent représenter presque n’importe quelle activité pendant le cycle de vie du développement logiciel.

Q: Comment les histoires d’utilisateur sont-elles apparues ?

Il n’y a aucune date spécifique ou événement rapportés sur l’origine des histoires d’utilisateur. Cependant, la littérature suggère que les histoires d’utilisateur ont évoluées pendant le processus de collecte et de mûrissement des besoins qui ont été à l’origine documentés sous forme de cas d’usage. Des « programmeurs extrêmes » à la fin des années 1990 ont rendu les histoires d’utilisateur populaires dans l’arène du développement logiciel. Des approches Agiles plus récentes, comme Scrum et Kanban, ont aidé à largement promouvoir l’usage massif les histoires d’utilisateur.

Q: Comment dois-je écrire  une histoire d’utilisateur ?

Le format le plus populaire pour écrire des histoires d’utilisateur dans beaucoup d’approches Agiles est comme suit :

En tant qu’utilisateur (du système), je veux faire (action) pour que (les bénéfices à avoir cette fonctionnalité).

Par exemple, « En tant qu’étudiant, je veux voir mes notes pour connaitre ma performance. »

Q: Qui est responsable d’écrire les histoires d’utilisateur ?

Il n’y a aucun rôle spécifique responsable d’écrire une histoire d’utilisateur. Toute personne impliquée dans le processus de développement logiciel, des parties prenantes du métier aux membres de l’équipe Agiles, peut écrire des histoires d’utilisateur. Cependant, beaucoup d’histoires sont écrites pendant la session de revue de l’arriéré de produit par les membres de l’équipe de développement, comme les programmeurs, testeurs et analystes, ainsi que le propriétaire de produit (Product Owner).

Q: Quelles sont les qualités d’une bonne histoire d’utilisateur ?

Une histoire d’utilisateur idéale devrait être courte, simple et sans équivoque. Beaucoup de partisans Agiles considèrent le modèle de Bill Wake INVEST comme une base pour une bonne histoire.

I.N.V.E.S.T. (Relisez le billet sur INVEST)

  • IIndépendante
  • N– Négociable
  • V– de Valeur
  • EEstimable
  • SSuffisamment petite (Small)
  • TTestable

Q: Les histoires d’utilisateur exigent-elles une approbation ?

qui approuve une histoire utilisateur ?

Contrairement aux exigences opérationnelles ou aux documents dans des approches de développement logicielles traditionnelles, aucun processus formel n’existe pour approuver des besoins dans un environnement Agile. Et les histoires d’utilisateur ne sont pas les seules fonctionnalités, donc ce sont les membres de l’équipe Agile qui acceptent les histoires quand la plupart d’entre eux sont confiants sur la capacité à livrer cette histoire en une itération. Tous les doutes sur une histoire d’utilisateur sont clarifiés par le propriétaire de produit dans le cadre de Scrum.

Q: Quels sont trois Cs des histoires d’utilisateur ?

En 2001, Ron Jeffries Proposé le concept de trois Cs : Carte (fiche), Conversation Et Confirmation, pour atteindre le consensus sur une histoire de la part des parties prenantes dans le cadre Agile.

  • La Carte d’histoire est écrite sur une fiche, qui est souvent un Post-it®.
  • La Conversation est une série de discussions entre l’équipe de développement et les parties prenantes internes et externes pour comprendre la complexité et la valeur de l’histoire.
  • La Confirmation doit s’assurer que la conversation tournant autour de l’histoire est parvenue à une conclusion.

Q: Quelles sont les différences entre un cas d’usage (Use Case) et une histoire d’utilisateur ?

Bien le cas d’usage et l’histoire d’utilisateur semblent semblables et que beaucoup de personnes les confondent comme une des façons de décrire des besoins, ils sont différents de bien des façons, comme suit :

Histoires d’utilisateur et tâches :

Les membres de l’équipe exécutent des tâches basées sur l’ensemble d’activités pour construire une fonctionnalité, comme exprimé dans l’histoire d’utilisateur. Par exemple, l’histoire d’utilisateur est: Comme un acheteur de mon futur domicile, je veux voir la liste de maisons dans mon voisinage pour que je puisse faire une liste des maisons candidates sélectionnées que je veux acheter.

Les tâches pour l’histoire pourraient être:

    • Codage, utilisation de la logique appropriée
    • Intégration d’APIs de recherche et de cartographie
    • Développement de scénarios de test
    • Intégration avec des sources de données
    • Finalisation de filtre de sélection

Les histoires d’utilisateur sont mesurées de manière relative avec des tailles comme S, M, L, XL, etc., ou en utilisant la séquence de Fibonacci : 1, 2, 3, 5, 8, 13 …, basée sur la complexité de développement des histoires. Les tâches sont toujours calculées en heures et sont basées sur le niveau d’effort que chaque membre doit fournir pour chacune des tâches.

CertYou est partenaire de DantotsuPM
Histoires d’utilisateur et épopées

Une épopée est un jeu de fonctionnalités qui ressemblent à une histoire au début, mais quand les membres de l’équipe commencent à l’analyser, ils constatent qu’elle pourrait être plus grande que précédemment envisagé. Donc ils doivent la décomposer en de multiples histoires. Une façon de différencier une épopée d’une histoire est en vérifiant qu’elle suit le modèle INVEST discuté plus tôt.

Rencontres sur le management de projets – 23 au 31 Juillet

Deux wébinaires en langue anglaise à vous recommander pour la fin-Juillet 2018 sur l’engagement du Product Owner et les « Lateral thinking skills ».

Mardi 24

You can be a far better leader and project manager if you use a little lateral thinking. This short presentation will give you stories, tips and methods to help you and your team to think differently, to solve problems creatively and to drive innovation. It will help you to start more fires.

Jeudi 26

The Product Owner has the ultimate goal of representing stakeholders to deliver value. A key attribute to achieving this goal is to be in tune with the Scrum Team to ensure they understand the items on the Product Backlog and get them to « Done ». The Product Owner needs to:

    • Be available to help clarify and negotiate to focus on getting to « Done »
    • Set a vision and trust the Development Team with the implementation of the Product Backlog Items
    • Bring stakeholders and the Development Team together to facilitate moves towards value
CertYou est partenaire de DantotsuPM

PMI is a registered mark of Project Management Institute, Inc.

Que signifie vraiment “le Produit Viable Minimal” ou mVP de toute façon ?

Elon Musc donne du sens à une idée qui peut nous embrouiller.

Un extrait de l’excellent billet https://medium.freecodecamp.com/what-the-hell-does-minimum-viable-product-actually-mean-anyway-7d8f6a110f38 de Ravi Vadrevu

Un processus MVP simplifié en 3 étapes

J’ai pris des méthodologies complexes comme LEAN, Agile et Guerilla pour en distiller le process mVP en 3 étapes :

  1. Commencez avec un produit simple et unique résolvant un minuscule sous-ensemble d’un grand problème;
  2. Continuez à itérez, en résolvant constamment de plus grands problèmes connectés à la résolution du grand problème;
  3. Communiquez constamment la vision du grand problème qui sera résolu.

Utilisons l’évolution de l’éclairage pour illustrer comment cela fonctionne.

Source : Egg Lighting

Grand problème : l’Humanité a besoin d’un éclairage bon marché, efficace pendant l’obscurité

1er mVP : Feu. Les gens ont observé comment la foudre des cieux pouvait enflammer des forêts et créer le feu. Après expérimentation, en frottant des bouts de bois entre eux, ils ont créé leur propre feu. Problème résolu. Mais le feu n’est pas particulièrement portable.

2ème mVP : Lampes à pétrole, Bougies et Lanternes à Gaz. Maintenant les gens pouvaient emporter la lumière avec eux quand ils se déplaçaient. Problème résolu. Mais les bougies et des lanternes à gaz ne sont pas particulièrement éclairantes et la plus légère brise les éteint.

3ème mVP : Ampoules incandescentes. Les premières ampoules étaient alimentées par batterie et plus fiables qu’une bougie vacillante. Problème résolu. Mais comme les villes ont grandi en taille, la demande pour un éclairage plus répandu a grandi. Le réseau national n’avait pas encore été construit.

4ème mVP : Électricité largement disponible. Pour transmettre l’électricité sur de longues distances, le courant alternatif et les transformateurs ont été développés. Des centrales électriques thermales ont été construites pour satisfaire la demande massive. Problème résolu. Mais comme la demande mondiale en électricité augmentait, des alternatives sont devenues nécessaires.

5ème mVP : Énergie solaire. Des ampoules de consommation en watts inférieures remplacent les ampoules incandescentes originales tandis que les panneaux solaires deviennent plus efficaces et meilleur marché à produire. Problème résolu. Mais les solutions solaires restent encore relativement chères et l’adoption trop faible pour être en position d’éteindre le réseau électrique.

6ème mVP : une Planète dont l’énergie provient seulement du soleil. Des batteries hautement efficaces peuvent être chargées par des panneaux solaires bon marché et omniprésents. À ce point il devient possible d’éliminer notre dépendance aux carburants fossiles. Nous n’y sommes pas encore tout à fait.

Méta Projets Management est partenaire de DantotsuPM

Elon Musk est un entrepreneur qui est exceptionnel dans son application du processus mVP en 3 étapes.

1. Commencez avec un produit simple résolvant un problème minuscule.

Il a lancé une voiture électrique en moins de 3 ans qui est devenue la voiture électrique la plus demandée au monde.

2. Continuez à itérer, en résolvant constamment des problèmes plus grands.

L’autonomie de la batterie continue de s’améliorer pour que les voitures aient davantage d’autonomie et améliore leurs performances: 100km/h en 2.28 secondes, la technologie de conduite sans chauffeur réduit les accidents, la seconde phase de Tesla introduit des bus et des camions électriques, la fusion de Tesla avec Solar City et l’achèvement de Gigafactory.

3. Communiquez constamment la vision du grand problème.

La vision suprême de Musk est une planète actionnée entièrement par le soleil et finalement habiter de multiples planètes. Il n’est pas le meilleur communicant du monde. Beaucoup de ses discours sont maladroits (il s’améliore avec le temps). Mais il a capturé l’attention du monde parce qu’il communique constamment sa vision, en livrant des mVPs tout au long de ce voyage.

Imaginez si Musk avait commencé à résoudre son grand problème en construisant d’abord la Gigafactory (avant Tesla et Solar City). Il pourrait avoir lancé un mVP qui produise 1 batterie par mois. Cette idée n’irait nulle part, parce qu’il ne nous aurait pas embarqué dans ce voyage depuis où nous nous trouvons maintenant vers où il voit que nous devons aller. Son mVP ne serait pas viable.

Les entrepreneurs font très souvent l’erreur de commencer par le grand problème. Ils livrent alors un mVP, mais le marché ne répond pas parce qu’ils ne nous ont pas embarqués sur le voyage exigé. Le résultat ? mVP non viable qui aboutit souvent à un flop.

Processus mVP en 3 étapes en pratique

Disons que vous ayez lancé votre produit. Une poignée de clients a signé pour votre première version. Votre outil de suivi vous dit qu’il y a des téléchargements. Mais vous remarquez aussi que l’engagement est très faible. Vos projections financières sont loin de l’utilisation que vous aviez prévue.

Contrairement à la croyance populaire, ce n’est pas un désastre.

La bonne nouvelle est que les gens adhèrent à une certaine partie de votre vision. C’est le premier pas dans la validation de votre marché. C’est à ce moment que le responsable de la stratégie produit doit sortir du bureau, parler aux clients et comprendre la situation :

  • Quelle est exactement la partie de votre vision qui a initialement capté leur attention ?
  • Qu’est-ce qui précisément rend votre produit difficile à utiliser pour atteindre la vision ?
  • Y a-t-il quelqu’un d’autre qui fait ceci mieux que vous? Que fait-il différemment ?
  • Le problème est-il que les clients veulent résoudre un problème différent de celui que vous adressez ?

C’est un processus systématique d’analyse et de compréhension du sens. C’est un processus scientifique qui se base sur des données et une métrique bien définie. Mais le processus est guidé par la vision de l’artiste qui imagine un futur meilleur plus enrichissant. Non seulement l’artiste voir l’avenir, mais il peut voir le chemin à parcourir pour atteindre cet avenir. Et il sait que les livraisons de mVPs sont comme des tremplins pour nous déplacer d’ici jusque là-bas.

C’est ma compréhension de ce que fait un Produit Viable Minimal qui est réellement Viable.

Quelle est la vôtre ?