Bientôt autant de certifiés PMI-ACP® que PMI-CAPM® !

Gageons que la certification PMI Agile Certified Practitioner (PMI-ACP)® va encore séduire davantage de managers de projet !

PMGS est partenaire de DantotsuPM

En effet, en Avril 2019, il deviendra possible de passer l’examen en ligne, depuis votre bureau ou de chez vous.

Le mouvement Agile est devenu un standard au fil des années comme approche de management de projet et cette certification permet aux managers de projets de s’acculturer aux différentes méthodes et états d’esprit associés à l’agilité.

Aussi, les statistiques de janvier dernier du PMI indiquent-elles que le nombre de certifiés PMI-ACP a atteint plus de 26000 professionnels en quelques années alors que la certification CAPM qui qualifie les débutants dans le métiers de management de projet en est à 37000 après bien plus longtemps. Il est vrai aussi que nombre de certifiés CAPM seront devenus des professionnels du management de projet et auront passé d’autres certifications après avoir obtenu l’expérience requise. Certains auront évolué vers d’autres rôles ou métiers dans lesquels leur culture projet leur restera toujours utile !

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

 

 

Avez-vous commandé cette grande affiche pour expliquer Scrum dans votre organisation ?

Vous souhaitez recevoir une aide visuelle pour interpréter le guide Scrum?

https://www.scrum.org/resources/blog/scrum-poster-visual-guideaid

Demandez votre copie gratuite de ce très sympathique et complet poster Scrum et montrez-le à vos collègues et amis.

Cette affiche peut être un outil d’apprentissage (par exemple lors de la lecture du guide Scrum) et un outil permettant à un ScrumMaster d’expliquer Scrum à l’organisation, au responsable produit ou à l’équipe de développement.

https://www.incrementor.com/products/scrum-poster

Une seule demande par personne est acceptée. Expédition aux États-Unis et en Europe uniquement. Vous serez informés par e-mail une fois le poster expédié.

CertYou est partenaire de DantotsuPM

L’art et la science de la priorisation de l’arriéré de produit (« Product Backlog ») par Kiron Bondale

Comment prendre en compte les multiples facteurs en compétition pour trouver le meilleur équilibre ?

The art and science of backlog prioritization

https://kbondale.wordpress.com/2018/04/08/the-art-and-science-of-backlog-prioritization/ par Kiron Bondale

Une responsabilité clef des « Product Owners » / Propriétaires de Produit est de s’assurer que la priorisation des articles de travail dans un arriéré de produit réalise au mieux les buts et la vision pour le produit. À la différence des portefeuilles de projet où les choix ou décisions de priorisation sont souvent prises par un comité de direction, avec un arriéré de produit, la responsabilité de la réussite business ou de l’échec du produit repose sur les épaules du Propriétaire de Produit.

Cette activité tient autant de la science que de l’art.

On doit prendre en compte de multiples facteurs en compétition et trouver un équilibre

  • Valeur d’affaires
  • Alignement avec la vision originale
  • Dépendances
  • Contraintes
  • Réduction de risque

L’évaluation du coût de retard ou du Weighted Shortest Job First (Travail Pondéré le Plus court en Premier) peut injecter cohérence et objectivité dans l’activité, mais cela demande aussi beaucoup d’apprentissage et d’efforts. Si bien utilisé, de telles approches d’évaluation devraient être utilisées pour guider le processus décisionnel plutôt que le remplacer.

Relisez ce billet sur le Weighted Shortest Job First

Le Propriétaire de Produit doit collaborer efficacement avec les parties prenantes clefs pour valider que les livrables ne satisferont pas seulement les besoins des uns ou des autres. Cette collaboration exige une volonté de la part du Propriétaire de Produit de reculer la sortie de certaines fonctions « très très demandées » si cela aboutira à un meilleur produit d’ensemble.

Quand il travaille avec une nouvelle équipe, le Propriétaire de Produit doit activement écouter pendant les discussions de revue de l’arriéré avec les membres d’équipe car certains pourraient manquer du courage d’ouvertement défier une décision peu éclairée. Une façon d’aider à surmonter ce risque est de demander activement à l’équipe au fur et à mesure que les articles sont classés s’ils voient des défauts dans l’ordonnancement ou s’ils pensent qu’un article pourrait devoir être abordé plus tôt. La priorisation peut être un bon sujet à considérer pendant des rétrospectives afin d’inspecter et adapter régulièrement le processus.

différentes perspectives

