Cependant, imaginez maintenant que vous exploitez un PMO allégé, agile et à la pointe de la technologie, qui contribue de manière mesurable à la réussite de votre organisation. Vous constaterez peut-être que ce PMO partage plusieurs caractéristiques avec les colibris. Le colibri est en effet le symbole même de ce qu’est un PMO allégé, agile et efficace.

Dans cet article, vous trouverez 10 caractéristiques que les PMO agiles partagent avec ces oiseaux. Les colibris :

• Appartiennent à une variété d’espèces différentes
• Font partie des oiseaux les plus petits
• Aiment les plantes à fleurs qu’ils pollinisent
• Volent avec une agilité déconcertante
• Sont très résistants à la fatigue
• Acquièrent des vocalisations par imitation
• Ont une haute résolution spatiale dans les champs de vision latéraux et frontaux
• Gardent la position de leur tête stable même dans les turbulences
• Peuvent entrer dans un état proche de l’hibernation
• Ont une espérance de vie de 3 à 5 ans
• Conclusion

Avant de passer en revue ces caractéristiques, regardez cette magnifique vidéo de National Geographic et admirez le comportement extraordinaire du colibri en période de turbulence.

A lire : Pourquoi se doter d’un PMO? Devoirs, Avantages et acceptation

Les colibris appartiennent à une variété d’espèces différentes

Les colibris sont de petits oiseaux agiles des Amériques. Ils constituent la famille des Trochilidae. Les colibris se répartissent en neuf clades principaux, les Topazes, les Hermites, les Mangues, les Brilliants, les Coquettes, les Patagones, les Gemmes de montagne, les Abeilles et les Émeraudes. Ils comptent entre 325 et 340 espèces !

Il en va de même pour les PMO. Les PMO peuvent appartenir à plusieurs branches ou clades (généralement de 3 à 7), du Bureau de Gestion de Projet ou de Programme au Bureau de Gestion de Portefeuille. Il peut s’agir d’un Bureau de Gestion de Projet d’Entreprise ou d’un Centre d’Excellence en Gestion de Projet. Il peut même s’agir d’un Bureau de Gestion des Initiatives Stratégiques. Beaucoup sont aujourd’hui chargés des grandes transformations (numériques), en tant que Bureaux de Gestion de la Transformation.

Ces branches comptent une grande variété de situations définies par les domaines, le niveau, l’étendue du contrôle ou l’expérience et les capacités dont elles font preuve. Il n’y a pas de taille unique. Cette diversité contribue certainement à l’agilité.

Identifier et compter toutes les personnes impliquées dans un PMO dans le monde est une tâche impossible. Les entreprises du Global 500 peuvent avoir plusieurs dizaines de PMO différents, du PMO d’une Business Unit jusqu’au PMO des systèmes d’information. LinkedIn donne plus de 1 000 000 de résultats lorsque l’on recherche des personnes dont le titre contient le mot « PMO ». Dans le même temps, Google donne 98 100 000 résultats pour une recherche avec « PMO » comme mot-clé.

La différence entre les colibris et les PMO est que ces derniers sont présents partout dans le monde et pas seulement sur le continent américain. LinkedIn recense 260 000 PMO aux États-Unis et des centaines de milliers en dehors des Amériques. Vous pouvez être sûr qu’ils ont tous une diversité passionnante basée sur leur culture, leur histoire et leur rôle dans leur organisation.

Conseils :

• Faites la différence entre le PMO et le « PM Officer ».
• Clarifiez ce que votre organisation appelle un PM Office avec une famille (PMO) et des clades (branches) comme Bureau de Gestion de Projet, Bureau de Gestion de Programme, Bureau de Gestion de Portefeuille, Bureau de Gestion des Initiatives Stratégiques, Bureau de Gestion de la Transformation, Centre d’Excellence de la Gestion de Projet.
• Tenez compte de la grande variété de personnes qui servent en tant que PM Officer ; clarifiez leur mission, leurs capacités et leurs besoins en développement personnel.
• Insistez sur l’objectif commun à tous : soutenir un portefeuille de projets, une transformation, un programme ou un projet.

Les colibris font partie des oiseaux les plus petits

Ils font partie des plus petits oiseaux, la plupart des espèces mesurant de 7,5 à 13 cm de long. Les colibris femelles ont tendance à être plus grandes, nécessitant plus d’énergie, avec des becs plus longs qui leur permettent d’atteindre plus efficacement les crevasses des fleurs hautes pour y trouver du nectar. Les femelles sont donc plus aptes à la recherche de nourriture, à l’acquisition du nectar des fleurs et à la satisfaction des besoins énergétiques liés à leur plus grande taille.

Les PMO agiles sont généralement très petits. Pouvez-vous imaginer un PMO lourd qui serait agile comme un colibri ? Dans le cas d’un leader du marché industriel, le PMO d’entreprise agile imite une volée d’oiseaux en coordonnant 35 petits PMOs et PM Officers décentralisés. Le graphique ci-dessus illustre cet exemple. Les PMO les plus efficaces que j’ai vus sont composés de très peu de personnes.

Dans une autre transformation mondiale de grande envergure, seules deux personnes constituaient le PMO. Cependant, ces deux personnes ont également créé et animé une communauté de dizaines de PMO décentralisés et allégés. Chacune d’entre elles était bien ancrée dans son organisation locale et était très dévouée, motivée et professionnelle. Ils ont agi localement en tant que mandataires du bureau de gestion du programme.

Conseils :

• Créez de l’agilité dans votre organisation en préférant un essaim de petits PMO distribués et diversifiés à un grand PMO monolithique.
• Faire en sorte que ces PMO établissent des liens, forment une communauté de pratique à l’échelle de l’organisation et partagent leur diversité.
• Influencez l’organisation en travaillant sur les interactions entre les PMO locaux

Les colibris aiment les plantes à fleurs qu’ils pollinisent de manière croisée

Les colibris adorent les plantes à fleurs porteuses de nectar. Ils dépendent du nectar des fleurs pour alimenter leur métabolisme élevé et leur vol stationnaire. De nombreuses plantes pollinisées par les colibris produisent des fleurs dans des tons de rouge, d’orange et de rose vif.

Les PMO aiment les grands projets, diversifiés et ambitieux. Il n’y a rien de pire qu’un projet ennuyeux pour lequel le PMO n’a ni défi à relever ni grand objectif auquel contribuer.

La plupart des PMO sont temporaires. Une fois que leur mission s’achève avec la fin d’un projet, ils passent à un autre projet. Un PMO qui passe d’un projet passionnant à un autre effectue une pollinisation croisée de ces projets.

En même temps, ils étudient et partagent une variété d’approches de gestion de projet, du démarrage « lean » à la gestion de mégaprojets ou à la gestion de portefeuilles d’initiatives stratégiques. Leur état d’esprit est constamment ouvert aux solutions les plus adaptées.

A consulter :  information sur la gestion de projet hybride (en anglais).

Ils maîtrisent même l’hybridation de plusieurs approches différentes au cours d’un même projet. Par exemple, ils introduisent des approches lean en amont, des approches agiles plus tard, et des approches waterfall dès que la plupart des incertitudes disparaissent.

Conseil :

• Assurez-vous que votre PMO est capable de comprendre et de s’appuyer sur une variété de corpus de connaissances, de méthodologies et d’outils.
• Utilisez les approches disponibles en fonction du niveau du projet (périmètre, portée, durée…). Certaines approches fonctionnent bien au niveau macro, d’autres au niveau micro. Ne les confondez pas.
• Là encore, tenez compte des interactions entre tous les éléments.

Les colibris volent avec une agilité déconcertante

Le colibri possède un certain nombre d’adaptations qui lui permettent de voler avec une agilité et une précision déconcertantes. Il peut voler en ligne droite, en marche arrière, vers le haut, vers le bas et même à l’envers. De toutes les espèces d’oiseaux connues, le colibri est peut-être l’une des plus emblématiques en raison de sa capacité unique à planer. Lorsqu’ils planent, les colibris bougent leurs ailes plus comme un insecte bourdonnant que comme un oiseau battant des ailes. Certains experts ont découvert que les ailes des colibris ont des propriétés aérodynamiques similaires à celles des pales d’un hélicoptère. Ils planent dans l’air à des rythmes de battements d’ailes rapides, qui varient d’environ 12 battements par seconde chez les plus grandes espèces, à plus de 80 chez certaines des plus petites. Parmi les espèces mesurées en soufflerie, la vitesse maximale dépasse 15 m/s (54 km/h) et certaines espèces peuvent plonger à des vitesses supérieures à 22 m/s (79 km/h).

Si vous voulez agir comme un PMO agile, alors soyez capable de voler en ligne droite, en marche arrière, vers le haut, vers le bas et même à l’envers au cours de votre effort ! Un tel PMO peut planer et soutenir des projets complexes avec une agilité remarquable lui permettant de naviguer dans les environnements les plus VUCA (Volatile, Uncertain, Complex, Ambiguous).

Ils interagissent avec les parties prenantes dans toutes les directions, verticalement (de haut en bas), latéralement (avec différentes fonctions, géographies, rôles). À l’instar de la manœuvre Cobra du Sukhoi Pugachev russe, ils évitent les manœuvres et les missiles de l’adversaire.

Le bureau de gestion de programme d’un client a réussi à contrer une opposition forte de la part du groupe de consultants internes de l’entreprise. Alors que ce dernier tentait d’imposer au comité de pilotage du programme une feuille de route linéaire et fixe, le PMO a opté pour une stratégie de sérendipité très souple. Le PMO a utilisé une tactique de diversion pour obtenir l’approbation de sa stratégie flexible.

Souscrivez à notre newsletter blog  et ne ratez plus aucune publication sur notre blog.

Les PMO agiles étudient et apprennent également les lois de la physique. Par exemple, ils apprennent qu’un système de contrôle doit être plus agile que le système qu’il prétend contrôler. Le système de gestion qu’ils mettent en œuvre doit répondre à cette obligation.

Un PMO de transformation complexe a mis en place un processus de prise de décision avec le comité exécutif qui était beaucoup plus rapide et efficace que l’ancien processus de gouvernance. Enfin, ils apprennent surtout les lois de la thermodynamique.

Par exemple, ils apprennent que les organisations sont des systèmes adaptatifs complexes. En tant que tels, les organismes dissipent leur énergie et mémorisent l’information (depuis Shannon, nous savons que l’énergie et l’information sont équivalentes). Et elles le font en augmentant constamment la vitesse à laquelle elles les dissipent (exactement comme notre univers est en expansion).

La conséquence de ce fait a poussé un PMO, bien que travaillant dans une entreprise très secrète, à construire un système de communication très ouvert et efficace de et vers toutes les parties prenantes. Ainsi, ils soutiennent leurs projets, programmes ou portefeuilles avec un état d’esprit très ouvert et un échange d’informations le plus large possible avec le monde extérieur.

Conseils :

• Mettez en œuvre un système de gestion qui vous rend plus complexe que le système que vous devez contrôler
• Échangez des informations avec le monde extérieur aussi rapidement que possible. La vitesse est un facteur clé de succès.
• Remplacez les feuilles de route linéaires, déterministes et inflexibles par des stratégies flexibles, opportunistes et sérendipiteuses.

Les colibris sont très résistants à la fatigue

Les colibris ont également la capacité de rester en vol stationnaire pendant de très longues périodes. Pendant le vol, la consommation d’oxygène par gramme de tissu musculaire chez un colibri est environ 10 fois supérieure à celle mesurée chez les athlètes humains de haut niveau. Les colibris sont rares parmi les vertébrés dans leur capacité à utiliser rapidement les sucres ingérés pour alimenter un vol stationnaire coûteux en énergie.

Les projets de longue durée constituent l’un des principaux défis des équipes de projet. Certains projets durent en effet très longtemps (parfois plus de 10 ans). Au niveau micro, certaines réunions sont également très longues (plusieurs jours). Si tout le monde est au courant des réunions quotidiennes, tout le monde endure également des réunions beaucoup plus longues (parfois plus d’une semaine).

