Un référentiel sur l’hybridation des modes projet est en marche au PMI France

Des nouvelles du Lab Hybrid, projet mené par Stéphane Derouin et supporté par le PMI France et en particulier son Président Ricardo Naciff .

Tout d’abord, un énorme bravo aux 29 bénévoles qui travaillent à la réalisation du guide des bonnes pratiques hybrides.

La phase idéation des trois thèmes : Gouvernance, cadre méthodologique, dimension humaine, et leurs sous thèmes est terminée.

La phase construction et rédaction du guide des bonnes pratiques démarre en janvier 2022 pour se terminer en juin 2022.

Stéphane Derouin constitue dès maintenant deux équipes pour la rédaction de ce guide pratique et opérationnel en charge de :

  1. La rédaction du document et de sa structure de narration.
  2. La collecte :
    • de retours d’expériences,
    • de bibliographie,
    • de témoignages,
    • de documents,
    • ou de contenus théoriques en rapport avec l’hybridation.

N’hésitez-pas à contacter Stéphane si vous souhaitez vous aussi contribuer à ce travail. Merci encore à toutes et à tous !

PMI Disciplined Agile de Poche par les volontaires du PMI France !

La team PMI Disciplined Agile de Poche, composée des bénévoles Claudine Blanquier, Laurent Thomas, Frédéric Martin et Selim Khaldi, facilite la découverte de Disciplined Agile avec des mémentos de poche résumant les fondamentaux de Disciplined Agile, EN FRANCAIS !

Le PMBOK V7

Le PMI, à travers la septième édition du PMBoK, a su prendre en compte l‘évolution de l’environnement de la conduite de projet : les approches adaptatives, dont font partie les démarches Agiles, sont identifiées et décrites dans le cadre général porté par des principes de conduite de projet.

De manière pratique, l’acquisition par le PMI en 2019 de la boîte à outils Disciplined Agile (DA), traduit tout l’intérêt qui est porté à ces approches.

À partir de ce constat, une équipe pluridisciplinaire de bénévoles du « Disciplined Agile Special Interest Group » du Chapitre PMI-France a décidé de faciliter la découverte de Disciplined Agile en produisant des mémentos de poche résumant les fondamentaux de Disciplined Agile, en français !

Un superbe travail de synthèse de l’essence de cette approche et une traduction compréhensible par tous les francophones.

3 mémentos de synthèse: https://www.pmi.org/disciplined-agile/posters

  1. PMI DA poche – boîte à outils, panorama de ce que DA peut vous apporter
  2. PMI DA poche – Choose your WoW, comment choisir votre manière de travailler en équipe ou avec plusieurs équipes.
  3. PMI DA poche – cycle de vie, les différentes modélisations des cycles de vie projet ou produit en fonction de votre contexte d’activités.

Ce travail est mis gracieusement à votre disposition sur le site PMI France

Et pour aller plus loin dans la découverte de Disciplined Agile et le partage d’expérience adhérez à la communauté LinkedIn francophone “Disciplined Agile, échangeons et partageons.

QRP est partenaire de DantotsuPM

« La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile » par Fidaa Berrjeb.

Dans ce billet, Fidaa explique les 4 valeurs du manifeste agile ainsi que chaque valeur du manifeste de test.

Le manifeste agile

1. Les personnes et les interactions plus que les processus et les outils

La méthode agile privilégie l’individu et lui donne le plus d’importance. Il est facile de comprendre les personnes plutôt que les processus ou les outils, car ce sont les personnes qui répondent aux besoins de l’entreprise et pilotent le processus de développement.

« Quand les entreprises prennent de l’ampleur, elles cherchent à reproduire leur succès initial. Elles confondent bien vite le processus et le contenu ». Steve jobs dans une interview en 1995.

2. Des logiciels opérationnels plus qu’une documentation exhaustive

L’approche Agile se concentre sur la production de valeur. La documentation reste nécessaire à la continuité et à la maintenabilité du projet, mais n’apparaît pas comme une priorité. Auparavant, l’équipe passait des heures sur la rédaction de documents et cela empêchait l’avancement des livrables.

3. La collaboration avec les clients plus que la négociation contractuelle

Le message ici n’est pas que les contrats doivent être jetés par la fenêtre mais que vous devriez collaborer plus souvent avec vos clients. L’approche Agile demande la collaboration continue avec le client et son implication dans toutes les phases du projet pour collecter ses retours et donc construire des produits de valeur.

4. L’adaptation au changement plus que le suivi d’un plan

