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

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

Prioritization is More Art Than Science

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

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

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

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

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

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

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

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

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

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

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

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

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

#3 – Prioriser c’est aussi suivre son instinct

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

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

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

SAFe 5.0, une brève avant-première par Henny Portman

Elle arrive bientôt, la nouvelle version de SAFe !

SAFe 5.0 brief preview

https://hennyportman.wordpress.com/2019/10/08/safe-5-0-brief-preview/ par Henny Portman

Au début 2020, une nouvelle version de SAFe sera disponible. Elle est, comme d’habitude, entièrement compatible avec la version précédente SAFe 4.6, permettant une migration en douceur.

Il y a maintenant 7 compétences fondamentales qui permettent l’agilité dans le business. Certaines sont repositionnées et restructurées et 2 nouvelles compétences étendent SAFe afin qu’il englobe l’entreprise toute entière et permettent l’agilité d’affaires. Voir la nouvelle grande image de SAFe.

Les deux nouvelles compétences sont : Culture d’Apprentissage Continu (Continuous Learning Culture / CLC) et Agilité Organisationnelle (OA).

La Culture d’Apprentissage Continu est basée sur trois dimensions : L’Organisation Apprenante (vision partagée, systems thinking, modèles mentaux, apprentissage dans l’équipe, maîtrise personnelle), l’Amélioration Inexorable (un sentiment constant de danger, optimisation de l’ensemble, culture de résolution de problème, Prise de recul aux événements marquants principaux, l’amélioration basée sur les faits) et la Culture d’Innovation (les gens innovateurs, le temps et l’espace, aller voir, expérimentation et réactions, pivoter sans pitié ni culpabilité, innovations à contre-courant).

Les trois dimensions d’Agilité Organisationnelle sont : des gens pensant LEAN et des équipes agiles (house of lean, principes SAFe, Manifeste Agile), des Opérations LEAN (temps de traitement –temps d’attente – temps de traitement) et Agilité de Stratégie.

L’ancienne compétence DevOps et release on demand est maintenant appelée Livraison de Produit Agile (Agile Product Delivery). Ici nous voyons des développements sur la Cadence, la livraison sur demande, DevOps et le Pipeline de Livraison en Continu. Une nouveauté est  la Position Centrée sur le Client Customer Centricity qui comprend : étude de marché, design avec l’utilisateur) et Design Thinking dans la Livraison Agile de Produit.

Livre sur mazon

Les équipes business de l’entreprise montent maintenant ‘sur le train’ et participent à la livraison et au support de solutions business innovantes. Ces équipes adoptent les valeurs, principes et pratiques Lean et Agiles.

Un dixième principe SAFe est ajouté : S’organiser autour de la valeur. Ce principe est basé sur Kotter ‘dual operating system’ comme décrit dans son livre XLR8 – Accelerate. Building strategic agilty for a faster moving world.

Si je prends une vue d’ensemble de la forêt agile, je replace SAFe pour souligner que SAFe couvre maintenant, au niveau produit, cible produit ainsi que le choix de culture.

Voir Bird’s eye view on the agile forest blog pour l’article complet.

Voir le Scaled Agile website pour plus d’information sur SAFe 5.0

Guide Kanban pour les équipes Scrum par Scrum.org

Un tout nouveau guide disponible gratuitement et traduit en français.

 

à télécharger en ligne

L’approche Kanban, orientée flux, peut améliorer et compléter le cadre de travail (Framework) Scrum ainsi que sa mise en œuvre. Les équipes peuvent ajouter des pratiques Kanban complémentaires, qu’elles débutent avec Scrum ou l’utilisent déjà.

Le Guide Kanban pour les équipes Scrum est le résultat d’une collaboration entre des membres de la communauté Scrum.org et des leaders de la communauté Kanban.

Ensemble, ils supportent Le Guide Kanban pour les équipes Scrum. Ils partagent la conviction que les professionnels du développement de produits peuvent bénéficier de l’application de Kanban couplée à celle de Scrum.

CertYou est partenaire de DantotsuPM

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

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

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

MVE and MVP and MMF: Defining the Difference

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

Source : Egg Lighting

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

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

Définissez les divers Minimums

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ndlt : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.

Copyright 2000 Don Wells

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

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

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

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

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

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

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

Les MVPs fournissent des retours à l’équipe

Produit Viable Minimum (MVP)

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

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

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

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

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

Vos minimums sont-ils assez petits ?

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

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

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