Il est donc important que les PMO et les membres de l’équipe démontrent leur capacité à « planer » pendant de très longues périodes, tant au niveau macro qu’au niveau micro. Les PMO agiles peuvent anticiper la fatigue du projet créée par l’impact du changement sur eux-mêmes et sur les parties prenantes.

La figure ci-dessus montre un exemple typique d’analyse de la fatigue d’un projet. La plupart des employés d’une grande entreprise travaillent simultanément sur plusieurs projets, soit en tant que contributeur direct, soit en tant qu’utilisateur. Dans cet exemple, le PMO a interrogé plusieurs employés d’une population donnée et a évalué leur fatigue liée à tous les projets dans lesquels ils étaient engagés. Ensuite, le PMO a récupéré la capacité de réorganiser le portefeuille de projets pour réduire cette fatigue en faisant reconsidérer leurs plans par les sponsors du portefeuille et des projets concernés. Ce graphique a aidé une entreprise à rationaliser son portefeuille de projets avant de lancer un nouveau programme important.

Ils peuvent également reconnaître cette fatigue et proposer d’adapter le style de gestion de projet. Enfin, ils permettent à toutes les parties prenantes de mieux comprendre ce qui se passe. Les gens se sentent ainsi plus à l’aise avec le projet.

Conseils :

• Votre premier objectif en tant que PMO est de survivre. C’est la seule façon de mener un projet à bien. Maintenez l’équilibre entre votre vie professionnelle et votre vie privée (physique et mentale).
• Appliquez la même règle à vos parties prenantes et aux membres de votre équipe.
• Appliquez ce que l’on appelle la « via negativa » en éliminant les activités et les projets inutiles, redondants, oisifs ou médiocres avant d’en lancer de nouveaux.

Les colibris acquièrent des vocalises par imitation

Composés de gazouillis, de grincements, de sifflements et de bourdonnements, les chants des colibris proviennent d’au moins sept noyaux spécialisés du cerveau antérieur. Une étude d’expression génétique a montré que ces noyaux permettent l’apprentissage vocal (capacité d’acquérir des vocalisations par imitation), un trait rare qui n’existe que chez deux autres groupes d’oiseaux (les perroquets et les oiseaux chanteurs) et quelques groupes de mammifères (dont les humains, les baleines, les dauphins et les chauves-souris).

Les PMO imitent également leurs pairs ainsi que d’autres professionnels importants. Ils apprennent la dynamique humaine des parties prenantes de leur projet. Cette dynamique humaine comprend une variété de domaines. Parmi eux, on trouve la connaissance des langues, de l’histoire, des cultures, des comportements humains, des biais cognitifs.

Ils apprennent les capacités des secteurs professionnels qu’ils soutiennent. Dans une grande entreprise industrielle, bon nombre des PMO les plus performants avaient une longue expérience de la R&D, du marketing et des ventes ou de l’industrie.

Ces PMO utilisent également des outils, matériels ou immatériels, qui les aident à adapter leur travail aux particularités du contexte. Par exemple, les PMO qui soutiennent une transformation numérique utilisent des outils très spécifiques qui ne seraient pas aussi utiles pour la construction d’une nouvelle usine de fabrication, et vice versa.

Découvrez notre article sur  Comment les PMO peuvent-ils éviter les échecs des projets .

Voici quelques exemples de qualités que l’on retrouve chez des PM Officers de haut niveau dans des entreprises internationales.

• Ils pratiquent plusieurs langues étrangères.
• Ils adaptent leur style d’interaction aux préférences culturelles de leurs parties prenantes.
• Ils établissent d’abord des relations lorsque c’est important.
• Ils se concentrent sur les actions et les résultats lorsque cela est approprié.
• Ils naviguent entre le court et le long terme, entre les statuts des différentes parties prenantes, entre les attitudes individuelles et collectives.
• Ils utilisent même l’analyse linguistique pour déceler les caractéristiques cachées des initiatives, des rapports ou de la communication.

Conseils :

• Les grands PMO travaillent principalement sur les relations avec et entre les parties prenantes.
• Les PMO « colibris » apprennent le style de leurs parties prenantes et adaptent leur attitude en fonction des besoins afin de rendre les relations plus fructueuses.
• Ils adaptent leur style d’interaction aux caractéristiques culturelles (individuelles et collectives) de leurs parties prenantes (langue, comportement, compréhension mutuelle).
• Ils peuvent même utiliser l’analyse linguistique pour déceler les caractéristiques cachées des initiatives, des rapports ou de la communication.

Les colibris ont une haute résolution spatiale dans les champs de vision latéraux et frontaux

Au cours de l’évolution, les colibris se sont adaptés aux besoins de navigation du traitement visuel pendant le vol rapide ou le vol stationnaire en développant un réseau exceptionnellement dense de neurones rétiniens permettant une résolution spatiale accrue dans les champs visuels latéraux et frontaux. L’élargissement de la région du cerveau responsable du traitement visuel indique une capacité accrue de perception et de traitement des stimuli visuels en mouvement rapide, que les colibris rencontrent pendant le vol rapide vers l’avant, le butinage des insectes, les interactions compétitives et les parades nuptiales à grande vitesse. Les colibris peuvent même voir des longueurs d’onde allant jusqu’à l’ultraviolet.

Plus un projet est complexe, plus l’environnement est VUCA, plus l’information est importante pour un PMO. Cependant, il y a une limite à la quantité d’informations disponibles, et les informations pertinentes doivent être extraites de l’énorme bruit que représente une trop grande quantité d’informations.

Les systèmes complexes sont également très sensibles aux conditions initiales. Ce phénomène porte le nom d' »effet papillon ». Les informations recueillies en amont sont vitales. L’intelligence économique précoce est la clé qui permet d’éviter de grosses erreurs par la suite.

Les systèmes complexes sont également imprévisibles pour les cibles en raison de l’impossibilité d’obtenir des informations complètes sur leur comportement, micro et macro. Il faut donc à la fois comprendre le plus précisément possible le fonctionnement d’un système et élaborer des stratégies innovantes adaptées à un environnement incertain et volatile.

Voici un exemple concret. Une entreprise du Global 500 souhaitait axer ses équipes sur le client. Le graphique ci-dessus montre les capacités critiques de l’ensemble de l’organisation (une vue macro) nécessaires pour mener à bien une telle transformation qui comprenait la formation des employés, de nouveaux systèmes d’information et de nouveaux processus.

Le PMO qui a construit ce graphique, appelé Marimekko, a été en mesure d’identifier les principales lacunes dans certaines fonctions vitales en contact avec la clientèle (générant une micro-analyse) ainsi que les surcapacités dans des fonctions moins critiques.

Enfin, le colibri mémorise parfaitement la carte de son territoire, toutes les fleurs existantes et, surtout, toutes les fleurs récemment visitées. Le colibri ne perd donc pas de temps à visiter à nouveau une fleur qui n’a pas encore été réapprovisionnée en nectar. De la même manière, les PMO agiles disposent de « versions uniques de la vérité » disponibles 24 heures sur 24 et 7 jours sur 7. La caractéristique importante est leur disponibilité dans l’ensemble de l’organisation à tout moment. Si les données étaient erronées, elles ne résisteraient pas longtemps à la vue de tous.

Conseils :

• L’accès à des informations pertinentes est vital. Un PMO qui accède à une grande quantité de données pertinentes bénéficie d’un réel avantage concurrentiel.
• Séparer les données utiles du bruit de fond.
• Transformer ces données en informations (par exemple utiles à la prise de décision) et en connaissances (par exemple à capitaliser et à utiliser dans d’autres projets).

Les colibris gardent la position de leur tête stable même dans les turbulences

Dans des conditions d’écoulement d’air turbulent créées expérimentalement dans une soufflerie, les colibris présentent une position et une orientation stables de la tête lorsqu’ils sont en vol stationnaire près d’une mangeoire. Dans des environnements naturels remplis de mouvements de fond très complexes, les colibris sont capables de rester en vol stationnaire avec précision en coordonnant rapidement leur vision avec la position de leur corps.

Le PMO agile fait preuve de la même capacité vitale à maintenir la tête hors de l’eau. Les turbulences frappent un projet. L’incertitude et l’instabilité secouent le cours d’un projet. Les conversations avec les collègues, pendant les réunions ou avec les dirigeants peuvent être difficiles. Cependant, le PMO agile reste confiant, calme et concentré sur sa mission.

Lors de la réalisation d’un important programme de transformation au sein d’un leader du marché, un petit groupe de cadres s’est opposé à l’approche qui allait mettre en péril leur statut personnel. Il y a eu des remous liés à la politique interne. Ils ont contesté secrètement les compétences du chef de programme. Le chef de programme et le PMO ont tenu bon en tant qu’équipe indéfectible jusqu’à ce que l’opposition disparaisse avec les premiers résultats positifs.

Conseils :

• Aucune quantité de données ne garantira jamais la prévisibilité des résultats. C’est pourquoi le PMO doit étudier et apprendre des stratégies flexibles et adaptatives.
• L’incertitude fait partie de la vie. Elle est source de risques et d’opportunités. Les deux doivent être pris en compte.
• Certaines incertitudes ont une probabilité de type courbe en cloche. Leur prévision est logique. En revanche, d’autres opportunités ont une probabilité de type longue traîne. N’essayez pas de les prévoir. Au lieu de cela, travaillez uniquement sur leurs conséquences potentielles.

Les colibris peuvent entrer dans un état proche de l’hibernation

Pour conserver de l’énergie lorsque la nourriture est rare, et la nuit lorsqu’ils ne cherchent pas de nourriture, les colibris peuvent entrer en torpeur, un état similaire à l’hibernation, ralentissant le taux métabolique à 1/15ème de son taux normal.

Il peut arriver aux PMOs de traverser des périodes de désert. Les projets peuvent être manquants, ralentis ou en attente de décisions clés. Ils peuvent travailler sur une initiative qui est arrêtée, temporairement ou non.

Imaginez que vous souteniez un projet de construction dans une belle ville italienne. Imaginez également que lorsque les ouvriers commencent à creuser les fondations, ils trouvent des ossements de la Rome antique. Il ne fait aucun doute que le projet sera interrompu et que les archéologues prendront le pas sur les travaux de construction.

Il est arrivé quelque chose de pire à une PM Officer chargée d’un portefeuille de marketing et de ventes. Son nouveau patron ne pensait pas qu’un PMO apporterait une valeur ajoutée. Il ne l’a pas exprimé clairement. En revanche, il a laissé pourrir la situation. Rapidement, la PM Officer n’avait plus de place à aucune table. Les chefs de projet du marketing et des ventes l’ont également ignorée de plus en plus, suivant en cela l’attitude de leur patron. Cette PM Officer a passé d’horribles mois de solitude jusqu’à ce qu’elle quitte son emploi pour en trouver un autre dans un environnement plus accueillant.

Dans ce genre de situation, il est temps pour le PMO d’hiberner, voire de fuir ou de se battre. Le PMO expert comprend les préférences temporelles et sait qu’il doit être patient maintenant et impatient plus tard.

La plupart des grands leaders ont passé beaucoup de temps en exil, en prison ou dans le désert. Ne vous inquiétez pas si cela vous arrive.

Conseils :

• L’adversité momentanée fait partie de la vie.
• Ne craignez pas la solitude, le silence ou le désert dans ces cas-là. Ce sont autant d’occasions de se ressourcer, d’apprendre, de s’interroger, d’attendre la maturité et, en fin de compte, de préparer un avenir meilleur.

Les colibris ont une espérance de vie de 3 à 5 ans

De nombreux colibris meurent au cours de leur première année de vie, en particulier pendant la période vulnérable entre l’éclosion et l’envol. Ceux qui survivent peuvent parfois vivre une décennie ou plus. Parmi les espèces nord-américaines les plus connues, la durée de vie moyenne est probablement de 3 à 5 ans.

Cela ne semble pas trop différent de la durée de vie des PMO.

Tout d’abord, faisons la différence entre la durée de vie d’un PMO et celle d’un PM Officer.

Les PMO sont essentiellement temporaires lorsqu’ils soutiennent un projet ou un programme. En revanche, ils sont conçus pour durer longtemps (ou pour être permanents) lorsqu’ils s’occupent d’une stratégie organisationnelle, d’un portefeuille de projets et de programmes ou d’un centre d’excellence.