Les méthodes traditionnelles considéraient le changement comme une dépense, il fallait donc l’éviter. L’intention était de développer des plans détaillés et élaborés. L’agilité nous invite à mettre en place un fonctionnement flexible capable d’absorber les changements et de redéfinir les objectifs et les priorités. Avec ce mode de fonctionnement, tout changement apporte une valeur ajoutée au lieu d’un obstacle à éviter.

Le manifeste du test

1. Tester au fil d’eau plus que tester à la fin

Traditionnellement, les gens considèrent les tests comme une phase qui se produit à la fin du développement. En revanche, en Agile, les tests sont une activité qui doit se produire parallèlement au développement .

2. Éviter les bugs plus que trouver les bugs

Il serait beaucoup plus productif de clarifier les spécifications avant de commencer à écrire une seule ligne de code, et de s’assurer que tout le monde, du client au développeur et au testeur, a exactement la même compréhension de la façon dont quelque chose doit fonctionner.

3. Tester la bonne compréhension plus que vérifier la fonctionnalité

En Agile, les testeurs doivent devenir des ambassadeurs du client; Ils doivent comprendre en profondeur qui sont leurs utilisateurs et ce qu’ils essaient de réaliser avec le produit. Les testeurs doivent être les représentants de ce client dans chaque décision de conception, en veillant à ce que la fonctionnalité réponde aux besoins réels des clients, pas seulement aux spécifications.

4. Construire le système plus que casser le système

Bien qu’il existe une croyance commune que les testeurs sont exclusivement engagés dans la destruction, ce n’est qu’à moitié vrai. Il ne faut pas oublier l’objectif principal de créer un produit de valeur et qui fonctionne bien. C’est pourquoi la reproduction des actions réelles d’un utilisateur est de la plus haute priorité.

5. La responsabilité de l’équipe sur la qualité plus que la responsabilité du testeur

Les testeurs ne peuvent pas améliorer la qualité, leur rôle est de déterminer le niveau de qualité et d’en informer les parties prenantes. Vous ne pouvez améliorer la qualité que par les efforts conjoints de toute l’équipe.

Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
Fidaa Berrjeb

Après ce premier billet qui, nous l’espérons, vous aura intéressés, Fidaa va essayer de s’orienter sur l’aspect Quality Assurance (QA) dans ses prochains billets car les sujets sont nombreux qui couvrent Agilité et QA.

Toutes ces choses

All the stuff

https://seths.blog/2021/12/all-the-stuff/ by Seth Godin

Les marchés vous persuadent souvent que vous n’en avez pas assez.

Vos communautés vous rappellent que si.


Il en est très souvent de même pour les fonctionnalités demandées par les parties prenantes dans vos projets !

A force d’empiler les fonctionnalités, on risque fort l’indigestion !

Jamais assez, ne rien perdre par rapport au produit précédent, bénéficier de toutes les fonctionnalités de tous les concurrents…

N’est-ce pas la beauté, la force de l’approche Agile que de se recentrer sur la valeur business de chaque fonctionnalité demandée pour les prioriser ?

Puis n’en réaliser qu’un relativement faible nombre des plus bénéfiques avec une équipe et un temps limité. Observer et apprendre du résultat. Puis, répéter l’exercice de priorisation jusqu’à ce que la valeur de la prochaine itération soit plus faible que celle que l’on pourrait tirer d’une initiative et/ou projet concurrents.

En bref, stop au gâchis !

Dans les transformations agiles, pensez de haut en bas et de bas en haut à la fois.

Quel est le meilleur endroit pour commencer une transformation agile dans une société ?

Think top-down and bottom-up for agile transformations

https://kbondale.wordpress.com/2020/10/18/think-top-down-and-bottom-up-for-agile-transformations/ par Kiron Bondale

Une question que l’on me pose régulièrement pendant mes formations est : « Quel est le meilleur endroit pour commencer une transformation agile dans une société ? ».

Si j’avais le choix, je préférerais utiliser la réponse échappatoire (mais correcte) “ça dépend”, mais sinon je réponds d’habitude que vous voudriez mener les deux approches simultanément, de haut en bas et de bas en haut.

Une approche pour des changements organisationnels majeurs est fréquemment de commencer par le haut avec la direction exécutive, créant une coalition d’engagement et de support vers une vision partagée de l’avenir.