Livre sur Amazon

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

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

 

scrum methodologie agile

si vous voulez devenir formateur certifié Scrum…

Scrum Inc a créé le « Licensed Scrum Program »

PMGS est partenaire de DantotsuPM

La mission du Scrum Inc « Licensed Scrum Program«  est de développer Scrum dans le monde entier, en libérant les gens des servitudes incroyables du système dans lequel ils travaillent. Nous sommes à un moment charnière où les plus grandes organisations du monde se rendent enfin compte que leur façon de travailler ne marche pas. Elles doivent changer et cherchent à le faire en faisant preuve « d’agilité », souvent sans les pratiques prouvées qui produisent de bons résultats.

Le programme « Licensed Scrum«  est conçu pour fournir aux particuliers et aux organisations une voie claire de mise en œuvre de Scrum d’une façon qui conduit à des résultats opérationnels immédiats et fait en sorte que Scrum ait un impact de transformation durable.

Ce programme enseigne comment nous délivrons réellement deux fois plus de résultats en la moitié de temps dans des organisations à travers le monde entier. Les formations de Scrum Inc. comprennent les principes Lean, les modèles du mouvement Scrum Pattern Language et les leçons tirées des implémentations de Scrum@scale dans la vraie vie.

Visionnez cette vidéo de Jeff Sutherland, l’un des concepteurs de Scrum.


You can register for a class on our website: http://www.scruminc.com/LSProgram If you’re interested in becoming a Licensed Scrum Trainer, learn more at: http://www.scruminc.com/LST


CertYou est partenaire de DantotsuPM

 

Voici pourquoi le #PMI® a acquis Disciplined Agile

ACQUISITION DE DISCIPLINED AGILE PAR LE PMI  (press release)

Livre sur Amazon

C’est pendant l’été, le 12 août, que le Project Management Institute a acquis les

droits sur Disciplined Agile (DA).

 

La boite à outils DA est un ensemble complet de connaissances agiles (un Body of Knowledge – BOK) qui fournit des conseils simples et pratiques pour aider les personnes, équipes et entreprises à décider de leur « façon de travailler » en fonction du contexte.

Parmi les principes clés

  • Être centré sur le client
  • Être pragmatique plutôt que puriste
  • Proposer une large gamme d’options agiles et LEAN
  • Adapter ses pratiques en fonction du contexte
  • Optimiser les flux dans l’ensemble de l’entreprise

CertYou est partenaire de DantotsuPM

Il s’agit pour les organisations d’adapter « leur façon de travailler » à leur contexte.

Disciplined Agile a compris la nécessité de personnaliser toute méthode ou toute approche, traditionnelle et prédictive, Scrum ou SAFe, afin d’obtenir des résultats qui les différencient de leurs concurrents.

La combinaison de PMI et DA offre donc une proposition de valeur nouvelle et attractive. Voici, je pense, pourquoi le PMI a fait cette acquisition. Elle lui permet de rester à la pointe dans le management de projet en utilisant de manière pragmatique des approches Agiles quand cela fait sens pour le projet.

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

Si vous connaissez ou utilisez déjà Disciplined Agile, n’hésitez pas à me contacter pour partager votre expérience sur ce blog.

Manager à l’ère du numérique et de l’Intelligence Artificielle avec Cécile Dejoux

Lors du dernier forum National du PMI France, le demi-millier de très chanceux participants ont pu échanger avec Cécile Dejoux !

Son entrée en matière a immédiatement capté notre attention avec une intéressante analogie gastronomique : « Nous sommes dans une nouvelle civilisation : Avant, on faisait confiance à l’expert, aujourd’hui à la multitude. »

Il s’agissait bien sûr des recommandations du guide Michelin versus celles de Trip Advisor.

Cécile entra ensuite dans le vif du sujet avec 4 étapes pour réussir toute transformation numérique.

  1. Repérer les dysfonctionnements
  2. Alléger les processus
  3. Tester de nouvelles méthodes de travail
  4. Penser en écosystèmes

Elle a identifié 4 compétences numériques

Livre sur Amazon

Sans dévoiler toute la pertinence de l’approche que vous retrouverez dans son ouvrage « Métamorphose des managers : à l’ère du numérique et de l’intelligence artificielle » que je vous invite à lire, j’ai tout de même noté cette liste intéressante, celle des compétences numériques.

  1. Curation
  2. Granularisation
  3. Partage
  4. Valorisation

