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

Comment marchent les classes de service dans #Kanban ?

Les classes ou catégories de services servent à établir l’ordre de priorité des travaux en fonction du coût des retards (CoD – Cost of Delay)

Les équipes doivent être en mesure de gérer les dépendances et d’assurer l’harmonisation avec les jalons. Kanban utilise le concept de classe de service pour aider les équipes à optimiser l’exécution de leur arriéré.

Les catégories de services aident à différencier les items de l’arriéré (product backlog) en fonction du CoD. Chaque catégorie de service a une politique d’exécution précise que l’équipe accepte de suivre.

Par exemple :

  • Standard – Représente la catégorie de service de base applicable aux travaux qui ne sont ni accélérés ni à date fixe. La plupart des éléments de l’arriéré devraient entrer dans cette catégorie. Le CoD est linéaire pour les tâches standards, ce qui signifie que la valeur ne peut être atteinte avant la livraison, mais il n’y a pas d’exigence de date fixe.

 

  • A date fixe – Décrit les travaux qui doivent être livrés à une date précise ou avant. En règle générale, le CoD de ces items est non linéaire et est très sensible aux petits changements de la date de livraison; ceux-ci doivent être managés activement pour atténuer le risque lié au planning. Par conséquent, ces éléments sont passés en développement suffisamment tôt pour être terminés dans les délais. Certains peuvent nécessiter une analyse complémentaire pour préciser la durée estimée. Certains doivent être reclassés comme accélérés si l’équipe prend du retard.

 

  • Accéléré – Un élément de l’arriéré dont le CoD est inacceptable nécessite une attention immédiate. Il peut entrer en développement, même en violation des limites actuelles des Travaux en Cours (WIP – Work In Progress). En règle générale, il ne peut y avoir qu’un seul item accéléré dans le système à la fois, et les équipes peuvent établir une approche pour que cet élément avance rapidement dans le système. Si les équipes constatent que de nombreux articles nécessitent une intervention rapide, le système est probablement surchargé. Soit la demande dépasse la capacité, soit le processus d’entrée peut nécessiter plus de discipline. Quoi qu’il en soit, le processus doit être ajusté.

© Scaled Agile, Inc.

« PMI s’engage à développer des produits et services de pointe qui apportent de la valeur à nos parties prenantes. » Sunil Prashara

Sunil Prashara est président et CEO de PMI depuis un peu plus de 100 jours !

PMGS est partenaire de DantotsuPM

J’ai relevé dans le dernier message de Sunil Prashara, CEO du PMI, à ses membres ce passage sur les certifications à venir qui m’a paru particulièrement pertinent et qui dit à peu près ceci:

« Bien que le PMP® demeure la principale certification professionnelle en gestion de projet, la profession voit une forte adoption des certifications Agile. Il s’agit d’une lacune identifiée pour PMI, et mon équipe étudie des options pour ajouter davantage d’offres Agile à notre portefeuille de certifications, en plus de la certification PMI-ACP®.

Comme nous l’avons vu dans une récente vidéo intitulée « Straight Talk with Sunil » mettant en vedette le vice-président de Global Solutions, Mike DePrisco, je crois que nous devons accélérer nos efforts pour créer plus de produits et de services afin de donner toutes les clés au manager de projet d’aujourd’hui et de demain. Dans certains cas, il faudra que nous établissions des partenariats avec d’autres organisations pour améliorer et moderniser nos produits; dans d’autres cas, nous pouvons construire nos propres produits ou explorer des options d’acquisition.

Plus à venir sur ce sujet très prochainement. »

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

13th annual State of Agile report

Au fil des années, les changements et ajouts à ce rapport sont incroyables car l’adoption Agile a grandi et évolué.

Il est difficile de croire que DevOps n’était presque pas mentionné, il y a seulement quelques années. Alors que le rapport de cette année indique que 73% des répondants planifient une initiative DevOps ou en ont déjà une en cours. DevOps et Agile sont devenus de plus en plus liés en support aux entreprises qui cherchent à développer et à fournir des logiciels de qualité de manière plus efficace, plus rapide et plus rentable pour leurs clients.

Le 13e rapport annuel présente de nouveaux thèmes, des changements de priorités et des domaines d’intervention élargis.

Au fur et à mesure que DevOps et Agile deviennent plus courantes, il est nécessaire que les deux approches soient connectées afin de voir le changement se matérialiser et en tirer un avantage concurrentiel. Une visibilité accrue des résultats Agile et DevOps devient de plus en plus critique pour l’amélioration continue des équipes.

Voici les principaux thèmes et conclusions de ce 13ème rapport annuel sur l’état de l’agilité

  • La réduction des coûts du projet est un facteur essentiel de motivation pour l’adoption Agile
  • DevOps est devenue une priorité organisationnelle et la traçabilité de bout en bout est essentielle pour améliorer les pratiques DevOps
  • La gestion de la chaîne de la valeur n’est pas nouvelle, mais gagne encore en importance
  • SAFe domine les méthodes de démultiplication « Scaling Agile »

Vous pouvez télécharger une copie du rapport complet sur l’état de Agile sur www.StateOfAgile.com