Ceci est critique dans les transformations agiles pour certaines raisons
  • Les équipes de développement ne travaillent pas de manière isolée et gagner l’adhésion pour changer comment les choses sont faites sera nécessaire de la part de tous les secteurs de support dont les ressources humaines, les finances et les achats.
  • Il y aura le besoin de financer des investissements comme la formation, le coaching, l’outillage et potentiellement même la dotation en personnel sur de nouvelles positions.
  • Sans changement dans les pratiques de management de portefeuilles de projets existantes et les métriques d’exécution (par exemple passer d’un focus sur maximiser l’utilisation à maximiser la valeur), il sera difficile d’obtenir les pleins bénéfices de la transformation.
  • Pour changer des comportements établis de cadres intermédiaires vers une mentalité agile, l’équipe de direction a besoin de modéliser d’abord les comportements cibles désirables. Les managers vont devoir être formés pour y parvenir et ils doivent aussi consentir à se tenir mutuellement responsables de cette nouvelle façon de travailler.
  • Il doit y avoir une vision fédératrice pour la transformation ainsi qu’un plan sur la façon d’y arriver. L’équipe de direction doit être entièrement engagée dans la création de ces livrables clefs.

Mais il y aura aussi besoin d’avoir l’engagement au niveau de l’équipe de développement. Si les membres individuels de l’équipe sont à l’aise avec comment les choses fonctionnent mais n’ont aucun sens d’urgence sur le besoin du changement, leur appui sera superficiel.

Leur pleine adhésion est nécessaire
  • Développez les détails des nouvelles façons de travailler et revoyez et adaptez celles-ci au fil du temps.
  • Soyez confortable sur imaginer et conduire des expériences avec les échecs occasionnels de celles-ci.
  • N’hésitez pas à prendre de nouveaux rôles et responsabilités.
  • Soyez ouvert et fournissez aux parties prenantes le plus fort niveau de transparence sur leur travail et le workflow qu’elles ont utilisé jusque-là.
  • Collaborez avec les parties prenantes d’autres domaines fonctionnels avec lesquelles vous pourriez précédemment avoir seulement coopéré.
CSP est partenaire de DantotsuPM, Découvrez tous leurs ateliers

Ces résultats sont nécessaires et un avantage clef de prendre les 2 approches en même temps, de haut en bas et de bas en haut, consiste en ce que cela crée un “effet sandwich” coinçant ceux du middle management qui ne voudraient pas changer comment ils travaillent.

Sans cela, il est peu probable qu’une transformation agile réussira.

Voici comment le principe d’exploration de PRINCE2 Agile peut vous faire économiser de l’argent !

En tant que chef de projet, recevoir un nouveau mandat de projet me rappelle les premières coordonnées dans une course d’orientation.

https://www.axelos.com/news/blogs/august-2020/how-prince2-agile-exploration-can-save-you-money de Maximiliano Clavijo Punschke – Chef de projet, Neem Consulting Ltd

La course d’orientation est un sport d’aventure en plein air dans lequel vous recevez une carte et des coordonnées. L’objectif est de naviguer d’endroit en endroit en passant par un ensemble de points de contrôle et de décider du meilleur itinéraire pour terminer le parcours dans les plus brefs délais. La seule différence est que la course est dans le projet une entreprise multinationale avec une structure organisationnelle complexe. Avant de vous précipiter aux prochains points de passage (ou aux phases de votre projet), il sera important de rencontrer votre équipe pour discuter de ce qu’est la cible finale (le livrable du projet) et si le projet est utile et viable.

Mais comment faire cela dans un environnement Agile PRINCE2® ?

D’après mon expérience, j’ai trouvé un excellent soutien de la part d’une valeur clé de PRINCE2 Agile : l’exploration. Cela m’a aidé à définir ce qui constitue le produit minimum viable (MVP) de mon projet et à définir les exigences obligatoires dans la description du produit de mon projet. Habituellement, les techniques d’exploration telles que « l’expérience » ou « spike/spiking » sont utilisées soit lorsqu’il existe des incertitudes autour des théories, lorsque l’impact est lié à l’utilisation de nouvelles technologies ou lorsqu’il existe des préoccupations fonctionnelles du point de vue du consommateur. Lorsque vous utilisez des techniques d’exploration au début du processus de projet PRINCE2 Agile (en avant-projet), cela peut être source de grande valeur.

Partenaire de DantotsuPM

Maintenant, imaginez qu’en plus du mandat du projet, vous receviez également la documentation technique de bout en bout pour intégrer une plate-forme de commerce électronique d’avant-garde pour votre organisation. Faire un Sprint d’une journée (un  spike) et créer un livrable temporaire un tel prototype peut offrir les avantages suivants:

  • Vous réduisez les incertitudes d’un point de vue technique et client.
  • Vous aidez à identifier tous les domaines qui doivent être examinés pour remplir la description du livrable du projet et son analyse de rentabilité.
  • Vous identifiez et impliquez les bonnes parties prenantes, qui peuvent ensuite faire partie de l’équipe de projet.
  • Vous créez des boucles de retours rapides pour accélérer le processus de collecte des exigences.
  • Vous créez une opportunité de générer des apprentissages qui peuvent soutenir l’analyse de rentabilité.
  • Vous aidez à résoudre les « inconnus connus » et à révéler des informations sur des « inconnus inconnus ».

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