Le Propriétaire de Produit voudra naturellement maximiser l’obtention de valeur business tandis que les propriétaires de solution voudront aborder des incertitudes sur la solution ou adresser l’adaptabilité ou la flexibilité dès le début. Une saine priorisation devrait ressembler à une lutte à la corde entre les représentants pour chaque facteur d’influence.

Un bon Propriétaire de Produit devrait mettre son ego de côté lors de l’activité de priorisation car son but n’est pas de démontrer son omniscience sur le séquencement du développement du produit, mais plutôt de livrer le meilleur produit possible.

SMPP est Partenaire de DantotsuPM

Que faire quand la co-localisation géographique des équipes pour un projet Agile n’est pas une option ?

Un des principes Agiles est : “la méthode la plus efficace et efficiente de transmettre l’information dans une équipe de développement est la conversation en face à face.”

When Co-location is not an Option

http://blog.scrumstudy.com/when-co-location-is-not-an-option/  par SCRUMstudy

Ceci est utilisé pris par la plupart des agilistes comme la justification pour des équipes géographiquement co-localisées. Il y a eu bien des débats autour de la possibilité d’avoir des équipes géographiquement distribuées et comment cela fonctionnerait dans un environnement Agile et plus spécifiquement Scrum. Vous pouvez lire de très forts avis pour ou contre.

Le manifeste agile exprime clairement “S’adapter au changement PLUS que suivre d’un plan” et c’est probablement ce qui devrait être fait ici.

les communications dans l'équipeLa manière dont les équipes travaillent change constamment et les équipes géographiquement distribuées sont une réalité dans un monde globalisé. Vous avez tous les jours des ScrumMasters aux États-Unis avec  des équipes de développement en Chine ou en Inde. Cela ne peut être ignoré. Ce qui peut être fait est de suivre l’esprit du Manifeste Agile qui considère la conversation en « face à face » comme la plus efficace. De nos jours, il y a tant d’outils à notre disposition qui peuvent donner une expérience de conversation en face à face même quand les équipes sont à des milliers de kilomètres de distance. En dehors des outils, il y a peu d’indications pour aider à coordonner efficacement le travail de ces équipes.

1. Les réunions Scrum

Une fois que l’équipe est prête à fonctionner en virtuel, il est essentiel que toutes les réunions recommandées par l’approche Scrum se passent dans la réalité comme prévues. Cela inclut par exemple un Daily Stand-up mais à distance. On peut utiliser des outils comme Skype ou d’autres outils de conférences sur internet (Webex ou GotoMeeting) pour suivre ces réunions. Ces réunions peuvent aussi servir de sessions de « team building » dans une équipe multiculturelle et multilingue. Le ScrumMaster doit prendre les devants et s’assurer que tous les membres d’équipe suivent ces réunions et participent comme exigé.

2. La communication

Businessman Using ComputerLes équipes Scrum distribuées géographiquement dans le monde entier peuvent varier en termes d’éthique de travail, de culture de bureau et de langue. Donc une plate-forme et une langue communes sont exigées pour manager les différences. Les facteurs comme des fuseaux horaires différents, des horaires de travail et le mode de communication devraient être clairement identifiés pour aider à mettre en place des canaux de communication clairs et transparents.

3. Co localisation

Il faut trouver des opportunités de réunir les équipes géographiquement et culturellement distribuées

Parfois quand le travail est proche de se terminer ou si le projet exige qu’une ou plusieurs équipes travaillent étroitement ensemble, les équipes pourraient devoir se rassembler temporairement en un même endroit. Cela aide dans la construction de l’esprit d’équipe quand les membres d’équipe parviennent à se connaître et ce augmente l’efficacité dans la livraison du projet.

Avec la globalisation, l’évolution vers des équipes Scrum géographiquement distribuées et travaillant dans un environnement virtuel est un changement inévitable et aussi un complément à la façon dont nous livrons des projets avec Scrum.
CertYou est partenaire de DantotsuPM

Jeff Sutherland a lancé en 2018 le Guide de Scrum@Scale: Quels sont vos retours ?

https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/  par Jeff Sutherland

La première équipe de Scrum a fini son premier Sprint il y a 25 ans. Mon but alors et il continue de l’être, était de construire des équipes à hautes performances. Depuis, je me suis concentré uniquement sur ce sujet. Comment permettons-nous aux gens d’en accomplir davantage, de vivre de meilleures vies et de changer fondamentalement la trajectoire de leur réussite ?

Des millions des gens se rencontrent généralement maintenant chaque jour pour leur Daily Scrum.

Il est stupéfiant de voir comment Scrum a réorganisé le monde de travail au travers de nombreuses disciplines et au-delà du logiciel. The Standish Group data montre que des projets Agiles ont trois fois moins de chance de complètement échouer que des projets en cascade et quatre fois plus de chance de réussir. C’est ce qui fait que les sociétés veulent devenir « Agile ».