Les PM Officers ont une attitude différente à l’égard du temps.

Certains PMO « meurent » très tôt. Il y a deux raisons à cela. Premièrement, c’est souvent le cas lorsqu’ils n’ont pas les capacités attendues. Leur processus de recrutement néglige des caractéristiques clés, comme leur niveau de compétences dans chacune des trois dimensions du triangle des talents (technique, commerciale et de leadership).

Deuxièmement, la plupart des durées de vie courtes surviennent lorsque les chefs de projet et les responsables de la gestion de projet ne fonctionnent pas rapidement comme un système que l’on pourrait comparer à un réseau d’amis très proches. Le PM Officer quitte alors le projet très rapidement. C’est notamment le cas lorsque des chefs de projet faibles tiennent leur PMO pour responsable du manque de performance du projet.

D’autres PM Officers restent quelques années. Ils commencent et finissent avec le projet.

Une différence essentielle par rapport aux colibris est que les PMO ont le privilège de trouver une nouvelle vie (en trouvant un nouveau projet à soutenir) chaque fois que l’un d’entre eux s’en va.

Mieux encore, les PMO ont une carrière de plus en plus passionnante qu’ils peuvent gérer avec agilité. Ils ont la possibilité de soutenir des domaines et des projets de plus en plus vastes (pensez aux PMO des mégaprojets ou aux PMO d’entreprise). Ils maîtrisent de plus en plus d’approches de pointe en matière de gestion de projet (voir les progrès récents dans le domaine de la science de la gestion de projet). Ces PMO ont un champ de responsabilités plus large. Ils peuvent également passer d’un rôle de PMO à un rôle de chef de projet et revenir à un rôle de PMO.

Les centres d’excellence de premier ordre sont souvent des communautés de personnes expérimentées. Toutes ces personnes bénéficient d’un développement personnel et d’une satisfaction à l’égard de leur travail, vraiment considérables. Et c’est vraiment ce que je vous souhaite.

Conseils :

• Distinguez la durée de vie d’un PMO en tant qu’organisation et la durée de vie d’un PM Officer en tant qu’individu.
• Adaptez la première aux besoins de l’organisation et la seconde à vos besoins de développement personnel.
• Dans un environnement qui tire vers le haut, restez le plus longtemps possible. Dans un environnement qui tire au contraire vers le bas, minimisez vos pertes et partez dès que possible. C’est aussi cela l’agilité.

Conclusion – Pour les PMOs agiles sont comparables aux colibris

Le colibri est le symbole de plusieurs caractéristiques clés qu’un PMO agile doit présenter. Un PMO se consacre à une mission. Ses caractéristiques ne servent qu’à remplir cette mission avec succès.

Si vous ne deviez vous concentrer que sur trois caractéristiques, ce serait celles-ci :

• Être léger, décentralisé et travailler comme une communauté soudée avec d’autres PMO.
• Développer un champ visuel très large à l’intérieur et à l’extérieur de votre domaine, à différentes échelles et à différents horizons temporels.
• Devenez stable même dans les turbulences grâce à de solides compétences personnelles, au soutien de votre communauté et à une stratégie d’adaptation flexible.

Êtes-vous d’accord ? Faites-le moi savoir en laissant un commentaire ci-dessous.

Et vous ? Quelle est votre expérience des PMOs agiles ? Laissez-nous vos commentaires ci-dessous.

A propos de l’auteur : Philippe Husser est consultant, conférencier et auteur. Il a publié un livre qui aide les PDG, les chefs de projet et les PMO à mieux prospérer dans un monde VUCA : The High-Impact PMO. Il rédige des articles dans le domaine de la gestion de projets complexes. Il anime également des sessions de formation dans le cadre de programmes de développement pour les personnes à hauts potentiels dans les grandes entreprises. Auparavant, Philippe a développé et dirigé le PMO d’entreprise chez Michelin avec un système de gestion de portefeuille Progress Initiative global, une gamme de diverses approches de gestion de projet, et une communauté de PMO décentralisés dans les unités d’affaires, les fonctions et les régions. Avant cela, il a occupé des fonctions de gestion de programmes de transformation dans plusieurs entreprises mondiales du secteur de l’aérospatiale et de la défense. Enfin, il anime un réseau LinkedIn de plus de 31 000 adeptes dans le domaine de la gestion de projet. Il a été le représentant de Michelin au Conseil exécutif mondial du PMI.

Plus d’informatios sur Philippe Husser sur LinkedIn. Vous pouvez également le contacter par  e-mail ou par téléphone (+33 6 07 34 10 16).

Intéressé(e) par les outils agiles ? voilà un article pour vous: Quickly Compare 10 Top Agile Project Management Tools

Der Beitrag Pourquoi les PMO Agiles sont comparables aux colibris erschien zuerst auf Blog Gestion de Projets pour les Entreprises.

Dans cet article, nous vous présentons les modifications apportées à ce qui est probablement le cadre de travail agile le plus célèbre :

• Qu’est-ce que le Guide Scrum ?
• Moins de règles, un langage simplifié
• Une équipe
• Planification du Sprint : Quoi, comment, pourquoi ?
• Un objectif pour le produit
• Le rapport entre les objectifs et les artefacts
• La pensée “Lean”
• Conclusion – Guide Scrum 2020

Qu’est-ce que le Guide Scrum ?

Le Scrum Guide est le manuel officiel du cadre de travail agile le plus connu, rédigé par ses fondateurs Jeff Sutherland et Ken Schwaber. Il est conçu pour aider les individus, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives à des problèmes complexes. Le Scrum Guide 2020 en est à sa 6e édition. Auparavant, le guide avait été mis à jour en 2010, 2011, 2013, 2016 et 2017. Le sous-titre de la version actuelle est « Le Guide définitif de Scrum : Les Règles du Jeu ».

Découvrez le nouveau Guide Scrum 2020.

Moins de règles, un langage simplifié

Les créateurs Schwaber et Sutherland ont réduit la description du Guide Scrum 2020 au cadre de travail et à ses éléments fondamentaux. La raison en est que certaines déclarations qui s’étaient retrouvées dans le guide au fil des ans ont semé la confusion à plusieurs reprises. D’un’ manière général, Schwaber et Sutherland ont essayé de rationaliser quelque peu la nouvelle version et de la rendre plus facile à comprendre. Ainsi, il existe désormais une définition plus claire du backlog produit. Pour le Daily Scrum (Mêlée Quotidienne), ils ont supprimé les suggestions de questions auxquelles les participants pourraient répondre pendant l’événement – ce qui ne signifie pas bien sûr que vous ne pouvez plus poser de questions.

Intéressé par une certification Scrum ou autre certification agile certifications ? Consultez cet aperçu.

La version 2020 du Guide Scrum comprend désormais seulement 13 pages. Sutherland et Schwaber l’ont vraiment considérablement raccourci. Entre autres, ils ont enlevé toutes les références à des projets logiciels en particulier et se sont débarrassés de toutes les redondances. De plus, ils ont généralisé la formulation.

Une équipe

Il n’y a désormais qu’une seule équipe Scrum dans son entièreté et plus de sous-équipes. Cette équipe consiste en un Product Owner, le Scrum Master et les « Développeurs », anciennement dénommés « Equipe de Développement ». Leur objectif est de créer à chaque Sprint un incrément publiable (releasable). Ce changement souligne le fait que le Scrum Master porte également une grande responsabilité pour le résultat.  Il faut savoir aussi que le terme pour l’équipe de développement n’est pas le seul qui a changé dans le Guide Scrum 2020. Les « rôles » sont devenus des « responsabilités ».

Un autre changement est que l’on dit maintenant des équipes qu’elles sont « auto-gérées ». Le Guide Scrum 2017 utilisait encore le terme « auto-organisées ». Avec ce changement, Sutherland et Schwaber veulent appuyer sur le fait que l’équipe Scrum planifie, structure et surveille son travail, ses processus et son avancement de manière indépendante. En même temps, elle poursuit un objectif global qui va au-delà du développement de produits, en s’alignant sur la stratégie de l’entreprise qui est définie de l’extérieur. La taille de l’équipe indiquée se réfère désormais à l’ensemble de la Scrum Team, au lieu du nombre de développeurs comme c’était le cas auparavant, et se compose d’un maximum de 10 personnes. Elle doit rester aussi petite que possible, mais aussi grande que nécessaire. À titre de comparaison : l’équipe de développement de l’ancien Scrum Guide 2017 comprenait un maximum de 9 personnes

Planification du Sprint : Quoi, Comment, Pourquoi ?

Jusqu’à présent, la planification du Sprint se concentrait sur les points suivants :

• Que cherchons-nous à accomplir ?
• Quel est le plan pour atteindre ce but ?

A ceci, le Guide Scum 2020 rajoute une autre question : le pourquoi. La réponse est fournie par l’Objectif Sprint. La question au sujet de l’objectif du Sprint actuel doit se poser dès le départ et être gardée en tête tout au long du processus.

Un objectif pour le produit

Le Guide Scrum 2020 énonce également clairement l’objectif du développement de produits : au travers d’un développement continu, le produit est censé atteindre un état apportant encore plus de valeur tout en restant utile. Ceci est exprimé par « l’Objectif Produit ». Ce que cela signifie : chaque produit peut avoir seulement un objectif produit. Jusqu’à ce que cet objectif soit atteint, vous ne pouvez pas en définir de nouveau.

Le rapport entre les objectifs et les artefacts

Le Guide Scrum 2020 est maintenant aussi plus spécifique dans sa définition de « Objectif du Sprint » et sa définition de « Fini ». De plus, le Guide stipule désormais que ces derniers sont des engagements. Le backlog produit, le backlog Sprint et l’incrément ont tous un engagement associé : l’équipe Scrum atteindra l’Objectif Produit en travaillant sur le Backlog Produit. Les membres de l’équipe atteindront l’Objectif Sprint en travaillant sur le Backlog Sprint. Ils parviendront finalement à un incrément « Fini » en se conformant à la définition de « Fini ».

La pensée « Lean »

Un autre changement intéressant dans la version actuelle du Guide Scrum est la référence à un concept qui est à la base de nombreuses idées sur le développement moderne et agile de produits. Ce concept était précédemment absent du guide. Le concept Lean est basé sur des principes tels que la simplicité, le respect des individus et l’amélioration continue, qui sont aussi les principes de base du travail des équipes Scrum et du développement continu du Guide Scrum.

Conclusion : Guide Scrum 2020

Cet article vous a présenté les changements les plus significatifs entre les versions 2017 et 2020 du Guide Scrum. Non seulement le langage a été simplifié, mais il y a également moins de règles.

On peut aussi citer comme nouveauté l’Objectif Produit et les questions relatives au « pourquoi » dans la planification du Sprint. De plus l’objectif pour le produit et le rapport entre les objectifs et les artefacts ont été définis plus clairement.

Il reste à voir comment les équipes Scrum et leur Scrum Masters percevront la façon de travailler avec le nouveau Guide Scrum. Les déclarations contenues dans le Guide suffiront-elles à comprendre ce qui importe dans le travail des équipes Scrum ? Et si la réponse est non, sauront-ils vers qui se tourner pour obtenir de l’aide ? Les consultants auront très certainement leur rôle à jouer, surtout si les organisations n’en sont qu’au début de leur périple Agile. Tous les autres se réjouiront certainement du fait que le nouveau Guide Scrum contienne moins de restrictions et plus de simplicité.

Donnez-nous votre avis !
Avons-nous omis un changement important ? Quel est votre avis sur le nouveau Guide Scrum 2020 ? Laissez-nous vos commentaires ci-dessous.

Antje Lehmann-Benz (PMP, PMI-ACP, PSM expert / instructor in Agile Methodology) – Antje Lehmann-Benz, PMP, is a project management instructor with a special focus on agile issues and scrum seminars. She also has experience in providing software training (JIRA and Confluence) and consulting. In addition to instructing on frameworks and theory, she is also experienced in the use of agile games and practical exercises to reinforce the knowledge gained.

Read more about Antje Lehmann-Benz on LinkedIn and XING.

Anna Pauels (Content Marketing Professional)