Dans PRINCE2 Agile, le travail à partir d’un spike peut être managé et contrôlé avec une approche de timeboxing telle que Scrum ou en utilisant un système basé sur les flux (par exemple Kanban). J’ai constaté qu’en raison du spike, j’étais mieux placé pour travailler avec l’équipe de développement sur les estimations du projet. Il est important d’être cohérent avec l’approche de management agile afin de s’assurer que les techniques d’estimation sont bien alignées.

Faire un ou des spikes au cours de la phase d’avant-projet a également fourni des informations sur les risques majeurs (dans mon cas, principalement les menaces) qui auraient un impact sur le projet s’ils se matérialisaient.

Toutes les données recueillies à partir de ce prototype ont contribué à éclairer l’élaboration de l’analyse de rentabilité. L’un des principes les plus pertinents de PRINCE2 Agile est de maintenir une justification business continue.

Le spike au cours de la phase d’avant-projet peut fournir suffisamment de données pour répondre à la question suivante : Le projet en vaut-il la peine et est-il viable ?

Si la réponse est « non », vous saurez alors que le spike vient de vous éviter un mauvais investissement. Si le projet fait partie d’un programme, il est fondamental de remonter ceci dès que possible; cela pourrait déclencher un examen de l’analyse de rentabilité du programme tout entier avec des conséquences majeures sur ses bénéfices et la réussite de la future organisation.

Si la réponse est « oui », utilisez les flux d’informations disponibles pour mettre en évidence les risques majeurs, l’impact associé et la probabilité lorsque vous demandez l’approbation de lancement du projet par la direction du programme.

Le Manager dans les Daily Scrum : Quelles sont les choses à ne pas faire en dehors d’éviter totalement sa présence.

Un des anti-modèles les plus courants aux Réunions Daily Scrum est la participation active des managers.

Back To Basics: Managers and Daily Scrum Meetings

https://tcagley.wordpress.com/2020/09/24/back-to-basics-managers-and-daily-scrum-meetings/ par Tom Cagley

Si vous n’allez pas plus loin dans la lecture de ce billet, je recommande aux managers de rester éloignés du Daily Scrum. Même s’il n’est pas interdit aux managers de venir au Daily Scrum ni que ce soit intrinsèquement mauvais en soi il y a toutes sortes de fréquents résultats négatifs.

Voici 4 des pires attitudes

1 – Mettre l’équipe sur le grill

Transformer le Daily Scrum en une réunion de statut où la déviation par rapport plan du leader est mise en évidence et même punie.

Ce comportement rend pour le moins difficile de produire une mentalité agile.

2 – Distribuer du Travail

Les leaders qui utilisent le Daily Scrum pour assigner du travail empêchent les équipes d’apprendre à s’auto-organiser et élimine l’objectif de planning d’équipe de la réunion. J’ai demandé à un manager pourquoi il distribuait le travail dans le Daily Scrum, sa réponse fut « je suis responsable de m’assurer que chacun est occupé ».

Distribuer du travail pendant cette rencontre signifie que le manager doit avoir une compréhension détaillée de toutes les histoires et tâches nécessaires pour faire quelque chose, les entraînant vers un micromanagement du travail. Le Daily Scrum est un événement dans l’équipe projet Agile dont l’objectif va à l’encontre de cette approche.

CSP est partenaire de DantotsuPM, Découvrez tous leurs ateliers

3 – Le « paraître »

La perception qu’a de vous votre manager (ou la personne renouvelant votre contrat) est importante pour votre carrière. C’est une tendance humaine de base que de vous assurer que vous paraissez bons aux yeux du patron, même parfois aux dépends de vos pairs. Ce comportement n’amène pas à partager les problèmes, demander de l’aide, ni à re-planifier.

4 – Désintérêt

J’ai récemment observé un manager qui venait chaque jour au Daily Scrum et passait tout son temps à faire des choses sur son téléphone. Quand s’adressait à lui, il semblait choqué que quelqu’un lui parle. Après le quatrième jour, j’ai pu coincer la personne pour une discussion. Sa formation Agile indiquait qu’il devait aller au Daily Scrum, mais il ne souhaitait pas être là. Il était passif-agressif. Il n’est plus revenu après cette rencontre et chacun s’est senti plus à l’aise. En tant que manager, si vous allez aller au Daily Scrum (ne le faites pas s’il vous plaît) écoutez et prêtez l’attention.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