Actuellement, la menace existentielle sur Scrum est le “Mauvais Scrum (Bad Scrum).” Donc, j’ai investi ces quelques dernières années à codifier les meilleures pratiques pour faire grandir Scrum et réfléchir à ce qui fonctionne ou pas et y donner un nom : Scrum@Scale.

Scrum@Scale est la structure pour que les organisations développent itérativement la meilleure façon pour Scrum de marcher dans leur contexte.

téléchargez gratuitement le guide complet de 19 pages

Donc je l’ai gardé simple. Le Guide Scrum@Scale comporte juste quelques pages. Comme avec Scrum et le Guide Scrum, il est libre d’accès. Vous ne devez pas me demander la permission. Prenez-le, utilisez-le et partagez votre connaissance et votre expérience.

Chaque équipe Scrum est différente, même des équipes dans la même organisation. Elles ont leur culture propre, leurs façons de travailler, des succès, des échecs, leur propre contexte. Mais elles suivent une structure commune. Et dans cette structure elles développent itérativement de nouvelles solutions aux problèmes qu’elles essayent de résoudre.

Pour disséminer le bon Scrum et avoir l’impact nous voulons avoir sur le travail, nous avons besoin de plus de personnes que seulement Scrum Inc. pour l’enseigner. Nous avions un pilote l’année dernière avec Angela Johnson de l’Équipe Co-Lead et avons énormément appris. Nous postons ses formations sur le site Web de Scrum Inc aussi bien que scrumatscale.com. L’an dernier, nous avons décerné un diplôme à notre première classe de formateurs Scrum@Scale. Ils étaient 17.

Vous pouvez lire le processus pour devenir formateur avec toutes les qualifications et bénéfices sur notre site scrumatscale.com.

Je veux vraiment mettre en évidence une chose que nous exigeons vraiment . Pour devenir un formateur Scrum@Scale vous devez avoir implémenté Scrum à l’échelle et soumis une étude de cas de ce travail. Qu’avez-vous appris ? Qu’est-ce qui était difficile ? Qu’est-ce qui a fonctionné ? Et cette étude de cas doit être partagée. Pas juste avec Scrum Inc. Pas seulement avec d’autres formateurs Scrum@Scale. Avec le monde entier. Nous voulons que le monde entende parler des réussites de nos formateurs et que ces histoires deviennent des points de référence dans une conversation globale.

Des centaines de personnes ont déjà suivi nos classes Scrum@Scale, beaucoup de coachs et formateurs. Les réactions que nous avons obtenues sont que c’est une codification des meilleures pratiques qu’ils avaient appliquées depuis des années. Nous voulons favoriser une communauté où les gens et les organisations se transforment en apprenant les uns des autres.

Nous voulons créer une bibliothèque vivante des innombrables manières d’utiliser Scrum à l’échelle dans une structure commune.

Jeff Sutherland, Creator of SCRUM

Une bibliothèque qui est là si vous êtes l’une des sociétés du Fortune 100 aux États-Unis ou une startup en pleine croissance à Hyderabad.

Comme vous le savez peut-être, je me suis retiré du poste de CEO de Scrum Inc en janvier 2018. Une des raisons principales est qu’ainsi je pourrai concentrer mes efforts sur Scrum@Scale et le partager avec autant de personnes que possible dont les vies seront meilleures grâce à cela.

Avez-vous déjà utilisé ce guide et quels sont vos retours personnels ?

CertYou est partenaire de DantotsuPM

Scrum Master Trends Report 2019 – Tendances chez les Scrum Masters !

C’est en 2017, que « Age of Product » a lancé le premier rapport sur les salaires des Scrum Masters.

Le tout premier rapport de l’industrie qui regardait en profondeur les antécédents scolaires, l’expérience au travail, les industries et les détails organisationnels des entreprises pour lesquels travaillent les Scrum Masters ou coaches Agile.

L’édition 2019 du Scrum Master Trends Report a été créée en partenariat avec Scrum.org, le principal établissement de formation et de certification Scrum fondé par Ken Schwaber, cofondateur de Scrum.

Pour en savoir plus sur l’état de l’industrie, téléchargez gratuitement le Scrum Master Trends Report 2019.

CertYou est partenaire de DantotsuPM

Savez-vous ce qu’est un registre de « Dette Technique » et comment bien l’utiliser dans les méthodes itératives #Agile ?

« Dettes et mensonges sont ordinairement ensemble ralliés » Rabelais dans Pantagruel.

