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 ?

Accueil bienveillant des changements dans les besoins exprimés

Le principe Agile d’accueillir des exigences changeantes avec bienveillance peut s’avérer le plus difficile à adopter !

Welcoming Changing Requirements

https://www.scrumalliance.org/community/articles/2017/may/welcoming-changing-requirements par Joseph Collins

Quelqu’un qui a passé du temps dans le cycle de vie de développement de logiciel traditionnel peut certifier que le principe Agile d’accueillir des exigences changeantes peut s’avérer le plus difficile pour des organisations basculant vers Agile. Dans le cycle de vie traditionnel, changer les besoins génère de la frustration, de la colère, du désespoir et, dans certains cas, des frais d’avocats et des coûts additionnels.

CertYou est partenaire de DantotsuPM

Le mouvement Agile demande que les clients et les organisations de développement travaillent ensemble et embrassent le changement pour le plus grand bénéfice de l’utilisateur final. Ce niveau de transparence exige que les murs tombent entre clients et développeurs. Il nécessite aussi que le client reconnaisse l’impact que le changement aura sur le projet et le coût complémentaire du changement sur le budget de projet, ainsi qu’acquérir un meilleur niveau de compréhension du travail.

Le client et les développeurs  atteignent une compréhension mutuelle

Dans une mauvaise mise en œuvre de Agile, les clients pensent qu’ils peuvent changer les exigences aussi souvent qu’ils le souhaitent et que le personnel de développement doit gérer ces changements. « Hé, vous avez dit que vous étiez Agiles, non ? »

Dans une bonne mise en œuvre, le client et le développement travaillent ensemble en étroite collaboration pour examiner et adapter le produit à chaque occasion possible. Comme le produit est revu fréquemment, le client et l’équipe maintiennent une compréhension partagée de l’état actuel du produit et de l’état actuel du marché. Quand le client change des exigences, le changement, son coût de mise en œuvre et son impact sur le projet dans son ensemble, sont mutuellement compris.

Jeff Sutherland utilise l’expression « Money for nothing and your change for free » (« l’Argent pour rien et votre changement gratuit ») quand il conseille des organisations sur la façon d’écrire des contrats Agiles (ndlt. Tiens, je ne savais pas que Jeff est fan de Dire Straits). En essence, on tient compte des deux côtés pour avoir une flexibilité maximale; l’équipe de développement tient compte d’exigences changeantes sans modifier le contrat ni charger des honoraires de modification et, en échange, le client consent à participer conjointement au processus Agile et au cycle de vie du développement de logiciel. Dans le cas où le client est satisfait avec moins de travail que prévu à l’origine, ils peuvent finir le contrat plus tôt, avec le paiement d’une partie prédéterminée du contrat restant.

Le changement est bon

La position est que le changement est bon. Il permet au client de satisfaire l’utilisateur final avec les fonctionnalités de plus forte valeur et de terminer le contrat au plus tôt. Il permet à l’entité de développement de recevoir la juste compensation pour livrer tôt et leur permet de se passer à l’opportunité suivante.

avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets

« Accueillir des changements dans les exigences, même tard dans le développement » ne signifie pas que le propriétaire de produit, le « Product Owner », est libre d’ajuster les critères d’acceptation après que le sprint ait commencé. Les processus Agiles qui exploitent le changement pour y gagner un avantage compétitif devraient être mis en œuvre avant l’exécution de sprint. De l’avis de tous, il existe un processus pour terminer un sprint plus tôt; cependant, c’est rare.

Les processus agiles facilitent l’élaboration progressive, la décomposition, le raffinement de l’arriéré de produit, une approche incrémentale et la planification de sprint; Ils exploitent pleinement le changement tout en protégeant l’équipe.

fausses idées sur l’arriéré de produit (Product Backlog)

L’Arriéré de Produit n’est pas une liste géante d’histoires utilisateurs

Misconceptions about the Product Backlog

http://www.extremeuncertainty.com/misconceptions-product-backlog/  par leontranter