En règle générale, les managers devraient trouver une raison d’être n’importe où plutôt qu’au Daily Scrum.  Comme avec toutes les règles, il y a des exceptions. Par exemple, le scénario de manager-joueur, où un membre de l’équipe est aussi le manager. J’ai entendu des scénarios où la présence d’un manager était utile, mais j’ai entendu ces histoires de managers pas de leurs équipes.

Et si vous rejoigniez le Lab Hybrid du PMI France ?

Une nouvelle initiative s’est mise en place au sein de la communauté des membres du PMI Chapitre France, le Lab Hybrid.

Allez découvrir les sommets du monde hybride avec Stéphane Derouin

Réunissant environ 25 membres, Stéphane Derouin a lancé cette nouvelle initiative à mi-parcours entre la gestion de projet dite traditionnelle et les concepts Agiles.

L’objectif de ce groupe de travail est de co-écrire un guide des bonnes pratiques hybrides, pragmatique et utilisable par le plus grand nombre .

Vous y retrouverez des aspects liés :

  • A la gouvernance
  • Au cadre méthodologique
  • A la dimension humaine.

Bien évidemment le projet lui-même sera géré en mode hybride avec une livraison du guide prévue pour le 31 mai 2022.

Ricardo Naciff, Président du PMI France

Le Business Owner est Ricardo Naciff, président du PMI France et Stéphane Derouin est le responsable du projet. Chaque sujet au sein des trois thématiques sera porté par une petite équipe qui fonctionnera en mode Agile / Scrum avec un Product Owner (Responsable du Product Backlog) et un Scrum Master.

Nous ne manquerons pas de partager avec vous l’avancement de ce projet au cours de l’année 2021/2022.

En savoir plus

CertYou est partenaire de DantotsuPM

La facilitation dans les projets Agile, comment ça fonctionne ?

Le manuel AgilePM® cite la facilitation comme une technique clé, mais comment devriez-vous utiliser la facilitation dans les projets agiles ?

Facilitation in Agile Projects

https://apmg-international.com/article/facilitation-agile-projects de  Tomasz Nedzi

Guide sur Amazon

Trois versions de suite du AgilePM® Handbook citent la facilitation comme une technique qui aide à construire l’équipe, à prendre des décisions et à identifier les risques. Cependant, la facilitation est à peine décrite dans le manuel et cet article en présente un résumé et explique comment elle peut être utilisée avec succès dans des projets.

Selon l’une des définitions : « la facilitation est toute action qui rend une tâche facile pour les autres ou une tâche qui est supportée par d’autres ». Le but de la facilitation est de veiller à ce que les réunions et les ateliers soient conçus et menés de manière efficace. Elle permet à l’équipe de prendre des décisions indépendantes, grâce à une personne indépendante, comme un facilitateur. Ce professionnel peut manager correctement les réunions, afin que les participants ne se « nuisent » pas entre eux, mais apprécient les différences d’opinion et en comprennent les avantages.

Qui est le facilitateur ou la facilitatrice ?

C’est une personne qualifiée pour sélectionner le « processus » approprié (formats, modèles, techniques et outils) à la « tâche » (objectif de la réunion).

Certains des modèles/techniques/outils sont :

  • Paraphraser avec un modèle de feedback,
  • Les quatre boîtes,
  • Résumer, Proposer, Produire – Summarise, Propose, Output (SPO)
  • Modèle Process Iceberg®,
  • Symptôme, Cause, Action (SCA),
  • Allégories,
  • Storytelling.

Ces dénominations semblent plutôt mystérieuses et compliquées et suggèrent que le rôle de facilitateur est difficile. C’est d’autant plus difficile que le facilitateur est censé manifester son impartialité même s’il est impliqué dans le travail ou s’il est émotionnellement dépendant des résultats.

De quoi le facilitateur ou la facilitatrice est-il responsable?

La facilitation met fortement l’accent sur la distinction entre la responsabilité du processus utilisé et la responsabilité de la tâche à réaliser. Comme dans le management de projet, un processus signifie effectuer certaines activités qui mènent à un résultat spécifique. Les normes de management de projet telles que PMBOK® Guide, Praxis Framework,  AgilePM®  définissent les processus nécessaires pour produire le livrable du projet, mais le livrable ou produit peut être différent pour chacun des projets.

Livre sur Amazon

Le manuel de facilitation (« Facilitation. Develop your expertise » par Tony Mann) ne définit pas le contenu de l’atelier (la « Tâche »), qui peut être différente à chaque réunion, mais il aide à identifier (le « Processus ») qui délivrera le résultat requis.  Le résultat requis du management de projet est de livrer le produit dans les contraintes du triangle du projet. Le résultat requis de l’atelier facilité devrait être, par exemple, les risques identifiés, les exigences hiérarchisées en un certain laps de temps. Comme dans le cas du management de projet, la facilitation devrait également inclure les parties prenantes, d’autant plus que l’atelier peut être mis en œuvre en utilisant différents formats.