4 Compétences d’Agilité

Pour vous donner envie d’en apprendre davantage sur son blog et ses MOOCs…

  1. Aller Vite
  2. Expérimenter
  3. Faire confiance aux personnes : « People before process »
  4. Nouveaux usages

Pour aller plus loin

Suivez l’actualité de Cécile Dejoux : https://www.ceciledejoux.com/presse  et découvrez ses ouvrages et MOOC dont voici un teaser.

De nombreuses présentations de la  journée de management de projet 2019 du PMI France sont disponibles sur le site du PMI France

Est-il plus pertinent pour vous d’adopter une approche itérative Agile, une prédictive comme Prince2 ou de mixer les 2s ?

La promesse de PRINCE2 Agile : une parfaite tempête ?

https://www.citi.co.uk/blogs/methodology/the-promise-of-prince2-agile/ par Jane Nichols

Comment avoir une approche de management de projet en laquelle on a déjà confiance et y ajouter le nouveau ‘ test de pertinence ’ pour s’assurer que l’approche adoptée est la bonne pour le projet en question ?

PMGS est partenaire de DantotsuPM

Une parfaite tempête de circonstances dans la gestion de projet dans le secteur public au Royaume-Uni aide à ouvrir la porte aux méthodes agiles et en particulier aux promesses de PRINCE2 Agile.

D’abord, certains projets n’ont pas atteint le succès escompté, ne livrant pas le produit escompté ou ne répondant pas aux attentes des parties prenantes. En combinant ces problèmes  avec la suite probable de mesures d’austérité du Gouvernement et encore plus d’attention sur les projets rend fort attirante l’opportunité d’avoir l’accès à des méthodes qui aideront à les mener plus efficacement.

D’autre part, il y a eu des dépenses significatives engagées dans les formations et certifications  PRINCE2® dans les secteurs tant publics que privés et les organisations veulent s’assurer que leurs investissements produisent un retour maximal. Les managers de projets qui ont acquis une certification de base ou avancée pourraient appliquer leur expertise de ces pratiques pour un effet encore plus important en se servant plus largement de la méthodologie qu’ils ont appris pour réussir l’examen. Cela signifie porter l’utilisation de PRINCE2 au-delà de la connaissance sur une application tangible et augmenter le retour sur l’investissement en conséquence. Et c’est pourquoi la création de PRINCE2 Agile fournira une combinaison gagnante de méthodologies aux projets : Ajouter Agile à l’approche PRINCE2 la rend plus flexible, pratique et de valeur.

Il s’agit de prendre l’approche de management de projet en laquelle on a déjà confiance et d’y incorporer le nouveau ‘ test de pertinence ’ pour s’assurer l’approche adoptée est la bonne pour le projet en question. Cela aidera les managers de projet à développer leur capacité professionnelle à choisir la meilleure approche pour un projet et prendre les bonnes décisions plutôt qu’être contraints à utiliser une seule et unique méthode.

QRP International est partenaire de DantotsuPM

Pourquoi mixer PRINCE2 et Agile ?

Le cocktail combinant PRINCE2 et Agile amènera les praticiens au-delà du simple ‘ posséder la connaissance ’ et les équipera de techniques pratiques pour démarrer. L’avantage d’utiliser les deux approches ensemble signifie que les managers de projet ‘ ne repartent pas de zéro ’ mais construisent sur leurs connaissances existantes.

Du point de vue d’une organisation, cela aidera à rentabiliser l’investissement fait dans PRINCE2 et adresser des secteurs où, parfois, cela ne convient pas tout à fait. En termes simplistes, cela permettra aux organisations d’être plus agiles en utilisant des approches qui aident à produire ce que veut l’utilisateur sans s’attendre à ce que l’utilisateur dise d’entrée de jeu “je sais ce que je veux”. Au lieu de cela, le projet peut présenter le résultat possible dans des livrables plus petits et les évaluer avec l’utilisateur pour démontrer ce qui est possible sans devoir décider du produit final dès le départ.

Cette façon de travailler permet d’apprendre rapidement, de manager plus efficacement les exigences des utilisateurs, de contrôler les dépenses et d’augmenter la probabilité de livrer le bon produit au final.

Partenaire de DantotsuPM

Dépasser la méthode : la promesse de PRINCE2 Agile