Il y a beaucoup de fausses idées sur l’Arriéré de Produit. En fait, je dirais que c’est probablement l’artefact le moins bien compris de Scrum. Et cela peut causer de gros problèmes, pas seulement pour votre produit et son planning, mais pour vos développeurs également. Étant un propriétaire de produit et manager cette chose est un travail difficile et il est facile se tromper. Cet article dissipera certaines des fausses idées sur l’arriéré de produit.

L’Arriéré de Produit n’est pas une liste géante d’histoires utilisateurs

Beaucoup de gens pense que l’arriéré de produit est essentiellement une grande liste d’histoires d’utilisateurs, classées de la plus haute à la plus faible priorité. Comme si vous aviez un grand tableau et chaque ligne dans le tableau était une histoire d’utilisateur, avec un identificateur, un nom et une description et c’est votre arriéré.

Cela semble agréable et simple, mais c’est un arriéré de produit épouvantable, pour nombre de raisons :

  • Les histoires ne sont reliées l’une à l’autre d’aucune façon significative
  • Il n’y a aucune dépendance entre les histoires
  • Les histoires sont non seulement sans rapport l’une avec l’autre mais elles ne sont liées à aucun horizon particulier ou version
  • Il n’y a aucune explication “de l’image plus grande” sur comment les histoires touchent au produit, ses fonctions et sa vision.

Un arriéré de produit est vraiment une feuille de route

Un bon arriéré de produit commence par une feuille de route, qui est une vue très de haut niveau de l’avenir du produit. Il y a évidemment beaucoup de choses que nous ne savons pas au commencement, mais un propriétaire de produit devrait commencer par une feuille de route et une vision de comment le produit pourrait se développer puis commencer à décomposer ce plan en des fonctionnalités ou des épopées et des versions ou des horizons.

roadmap to success...
Il s’agit d’une feuille de route

Cela vous permet de :

  • Rapprocher des histoires l’une de l’autre, via une fonction ou une épopée
  • Donner les dépendances entre histoires
  • Définir les fonctionnalités et épopées et quelle valeur elles fournissent et pourquoi vous les construisez.

Les fonctionnalités et épopées peuvent entrer dans l’arriéré. Et elles peuvent avoir leur propre description avec valeur, risque, bénéfices, dépendances et critères d’acceptation définis. Elles peuvent être évaluées et priorisées. Tout cela fournit “l’image plus grande”, la « big picture ». Si vous avez juste une liste d’histoires, comme quelqu’un l’a une fois dit, vous avez “un sac de feuilles, au lieu d’un arbre”.

Un arriéré de produit devrait être un arbre, pas un sac de feuilles

Donc vous voulez vraiment des histoires dans votre arriéré, mais vous voulez d’autres choses aussi. Et vous voulez que les histoires découlent de ces autres choses. Les histoires entrent en dernier, pas en premier.

arbre de la connaissanceAinsi, si vous voulez un arbre :

  • Débutez avec une vision de produit et une feuille de route
  • Décomposez-les en fonctionnalités et épopées
  • Dressez la carte des fonctionnalités et des épopées sur des horizons ou des versions
  • Décomposez -les alors en histoires d’utilisateur.

C’est un grand sujet et qui mérite beaucoup plus de couverture. Je recommanderais que vous lisiez User Story Mapping par Jeff Patton si vous voulez en savoir davantage.

Vous n’avez pas besoin d’évaluer toutes les histoires de l’arriéré

Certaines personnes pensent que vous devez avoir des évaluations sur tout dans l’arriéré, parce qu’autrement les items ne sont pas prêts à être travaillés. C’est-à-dire, ils ne respectent pas votre définition de « Prêts » (Ready). Et avoir quelques histoires prêtes à engager est bon, vous n’avez pas besoin que tout l’arriéré soit prêt à être entrepris. Le fait est que certaines des choses dans l’arriéré pourraient ne pas être travaillées avant une longue période de temps. Certaines d’entre elles pourraient ne jamais être développées. Et c’est OK.