Nous appelons un « Format » la façon dont les ressources sont utilisées pendant la réunion :

  • Groupe – signifie que les parties prenantes impliquées travailleront ensemble en groupes,
  • Tous – signifie que tout le monde travaillera seul,
  • Tout à un – cela amènera toutes les personnes à travailler ensemble avec un seul support, par exemple un tableau à feuilles mobiles,
  • Un pour tous – une personne communique avec les autres, par exemple quand ils ont l’expérience, les connaissances à partager.

    un pour tous, tous pour un

Deux parties prenantes clés sont mentionnées dans le manuel de facilitation

  1. Leader de tâche – personne responsable de la définition de l’objectif de la réunion, par exemple Manager de projet, Leader d’équipe,
  2. Facilitateur – responsable du processus de l’atelier.

Par conséquent, nous nous attendons à ce que le leader de tâche ait des connaissances spécialisées sur la tâche, et le facilitateur n’a donc pas besoin d’être expert en la matière. Une connaissance spécifique de la tâche pourrait même être un obstacle si le facilitateur voulait s’engager dans la création de la solution, perdant ainsi son impartialité.

Il est peu probable que nous nous attendions à ce que le manager de projet soit le facilitateur, mais nous pouvons nous attendre à ce qu’il assume le rôle de leader de tâche. AgilePM® Handbook suggère clairement que le facilitateur devrait être un rôle distinct et indépendant du manager de projet.

Un facilitateur efficace devrait…
  • Être orienté sur le changement,
  • être audacieux, courageux, prendre des risques,
  • avoir un focus général et être focalisé sur les idées,
  • être flexible,
  • être prompt à répondre et à agir,
  • être orienté processus,
  • être un catalyseur discret,
  • être  extraverti,
  • être capable de rester calme sous le stress,
  • avoir un faible niveau de tension,
  • avoir une large connaissance des affaires.

Estimation du temps et du coût de la facilitation

Le manager de projet doit trouver une personne adéquate pour remplir le rôle de facilitateur, mais il doit également être en mesure d’estimer le temps nécessaire pour mener les ateliers.

Cependant, il y a ici plusieurs risques car les tâches peuvent avoir différents niveaux d’incertitude.
  • Avec la certitude que la question à laquelle il faut répondre est claire et que la réponse sera facile à obtenir des participants à l’atelier, il est plus facile d’estimer le temps nécessaire. Cette durée estimée sera alors généralement suffisante pour atteindre les objectifs de la réunion.
  • Lorsqu’il s’agit de complexité, c’est-à-dire que la question est claire, mais que la réponse n’est pas encore connue, le temps estimé à l’origine peut être plus que doublé pendant l’atelier.
  • Et enfin, lorsque nous avons affaire à l’incertitude (la question/problème est inconnu et doit d’abord être compris pour trouver une réponse ou une solution), le temps réel de l’atelier lui-même peut être jusqu’à 4,5 fois plus long.

De plus, le rôle de facilitateur est de bien manager le « triangle d’or de la facilitation ». Comme dans le cas du « triangle de projet », où les « portée-délais-coûts » restent en équation les uns par rapport aux autres, dans le cas de la facilitation, nous avons un triangle interdépendant « tâche-temps-maturité du groupe ».

Cela signifie que le temps des ateliers dépend de la tâche (que nous connaissons dans le management de projet comme la portée) et de la maturité du groupe/processus, c’est-à-dire de la difficulté de mettre en œuvre une tâche donnée. Cependant, le niveau de difficulté ne peut être estimé que par un facilitateur expérimenté. Cela signifie que le manager de projet (comme dans le cas de l’estimation d’autres tâches du projet) doit utiliser l’aide d’un facilitateur expérimenté pour planifier des ateliers. Cela signifie aussi que la logistique des ateliers (emplacement, équipement) affectera le budget du projet.

QRP est partenaire de DantotsuPM

En résumé

Un facilitateur expérimenté (comme un manager de projet expérimenté) utilise un processus afin que d’autres personnes puissent atteindre les objectifs. Ce sont les compétences et l’expérience du facilitateur (comme dans le cas du manager de projet) qui déterminent l’efficacité avec laquelle il ou elle gère la sélection des outils appropriés et l’ajustement du processus aux exigences de la tâche. La facilitation (un peu comme le management de projet) est une activité professionnelle différente. La responsabilité du manager de projet est d’aller chercher et de motiver un professionnel suffisamment expérimenté pour obtenir des résultats d’atelier satisfaisants.