Tant dans PRINCE2 que PRINCE2 Agile, l’utilisation de l’approche dite de MoSCoW (classification des exigences projet entre : Must, Schould, Could et Won’t be included) est une façon pratique de donner aux managers de projet la capacité de retourner voir leurs sponsors et être explicites sur quels sont les éléments à fournir et selon quelles priorités.

Le manager de projet et l’équipe sont donc plus certains des besoins en ressources, des éléments à fournir par le projet et de comment tout cela s’aligne avec le cas d’affaires. Cela, à son tour, rend l’exécution du projet plus prévisible, plus sûre et en fin de compte avec davantage de chance de réussir.

Dans certaines formations PRINCE2, la technique de Moscow peut ne pas être détaillée à moins que les chefs de projet ne soient en position de prendre d’importantes décisions et cette approche peut donc être nouvelle pour ces managers de projet. PRINCE2 Agile comble le trou entre la théorie et la pratique avec une approche pour l’utiliser dans les projets qui devrait la rendre plus facile et plus fréquemment déployée.

Avoir la capacité d’aller au-delà du suivi d’une méthode ou une discipline et commencer à utiliser l’apprentissage résultant de l’expérience apportent extrêmement de valeur aux managers de projet. En fait, il s’agit de construire une plus grande compétence professionnelle, à long terme à travers la communauté des managers de projets et de programmes dans son ensemble.

‘Le 70-20-10’, le modèle d’apprentissage utilisé dans le secteur public correspond à 10 % pour l’étude en salle de formation, 20 % à apprendre des autres et 70 % par l’expérience. Cela signifie des managers de projet qui développent la capacité, par leur expérience aussi bien qu’études et obtention de qualifications, de gérer des projets plus complexes avec une plus grande confiance et meilleure efficacité. PRINCE2 Agile est un bon pont pour lancer les chefs de projet dans ce voyage vers l’application ce qu’ils savent.

Se concentrer sur le futur de la réussite de projet

Une nouvelle approche, comme la promesse de PRINCE2 Agile, accroit l’opportunité que les bons produits soient livrés pour répondre à un cas d’affaires. L’approche se fonde sur ce que l’on a déjà appris et devrait nous amener à progresser tant sur les  processus que les résultats réalisables. Pour des organisations considérant une aussi nouvelle approche, le critère de décision est simple : Obtenir un retour sur investissement.

Mais la volonté d’adopter une telle méthodologie exige la coopération des membres de deux communautés de pratiques tout à fait distinctes et leurs perceptions les uns des autres. La communauté Agile peut considérer PRINCE2 Agile comme inflexible alors que les praticiens PRINCE2 questionnent le niveau de contrôle avec des principes de livraison Agile.

Mais avec une compréhension des bénéfices mutuels sur le contrôle et la flexibilité, basée sur la communication claire de ces avantages, les deux camps devraient reconnaître la valeur que chacun peut apporter pour mener le projet au succès.

Clairement, la gestion du changement impliquant la dimension culturelle sera importante pour persuader des professionnels de projet que mixer PRINCE2 et Agile aura un impact positif sur leur travail dans le long terme.

#DevOPS n’est pas l’apanage des seuls services informatiques et développeurs !

Tous concernés si nous voulons réussir ce bouleversement dans la manière de développer, mettre en production et utiliser efficacement les produits des projets Agiles.

Dans son billet « 10 profils qui ont besoin de comprendre DevOPS », notre partenaire QRP recense au moins 10 rôles et autant sinon plus de départements dans l’entreprise qui ont besoin de se familiariser avec ces concepts et approche.

Lisez ce billet de QRP International, partenaire du blog DantotsuPM

Je vous invite à le lire, que vous soyez manager de projet, sponsor ou simple partie prenante potentiellement impactée par un projet mené en mode Agile (Marketing, Finance, Ventes, Support…).

Restez sur les rails en gardant à l’esprit les préceptes fondamentaux de Agile et les principes qui les sous-tendent.

Téléchargez gratuitement Le Manifeste Agile : 4 préceptes et 12 principes !

Imprimez-les, affichez-les au mur, faites-les suivre à vos équipes et surtout, appliquez-les !

Le Manifeste Agile a été écrit en février 2001 par 17 développeurs informatiques libres d’esprit. Il a donné naissance au mouvement Agile dans le développement de logiciels. Bien que chaque méthodologie Agile applique les préceptes et les principes à sa manière, ceux-ci leur servent de guide tout au long du processus de développement.

à télécharger en langue anglaise sur Agile Alliance.

Accédez à la vidéo de notre partenaire QRP International