Souvenez-vous, votre arriéré est fondamentalement superflu. Pour être plus spécifique, c’est le gâchis de type « Inventaire » en Lean. C’est une pile de choses qui restent là à attendre. Sans faire quoi que ce soit, sans allant où que soit, sans ajouter aucune valeur. Vous pouvez dépenser beaucoup de temps à construire, définir et évaluer un énorme arriéré de choses. Ou vous pouvez dépenser ce temps à faire en réalité du travail. C’est-à-dire à construire un logiciel.

Trouvez le bon équilibre

balance temps vs ressourcesIl existe un bon équilibre et le trouver n’est pas aisé. Si vous n’évaluez rien, vous ne savez pas combien de temps il faudra pour construire quoi que ce soit. Si vous évaluez tout, c’est beaucoup de travail. Je pense qu’il est bon d’utiliser un système « n+1 » ou « n+2”, où vous avez le prochain ou les 2 sprints suivants de travail bien défini et évalué et prêt à entreprendre. Ainsi, si vous entrez dans la planification de sprint, vous pouvez avoir une vue d’où vous allez vous rendre. Et si les choses changent et que vous décidez de prendre quelque chose d’autre dans l’arriéré qui est un peu plus loin, vous pouvez aussi le faire. Mais vous ne dépensez pas 90 % de votre temps en planification et estimations.

Mais comment faisons-nous la planification d’une version si nous n’avons pas évalué les histoires ?

Les gens se bloquent sur ce point, mais c’est très simple. Vous pouvez simplement utiliser des moyennes. Donc, vous avez les un ou deux sprints d’histoires évaluées et pour le reste de votre arriéré, vous pouvez juste utiliser des points d’histoire médians (pour cette équipe) pour chaque histoire. Si vous avez 50 points d’histoires dans vos deux sprints suivants, avec une moyenne de 6.2 points (ce ne sera probablement pas un nombre de Fibonacci). Vous avez 30 autres histoires dans votre arriéré. Donc votre taille d’arriéré de produit est de 186 (6.2 fois 30) plus 50 (vos sprints évalués) pour un total de 236. Vu ? Facile.

La vérité est, quelques histoires s’avéreront être plus grandes que la moyenne et certaines s’avéreront être plus petites et c’est OK. Parfois votre vitesse sera plus élevée, parfois plus lente et c’est OK. Si vous le pouvez, essayez de faire décomposer les histoires en tailles semblables, proches des 5 ou 8. Cela rend l’affaire plus simple et plus précise. Vous pouvez même faire des estimations approximatives pour des fonctionnalités où vous n’avez pas décomposer les histoires, avec des évaluations de niveau de fonctionnalité, ou en utilisant un nombre moyen d’histoires par fonctionnalité et en multipliant le tout.

Souvenez-vous, l’estimation n’est pas porteuse de tant de valeur en premier lieu. N’y investissez pas trop de temps. Parce que les incertitudes sur les bénéfices sont plus fortes que les incertitudes sur les dépenses.

Vous ne devriez pas mettre chaque idée à laquelle vous pouvez penser dans l’arriéré

Certains propriétaires de produit se lâchent un peu trop quand ils passent sur Agile et disent “Super, je peux mettre tout ce que je veux ici ! Étonnant !”. Et passer les 20 jours suivants à bourrer l’arriéré de plein de particules et des pièces aléatoires, comme des gosses dans une confiserie.

Ce n’est pas une bonne pratique. Souvenez-vous, les articles dans l’arriéré sont une forme de gâchis. Vous voulez une feuille de route claire et une vision pour votre produit, pas une grande liste aléatoire de blanchisserie “de choses qui pourraient être sympas”. L’arriéré devrait refléter votre vision et stratégie pour le produit. Il devrait être capable de prendre en compte des changements, mais ne l’exagérez pas et surinvestissez pas. Concentrez-vous sur votre sprint actuel et paire suivante de sprints. Essayer de penser beaucoup plus loin que cela est de la pure spéculation et n’apporte pas de valeur.