Anna a travaillé en tant que journaliste et photographe pour les chaînes de télévision ARD et ProSieben ainsi que pour des journaux comme Münchner Merkur et tz et de nombreux magazines de modes de vie. Aujourd’hui Anna est Content Marketing Professional chez TPG The Project Group, et gère les blogs allemand, anglais et français ainsi que les réseaux sociaux et la newsletter mensuelle de l’entreprise.

En savoir plus sur Anna Pauels sur LinkedIn.

Der Beitrag Le Guide Scrum 2020 – Aperçu des modifications au guide erschien zuerst auf Blog Gestion de Projets pour les Entreprises.

Qu’est-ce qu’un product owner

Voici la définition donnée par le Guide Scrum :

« Le product owner est chargé de maximiser la valeur du produit résultat du travail de l’équipe de développement. La manière dont cela est fait peut largement varier selon les organisations, les équipes Scrum et les individus eux-mêmes. »

Presque toutes les équipes agiles ont une personne qui joue le rôle de product owner. Mais qu’est-ce exactement qu’un product owner, et quels sont les défis les plus courants auxquels il est confronté ? Cet article apporte des éléments sur ce rôle clé en répondant aux questions suivantes :

• Est-ce que seules les équipes scrum ont un product owner ?
• Comment un product owner peut-il mesurer la valeur du produit développé par l’équipe ?
• Quelles sont les responsabilités exactes du product owner ?
• Quelles compétences et expertise un product owner doit-il avoir ?
• Quels sont les devoirs du product owner ?
• Qu’est-ce que la gestion du backlog produits ?
• Quels paramètres sont utilisés pour mesurer la valeur des bénéfices fournis par le produit ?
• Quels défis le product owner est-il censé surmonter ?
• Conclusion

Est-ce que seules les équipes scrum ont un product owner ?

Le rôle de product owner prend ses origines dans la méthode Scrum. Cependant, de nombreuses équipes agiles ont quelqu’un qui s’occupe des tâches associées – même si elles n’utilisent pas la méthodologie Scrum.

Dans la programmation extrême (une autre approche agile en dehors de Scrum), par exemple, il y a le rôle appelé « client sur site » ou « mandataire du client ». Bien que cette personne fasse partie de l’équipe de développement du produit, son rôle est de représenter le client vis-à-vis des développeurs.

On comprend vite pourquoi ce rôle est nécessaire : La plupart des équipes agiles travaillent avec des solutions innovantes. Elles assument souvent l’entière responsabilité de « leur » produit, depuis le développement jusqu’à son remplacement éventuel, en passant par l’amélioration et la maintenance. Naturellement, l’équipe a besoin qu’une personne prenne la responsabilité de s’assurer que ce travail va dans la bonne direction dès le départ. Cette personne peut être le product owner.

Que fait un product owner ?

La personne occupant le rôle de product owner s’assure que le produit :

• Sert le marché et offre des solutions pour répondre à la demande existante ou nouvelle.
• Fournit à ses collègues des solutions vraiment sensées et utiles, moyennant un effort raisonnable (s’applique au développement interne de produits pour les autres départements de l’organisation).
• Répond aux exigences convenues par les parties prenantes dès que possible et que l’équipe de développement comprend ces exigences. Idéalement, toutes les parties concernées doivent pouvoir s’identifier à la solution.
• Peut atteindre un stade de développement avancé dans un délai donné, éventuellement par incréments sous la forme de résultats intermédiaires convenus.
• Fournit des gains rapides afin de garantir les liquidités nécessaires à la poursuite du développement.
• Répond aux attentes internes et externes en matière de qualité.
• Permet de satisfaire les parties prenantes – surtout les clients – moyennant un effort et un coût raisonnables, sans que la liste des exigences ne devienne interminable.
• Conserve sa position concurrentielle ou, mieux encore, est en avance sur la concurrence.

Quelles sont les responsabilités exactes du product owner ?

Dans le triangle ouvert et contraire de l’environnement agile, c’est le product owner qui porte la responsabilité première d’équilibrer et de prioriser le périmètre, le coût et le planning du produit.

Avec l’équipe de mise en œuvre, le product owner est également en charge de s’assurer que les exigences de qualité sont respectées. Certains des modèles triangulaires considèrent qu’il s’agit d’une dimension supplémentaire à prendre en compte.

On peut donc dire que les product owners assument une grande partie des tâches traditionnellement gérées par les chefs de projet.

Cependant, les chefs de projet sont également responsables de la création de l’équipe projet, de l’attribution des tâches aux membres de l’équipe projet et du suivi de leur travail. Ils peuvent également être impliqués dans le lancement du projet, par exemple en sélectionnant les projets ou en réalisant des études de faisabilité.

C’est généralement différent pour les product owners :

Une perspective de produit axée sur les solutions

Les product owners agiles s’occupent d’une perspective de produit axée sur les solutions tout au long du cycle de vie de leur produit. Ils réfléchissent à leur produit et à ses utilisateurs, y compris aux processus opérationnels après le développement initial. Ce faisant, ils se détachent de la réflexion purement orientée projet.

Backlog initial

L’une des premières tâches du product owner est typiquement la création du backlog initial (la liste de toutes les exigences du produit) en collaboration avec les parties prenantes, et parfois avec l’équipe de développement elle-même ou son représentant.

Mise en œuvre détaillée du produit

L’entreprise du projet a déjà été décidée par exemple par la direction du produit, qui dans un contexte agile, a une perspective supérieure du portefeuille. Le product owner, en revanche, se consacre à la mise en œuvre dans le détail d’un produit.

Soutien des coaches agiles

Le développement de l’équipe, la résolution des conflits, la conception des processus et des règles pour la coopération sont du ressort des coachs agiles (ou des Scrum Masters dans la méthodologie Scrum). Ils assistent également les product owners dans leurs tâches.

Consultation / coordination avec l’équipe développement

L’équipe de développement qui est en auto-organisation est responsable de la répartition des tâches. Elle assume également, dans une large mesure, la responsabilité de la qualité des itérations. Cependant, l’équipe doit souvent se coordonner avec le product owner pour s’assurer qu’elle ne s’écarte pas des objectifs, des exigences et des réalités du marché.

Responsabilité partagée avec l’équipe développement

Au lieu de faire des rapports, les développeurs montrent où ils en sont par le biais de démonstrations régulières des résultats de leur travail (par exemple, les nouvelles fonctionnalités du produit). Lors de la revue du produit pour les parties prenantes, à la fin de l’itération, le product owner et l’équipe de développement recommencent tout cela ensemble pour tous ceux qui ne font pas partie de l’équipe de produit agile. Ensemble, ils assument la responsabilité de leurs propres résultats.

Quelles compétences et expertise un product owner doit-il avoir ?

Les responsabilités principales du product owner sont d’évaluer et d’équilibrer différents facteurs tels que :

• Le coût, la profitabilité, et le retour financier du développement du produit, la satisfaction client et le potentiel de commercialisation,
• La liste souvent sans fin des souhaits et exigences clients et la capacité de l’équipe de développement,
• La productivité de l’équipe, la qualité et les bénéfices des résultats,
• Mesures proactives (analyse des risques, développement de nouvelles fonctionnalités, intégration), mesures réactives (tests, résolution de bugs, maintenance).

Idéalement, le product owner peut trouver un bon équilibre entre ces facteurs souvent divergents. Mais ce n’est pas une tâche facile. Pour vraiment comprendre ces facteurs, la personne qui occupe ce poste doit posséder et utiliser les connaissances et les compétences exigées des chefs de projet y compris les connaissances et compétences suivantes :

• Calculs de profitabilité
• La capacité à garantir que la solution développée propose les avantages attendus (ingénierie des bénéfices)
• Méthodes d’analyses des risques
• Analyse des exigences et techniques de priorisation pour gérer le backlog produit
• Analyse des parties prenantes et une aptitude pour traiter avec ces personnes
• Confiance en soi et bonnes capacités de négociation
• Une sensibilisation à l’innovation
• Compétences humaines, y compris dans les relations avec l’équipe de développement.

Quels sont les devoirs du product owner ?

Les principaux devoirs du product owner sont les suivants :

1) Fixer les objectifs et définir la vision

• Fixer les objectifs et faire en sorte de les réaliser
  Les product owners doivent fixer les objectifs généraux et les suivre sur le long terme. Les développeurs en revanche, doivent réaliser le travail technique pour réaliser ces objectifs, étape par étape.
• Développer une vision pour le produit
  Les parties prenantes collaborent avec l’équipe développement pour développer la vision du produit, qui guide ensuite les efforts pour la suite. Un exemple : L’application « BestDoc » est une plateforme permettant de trouver un médecin, de consulter des avis et de faire un rendez-vous. Elle est utilisée par les individus pour chercher les meilleurs praticiens dans leur région. Mais cette formule peut aussi être vue comme un slogan ou une phrase inspirante ou motivante).

2) Impliquer les parties prenantes tôt et souvent
Pour comprendre les intérêts des parties prenantes, le product owner doit également comprendre les parties prenantes elles-mêmes. Il est du devoir du product owner de tenir compte de ces intérêts et, si nécessaire, de les filtrer pour l’équipe développement.

3) Gérer la planification à haut niveau

• Planifier les itérations en avance
  Préparer bien en avance le contenu des 1 à 3 prochaines itérations et présenter le plan global à l’équipe pour atteindre ces objectifs.
• Planifier les packs de version
  Fixer les objectifs généraux et développer un planning efficace : par exemple quelle fonctionnalité sortira et quand.

4) Mesurer le succès et les bénéfices
Définir des paramètres qui peuvent être utilisés pour mesurer de manière réactive les avantages réels du produit et sa valeur ajoutée.

5) Créer et maintenir un backlog produit
Gardez toujours cette vue d’ensemble à jour et affinez-la, ou assurez-vous que quelqu’un d’autre la crée pour le product owner.

6) Préparer les revues de sprint
Quelles sont les principales parties prenantes qui seront invitées et qu’est-ce qui leur sera montré ? Quel retour d’information souhaitez-vous obtenir de leur part ? Quels membres de l’équipe sont disponibles et quelles fonctionnalités peuvent-ils montrer dans la démo ?

7) Participer activement aux rétrospectives
Quels sont les progrès réalisés par notre équipe ? Disposons-nous des bons outils et processus ? Comment pouvons-nous nous améliorer ? Le product owner ainsi que les membres de l’équipe poursuivent les efforts internes de l’équipe pour promouvoir l’amélioration continue.

Qu’est-ce que la gestion du backlog produits ?

Le guide scrum guide donne des informations sur ce point, disant que le backlog produit comprend les aspects suivants :

• Documenter de façon claire et concise toutes les entrées dans le backlog produit,
• Trier les entrées du backlog produit de manière à faire progresser de façon optimale les objectifs,
• Optimiser la valeur du travail réalisé par l’équipe développement,
• Veiller à ce que le backlog produit soit visible, transparent, clair pour tout le monde et qu’il montre ce sur quoi l’équipe scrum travaillera ensuite,
• Veiller à ce que l’équipe développement ait la compréhension nécessaire des entrées du backlog produit.

Bien entendu, même cette liste issue du guide Scrum ne couvre pas la totalité des choses rencontrées dans la pratique. Mais elle n’avait pas pour objectif d’être exhaustive. Un bon product owner est quelqu’un qui sait gérer l’ingénierie des exigences dans un contexte agile.

Affiner le backlog produit implique des activités telles que :

Prendre des décisions sur le contenu du backlog

Que doit-on inclure dans le backlog et que doit-on en exclure ? Savoir dire « non » aux parties prenantes pour des demandes qui sont inadaptées ou pas réalistes à ce stade. Une organisation doit respecter les décisions du product owner même si cela est parfois difficile. Il faut aussi ici ajouter de nouvelles entrées dès que c’est nécessaire et supprimer celles devenues superflues.

Prendre des décisions sur le type d’entrées

Descriptions fonctionnelles, spécifications, résolutions de bugs, exigences non fonctionnelles telles que la sécurité, l’évolutivité, la maintenabilité ? Ou bien la description de la solution axée sur les résultats du point de vue du client (témoignages d’utilisateurs) en une phrase courte ? Une combinaison des deux est logique car aucun de ces types d’entrées seules ne répond entièrement aux exigences d’un produit.