Using a « Technical Debt Register » in Scrum

https://www.scrum.org/resources/blog/using-technical-debt-register-scrum par Ian Mitchell

En vieillissant, je me métamorphose en l’un de ces types nostalgiques et ennuyeux qui vit trop dans le passé. Les choses étaient mieux avant, mon enfant. Nous avions des standards et il y avait moins de « sur-simplification ».

Mais parfois au crépuscule, comme je me lève de mon fauteuil à bascule sous le porche et me penche en avant pour soulager mon dos, je reconnais qu’il y a une chose qui est en réalité meilleure maintenant qu’au début des années 2000 : De nos jours, un homme peut parler de la « dette technique » sans que les gens le prennent pour un fou.

La dette technique peut être définie comme les conséquences à long terme de faibles décisions de conception. À l’origine décrit comme une métaphore par la Ward Cunningham, à peu près tout le monde accepte maintenant que la dette technique est un risque réel qui peut réellement être encouru. Cette identification est bonne. Critiquer Java et en damner les conséquences n’est pas vraiment « Agile », c’est juste jouer au cow-boy. Mais la vérité est que pendant des années, cela n’a pas été compris, pas avant que les dettes de certains imbéciles soient si importantes qu’elles ne puissent perdurer.

Cela vaut cependant la peine de garder à l’esprit que pas tous les défauts et bugs ne constituent de la dette technique.

Écopez un peu de votre dette avant qu’elle ne vous noie.

C’est parce qu’ils ne reflètent pas toujours « des décisions de conception ». Ce sont souvent juste des erreurs, peu importe à quel point ils pourraient être irresponsables ou indignes. Ainsi quand une décision ne met pas directement en péril la qualité de produit, ce n’est pas de la dette technique. Une équipe peut souhaiter un nouvel environnement ou un module d’extension, mais ne pas les fournir n’est pas de la  » dette technique », puisque cela ne met pas en danger la qualité du produit lui-même. Cela pourrait très bien réduire la vitesse de développement, parce qu’ils doivent boitiller en utilisant une vieille plate-forme de développement, mais c’est un problème différent.

Dans Scrum, l’attente consiste en ce qu’une définition de DONE (fait) devrait être suffisamment robuste pour que des niveaux ingérables de dette ne puissent pas s’accumuler. De là, si on sait que la dette technique va augmenter, la définition de DONE devrait être revisitée. Il est essentiel de découvrir pourquoi la dette est encourue et comment cela peut être évité.

Il y a certain nombre d’autres contrôles qui peuvent être utilisés pour limiter la dette.

Par exemple, une équipe devrait tenir compte du « refactoring » (et bien d’autres tâches) en décidant de combien de travail ils peuvent embarquer dans un Arriéré de Sprint sans mettre en péril la qualité à long terme. Mais en dehors de ces contrôles et recherches d’équilibre, il n’y a aucune prescription sur comment la dette technique devrait être traitée une fois que vous l’avez. Ce n’est pas une inadvertance, puisque Scrum est délibérément aussi non-normative que possible. C’est une structure de travail qui laissent aux équipes la décision de comment elles la mettent en œuvre.

finiNotez cependant que mettre en œuvre « des sprints spéciaux » pour nettoyer la dette technique n’est pas une option. Des sprints techniques de dettes, aussi mentionnés comme des sprints de solidification ou renforcement, sont essentiellement un anti-modèle. Chaque Sprint doit apporter un incrément de valeur véritable. C’est pourquoi la Définition de DONE est le rempart primaire contre l’accroissement de la dette en premier lieu.

Ce que font certaines équipes est de maintenir un registre de dettes techniques

Dans ce registre les décisions de conception qui mènent à de la dette peuvent être rationalisées. Vous pouvez penser à ce registre comme un registre RAID (Risques, Assomptions, Issues & problèmes, et Dépendances) qui est sous le contrôle de l’équipe. L’équipe y détaille les conséquences techniques de décisions prises de manières opportunes sur la qualité de mise en œuvre du produit, souvent en termes de probabilité, d’impact et de remédiations envisagées. Il peut être possible de recommander de l’adresser pendant un Sprint, si l’équipe a une compréhension suffisante de l’Arriéré de Produit. Suppositions et dépendances peuvent aussi entrer dans le registre et bien sûr quelques risques peuvent finalement transformer en douloureux problèmes.