CertYou est partenaire de DantotsuPM

Vous pouvez aussi totalement enlever des choses de l’arriéré

Des personnes pensent qu’une fois que quelque chose entre à l’arriéré, il ne peut jamais en ressortir. Ils pourraient penser “quel serait le point d’ôter quelque chose de l’arriéré ? C’est juste une idée, c’est juste un item de contenu potentiel. Nous pourrions ne jamais le construire, mais il n’y a aucun mal à le garder là”. Il y en a, c’est du superflu. Il introduit de la confusion embrouille les choses. De nouveau, l’arriéré n’est pas une liste de blanchisserie, c’est une feuille de route des fonctionnalités par version et qui reflète une vision et une stratégie de produit. Tenez-le fermement et propre et à jour. N’ayez peur de supprimer des choses. Si vous voulez vraiment y revenir plus tard, vous pourrez probablement la déterrer ou y bien réfléchir de nouveau (les choses peuvent avoir changé et reprendre le besoin pourrait ne pas être une mauvaise chose de toute façon).

Les développeurs devraient avoir voix au chapitre dans l’arriéré de produit

Certains pensent que l’arriéré de produit est exclusivement le domaine du propriétaire de produit. Et c’est partiellement vrai, mais pas tout à fait. Le propriétaire de produit dit ce qui y entre et dans quel ordre. Il est responsable de l’arriéré de produit. Et généralement, les développeurs s’occupent de l’arriéré de sprint, puisque c’est leur domaine. Ils construisent la portée qui entre dans le sprint. Mais un propriétaire de produit avisé parle toujours à l’équipe comme il construit et manage l’arriéré.

Les développeurs comprennent de domaine technique du produit. Ils comprennent ce sur quoi d’autres équipes travaillent et quelles nouvelles technologies arrivent (au minimum, ils le devraient). Ils comprennent les risques techniques et les dépendances dans le travail. Donc la discussion sur l’arriéré de produit avec eux est extrêmement importante.

La planification de sprint devrait être un environnement “sans aucune surprise”. Personne ne devrait lever la main en lisant un article de l’arriéré et dire “qu’est-ce diable que cela ? Je n’ai même aucune idée de ce que cela signifie ». La planification de sprint devrait être le choix final de quels articles de portée bien définis et compris de l’équipe prêts pour entrer dans le sprint.

J’espère que cet article effacera quelques fausses idées sur l’arriéré de produit! C’est un sujet important, difficile et il existe beaucoup de lectures que vous pouvez faire si vous êtes intéressés par ce sujet.

Certifications Agile et Scrum

Agile and Scrum Certification

http://www.growingagile.co.za/2013/01/agile-and-scrum-certification/  par Karen Greaves

Scrum Alliance

La Scrum Alliance était le premier organisme de Certification Scrum, fondée en 2002. Elle offre une gamme de Certifications Scrum, la plus populaire étant le Certified Scrum Master (CSM). Il y a actuellement plus de 400000 CSMs dans le monde. Le CSM est une certification de niveau d’entrée. Pour obtenir le CSM vous devez suivre une formation de 2 jours donnée par un Certified Scrum Trainer (CST) et réussir ensuite un test en ligne avec le livre ouvert. Pour trouver une formation proche de vous, allez sur le site  de la Scrum Alliance. Les tarifs des cours varient selon la région et le fournisseur. Si vous considérez cette certification, la meilleure approche est d’acquérir quelques mois d’expérience avant d’y aller. Ainsi, vous saurez quelles questions poser et les parties sont les plus difficiles pour vous.

La Scrum Alliance offre aussi une certification de niveau d’entrée pour des Propriétaires de Produit appelés le Certified Scrum Product Owner (CSPO). Un cours de 2 jours donné par un CST. Actuellement, il n’y a pas de test sur le CSPO.