Prendre des décisions sur les exigences et le calendrier

Quelles sont les exigences pour quelle itération et version ? Plus précisément, cela relève de la responsabilité de toute l’équipe lors de la planification des itérations. La plupart des parties prenantes veulent aussi avoir leur mot à dire à ce sujet. Une cartographie des témoignages utilisateurs peut être utile.

Préparer les estimations de coûts

Obtenir de l’équipe des estimations approximatives de l’effort à réaliser. Parce qu’au niveau du backlog produit, les exigences sont principalement formulées du point de vue de l’utilisateur. La décomposition en tâches n’est effectuée que lors de la planification des itérations. Les tâches sont ensuite intégrées dans le backlog de l’itération.

Prioriser les entrées

Normalement ceci est juste une liste linéaire dans le backlog produit. Cela signifie que la priorité vient de l’ordre des items de la liste. Les items les plus en haut de la liste doivent être mis en œuvre plus tôt que les entrées qui se trouvent plus bas dans la liste.

Notre astuce : Concentrez-vous uniquement sur les entrées les plus en haut de la liste quand vous formulez et évaluez les entrées. Les entrées en bas de liste sont moins importantes car elles peuvent encore changer voire même disparaître.

Cette stratégie en ligne avec le principe du « juste à temps » vous permet d’éviter de gaspiller votre énergie sur des besoins qui ne sont pas immédiats.  Elle utilise les critères DEEP. Cela vous aide à garantir que lorsque vous travaillez avec des backlogs produits, vous suivez des principes agiles et pas seulement un planning en cascade sous un nouveau nom.

Notre astuce : Si l’utilisation d’une stratégie plate et linéaire pour prioriser les entrées du backlog n’est pas suffisante, vous pouvez également utiliser la méthode du User Story Mapping (cartographie des témoignages utilisateurs) pour une gestion multidimensionnelle du backlog.

Quels paramètres sont utilisés pour mesurer la valeur des bénéfices fournis par le produit ?  

Cette question ou quelque chose d’assez semblable, est une question qui revient souvent dans les examens de certification tels que ceux de Scrum.org. Au départ, cela semble être une question difficile. Comment pouvons-nous, en tant qu’équipe, mesurer la valeur de notre produit ? Certainement pas basé uniquement sur notre productivité. Celle-ci peut être élevée mais si les résultats sont faux, cela n’est pas très utile.

Par contre, le management basé sur les preuves (“Evidence-based management“), définit plusieurs paramètres, dont certains ne sont pas très connus. Mais les product owners peuvent les trouver plutôt utiles.

Le management basé sur les preuves reconnaît quatre catégories principales pour les paramètres individuels :

• Valeurs actuelles :
  Mesure l’acceptation et l’utilisation du produit par le marché. On prend également en compte le moral de l’équipe qui le développe. Quel est le degré de satisfaction des investisseurs potentiels ?

Exemples de mesures : Cette catégorie comprend, par exemple, les indices de satisfaction des clients (tels que ceux fournis par les enquêtes et les commentaires sur le produit), des mesures indiquant la relation entre l’utilité des différentes fonctions et le degré de satisfaction des clients à l’égard de ces fonctions particulières.

• Time-to-Market
  Cette mesure indique le temps qui s’écoule entre le moment où une nouvelle exigence est formulée initialement et celui où l’auteur reçoit la solution. À quelle vitesse pouvons-nous traiter de nouvelles informations et les utiliser ?

Exemples de mesures : Fréquence de publication des versions, fréquence d’intégration, temps de traitement des entrées dans le backlog et délai de livraison.

• Capacité à innover
  Cette mesure indique à quel point le processus de recherche d’une solution est innovant. Quel est le degré d’innovation du produit et de sa fonctionnalité ? Cette question doit également être posée lors de la poursuite du développement d’un système mature dans une grande entreprise.

Exemples de mesures : Avantages des différentes fonctions par rapport aux autres, efforts ou dépenses associés à de nouveaux développements (en pourcentage) par rapport à des activités telles que la maintenance, et temps que l’équipe consacre effectivement au produit (par rapport à d’autres tâches).

• Valeur non réalisée
  Cette mesure tient compte du potentiel (encore) non réalisé. Cela vaut-il la peine d’y regarder de plus près ?

Exemples de mesures : Parts de marché, attentes des utilisateurs par rapport à ce qu’ils ont reçu.

Notre astuce : Ces mesures sont particulièrement utiles quand elles sont suivies sur une période longue car les développements et tendances sont alors plus visibles.

Quels défis le product owner est-il censé surmonter ?

Jusqu’à présent, nous avons examiné de près le rôle du product owner et quelques-uns de ses outils principaux et ses tâches. Nous allons maintenant nos pencher sur les défis auxquels les product owners sont confrontés dans leur travail quotidien

Les enquêtes menées auprès des product owners et des développeurs par les coachs agiles ont montré que les principaux défis sont les suivants :

La pression du temps

Problèmes possibles – Le rôle n’est peut-être pas pourvu à plein temps mais doit quand même être réalisé en plus du travail opérationnel. Trop de produits et d’équipes doivent être gérés simultanément. L’équilibre entre temps consacré aux parties prenantes et temps consacré aux équipes est difficile à trouver.

Solution possible – Analyse de la cause : Quelle est la véritable raison pour les problèmes de temps ? Que peut-on changer ? Y a-t-il des méthodes de gestion du temps qui pourraient s’appliquer et aider ? Peut-être faut-il revoir les priorités des projets et des besoins ?

Manque de connaissances sur les tâches

Problèmes possibles – Le product owner en sait trop peu sur son propre rôle et sur le développement agile. Le rôle est souvent attribué sans plus d’explication ou de formation.
Solution possible – Plus de formation, accès à des ouvrages tels que le livre très reconnu « Professional Product Owner » de Don McGreal et Ralph Jocham.

Manque d’expertise outil

Problèmes possibles – Le product owner ne connaît pas les outils, les documents, les mesures nécessaires à son travail.
Solution possible – Discussion sur les outils pour créer des visions et des feuilles de routes pour les produits, pour définir les stratégies de planification des versions, outils de management basé sur les preuves et enfin les outils d’analyse des parties prenantes.

Manque de pouvoir de décision

Problèmes possibles – Le product owner n’est pas autorisé à prendre de décisions. Les voies hiérarchiques sont trop compliquées et longues.
Solution possible – Escalade et discussion de ces problèmes avec la direction

Problèmes impliquant les parties prenantes

Problèmes possibles – Manque de participation et d’intérêt de la part des parties prenantes, conflits entre les parties prenantes sur les priorités à donner, trop de parties prenantes.
Solution possible – Analyse des parties prenantes, apprendre et appliquer des techniques de modération, analyse des besoins réalisée conjointement avec les parties prenantes, implication de coachs agiles.

Problèmes avec la structure organisationnelle

Problèmes possibles – Complexité organisationnelle élevée et problèmes symptomatiques de « silos ».
Solution possible – Raccourcir les boucles des retours de commentaires avec l’aide de coachs agiles.

Des projets trop complexes

Problèmes possibles – Projets faisant intervenir de nombreuses entreprises différentes. Le product owner et les développeurs ne font pas partie de la même entreprise.
Solution possible – Ceci ne doit pas forcément être un problème, mais c’est un sujet dont il faut s’occuper consciencieusement. La mise en place de contrats et d’accords entre les équipes aide dans ce sens.

Environments très régulés

Problèmes possibles – L’environnement/l’industrie rend les méthodes de travail “légères” difficiles en raison de superstructures de processus.
Solution possible – Intelligence situationnelle, concentration sur une bonne culture de l’erreur et un apprentissage aussi rapide que possible face aux circonstances extérieures.

Les products owners ne peuvent pas, et ne doivent pas, résoudre tous ces problèmes seuls. Il faut habituellement la participation de la direction et de toutes les personnes impliquées ainsi qu’un bon accompagnement/coaching.

Notre astuce : Si vous rencontrez l’un de ces problèmes dans votre organisation, il est conseillé de les traiter le plus rapidement possible en les signalant à la personne ou le bureau en charge.

Conclusion

Dans cet article nous avons abordé les thématiques suivantes :

• Les devoirs du Product Owner
• Les défis que le Product Owner doit relever
• Les paramètres pour mesurer les bénéfices d’un produit
• Ce que la gestion du backlog produit comprend

Pour résumer : Un bon product owner peut apporter une contribution précieuse au succès de l’entreprise sur le marché. Cette personne occupe un poste très intéressant et influent offrant de nombreuses possibilités. Toutefois, la personne qui occupe ce poste peut également être confrontée à des défis difficiles.

Si vous êtes (ou souhaitez devenir) product owner, soyez prêt à un apprentissage continu des méthodologies, outils, et des relations humaines.

L’aventure vous tente ?

Si la réponse est oui, alors explorez l’utilisation des méthodes agiles dans vos équipes et vos projets. Si vous souhaitez en savoir plus et approfondir vos connaissances, envisagez de suivre une formation de développement professionnel pour devenir Professional Scrum Master (PSM I) ou PMI Agile Certified Practitioner (PMI-ACP).

Les méthodes agiles sont-elles adaptées à votre environnement de travail ? Nous sommes curieux de vos retours. Laissez-nous un commentaire !

 Antje Lehmann-Benz (PMP, PMI-ACP, PSM expert / formatrice en Méthodologie Agile) – Antje Lehmann-Benz, PMP, enseigne la gestion de projet et se concentre particulièrement sur des séminaires sur les questions Agiles et Scrum. Elle a également de l’expérience dans la formation aux logiciels (JIRA et Confluence) et en consulting. En plus d’enseigner les cadres et la théorie, elle est également expérimentée dans l’utilisation de jeux et d’exercices pratiques Agiles pour renforcer les connaissances acquises.  

En savoir plus sur Antje Lehmann-Benz sur LinkedIn et XING.

Der Beitrag Qu’est-ce qu’un product owner et quel est son rôle au sein de l’équipe agile ? erschien zuerst auf Blog Gestion de Projets pour les Entreprises.

Et pourtant, il n’existe pas deux projets identiques. Les approches agiles ne fonctionnent pas toujours et ne peuvent pas être appliquées à volonté à tous les types de projets.

Nous avons plutôt besoin de plus de force d’innovation et de créativité. Travailler sur des projets nécessite de se concentrer clairement sur la valeur commerciale. Et sur des horizons de planification plus courts, mais tout aussi solides. Les entreprises mettent en œuvre ce changement, comme en témoignent l’émergence et la demande de nouveaux intitulés de poste.

Cet article abordera les thématiques suivantes :

• Gestion de projet Agile – Définition
• Quel est l’intérêt des méthodes de gestion de projet Agiles ?
• Nouveaux intitulés de poste comme conséquence de la gestion de projet Agile
• Pourquoi les certifications Scrum ont du sens
• Bien préparé(e) pour les certifications Scrum
• Qu’y a-t-il de nouveau dans le Guide Scrum 2020 ?
• Autres approches et méthodes pour la gestion de projet agile
• Aperçu des certifications Agiles les plus importantes
  • PMI Agile Certified Practitioner (PMI-ACP)
  • Certified Scrum Master (CSM)
  • Professional Scrum Master I (PSM I)
  • Certified Scrum Practitioner (CSP)
  • Scaled Agile Framework (SAFe)
    
• Quelle certification Agile est celle pour vous ?
• Conclusion

Vous découvrirez ici pourquoi les certifications Scrum ont un sens si vous commencez tout juste à utiliser les méthodes agiles. Par ailleurs, vous en saurez plus sur la certification PMI-ACP, la certification pour les chefs de projets agiles avancés.

Plus : vous aurez un aperçu des prérequis et des frais pour plusieurs de ces certifications.

Gestion de Projet Agile – Définition