Il n’y a aucune magie dans SAFE® sauf peut-être pour le PI Planning ?

Regardons de plus près de la cérémonie du PI Planning et, se faisant, éclairons peut-être pourquoi il est considéré avec un tel respect.

Unravelling PI Planning

https://www.digite.com/blog/unravelling-pi-planning/ par Anshuman Singh

Il y a une citation présentant le contenu du PI Planning sur Scaled Agile Framework : “Il n’y a aucune magie dans SAFE® sauf peut-être pour le PI Planning”.

Regardons de plus près de la cérémonie du PI Planning et, se faisant, éclairons peut-être pourquoi il est considéré avec un tel respect.

La plupart des organisations qui mettent en œuvre SAFE® ne le mettent pas entièrement en œuvre. Mais s’il y a un dénominateur commun entre toutes ces mises en œuvre de SAFE®, c’est le PI Planning. Ainsi qu’est-ce que le PI Planning ? Et que signifie ‘PI’ dans PI Planning ?

Eh bien, PI signifie Programme Increment, un Incrément de Programme. Un Incrément de Programme entre dans une fenêtre de temps (timebox) de 8 à 12 semaines (le défaut étant 10 semaines comme recommandé par Scaled Agile Inc.). Cette timebox de 10 semaines encapsule 5 Sprints Agiles ou Itérations de 2 semaines. La 10ème semaine du PI se termine avec la Démonstration de PI où le travail construit pendant le PI est présenté aux parties prenantes. (Il est utile de noter ici, qu’un PI est un incrément d’un Programme entier. Un Programme est là où les équipes et autres ressources sont investies d’une mission de développement importante. Un Programme consiste donc en de multiples Incréments de Programme.

Comme le PI a 5 itérations avec des équipes multiples travaillant en cadence pour réaliser une vision commune, il est important pour ces équipes de se rassembler et planifier le cours des actions pour la durée entière du PI. La réunion aide aussi les équipes à comprendre quelles sont les dépendances entre elles et les risques à adresser. Cette réunion est appelée PI Planning. C’est une réunion complexe et détaillée d’une durée de 2 jours pendant la semaine 10 du PI.

Alors, qu’est-ce qui entre dans un PI Planning ?

La Vision du Programme et le Programme Backlog sont deux entrées principales et essentielles pour conduire une réunion de PI Planning. La Vision fournit le contexte à l’équipe entière sur pourquoi et comment le travail fait dans le PI aidera dans la construction de la Solution complète. Le Programme Backlog comprend des 10 premières fonctionnalités classées par priorité et accompagnées de descriptions courtes des bénéfices business que la fonctionnalité génèrerait.

Le Programme Backlog appartient au Product Manager qui est aussi responsable de s’assurer qu’on l’ordonne selon la priorité business en fonction de la réalité du marché et d’autres facteurs exogène. Les 10 premières fonctionnalités sont aussi accompagnées de Starter Stories (beaucoup d’histoires peuvent manquer, beaucoup ont besoin d’être décomposées ou sont des duplications dans les backlogs d’autres équipes). Ces Starter Stories permettent aux équipes de démarrer rapidement leur planification pour le PI.

Visitez le site SAFe

PI Planning

La réunion de PI Planning s’applique à l’équipe entière allouée au Agile Release Train et on s’attend à ce que chacun y participe. Si certains des membres d’équipe sont à d’autres emplacements géographiques, ils doivent participer à distance. La réunion de PI Planning est divisée en différentes sessions sur un créneau de 2 jours.

La réunion de PI Planning est organisé par le Release Train Engineer  (RTE, aussi appelé le Scrum Master du Agile Release Train). Le RTE présente la Vision et les 10 premières fonctionnalités à la session inaugurale du PI Planning. Après cela, toutes les équipes entrent dans leurs sessions respectives où elles évaluent leur propre vélocité pour au moins les 2 premières itérations sur les 5. Les équipes mûrissent les fonctionnalités et les Starter Stories et évaluent leur taille. À la fin du premier jour, les équipes se réunissent avec les Business Owners, des architectes système et d’autres parties prenantes pour obtenir des clarifications et mettre en avant leur compréhension.

Le deuxième jour, les équipes entrent de nouveau dans des sessions spécifiques et détaillent encore davantage leurs backlogs respectifs. Chaque équipe formule une liste d’objectifs appelés des Objectifs d’Équipe et les Business Owners donnent chacun des objectifs un score de Valeur Business. Le score de Valeur Business est un chiffre entre 1 à 10 (10 pour la Valeur la plus élevée côté business, 1 pour la plus basse). Plusieurs objectifs peuvent avoir le même score de Valeur Business.

Après cela, chaque équipe présente son plan au groupe assemblé en entier. Le plan met en évidence les risques identifiés, les dépendances prévues et les objectifs agréés avec leur Valeur Business. Une fois que chacune des équipes a achevé sa présentation, une liste agrégée d’objectifs d’équipe est présentée et une liste agrégée de risques de Programme est aussi compilée.

L’équipe discute chacun des risques et les adresse avec l’approche ROAM (Resolved, Owned, Accepted, Mitigated). Finalement, il y a un vote de confiance où chaque équipe donne son score (entre 1 et 5) de confiance d’atteindre les divers objectifs. Si une équipe donne un score de moins de 3, ses membres doivent exprimer leurs réserves qui sont discutées avec le groupe entier. Le problème pourrait ajouter à la liste de risques ou exiger un peu de re-planification ou être simplement informatif. Si nécessaire les équipes retravaillent leurs plans jusqu’à ce qu’un fort niveau de confiance puisse être atteint.

La magie de SAFe tient en grande partie à ce qui va sortir du PI Planning.

Productions du PI Planning

Les productions de la réunion PI Planning sont les suivantes

  • Une liste d’Objectifs d’Équipe avec la Valeur Business, où les objectifs sont les résumés business de ce que chaque équipe a l’intention de livrer dans le prochain PI.
  • Il y a aussi des Objectifs additionnels que chaque équipe peut avoir choisi au cas où elle serait capable d’achever son travail et qu’une certaine bande passante resterait.

Les objectifs d’équipe sont agrégés et raffinés pour former les Objectifs complet du PI avec sa Valeur Business. C’est réalisé par le RTE après que la réunion de PI Planning soit finie et pas pendant la réunion.

  • Nous gagnons une compréhension de la vitesse de chaque équipe au minimum pour l’Itération 1 et 2, avec des histoires d’utilisateur de taille identifiée pour ces itérations sur lesquelles les équipes travailleront.
  • Une production importante du PI Planning est le tableau de Dépendance de Programme qui dépeint les Fonctionnalités / Histoires, les Dépendances et les jalons marquants. Les architectes et des membres d’équipe UX jouent un rôle clef pour aider à identifier ces dépendances.
  • Le PI Planning donne aussi une liste de Risques identifiés et comment ils ont été adressés à travers le mécanisme ROAM.

Rôles Principaux dans le PI Planning

Les rôles clefs et leur fonction pendant le PI Planning sont mis en évidence ci-dessous.

  • Business Owner – fournit la Valeur Business et l’approbation des Objectifs de l’Équipe PI
  • Product Manager – fournit les 10 premières fonctionnalités priorisées du backlog
  • RTE – présente le processus de planification et les résultats attendus
  • Product Manager et ScrumMasters – supportent les sessions d’Équipe et la décomposition des histoires
  • Équipes Agiles – mûrissent les fonctionnalités des Histoires d’Utilisateur pendant les sessions d’Équipe, identifient les risques et donnent le crucial vote de confiance
  • Architecte Système / – aide à établir des dépendances inter-équipe et les risques
QRP est partenaire de DantotsuPM

Épilogue

Le PI Planning sert la fonction importante de rassembler l’équipe entière et d’aider ses membres à gagner une perspective unifiée sur le travail qu’ils vont accomplir.

Les équipes entendent directement des Business Owners, les leaders organisationnels, comment le PI en cours de planification aidera l’organisation à s’approcher des ses objectifs finaux et quel est l’avenir attendu de la solution en construction.

Sur une note plus banale, les équipes sont capables de mettre en évidence les interdépendances et comment elles prévoient de les adresser avec succès. Ayant formulé les objectifs du PI, les équipes développent un sentiment d’appropriation pour les livrer.

La réunion de PI Planning est organisée dans la 5ème itération du PI qui est l’Itération de l’Innovation et de la Planification et n’a ainsi pas à être planifiée sur un créneau de temps complémentaire. Elle répond au besoin de perspective que les équipes désirent souvent mais obtiennent rarement. Elle distribue la planification et le contrôle du travail aux équipes qui sont en fin de compte responsables de sa livraison.

Et c’est une bonne chose!

Anshuman Singh, Product Manager, SwiftEASe

Regardez comment SwiftEASe aide dans les réunions de PI Plannning et suit les  objectifs, risques et le statut d’achèvement de fonctionnalités du PI.

SAFe® et Scaled Agile Framework sont des marques déposées de Scaled Agile, Inc.