Certified Scrum Product Owner offre un parcours de certification avec Certified Scrum Professional (CSP), Certified Scrum Coach (CSC), Certified Enterprise Coach (CEC), Certified Agile Leader (CAL) et Certified Scrum Trainer (CST) pour ceux avec plus d’expérience. Vous pouvez en découvrir davantage sur ces programmes sur le site de la Scrum Alliance.

Scrum.org

Ken Schwaber a quitté la Scrum Alliance et formé Scrum.org en 2009. Ils offrent maintenant des certifications Scrum. Vous pouvez passer la certification Scrum.org en ligne sans suivre de formation. La certification Scrum.org est appelée Professionnel au lieu de Certifié. PSM au lieu de CSM. Il y a des niveaux multiples sur chacune des certifications de Scrum.org, c’est-à-dire PSM I, II et III. Il y a actuellement plus de 75000 I PSM, 600 PSM II et 360 PSM III dans le monde. On considère le PSM comme l’équivalent du CSM.

Vous pouvez passer les évaluations sans suivre aucun cours, mais il y a un coût à prendre l’examen. Scrum.org offre aussi un Professional Scrum Product Owner (PSPO). Les prix des cours varient par région et formateur.

Project Management Institute (PMI-ACP)

Listée en dernier parce que ce n’est pas une certification spécifique à Scrum, il y a l’offre du PMI : le Praticien Certifié Agile (PMI-ACP). Actuellement il y a 17000 détenteurs de la certification PMP-ACP. C’est une offre agile semblable au PMP dans la gestion de projet traditionnelle. Elle exige la preuve tant d’expérience de gestion de projet traditionnelle que d’expérience agile et il faut réussir une évaluation dans un centre d’examen autorisé.

Pour tous les détails (en anglais)

Bien qu’il n’y ait aucun cours spécifique exigé, 21 heures de formation sont requises. Comme avec le PMP, il y a des cours préparatoires disponibles pour fournir les heures de formation nécessaires et couvrir le matériel que vous devez connaitre.

CertYou est partenaire de DantotsuPM

“PMI,” the PMI logo, “PMP,” “Project Management Institute” and “PMI-ACP” are registered marks of Project Management Institute, Inc.

Rencontres sur le management de projets – 15 au 21 Janvier 2018

Les rendez-vous sur le management de projets et le leadership que je vous conseille pour la troisième semaine de Janvier :

Lundi 15

L’intention de la Communication Collaborative (appelée aussi Communication Non Violente, processus mis au point par Marshall B. Rosenberg) est de créer une qualité de relation avec soi-même et les autres, qui permette à chacun au sein d’une organisation et à tous de construire des espaces relationnels agiles et efficaces. Elle transmet le langage de l’essentiel pour développer son assertivité, oser la confrontation bienveillante, Identifier la solution optimum pour construire la confiance. Cet art du dialogue permet de booster la qualité des relations interpersonnelles au service de la performance collective.

Mardi 16

Yvan Bourgnon a souvent, au cours de ses courses transocéaniques en multicoque, heurté des objets flottants non identifiés. En 2015 encore, lorsque  le bateau avec lequel il participait à la Transat Jacques Vabre entra en collision avec un container, l’obligeant à abandonner la course. Confronté de façon brutale à la pollution océanique lors de cet incident mais aussi à l’occasion de son récent Tour du monde en catamaran de sport, Yvan Bourgnon  a décidé d’AGIR. Avec la création de son association « The Sea Cleaners  » dédiée à la lutte contre la pollution océanique, il se lance dans la construction d’un navire révolutionnaire « Le Manta  », collecteur de déchets plastiques.

Méta Projets Management est partenaire de DantotsuPM

Dans tout projet, il y a des hauts et des bas. Lorsque l’on est dans le haut de la vague, il est facile de surfer, mais lorsque l’on est dans le bas, comment faire pour se motiver? Comme gestionnaire de projet, il est de notre responsabilité de se doter d’outils afin de rester positif et continuer à diriger notre équipe. Cet atelier vise à partager avec vous, quelques outils pour vous inspirer dans le développement de vos propres outils de motivation et de résilience.