Un registre technique de dettes peut aider à informer des équipes de comment la dette encourue devrait être gérée. Ils peuvent prendre des décisions réfléchies et informées sur quand vraiment ajouter de la dette et quand au contraire la rembourser. L’utilisation d’un tel registre ne fait pas partie de Scrum, mais néanmoins cette technique peut aider une équipe à prendre en main la dette technique qu’ils décident d’accepter. Parfois, par exemple, la dette technique peut être réglée en mettant en œuvre des histoires de l’arriéré de produit. Dans d’autres cas pas, et la dette doit alors être adressée séparément.

Que faire ?

Certains cas de dette peuvent devoir être exposés au Propriétaire de Produit pour leur prise en considération et d’autres pas. Dans les cas sévères, de la dette technique peut avoir été accumulée qui excède la valeur du projet lui-même, probablement même de multiples fois. Dans de tels cas extrêmes, l’approche la plus pragmatique peut être de tuer le projet et repartir de zéro. Inutile de le dire, cette variation de « échouer maintenant plutôt que plus tard » nécessite un courage extrême.

remboursez graduellement votre dette

Une autre option quand on fait face à une dette technique substantielle est de la réduire graduellement, Sprint après Sprint. L’équipe peut devoir s’entendre avec le Propriétaire de Produit pour livrer quelque chose, à chaque itération, qui fournisse tout de même une valeur suffisante aux parties prenantes. Clairement ce n’est pas une excellente option. Elle peut se terminer en marchandages, où la magnitude et la propriété du problème de la dette ne sont pas reconnues ni rendues visibles des parties prenantes. La dette technique devient alors plus d’un cas de problème technique. Les parties affectées pourraient être encouragées à fermer les yeux tant qu’elles obtiennent quelque chose de valeur immédiate pour le business en retour, mais aucun de ceci n’est bon pour la franchise, la confiance ni la transparence.

Maintenant, bien qu’ayant comparé un registre technique de dettes à un registre RAID, je ne suggère pas qu’il doive prendre la forme « documentée » habituelle de celui-ci. Selon mon expérience, il est généralement meilleur d’utiliser un « Information Radiator ». Parfois, cela peut être aussi rudimentaire qu’une feuille de papier scotchée au dos de la chaise du ScrumMaster, mais je préfère proposer aux équipes d’utiliser un mur de cartes dédié à cette fin. Les statuts typiques sont : A faire, En cours, Fait et A escalader. Les articles sont Faits quand ils sont ou atténués ou acceptés.

Incidemment, cela marche aussi pour les registres RAID conventionnels au niveau du projet et du programme. L’escalade depuis un Registre de Dettes Techniques impliquerait sa promotion à un tel niveau. Les managers sont ainsi encouragés à prendre un intérêt actif dans ces registres et questionner tout problème non remonté qui semblent bloqué.

Cela peut être une excellente façon d’encourager le « gemba » chez les managers, où ils sortent du bureau, s’y promènent, mettent leurs liens hiérarchiques et filtres de côté et voient la réalité des choses par eux-mêmes.

CertYou est partenaire de DantotsuPM

Pour aller plus loin, relisez ces précédents billets sur ce sujet

 

Comment rester un manager de projet pertinent voire recherché dans le monde actuel ?

S’adapter au monde numérique et disruptif ou bien disparaitre: Le quotidien des managers de projet…

Staying relevant as a Project Manager in today’s world

http://www.virtualprojectconsulting.com/staying-relevant-as-a-pm/ par Derek Smith

Dans le monde numérique et disruptif actuel, les cadres et organisations font face à de féroces défis compétitifs qui exigent qu’ils s’adaptent continuellement, ou bien affrontent les conséquences de ne pas le faire et la possibilité de disparaitre totalement. Il en va de même pour les managers de projet. Ils/Elles doivent se tenir au courant ce qui change avec les méthodes Agiles et dans la philosophie du management de projet pour rester pertinents et employables.

Pratiques Agiles et Lean

 

Livres sur Amazon

Des pratiques flexibles Agiles et Lean, comme Scrum et Kanban qui étaient autre fois un domaine réservé aux développeurs de logiciels, sont idéalement positionnées pour générer le succès dans le business. Elles font des incursions significatives à l’extérieur du département informatique et trouvent l’acceptation et l’appui des dirigeants exécutifs. Les organisations ont besoin de sentir rapidement venir les changements externes et internes et de s’y adapter pour livrer des résultats efficaces et rentables, sans perdre de vue le fait que la gouvernance d’ensemble est toujours requise.

La recherche du succès commence aussi par choisir la bonne approche pour délivrer les projets. Certaines caractéristiques spécifiques des projets et des besoins organisationnels devraient former les bases du choix de l’approche la meilleure.