Dans la gestion de projet traditionnelle, on a tendance à utiliser l’approche de la planification autant et aussi loin que possible. Les méthodes traditionnelles de contrôle de projet peuvent être utiles. Elles vous permettront de structurer et de mettre de l’ordre dans vos workflows. En conséquence, vous perdez un peu de votre flexibilité. Surtout dans le monde des logiciels (mais pas seulement), cela peut sembler un peu rigide. C’est pourquoi les méthodes agiles poursuivent un objectif particulier depuis les années 1990 : fournir des cadres plus légers et plus flexibles pour les processus de développement. On les appelle « agiles ». Il s’agit de méthodes de planification et de contrôle très souples et adaptables pour des environnements de projet particulièrement dynamiques.

Quel est l’intérêt des méthodes de gestion de projet agiles ?

La gestion de projet agile a été développée pour des environnements très complexes comme par exemple le secteur des logiciels. Mais elles ont aussi beaucoup de succès dans d’autres secteurs.

En particulier, les méthodes agiles sont utilisées dans les projets qui ont au départ des exigences très vagues. Bien souvent, des changements fréquents sont prévisibles. Dans la plupart des cas, il n’y aura guère plus qu’une vision. L’équipe est supposée mettre cette vision en œuvre d’une façon innovante.

Si les exigences de départ sont vagues et que les changements sont la norme plutôt que l’exception, les méthodes agiles ont tendance à être plus efficaces que la gestion de projet traditionnelle.

Pendant toute la durée du projet, des équipes compactes travaillent en étroite collaboration pour réaliser et préciser ces objectifs. Cela se fait toujours sur de courtes périodes, avec des résultats qui se renforcent et se mutualisent les uns les autres.

Les équipes jouissent d’une grande autonomie. Afin de rester sur la bonne voie, elles sont néanmoins en communication régulière avec tous les participants au projet.

En outre, les équipes appliquent des techniques visant à accroître la transparence vers l’extérieur et la cohésion de l’équipe en interne.

Des soutiens tels que les Scrum Masters aident les équipes à relever et à maîtriser les défis. En même temps, ils aident l’organisation à augmenter le niveau de maturité dans l’application des méthodes agiles.

Le manifeste agile résume ce qui est essentiel pour toutes les méthodes agiles.

Scrum est l’approche agile la plus connue et la plus utilisée de par le monde.

En raison de la grande flexibilité de son cadre général, la gestion de projet agile avec Scrum est particulièrement bien adaptée à une application en dehors de l’industrie des logiciels.

De nouveaux intitulés de postes grâce à la gestion de projet agile

Saviez-vous que « Scrum Master » et « Product Owner » deviennent désormais des intitulés de postes à part entière ?

Issus du nom d’un rôle dans l’équipe Scrum, ces termes sont de plus en plus souvent utilisés explicitement dans les offres d’emploi. En outre, les entreprises incluent ces termes dans le parcours de carrière de leurs employés.

Comme dans tous les domaines, l’expérience du candidat est clé. Elle ne doit pas être sous-estimée.

Au-delà de l’expérience professionnelle, les Scrum Masters doivent avoir les compétences suivantes pour réussir dans leur rôle de médiateur et de soutien :

• Connaissance de la nature humaine
• Tact
• Capacité à modérer
• Compétences en résolution de conflit

Pourquoi les certifications Scrum ont du sens

Dans et autour de Scrum, il subsiste d’innombrables malentendus. La réussite de l’introduction de ces méthodes dépend aussi énormément du stock de connaissances des participants.

C’est pourquoi les certifications sur les bases des pratiques agiles telles que le “Professional Scrum Master I” de Scrum.org ou le Certified Scrum Master de la Scrum Alliance  peuvent être très utiles.
Ces deux certifications sont destinées à ceux qui débutent dans les méthodes agiles.
Les titulaires de ces certifications montrent ainsi qu’ils ont compris les principes fondamentaux du cadre Scrum et l’ont démontré lors d’un examen.

Grâce à ces certifications, ils montrent en outre leur volonté à :

• Diriger et soutenir les autres dans un tel rôle,
• Aider l’organisation à mettre Scrum en place,
• Être volontaire pour acquérir plus d’expérience en Scrum.

Ce dernier point est particulièrement important si vous débutez votre carrière Scrum.

Bien préparé(e) pour les certifications Scrum

Il n’y a pas de prérequis pour les deux certifications “Professional Scrum Master I” et “Certified Scrum Master”.

Toutefois, l’examen pour Professional Scrum Master I est plutôt difficile. Pour mettre toutes les chances de son côté, il est judicieux de participer à un séminaire de préparation Scrum Master.

Votre certification agile prouvera qu’en tant que Scrum Master en devenir ou Scrum Master actif :

1. Vous connaissez le contenu du Guide Scrum et autres guides sur le même sujet,
2. Vous avez su démontrer cette connaissance en situation d’examen.

Qu’y a-t-il de nouveau dans le Guide Scrum

A l’occasion du 25^ème anniversaire de Scrum, le 18 novembre 2020, le Guide Scrum 2017 a été mis à jour. Le nouveau Guide Scrum décrit Scrum comme étant un cadre qui aide à créer de la valeur au moyen de solutions adaptives à des problèmes complexes. En même temps, quelques passages de texte ont été raccourcis, voire effacés. Au global, le Guide Scrum 2020 décrit désormais moins comment les éléments de Scrum doivent être mis en œuvre. Cela rend le contenu plus clair à la lecture. D’autres changements ont été faits tels que :

• Rôles : au lieu du terme « Equipe de développement », on parle maintenant de « Développeurs »
• Il y a maintenant 3 niveaux d’objectifs sur lesquels les équipes doivent s’engager : L’Objectif Produit pour le produit, l’Objectif Sprint pour le sprint et la Définition de Réalisé pour l’incrément.
• Le Scrum Master est désormais officiellement responsable de l’efficacité de l’équipe Scrum.
• Au lieu de « s’auto-organiser », l’équipe Scrum « s’auto-gère ».

Astuce : A partir du 9 janvier 2021, tous les examens de Scrum.org seront basés sur la nouvelle version du Guide Scrum. Découvrir ici le nouveau Guide Scrum.

Autres approches et méthodes pour la gestion de projet agile

Les Scrum Masters qui excellent ne se limitent pas à Scrum uniquement. Il existe d’autres méthodes et approches agiles. Elles peuvent être combinées à souhait et ont de nombreux points communs. Par exemple, de nombreuses méthodes sont basées sur :

• Une conception ouverte et confiante en l’Homme
• Un mode de fonctionnement itératif et incrémental

De plus, il existe des problèmes d’environnement dans les organisations auxquels les méthodes agiles accordent souvent peu d’attention. Nous pourrions par exemple citer les suivants :

• Gestion de portefeuille
• Gestion des ressources
• Méthode de sélection des projets
• Structure organisationnelle

Scrum permet la combinaison de différentes approches et méthodes agiles.

Tout cela nous ramène au développement de produits au niveau des équipes individuelles pour lesquelles Scrum a été principalement développé, ainsi qu’aux questions de gestion de projet. Cela nécessite une perspective plus globale et de plus haut niveau.

Et c’est là qu’intervient le PMI-ACP® (« Project Management Institute Agile Certified Practitioner »).

Project Management Institute Agile Certified Practitioner

La certification PMI-ACP est destinée aux personnes qui ont déjà une expérience de projet (agile). Elle prétend rassembler les idées de toutes les méthodes agiles et les consolider de manière standardisée.

Et le Project Management Institute (PMI)® prend cet objectif très sérieusement : son manuel standard pour l’industrie de la gestion de projet, la 6me édition de son « Guide to the Project Management Body of Knowledge » (PMBOK® Guide) a été publiée en pack avec le « New Agile Practice Guide » ou « Nouveau Guide de la Pratique Agile » en 2017.

Guide de la Pratique Agile

Outre la prise en compte des méthodes agiles individuelles, le Guide des Pratiques Agiles contient également des directives et une aide pour la sélection de méthodes en situation. De plus, il comble le fossé entre les méthodes agiles et les méthodes traditionnelles de gestion de projet.

Celles-ci sont encore très nécessaires dans toutes les situations où les approches agiles ne suffisent pas pour résoudre les problèmes.

Le contenu du Guide des pratiques agiles est le résultat de la collaboration du PMI avec l’Alliance Agile (une association de nombreux promoteurs d’idées agiles, à ne pas confondre avec la Scrum Alliance), ce qui présage d’une base d’expertise solide pour le nouveau Guide de Pratique Agile.

Depuis mars 2018, ce guide est également la référence officielle pour l’examen du PMI-ACP – mais seulement comme une des nombreuses sources pertinentes du catalogue de la littérature agile.

Ces derniers temps, la popularité de la certification Agile Certified Practitioner a fortement augmenté. Il existe donc une demande de documentation de haute qualité pour préparer l’examen.

Le Guide des Pratiques Agiles aide les candidats à l’examen à cerner la perspective du PMI sur la gestion de projet agile. Il donne également des exemples pratiques de l’utilisation des méthodes présentées.

Combinaison du PMI-ACP avec la certification PMP

Notez que la certification PMI-ACP et le traditionnel PMP® (Project Management Professional) du PMI forment ensemble une excellente combinaison de certification.

Un autre point en faveur de la combinaison est que les prérequis de l’examen sont plus faciles à remplir pour les titulaires du certificat PMP®. Vous n’aurez pas à prouver une expérience de projet supplémentaire si vous êtes PMP. Toutefois, il n’en va pas de même pour l’expérience et la formation en matière de projets agiles. Des preuves et des certifications dans ces domaines seront demandées à tous les candidats.

Attention : A partir du 2 janvier 2021, l’examen PMP® comprendra des questions supplémentaires sur les 3 approches de gestion de projet suivantes :

• Prévisionnelle
• Adaptive/agile
• Hybride

Cela veut dire que même les futurs PMP doivent désormais connaître quelques idées et méthodes agiles, par exemple la maintenance des Backlogs, les méthodes d’estimation ou les Rétrospectives

Aperçu des principales certifications en gestion de projet agile

Vous trouverez ci-dessous une comparaison des certifications en gestion de projet agile mentionnées dans cet article.

PMI Agile Certified Practitioner (PMI-ACP)
Certification délivrée par :  Project Management Institute (PMI)

Prérequis

– 2000 heures d’expérience projet (ne s’applique pas aux détenteurs de la certification PMP)
– 1500 heures d’expérience en environnement agile
– 21 heures de formation en pratiques agiles (par exemple en suivant la formation PMI-ACP de TPG)

Type d’Examen

Au centre d’examen : 120 questions à choix multiple avec 4 choix et une seule bonne réponse.
Durée de l’examen : 3 heures.
Alternative : Examen surveillé en ligne (examen en ligne avec une surveillance via webcam par un surveillant à distance).

Score de réussite (pourcentage nécessaire de bonnes réponses)

Secret (estimé à approximativement 70%).

Prix de l’examen

$435 (Membres PMI®, un peu plus pour les non-membres).

Validité

Cycle de 3 ans (30 unités de développement professionnel (PDU) – les PDU doivent être acquises au cours de cette période dans des environnements et / ou des sujets agiles).

Objectif

Standardisation du plus grand nombre possible de pratiques agiles.

Groupe cible

Les personnes qui cherchent à prouver et à améliorer leur expérience des méthodes agiles et leur compréhension de celles-ci.

Certified Scrum Master (CSM)
Certification délivrée par : Scrum Alliance

Prérequis

Suivre une formation de 2 jours animée par un formateur spécialement autorisé, dans les 90 jours maximum avant de passer l’examen.

Type d’examen

En ligne : 35 questions à choix multiple.
Durée de l’examen : 1 heure.

Score de réussite (pourcentage nécessaire de bonnes réponses)

68,6%

Prix de l’examen

L’examen ne peut être passé qu’après avoir suivi une formation et le prix est inclus dans le coût de la formation.

Validité

Cycle de 2 ans (puis re-certification en ligne pour $100).

Objectif

Clarification et promotion de Scrum.

Groupe cible

Les personnes souhaitant faire un premier pas vers la maîtrise de Scrum.

Professional Scrum Master I (PSM I)
Certification délivrée par : Scrum.org

Prérequis

Pas de prérequis formel mais une excellente connaissance du Guide Scrum est nécessaire pour réussir l’examen ; un examen pour s’entraîner « Scrum Open » est disponible sur scrum.org.