La médiation est inhérente au métier de chef de projets. Delphine Bressy-Ransch, avocate de formation, présentera des techniques de médiation. Bruno Laude,  président du PMI France participera à cette session.

Learn more about the PMI Professional Awards, the overall PMI Professional Awards Program, and submit nominations for these professional awards! You can work within your PMI chapter and region to support PMI awards and reach out to award winners and finalists as an important resource for chapter/region learning.

Mercredi 17

Join Johanna Rothman as she discusses the measures that are actually useful in understanding what your team does, where the work is, and how long the work really takes. In addition, we’ll examine what it takes to explain the team’s progress to others : product backlog burnup chart, ways to talk about what’s done and not yet released, how to show others a working product.

Jeudi 18

Sans aucun doute, vous avez déjà entendu parler de la mise à jour 2017 de PRINCE2. Vous êtes certifié PRINCE2 Foundation ou Practitioner et comme tous les professionnels certifiés PRINCE2, vous avez de nombreuses questions sur la mise à jour. Ce webinaire met en avant le contenu de la mise à jour au niveau de la méthode, des modalités de certifications et le programme d’adhésion.

Partenaire de DantotsuPM

Stephen Denning will be presenting on What’s Next For Agile: Strategic Agility. Many organizations have embraced Agile management on the assumption that if they upgrade existing products and services through cost reductions, time savings or quality enhancements for existing customers (i.e. operational Agility), they will realize financial gains. Owing to increased competitive pressures, this assumption often proves incorrect and consequently top management support for Agile often flags. It turns out that major financial gains are more likely to come from strategic Agility, i.e. generating innovations that create entirely new markets and that turn non-customers into customers.

Software development is frequently discussed from a project management perspective, focusing on knowledge areas, challenges, specific business cases. In this presentation, we want to discuss Agile Software development from the Product Owner perspective, his/her role, profile, performance and challenges.

Praxis is a community driven framework which can help individuals and organisations realise the intended benefits of projects, programmes and portfolios. An entirely free framework, during this session several project and programme management experts will provide an overview of the Praxis Framework and discuss:

    • The integrated nature of the framework and how it encompasses knowledge, method, competency and a capability maturity model.
    • An introduction on how to navigate the website.
    • The key differences between the Praxis Framework and alternative best practice guides.
    • How to obtain a Praxis Framework Certification.
APMG est partenaire de DantotsuPM

La Biotypologie® est une méthode d’évaluation de la personnalité innée fondée sur l’analyse des caractéristiques génétiques des mains : chaleur, moiteur, largeur de la paume, longueur des doigts, forme des ongles, nombre de lignes, empreintes digitales. Basée sur la typologie des quatre tempéraments d’Hippocrate, la Biotypologie® est une approche universelle permettant de cerner les aptitudes naturelles et des motivations qui en découlent, indépendamment de l’ethnie, de la culture, de l’âge, du sexe et de l’origine socio-culturelle. Cela aide autant dans la lucidité sur soi (pour être en accord avec soi-même) que dans la compréhension mutuelle (pour désamorcer les conflits et les communautarismes).

ms scrum & kanban
inscriptions gratuites en ligne

Vendredi 19

CSP est partenaire de DantotsuPM

Votre environnement devient de plus en plus complexe, volatile et incertain ? Dans ce contexte vos managers doivent relever un grand défi : sortir de leurs automatismes et se réinventer dans leurs modes de fonctionnement. Leur mission désormais est de faire émerger de nouvelles formes d’organisations, plus agiles, au sein desquelles chaque collaborateur s’engagera librement, en tant qu’acteur d’un projet inspirant.