Alors que chacun saute sur le train en marche pour capitaliser sur la formation et l’adoption, et avec tant de choix quand on parle des approches, il peut être intimidant d’essayer de suivre les avancées sur comment ces pratiques se développent et lesquelles choisir. PMI a produit une série de rapports sur le leadership. Notons que les 6 rapports sont liés à atteindre une plus grande agilité.

Les rapports couvrent des sujets comme se concentrer sur le client, provoquer des retours fréquentes, choisir la bonne approche et transformer l’organisation en se concentrant sur les personnes et surveillant les progrès. Développer la collaboration entre des branches différentes du business, changer la culture et évaluer les besoins transverses aux entités fonctionnelles sont d’autres aspects primordiaux à considérer pour atteindre une agilité organisationnelle plus élevée.

CertYou est partenaire de DantotsuPM

Avancement de carrière

accessible sur le site web du PMI

Du point de vue de leur carrière, les managers de projet doivent continuer à être au fait des avancées pour rester recherchés et gagner des salaires convenables. PMI Pulse of the Profession® indique que les parties prenantes font le forcing pour adopter des pratiques agiles. Les organisations qui sont agiles et répondent rapidement à la dynamique des marchés, récoltent plus de bénéfices de leurs projets que celles qui ne le sont pas — 75% contre 56%, selon la recherche.

Il est pour cette raison que le PMBOK ® le Guide –Sixième Édition s’est enrichi de pratiques agiles et que le PMI® s’est associé avec Agile Alliance® pour créer le nouveau Agile Practice Guide.

Pour tous les détails (en anglais)

La certification PMI-ACP® est actuellement celle qui connait la croissance la plus rapide au PMI et couvre beaucoup d’approches Agile comme Scrum, Kanban, Lean, la programmation extrême (XP) et le test-driven development (TDD).

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

PRINCE2 Agile pour les manager de projet et organisations PRINCE2®

Agile signifie accepter que votre projet ne livrera pas nécessairement tout qui a été spécifié au départ et que, en effet, les utilisateurs n’ont pas nécessairement besoin de tout ce qu’ils ont spécifié.

PRINCE2 Agile for PRINCE2® practitioners

https://www.axelos.com/news/blogs/october-2018/prince2-agile-for-prince2-practitioners par Julia Gosse

A quels défis PRINCE2® les praticiens et leurs employeurs font-ils face avec le concept de livraison de projet Agile ?

Le plus grand défi consiste en ce que le terme « Agile” est souvent mal compris : les gens pourraient faire des raccourcis comme « juste plus vite »; ils pourraient avoir entendu dire que c’est seulement pour les projets informatiques, qu’il relève seulement de Scrum ou que leurs contraintes légales les empêchent d’utiliser.

L’approche Agile

Les projets agiles aboutissent souvent à une livraison plus rapide mais Agile est un état d’esprit. Cela signifie accepter que votre projet ne livrera pas nécessairement tout qui a été spécifié au départ et que, en effet, les utilisateurs n’ont pas nécessairement besoin de tout ce qu’ils ont spécifié.

Quand vos délais sont figés vous devez vous concentrer sur quelles sont les réelles priorités.  Se précipiter pour tout délivrer peut diluer le résultat et réduire le niveau de qualité, quelque chose qui reviendra vous hanter plus tard. Un projet Agile préfère ne pas livrer une chose si elle n’est pas à la norme exigée, mais tout dans l’approche est conçu pour s’assurer que ce qui est livré apportera de la valeur au client.

Des approches de livraison Agiles sont de plus en plus utilisées avec beaucoup de succès dans les projets en dehors de l’informatique. J’ai récemment travaillé avec une société d’événementiel utilisant Agile pour planifier et organiser une grande conférence. C’était particulièrement utile pour ce projet qui avait une durée imposée et des coûts fixes.

Davantage d’organisations et praticiens expérimentés avec PRINCE2 gèrent bien cette approche et voient Agile comme un outil très utile. En conséquence, ils adoptent certaines approches comme la co-localisation de l’équipe de projet, l’utilisation d’interactions régulières et la collaboration avec clients et utilisateurs.

Le webinaire en replay de notre partenaire QRP

Pourquoi le travail avec PRINCE2 Agile est-il efficace dans une organisation PRINCE2 ?

1. Une langue et une approche communes

Vous avez déjà obtenu un niveau de contrôle et une terminologie que vous comprenez et les organisations PRINCE2 sont expertes pour adapter PRINCE2 à des projets différents.

2. Flexibilité avec les méthodes Agiles