Type d’examen

En ligne : 80 questions à choix multiple avec diverses options et 1 ou plusieurs bonnes réponses.
Durée de l’examen : 1 heure.
Astuce : Chez TPG, nous proposons un séminaire d’entreprise Scrum (en anglais ou allemand) avec l’option de passer l’examen directement après. En seulement 3 jours, les participants pourront avoir leur certification PSM I en main.

Score de réussite (pourcentage nécessaire de bonnes réponses)

85%

Prix de l’examen

150$

Validité

Illimitée.

Objectif

Clarification et promotion de Scrum.

Groupe cible

Les personnes souhaitant faire un premier pas vers la maîtrise de Scrum.

Certified Scrum Practitioner (CSP)
Certification délivrée par : Scrum Alliance

Prérequis

Certification A-CSM (Advanced Certified Scrum Master) minimum de 2 ans d’expérience dans le rôle de Scrum Master au cours des 5 dernières années.
Avoir fini les exercices donnés à la fin du cours dans les 12 mois qui suivent.
La participation au cours est possible sans remplir ces prérequis, mais dans ce cas, aucune certification ne pourra être obtenue.

Prix de l’examen

250$

Validité

Illimitée.

Objectif

Etendre son expertise en gestion de produit agile.

Groupe cible

La certification CSP-SM est adaptée pour les Scrum Master tandis que la certification CSP-PO est adaptée pour les Product Owners.

Scaled Agile Framework (SAFe)
Certification délivrée par : Scaled Agile, Inc.

Prérequis

Plus de 5 ans d’expérience en développement de logiciel, test, analyse busines, gestion de produit ou de projet et expérience en Scrum.
Avoir suivi un cours sur le contenu de SAFe avec un organisme de formation.

Type d’examen

Questions à choix multiple, 45 questions en 90 minutes. Possibilité de passer l’examen en ligne.

Score de réussite (pourcentage nécessaire de bonnes réponses)

76% ; 34 bonne réponses.

Prix de l’examen

435$

Validité

Un an. Après la date de fin de validité, la certification peut être renouvelée pour un coût de 100$ sans avoir à repasser d’autre examen.

Objectif

Agile Scaling (très larges projets d’entreprise)/méthodes Scrum.

Groupe cible

Personnel senior, Scrum Masters, Product Owners, responsables des demandes, des versions et des tests, coachs, chefs de projet souhaitant organiser des équipes multiples au moyen de méthodes agiles.

Quelle certification Agile est celle pour vous ?

Vous connaissez maintenant les principales certifications en gestion de projet agile. Mais comment savoir laquelle est la bonne pour vous ? Au début il est logique de commencer avec les bases de Scrum ; vous développez ainsi une bonne base en vue de la plupart des certifications mentionnées ci-dessus. Vous avez ensuite l’option d’élargir vos connaissances comme indiqué dans le graphique ci-après :

Conclusion – Comparaison des certifications en gestion de projet agile

Cet article vous a présenté les principes généraux des méthodes agiles. Nous avons aussi expliqué quand leur application a du sens. Un accent particulier a été placé sur Scrum.

Vous connaissez désormais les certifications agiles suivantes :

• PMI Agile Certified Practitioner (PMI-ACP)
• Certified Scrum Master (CSM)
• Professional Scrum Master I (PSM I)
• Certified Scrum Master (CSP)
• Scaled Agile Framework (SAFe)

Vous pouvez ainsi choisir en connaissance de cause le chemin à suivre pour vous et vos collaborateurs.

Communiquez-nous vos commentaires !
Quelle est votre expérience de la gestion de projet agile ? Avons-nous peut-être omis une certification en gestion de projet agile ou un détail important ? Avez-vous trouvé cet article utile ? Envoyez-nous vos commentaires !

 Antje Lehmann-Benz (PMP, PMI-ACP, PSM expert / formatrice en Méthodologie Agile) – Antje Lehmann-Benz, PMP, enseigne la gestion de projet et se concentre particulièrement sur des séminaires sur les questions Agiles et Scrum. Elle a également de l’expérience dans la formation aux logiciels (JIRA et Confluence) et en consulting. En plus d’enseigner les cadres et la théorie, elle est également expérimentée dans l’utilisation de jeux et d’exercices pratiques Agiles pour renforcer les connaissances acquises.  

En savoir plus sur Antje Lehmann-Benz sur LinkedIn et XING.

Der Beitrag Les Certifications en Gestion de Projet Agile : Comparaison erschien zuerst auf Blog Gestion de Projets pour les Entreprises.

De telles rétrospectives agiles aident à l’amélioration continue des processus, des méthodes et du travail d’équipe.

Cet article couvre les points suivants :

• Qu’est-ce qu’une rétrospective agile ?
• Que doit inclure une rétrospective ?
• Comment une rétrospective doit-elle être organisée ?
• Quels sont les formats les plus adaptés à une rétrospective ? (+ téléchargement d’une trame)
• Rétrospective : méthodes et exemples
• Outils pour les équipes virtuelles
• Et après la rétrospective ?
• Conclusion

Qu’est-ce qu’une rétrospective agile ?

Le concept de base d’une rétrospective est ancré dans le 12e principe du manifeste Agile : « À intervalles réguliers, l’équipe réfléchit à la manière de devenir plus efficace, puis elle s’accorde et ajuste son comportement en conséquence. »

Les équipes agiles travaillent de préférence en intervalles courts appelés des itérations (« sprints » dans la pratique Scrum). Ces dernières peuvent être vues comme des cycles de développement, mais elles représentent aussi des cycles d’apprentissage car on part du principe que les initiatives complexes nécessitent des approches par étapes dans lesquelles il est nécessaire de fréquemment s’arrêter pour s’auto évaluer et évaluer les résultats (intermédiaires).
Les rituels « inspecter et adapter » sont par conséquent clés pour chaque itération. Cela vous donne l’opportunité d’influencer de manière significative la suite de votre projet. Trois facteurs sont analysés et, si nécessaire, adaptés :

• Produit
• Processus
• Personnes

Les réunions de revue des itérations ou les réunions de revue produit à la fin de chaque itération avec les parties prenantes, servent à évaluer et adapter le produit. Ces réunions profitent aussi aux futurs développements de fonctionnalités grâce aux retours des parties prenantes.

Les rétrospectives diffèrent donc des réunions sur les enseignements tirés utilisées en gestion de projet traditionnelle, notamment au niveau du calendrier et de la fréquence.

Alors que les projets planifiés de manière traditionnelle organisent la réunion entre le chef de projet et l’équipe une fois le projet terminé pour échanger sur ce qu’il s’est passé et sur les enseignements tirés, avec les équipes agiles, ces réunions se tiennent régulièrement, après chaque itération et avant que la prochaine itération ne commence. Cela vous permet d’appliquer immédiatement ce que vous avez appris au projet en cours plutôt que de simplement rassembler ces résultats pour les utiliser sur de futurs projets.

Que doit inclure une rétrospective ?

Les parties prenantes peuvent être invitées à la réunion de rétrospective mais leur présence n’est généralement pas nécessaire. Si l’équipe veut parler ouvertement et honnêtement de l’itération qui vient de se terminer, la présence des parties prenantes peut être un obstacle. Une rétrospective est donc un événement collectif et les coachs expérimentés ont toujours un répertoire suffisant d’exercices pour soutenir cet effort.
Les coachs Agiles (« scrum master » dans une équipe scrum) aident l’équipe à identifier les bonnes pratiques et les possibles améliorations qui peuvent être utilisées dans la prochaine itération.
La franchise et l’honnêteté sont par conséquent essentielles dans une rétrospective.

Bien que l’équipe puisse être plutôt satisfaite de ses réalisations, les membres de l’équipe se félicitant pour un travail bien fait, il est également important d’être ouvert à tout problème critique et d’en discuter. Ceci inclut les sentiments, les émotions des personnes.

Prévoyez un lieu sécurisant pour traiter de ces sujets.

Au minimum, les personnes suivantes doivent prendre part :

• Un product owner (maître d’ouvrage ou un chef de projet fonctionnel selon l’organisation de l’équipe)
• Tous les membres d’équipe
• Un coach d’équipe

Comment une rétrospective doit-elle être organisée ?

Une rétrospective prend généralement jusqu’à 3 heures, en fonction de la durée de l’itération examinée.

L’expérience montre qu’une réunion en 5 étapes a le plus d’efficacité :

1. Mettre en place une atmosphère propice aux discussions
   L’équipe se réunit pour la rétrospective. Les participants s’efforcent d’éviter les distractions et acceptent de participer à une discussion ouverte dans laquelle chaque personne est traitée avec respect.
2. Rassembler les sujets à discuter
   Ensemble, les membres d’équipe réfléchissent sur la façon dont s’est déroulée l’itération et font un brainstorming pour trouver des améliorations possibles.
3. Acquérir des connaissances
   Tous les participants approfondissent les questions qui ont été abordées : Quelles en sont les causes ? Quelles mesures spécifiques peuvent être prises pour améliorer les choses ?
4. Prendre des décisions
   Conformément au principe agile que « moins c’est plus », le groupe se met d’accord sur une ou deux améliorations spécifiques à mettre en place à la prochaine itération.
5. Conclusion
   Après être parvenu à un accord en phase 4, la rétrospective est terminée et l’équipe retourne à ses activités. L’itération suivante peut commencer. 

Quels sont les formats les plus adaptés à une rétrospective ?

D’une manière générale, aucun format particulier n’est nécessaire pour organiser une rétrospective, avec ses différentes phases. Il n’est pas non plus nécessaire de suivre strictement chacune des étapes individuelles énumérées ci-dessus, bien que la réunion progresse généralement rapidement et de façon fluide d’une étape à l’autre. L’important est de terminer la réunion par un accord sur une ou deux améliorations spécifiques pour la prochaine itération.

L’expérience montre également que l’équipe est souvent à cours d’idées ou perd de sa créativité après quelques itérations. Il y a alors un sentiment d’urgence à supprimer ces réunions. Ou bien l’équipe projet ne sait toujours pas comment faire en sorte que les rétrospectives soient productives et créatives.

Pour ces situations, il existe une multitude de formats et de techniques de modération permettant d’intéresser et d’impliquer votre équipe et de rendre plus facile et beaucoup plus passionnant le travail de l’équipe sur les processus d’amélioration.

Notre astuce : Le site Internet Retromat regorge de bonnes idées.  Il donne des formats pour chaque phase de la rétrospective. Dans la prochaine partie de cet article nous vous en présenterons quelques-uns.

Note : Les équipes aiment généralement essayer ces diverses techniques, mais elles peuvent aussi parfois être perçues comme « écrasantes » et éprouvantes. Alors souvenez-vous toujours que « moins c’est plus ».

Les coachs d’équipes expérimentés utilisent 1 à 2 formats par rétrospective. Il peut leur arriver de répéter certains formats pour éviter d’être trop exigeant avec l’équipe ou même de ne pas du tout utiliser certains d’entre eux.

Choisissez le format le plus adapté au niveau de développement ou à l’expérience de votre équipe. « L’étoile de mer » est un format classique facile à utiliser et à comprendre et il fonctionne même à distance si vous utilisez un tableau blanc électronique.

En revanche, pour un format comme “Writing The Unspeakable (Ecrire l’indicible)”, l’équipe doit pouvoir se réunir sans être dérangée et tous les membres doivent bien se connaître et se faire confiance.

Notre astuce : Présentez les dernières techniques de rétrospective en douceur à votre équipe. Choisissez un format assez simple. Au fil du temps pour vous pouvez évoluer vers des techniques plus exigeantes.

Est-ce que de nombreux sujets discutés traitent de votre environnement dans lequel votre équipe travaille ? Si c’est le cas, il sera bon à un moment donné d’impliquer aussi les parties prenantes.

Rétrospective : méthodes et exemples

Pour briser la glace :

EAVP : Chaque membre d’équipe doit dire de quel profil il se sent le plus proche dans la rétrospective du jour :

• Exploreur (avide et enthousiaste)
• Acheteur (cherche juste à savoir s’il peut obtenir des informations, des connaissances)
• Vacancier (apprécie le temps passé loin de ses autres activités)
• Prisonnier (préfèrerait être ailleurs)