En un mot : inviter la vitalité au travail !

  • Webinar – QRP – 30 minutes, chrono en main pour comprendre la gestion de projet selon PRINCE2
    Partenaire de DantotsuPM

    Vous cherchez une méthode solide pour gérer et maîtriser vos projets de l’élaboration à la clôture? Vous recherchez une approche qui a déjà fait ses preuves et qui s’adapte facilement à votre environnement? Si vous répondez oui à l’une de ces questions, nous vous invitons à suivre ce webinar qui vous présentera en 30 minutes, chrono en main, le contexte de la gestion de projets, la méthode PRINCE2, ses éléments et ses bénéfices.

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

Partenaire de DantotsuPM

5 recommandations pour réussir les projets Agile

Tout est devenu ou doit devenir Agile de nos jours !

Five Tips for Agile Project Success

http://www.thinkbrownstone.com/2015/11/five-tips-for-agile-project-success/ par Meaghan Sorte

Il semble que tout le monde utilise Agile pour manager des projets de nos jours. Et il y a de grandes chances si vous questionnez vos contacts professionnels que vous constatiez qu’une certaine forme d’Agile dirige leur travail. À Think Brownstone, nous travaillons souvent étroitement avec des clients en tant que membres de leurs équipes projet Agile (tant comme experts UX que développeurs). Nous avons pu adapter nos méthodes Agile pour aider les clients à lancer avec succès des produits en permettant un processus flexible pour notre équipe.

Ci-dessous, je partagerai les 5 astuces qui nous ont aidés à réaliser ces succès avec Agile.

1. planifiez continuellement

La planification est continuelle dans tout projet qui n’est pas « en cascade ». La rapidité d’exécution des activités, les chevauchements de tâches et les exigences opérationnelles qui changent constamment demandent de l’attention. Vous ne connaîtrez pas chaque détail à l’avance, mais c’est bien. Le but est de rester maitre de la planification pour que vous soyez toujours un coup d’avance sur vos efforts de développement.

Même si cela peut sembler fastidieux, une planification appropriée en amont payera ses dividendes en cours de route. Une bonne façon de commencer est d’avoir une session de planification avec l’équipe entière (le propriétaire de produit, UX/Responsable de l’eXpérience Utilisateur, et les développeurs). Utilisez ce moment pour revoir le design de conception et permettre à l’équipe de poser des questions. Cette session est une bonne occasion de découvrir des domaines sur lesquels vous pouvez devoir faire des recherches plus approfondies. Cette sorte de planification vous aide aussi à savoir ce que vous ne savez pas (encore) et comprendre les risques que ceci pourrait poser.

Une fois que votre projet est démarré, la planification est tout aussi critique. Vous devrez surveiller l’arriéré de produit et la vitesse de livraison de l’équipe. Quand les priorités changent, comprendre les variables avec lesquelles vous travaillez vous aidera à planifier les sprints à venir et ajuster le sprint actuel si nécessaire. Vous devrez continuer à travailler avec votre équipe pour planifier, re-prioriser si nécessaire et ajuster es attentes. Juste quand vous pensez que vous avez fini de planifier, soyez prêt à planifier un peu plus.

2. faites ce qui est bien pour le produit

Parfois (en réalité, la plupart du temps) « la bonne façon » n’est pas la voie la plus facile, la plus rapide, ni la moins coûteuse. Cela ne signifie pas que vous devriez mettre en péril votre vision pour le cœur du produit. Déterminez la meilleure ligne de conduite, évaluez les impacts et prévoyez comment avancer. Les dates changent, les priorités changent et le monde avance.

Sur la même ligne de pensée, un propriétaire de produit avisé sait quand il est temps de prendre une décision difficile et tirer sur les rênes. Il y aura toujours encore une fonctionnalité à caser parce que c’est « une capacité à surprendre » ou parce qu’un grand client la demande. Prenez du recul pour considérer ce qui est le plus critique et voir s’il y a d’autres façons d’atteindre ce but. Le chemin peut ne pas sembler exactement comment vous l’avez prévu, mais vous pourrez probablement trouver un passage.

3. Sachez que les outils que vous utilisez sont seulement aussi bons que les données qui y entrent