Il y a beaucoup de saveurs différentes d’Agile et bien que Scrum soit probablement la plus populaire, ce n’est pas la seule approche de développement Agile. PRINCE2 n’a jamais été normatif dans la définition de comment vous livrez un projet et PRINCE2 Agile peut travailler avec une ou de nombreuses approches Agiles, y compris Scrum, Kanban et DevOps. Cela garantit que l’équipe de management de projet comprend comment s’interfacer avec l’approche de livraison Agile.

Prince2 est nativement tourné vers les approches Agiles

Il est important de comprendre que PRINCE2 Agile est toujours centré sur le management de projet et que l’équipe devra être formée dans l’approche (ou les approches) de livraison Agile qu’ils adoptent.

3. Avoir une perspective business

Livre su Amazon

Dans PRINCE2 le manager exécutif représente les intérêts de l’organisation; appliquer ceci à l’environnement Agile est une approche gagnante car vous maintenez la perspective business. Cela assure que les utilisateurs ne se laissent pas emporter par leurs demandes et ce qui est livré répond aux exigences d’affaires. Cela résonne bien dans le monde Agile parce que la livraison de valeur est le principal déterminant pour donner la priorité à ce qui devrait être livré ensuite.

4. L’Agilomètre

Essentiellement c’est un outil d’évaluation de risque pour aider évaluer à quel point Agile est approprié pour un projet donné. Même dans un projet prédictif (en cascade) vous pouvez incorporer quelques éléments Agiles, donc l’Agilomètre permet aux organisations d’évaluer les implications de procéder ainsi.

Dans PRINCE2 Agile® Guidance, on trouve aussi une façon unique d’adresser les questions potentielles liées à l’introduction des méthodes agiles. Par exemple, des assomptions dérangeantes sur les besoins devant être spécifiés au début d’un projet, comment adresser la résistance à un plus grand niveau de collaboration et penser à de la formation ou des ateliers pour encourager l’acceptation d’Agile dans le management de projet.

Pourquoi les praticiens PRINCE2 devraient-ils embrasser Agile?

Les exigences et les attentes des utilisateurs dans un monde de haute technologie augmentent et les gens sont moins enclins à accepter des produits ou des systèmes périmés ou attendre pendant des mois et même des années pour les remplacer.

L’utilisation des apps sur les téléphones portables encouragent des retours et de nouvelles versions fréquentes. Nous devenons tous très habitués du style de livraison collaboratif, itératif et progressif qu’Agile favorise.

L’union des contrôles de management de projet de PRINCE2 avec la connaissance et des capacités Agiles facilite une plus grande adaptabilité aux changements sur les marchés et donne une capacité de répondre et de changer beaucoup plus rapidement.

CertYou est partenaire de DantotsuPM

 

Qu’est-ce que Agile Hybride en réalité ?

“Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride” ???

What is Hybrid Agile, Anyway?

https://www.agilealliance.org/what-is-hybrid-agile-anyway/ par Becky Hartman, Mike Griffiths, Johanna Rothman, Jesse Fewell, Betsy Kauffman, Stéphane Matola et Horia Slusanschi

Maintenant que le mouvement Agile s’est étendu à de plus grandes organisations dans davantage d’industries, nous voyons énormément de variation. Accordé, nous utilisons une grande variété de structures, techniques et méthodes utilisées, de XP à Scrum à Kanban à la Livraison Continue. Cependant, récemment nous entendons de plus en plus parler d’approches « Hybrides ».

Peut-être avez-vous entendu un dirigeant dire : “Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride”.

Ou peut-être vous avez entendu un consultant déclarer fièrement “À moins que vous ne fassiez beaucoup de prototypage, vous êtes seulement Agile Hybride”. Et ensuite, lors d’une rencontre vous entendez une autre personne dire, “Oh, nous ne sommes pas hybrides, nous utilisons une approche mélangée”.

A travers toutes ces discussions, ce que les gens veulent dire en réalité peut devenir assez confus. Ceux parmi nous qui travaillent sur le prochain Guide de Pratique Agile ont aussi entendu ces points de vue et nous ajoutons qu’une section au guide concentrée sur ce sujet. Voici certains des modèles initiaux que nous voyons…

« Itératif » par rapport à « Incrémental » par rapport à « Agile »

Les cycles de vie des projets suivent un continuum, de prévisionnel (« plan driven ») à  Agile. Pour nous aider à comprendre ce continuum, considérons deux des aspects clés de l’Agilité que sont “Livrer Tôt et Souvent” et “S’adapter au Changement”. Si nous devions les tracer sur un graphique bidimensionnel, nous obtiendrions quelque chose comme cela …