Chaque personne écrit la première lettre du mot de leur choix sur un bout de papier et les papiers sont ramassés anonymement. Si l’un des papiers comporte un V ou P, alors le sujet est discuté par l’équipe. Pourquoi un membre de l’équipe se sent comme un « vacancier » ou un « prisonnier » ? Que doit-on changer pour améliorer l’attitude de l’équipe envers la rétrospective ?

Faites une liste des problèmes :

Voilier / Yacht Les participants à la rétrospective regardent ensemble la photo d’un bateau sur un chevalet de conférence par exemple puis après avoir écrit les problèmes qui leur tiennent à cœur sur des post-it, collent ces post-it sur la partie du bateau qui représente le mieux leur problème. Par exemple, le problème est lié à quelque chose qui :

• Nous motive en tant qu’équipe (moteur du bateau ou voile) ?
• Pourrait représenter un danger plus tard (iceberg) ?
• Ralentit l’équipe (ancre) ?

Se renseigner :

5 Pourquoi : Méthode développée par l’ancien PDG de Toyota Taichii Ohno. Comme le ferait un enfant, nous posons la question « Pourquoi » 5 fois. Regardons un exemple.

Problème : Nous avons manqué l’échéance de livraison pour notre nouvelle version de produit.

Pourquoi avons-nous manqué l’échéance ?

Parce que tout le monde n’a pas fini ses tâches dans les temps.

Pourquoi tout le monde n’a-t-il pas fini dans les temps ?

Parce qu’il y avait beaucoup de demandes de support urgentes à gérer en même temps.

Pourquoi y a-t-il eu de nombreuses demandes de support urgentes et simultanées à gérer ?

Parce qu’une importante mise à jour matérielle qui était planifiée au même moment a provoqué des incidents.

Pourquoi une importante mise à jour matérielle a-t-elle été planifiée exactement au même moment ?

Parce que les priorités pour l’équipe n’ont pas été clairement fixées et planifiées.

Pourquoi les priorités de l’équipe n’ont-elles pas été clairement fixées et planifiées ?

Parce que les parties prenantes n’étaient pas d’accord sur laquelle était la plus importante.

Qu’est ce qui a causé le problème ? Des conflits sur les priorités parmi les parties prenantes => les priorités n’ont pas été bien coordonnées.

Taiichi Ohno était convaincu que le problème serait clairement identifié après le 5^ème « Pourquoi ». Après avoir fait cet exercice, vous pouvez discuter des résultats et faire une session de brainstorming pour trouver des idées afin d’éviter ce problème dans le futur. Par exemple, il pourrait être utile de faire remonter le problème au niveau hiérarchique supérieur ou alors d’aider les parties prenantes à trouver un accord.

Parvenir à un accord :

Utiliser des points de couleur pour voter : Présentez les mesures proposées dans les phases de la rétrospective et demandez ensuite aux participants de voter sur celles-ci en utilisant les points de couleur qui leur ont été donnés. Chaque personne reçoit deux ou trois points de couleur à attribuer comme elle l’entend pour indiquer les mesures qu’elle juge les plus importantes. Ils peuvent donner tous leurs points à une seule mesure ou les répartir entre plusieurs mesures. La mesure comportant le plus grand nombre de points est mise en œuvre lors de l’itération suivante.

Conclure la rétrospective :

Respect et appréciation : Chaque membre de l’équipe est invité à remercier ou à féliciter personnellement un autre participant pour une contribution spécifique au projet. Cela peut être pour l’aide qu’ils ont apportée ou pour leur grande implication. Une fois que chacun a contribué, la rétrospective peut se terminer.

Outils pour les équipes virtuelles

Certains des formats mentionnés ci-dessus, sont plutôt destinés pour des groupes se réunissant en personne dans une salle de réunion. Les équipes projets sont toutefois de plus en plus globales et collaborent à distance. Cela n’exclut cependant pas l’utilisation de formats innovants de rétrospective.

Dans la rétrospective, il est utile de disposer non seulement d’un bon outil de vidéo conférence (idéalement avec utilisation de la webcam pour que tout le monde se voit) mais aussi des outils suivants :

1. Le site Internet “Fun Retrospectives” a développé son propre outil à distance pour le format « Etoile de mer ».
2. Des tableaux blancs virtuels et interactifs tels que IdeaBoardz, Miro, Mural, et Padlet offrent des trames pour les rétrospectives. Les membres de l’équipe peuvent apporter leur contribution sur ces tableaux en temps réel.
3. Si vous fournissez à toutes les personnes impliquées des diapositives Google ou un document Word, tout le monde peut les utiliser simultanément et en temps réel.
4. Pour les entreprises dont la politique de sécurité empêcherait l’utilisation des options mentionnées ci-dessus, vous pouvez simplement créer une présentation et la partager depuis votre écran. Vous pouvez alors ajouter les retours et commentaires des membres d’équipe directement à la présentation afin que tout le monde les voie immédiatement. Une autre option est d’envoyer en amont la présentation par e-mail à tous les participants ce qui permet à tout le monde d’y réfléchir et de noter ses idées avant la réunion. Les retours des uns et des autres peuvent être discutés pendant la réunion.

Modèle possible pour 3 et 4 : l’image du voilier un peu plus haut dans cet article.

Méthodes avancées pour les rétrospectives  

Votre équipe est-elle composée de professionnels expérimentés déjà familiers avec les rétrospectives ? Si c’est le cas, voilà quelques nouvelles choses que vous pouvez essayer :

• Futurespectives: comme son nom l’indique, les futurespectives vous font vous concentrer sur le futur plutôt que sur le passé. Ceci est particulièrement utile au démarrage du projet quand les objectifs sont définis et que les risques sont identifiés. Voici quelques exemples de formats qui ont fait leurs preuves :
  • Souvenez-vous du futur– la question est posée à l’équipe (éventuellement avec les parties prenantes et peut-être un client) : « En supposant que le projet vient de se terminer et qu’il a été une parfaite réussite, qu’est-ce qui en a fait une réussite ? »
  • Pre-Mortem– En inversant la question pour identifier les scenarios que vous souhaiteriez éviter, demandez aux participants : « En supposant que le projet vient de se terminer et qu’il a été un échec complet, pourquoi a-t-il été un échec ? Qu’est ce qui a causé l’échec ? »
  • Espoirs & Inquiétudes– Chacun a l’opportunité d’exprimer ses espoirs et ses inquiétudes au sujet du projet qui vient de démarrer et ceux-ci sont discutés avec les autres participants.

Il est également instructif de répéter un exercice tel que celui-ci à mi-parcours du projet pour voir ce qui a changé depuis le début du projet.

• Liberating Structures a été développé à l’origine pour servir de contrepoids aux présentations monotones – “Mort par PowerPoint” (trop de diapositives avec trop de contenu) – et aux réunions sans fin. Il s’agit d’une série de formats conçus pour extraire des idées innovatives du groupe en utilisant l’intelligence collective des participants du groupe. Cette technique est utile dans d’autres domaines également mais cela fonctionne particulièrement bien dans les rétrospectives.

Astuce pour les débutants : 1-2-4-all: Un sujet est présenté (pour encourager plus de plaisir et de créativité, la question peut être formulée de manière négative. Par exemple : quel est le meilleur moyen d’entraver l’agilité de notre entreprise ?)

• L’équipe a une minute au cours de laquelle chaque participant écrit le plus d’idées possible sur un bout de papier.
• Puis, chaque participant choisit un partenaire. Pendant les 2 prochaines minutes, le binôme discute de ses idées et crée une nouvelle liste consolidée.
• Après cela, chaque binôme se rapproche d’un autre binôme. Chaque nouveau groupe composé de 2 binômes a maintenant 4 minutes pour discuter des idées sur chacune de leur liste et pour développer une nouvelle liste consolidée.
• Dans l’étape finale, chaque groupe a 5 minutes pour discuter et sélectionner l’idée qu’il trouve la plus importante pour la présenter à l’ensemble du groupe. Chaque groupe peut écrire l’idée sur une grande fiche ou sur un chevalet de conférence puis l’explique à l’ensemble du groupe. Quand l’exercice a été formulé comme une question négative, les idées générées peuvent ensuite être reformulées comme des idées positives.
• Les jeux agiles sont non seulement utiles pour enseigner les méthodes agiles au cours d’ateliers d’introduction, mais le principe de ludification a aussi montré que les formats utilisant des jeux et/ou des compétitions sont plus efficaces que des discussions ou des présentations et mènent à une meilleure compréhension sur le long-terme de ce qui a été appris. Des simulations familières telles que Ubongo Flow Game,Lego4Scrum, et Fearless Journey réveillent les instincts de jeu des participants et fonctionnent comme des expériences d’apprentissage directes et souvent tactiles.

Astuces pour les débutants : White Elephant Sizing (estimation de la taille de l’éléphant blanc) : Le groupe estime le travail en utilisant la taille des t-shirts comme référence. Cela permet aux participants d’estimer le périmètre relatif des projets agiles. Dans une rétrospective, vous pourriez demander aux participants de commencer par estimer la quantité de travail impliquée dans les activités domestiques ordinaires (comme passer l’aspirateur, désencombrer un placard, rénover une cuisine ou préparer un repas) et ensuite discuter au sein de l’équipe de la manière dont chaque personne est arrivée à ces estimations. Les connaissances acquises ainsi peuvent être utilisées dans la prochaine itération lorsqu’il s’agira d’estimer l’effort nécessaire pour répondre aux exigences « réelles ».

Et après la rétrospective ?

Idéalement, votre équipe propose au moins une idée concrète et immédiatement réalisable au cours de la rétrospective. Il est important que l’équipe mette effectivement cette mesure en œuvre et que ses efforts soient pris au sérieux par son entourage pour que l’équipe ait le sentiment que la rétrospective a été utile et productive.

Vous devriez donc documenter ces suggestions d’amélioration dans un registre.

Traitez-les avec la même diligence qu’une exigence fonctionnelle ou technique lors de la prochaine réunion de planification : comme quelque chose qui doit être planifié et réalisé.

Vous pouvez utiliser des mesures comme celles-ci pour suivre le succès de la mise en œuvre :

• Mesure continue de la productivité et du nombre de tâches traitées simultanément (rapidité de l’équipe)
• Atteindre le nombre cible d’utilisateurs de produits (enquêtes clients)
• Satisfaction de l’équipe
• Confiance de l’équipe dans la qualité de leur produit (enquêtes collaborateurs).

Résumé

Dans cet article, vous avez obtenu des informations sur :

• Pourquoi il ne faut pas attendre la fin du projet pour organiser une réunion sur les enseignements tirés et comment la tenue régulière de réunions de rétrospectives peut vous aider à en savoir plus sur les améliorations de processus possibles.
• Les façons de vous assurer que vos rétrospectives sont créatives et productives sur le long-terme, y compris des méthodes adaptées aux équipes travaillent à distance et/ou expérimentées.
• Comment identifier des mesures spécifiques d’amélioration, les mettre en œuvre et suivre leur succès.
• Le rôle des coachs agiles et des scrum masters dans l’assistance aux équipes.

Faites-nous part de vos commentaires. Quelle a été votre expérience avec les rétrospectives et possiblement avec les méthodes spécialisées ? Avez-vous des astuces à partager pour travailler avec des équipes à distance ? Partagez avec nous ci-dessous !

 Antje Lehmann-Benz (PMP, PMI-ACP, PSM expert / formatrice en Méthodologie Agile) – Antje Lehmann-Benz, PMP, enseigne la gestion de projet et se concentre particulièrement sur des séminaires sur les questions Agiles et Scrum. Elle a également de l’expérience dans la formation aux logiciels (JIRA et Confluence) et en consulting. En plus d’enseigner les cadres et la théorie, elle est également expérimentée dans l’utilisation de jeux et d’exercices pratiques Agiles pour renforcer les connaissances acquises.  

En savoir plus sur Antje Lehmann-Benz sur LinkedIn et XING.

Der Beitrag Les rétrospectives pour les projets Agiles– guide pratique (+ téléchargements) erschien zuerst auf Blog Gestion de Projets pour les Entreprises.