Les équipes doivent comprendre tous les processus et flux de travail associés au projet et quelles sont leurs responsabilités dans ceux-ci. La dernière chose dont vous voulez vous inquiéter est un problème de communication surgissant à cause d’étapes manquées (qui peuvent en fin de compte causer des retards). Pour communiquer efficacement, assurez-vous que les membres du projet informent leur équipe quotidiennement lors des réunions standup et managent activement les statuts des tâches qui leur sont confiées.

Votre équipe devrait aussi opérer de façon systématique et communiquer de façon opportune pour qu’il soit facile de suivre le progrès. Trouvez des façons de fournir de la visibilité à ceux qui en ont besoin et supprimez le bruit pour ceux qui ne sont pas concernés. Les tableaux de bord peuvent être un outil puissant pour montrer comment le travail progresse et identifier rapidement les risques (les délais, la portée, ou des ressources) dans le projet.

4. Ayez une compréhension claire et partagée de ce que « done » signifie

Parce que les méthodes Agile varient, « done » peut avoir de significations différentes selon les projets. Ce qu’une équipe considère « done » peut ne pas correspondre à ce qu’une autre équipe en penserait. Pour éviter toute confusion, votre équipe devrait créer une définition partagée de ce que « done » signifie pour que tout le monde sache quand considérer une fonctionnalité complète.

finiSi vous êtes nouveaux en Agile, posez une définition simple. « Done » pour une fonctionnalité pourrait être défini selon des critères clairs d’acceptation pour déterminer si l’histoire d’utilisateur est complète. Les critères d’acceptation contiendraient une liste explicite de déclarations (avec un accepté/rejeté) qui manifeste si le livrable répond aux exigences. Une fois qu’une fonctionnalité a été codée et testée, elle peut être remise au propriétaire de produit pour la revue finale. Le propriétaire de produit acceptera alors (idéalement, par écrit) une fonctionnalité avant qu’elle ne soit considérée « done ».

5. Gardez l’objectif final à l’esprit

À un certain point dans votre projet, vous allez devoir faire des compromis. Quand ces situations surgissent, vous devrez prendre du recul et

vous demander, « Quel est le MVP ? (Minimum Viable Produit) ». Assurez-vous de livrer de la valeur – une réelle Valeurà vos clients et votre business. Si vous n’avez pas fait de recherche avec des clients, ne passez pas du temps à créer quelque chose qu’ils peuvent ne pas vouloir ni avoir besoin. Concentrez vos efforts sur ce qui va fournir un bénéfice à court terme et ce sur quoi vous pouvez continuer à construire dans l’avenir.

Produit Viable Minimum (MVP)

Bien que nous ne suivions pas un processus de développement logiciel Agile strict à Think Brownstone, les méthodes que nous avons adaptées se sont avérées fructueuses tant avec des projets internes que clients. Avec autant de sortes différentes d’Agiles utilisées, ce qui marche pour certains peut ne pas toujours marcher pour d’autres, mais nous avons constaté que garder ces 5 astuces à l’esprit peut mener au succès.

Quelles autres astuces avez-vous trouvées utiles pour manager des projets agiles ? Quel conseil pouvez-vous communiquer à celles et ceux qui sont nouveaux en Agile ? Répondez dans la zone commentaires de ce billet.

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

16 November – Webinar – Creating the « right » product roadmap with data

Details and registration online

Data can be qualitative or quantitative, and comes from multiple sources: customer interviews, product usage & funnel analytics, company financial performance, and internal stakeholders.

How do you use that data to create a product roadmap that is aligned with your organization’s business objectives?

  • Analyze information from multiple sources to determine what should be included on a product roadmap
  • Achieve stakeholder buy-in on a roadmap
  • Respond to new information and urgent needs while executing a long-term roadmap

Register for this free webinar: November 16, 2017 11 AM PST, 2 PM EST, 8 PM CET

Enregistrer

%d blogueurs aiment cette page :