Sur le continuum d’approches, depuis prédictives (en bas à gauche) à Agiles (en haut à droite), il y a différents degrés de livraison (incrémentale) et  degrés de changement (itératif). Les techniques qui réalisent à la fois de forts niveaux de livraison et de hauts degrés d’adaptabilité sont appelées « Agiles ».

« Mélangé » (Blended) versus « Hybride »

Mais c’est juste trop simpliste. Dans le monde réel, nous n’utilisons pas juste une approche. Nous combinons presque toujours plusieurs techniques différentes. Pour nous aider à comprendre les différentes combinaisons, nous avons posé quelques définitions de travail.

Mélangé Agile (« Blended Agile ») est la combinaison de deux ou plus des méthodes établies, techniques, ou structures Agiles.

En ajoutant un peu de Kanban et des limites de travail en cours (« Work In Progress ») à vos Sprints Scrum, vous obtenez une approche « Mélangée ».  Ou peut-être voulez-vous « mélanger » un tableau de visualisation (« Information Radiator ») avec votre approche de livraison en continu. Pour beaucoup de praticiens Agiles, c’est facile à comprendre.

Nous combinons des techniques adaptatives-agressives connues pour être meilleurs dans ce que nous faisons :

Mélangé = Agile + Agile = Meilleur Agile

  • Mais en ce qui concerne le reste d’entre nous simples mortels ?
  • Et si nous ne sommes pas encore capables d’utiliser ces diverses techniques?
  • Et s’il y a contraintes ou demandes qui exigent que quelques éléments non-agiles se produisent ?

Et bien, dans ces cas, vous devriez considérer « l’Hybride »

L’Hybride Agile est la combinaison de méthodes Agiles avec d’autres techniques non-agiles.

Par exemple, un effort important pour détailler les exigences, suivi de sprints de livraison progressive serait une “Approche Hybride”. De même, le prototypage itératif fréquent d’un design, suivi d’une mise en œuvre prédictive avec un  plan simple serait “une Approche Hybride”.

Ici, l’idée est de prendre une approche non-Agile et d’y injecter quelques techniques Agiles pour aborder une question ou une opportunité spécifique:

L’hybride = non-Agile + Agile = quelque chose entre les 2 qui a du sens

Quand devrions-nous utiliser des approches Hybrides ?

Comme toute autre chose dans le monde, il y a une bonne et une mauvaise raison de faire quelque chose. Pour être clair, la mauvaise raison de mélanger des techniques est de vouloir faire comme les autres. “Utiliser des techniques Agiles” n’est pas le but. Le but est de livrer le bon résultat business en utilisant les bonnes techniques.

Voici deux scénarios :

1. Hybride comme Adéquat en fonction du but

Pour les projets qui ont un profil de risque inférieur, utilise des approches prédictives pour minimiser les dépenses. Pour des projets de risque plus élevés, utilisez des techniques Itératives pour répéter des activités jusqu’à ce que les problèmes se révèlent et soient résolus. Pour des projets ayant besoin de livraisons agressives, des techniques Progressives livreront quelque chose plus tôt et assureront l’engagement du client. Finalement, pour naviguer dans des environnements complexes, des techniques Agiles peuvent avoir un fort coût initial aérien, mais pourraient le valoir pour les résultats d’ensemble. Chacune a sa propre force. Le mélange de celles-ci de la bonne façon peut mieux répondre à votre contexte que l’utilisation de seulement une d’entre elles.

2. Hybride comme Transition-vers-Agile

Beaucoup d’équipes ne sont pas capables de basculer vers les façons de travailler en mode Agile d’un jour à l’autre. Plus l’organisation est grande, plus ses composantes sont en mouvement, plus longtemps il faudra pour changer. Si vous avez vécu dans un monde prédictif depuis de nombreuses années, les méthodes Agiles paraitront très différentes. En conséquence, votre incursion initiale dans le monde Agile sera un amalgame peu ordonné des deux. C’est OK. Vous utilisez des techniques spécifiques pour vous déplacer dans la direction vers laquelle vous voulez aller.

Chaque projet a des besoins différents. Pour ceux qui se trouvent dans un environnement surtout prédictif, une approche hybride peut être une transition vers davantage d’adaptabilité et de livraisons. Pour ceux qui ont déjà adopté la livraison et l’adaptation agressives, incorporer quelques nouvelles techniques peut encore hausser votre challenge.

CertYou est partenaire de DantotsuPM

Ne déclarez pas simplement “Nous sommes Agiles”, la réalité est que vous utilisez déjà presque toujours une combinaison de techniques différentes. Au lieu de cela, une meilleure stratégie serait de vous poser et de réfléchir à quelles approches seraient les meilleures pour ce que vous voulez réaliser en fonction de là où vous êtes.