Catégorie : agile

Méthodes, retours d’expérience, bonnes pratiques

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

Le par mopertodans agile, outils et méthodesLaisser un commentaire

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.

Le par mopertodans agile, best practicesLaisser un commentaire

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 ?

Le par mopertodans agile, formations et certifications, outils et méthodesLaisser un commentaire

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 par mopertodans agile, outils et méthodesLaisser un commentaire

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 ?

Le par mopertodans agile, outils et méthodesLaisser un commentaire

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.

Choses à faire avant la réunion de planification du sprint

Le par mopertodans agile, experience sharingLaisser un commentaire

Découvrez ce que vous devriez faire avant même le début de votre réunion de planification de sprint afin de faire du prochain sprint un succès.

https://blog.gurock.com/sprint-planning/ par Nishi Grover Garg

Les équipes Scrum se réunissent pour décider des éléments de travail de leur prochain sprint lors de la réunion de planification du sprint. Mais est-ce le début de la conversation pour le sprint à venir, ou y a-t-il des choses à faire avant ?

Priorisez le Product Backlog, l’arriéré de produit

La première et la plus importante considération est d’avoir un product backlog vivant qui est à jour et hiérarchisé pour suivre l’évolution des besoins de l’entreprise. Le propriétaire de produit doit avoir un œil constant sur l’ajout, la suppression, la modification et la mise à jour d’éléments dans le product backlog. Lorsque le temps vient de planifier le sprint suivant, le chef de produit doit apporter à la table une liste des éléments de valeurs les plus élevées que l’équipe puisse choisir.

Détaillez les fonctionnalités

Étant donné que la plupart des exigences agiles sont courtes, soit sous la forme d’histoires utilisateur (User Stories) ou simplement de phrases listant les fonctionnalités nécessaires, elles nécessitent d’être détaillées pour pouvoir être implémentées. Le propriétaire de produit doit passer du temps à rechercher chacune des fonctionnalités et à essayer de présenter en termes simples le besoin réel que chacune exprime. Utilisez des listes à puces ou des phrases simples, pour expliquer la fonctionnalité en détail. Nous voyons cela se produire principalement pendant ou après la réunion de planification du sprint, mais si des exigences sont connues avant la réunion, le propriétaire de produit peut avoir une longueur d’avance.

Décidez d’une définition de done

Au cours d’une réunion de planification de sprint, l’équipe choisit généralement ce qu’elle fera et livrera à la fin de cette itération de sprint. Il est impératif que les membres de l’équipe connaissent et conviennent d’une définition de done pour chaque histoire utilisateur ainsi que chaque tâche de chacune. Qu’il s’agisse d’une tâche de développement, d’une tâche de conception ou d’exécution de test ou d’une tâche de revue de livrable, tout le monde doit s’accorder sur une compréhension commune de ce que signifie « done » afin d’assurer une livraison fluide et aucun conflit à la fin du sprint.

Soignez les user stories

Chaque histoire utilisateur qui est mise en avant pour la planification du sprint doit être soignée, développée et détaillée avec les connaissances et les commentaires de l’équipe entière.

Lorsque les testeurs, les développeurs et le propriétaire de produit s’assoient ensemble et discutent d’une nouvelle fonctionnalité, de nombreuses nouvelles questions peuvent survenir de la part de l’équipe. Les questions portent souvent sur l’intégration avec les fonctionnalités existantes, le comportement de la fonctionnalité dans des cas spécifiques ou la manière dont le comportement doit être adapté pour différents types d’utilisateurs. Les cas spéciaux font également partie des critères d’acceptation définis dans l’histoire utilisateur pour la rendre complète.

Quelles que soient les questions, il est préférable de les poser au plus tôt et d’y répondre avant de choisir l’histoire utilisateur. Fondamentalement, cela signifie qu’une conversation doit avoir lieu pour chaque user story, afin que l’équipe puisse se comprendre et décider des critères d’acceptations définis et agréés par tous.

Ces sessions de « toilettage d’histoires » doivent avoir lieu avant la réunion de planification du sprint afin que pendant la planification, l’équipe sache exactement ce qui est requis de cette fonctionnalité et puisse donner de meilleures estimations et story points en fonction de sa complexité.

Commencez par le design

De nombreuses histoires utilisateur ont besoin de storyboards visuels ou de maquettes de l’interface utilisateur, et dans ces situations, les concepteurs d’expérience utilisateur ou UX designers peuvent avoir besoin d’être impliqués. Ces histoires doivent être sélectionnées un sprint à l’avance et allouées d’abord aux UX designers, afin qu’ils puissent construire les maquettes ou les images d’écran prêtes avant que la fonctionnalité ne soit sélectionnée pour le développement dans le sprint suivant. Cette approche facilite la communication et évite les retards pendant le développement.

De même, certaines histoires utilisateur peuvent nécessiter une recherche sur une nouvelle approche, une nouvelle technologie ou un nouvel outil avant de commencer, ou il peut être nécessaire de créer un design d’architecture complet pour une certaine partie avant de se lancer dans sa mise en œuvre. Dans de tels cas, la tâche de conception ou de R&D doit être créée et démarrée dans un sprint précédent, puis allouée au développeur ou à l’architecte principal au sein de l’équipe pour préparer les designs et résultats de recherche pertinents. Ils peuvent ensuite partager ces informations avec l’équipe afin que tout le monde soit prêt à commencer à travailler sur la mise en œuvre dans le sprint suivant.

Un propriétaire de produit doit être constamment à l’affût des histoires utilisateur qui peuvent nécessiter un travail de conception ou de recherche avant de les commencer, et avoir ces user stories distribuées aux personnes concernées avant le sprint pour s’assurer que la mise en œuvre sera fluide et que la livraison pourra avoir lieu à temps.

Nishi est une formatrice en entreprise, une passionnée agile et une testeuse dans l’âme ! Avec plus de 11 ans d’expérience dans l’industrie, elle travaille actuellement chez Sahi  Pro en tant qu’évangéliste et responsable des formations. Elle est passionnée par la formation, l’organisation d’événements et de rencontres pour une communauté de test, et a été conférencière lors de nombreux événements et conférences de test.

Consultez  son blog où elle écrit sur les derniers sujets dans les domaines Agile et Testing.

CertYou est partenaire de DantotsuPM

Comment un ou une manager de projet s’adapte-t-il ou elle à Agile ?

Le par mopertodans agile, experience sharingLaisser un commentaire

Les chefs de projet expérimentés peuvent manager des projets agiles, si ils et elles font les adaptations nécessaires !

How a Project Manager Adjusts to Agile

http://www.bonniebiafore.com/how-a-project-manager-adjusts-to-agile/ de Bonnie Biafore

Voici comment vous devez vous adapter lors du management de projets agiles…

Abandonnez le Gantt Chart.

Agile est une approche de production fluide basée sur l’apprentissage progressif et l’adaptation aux changements des priorités du business. Par conséquent, les tâches planifiées à l’avance dans un diagramme de Gantt ne sont pas pertinentes. Au lieu de cela, vous managez un ensemble fluide d’activités de conception, de construction et de test en mesurant la production de livrables pour le client.

Revoyez votre position sur le management des modifications.

En agile, le changement est la norme, pas l’exception. Les managers de projet doivent être à l’aise avec le fait de revoir continuellement la portée et les priorités pour répondre aux besoins des clients. La gestion du changement n’est pas un processus de contrôle séparé et distinct dans agile; elle est inhérente à l’approche agile de création de valeur pour les clients.

Utilisez un format différent de rapport d’avancement.

Agile met l’accent sur la vitesse : la vitesse à laquelle les fonctionnalités sont produites et la productivité de chaque sprint. Vos rapports d’avancement doivent inclure ces éléments ainsi que les commentaires des utilisateurs finaux qui utilisent les livrables produits par l’équipe agile.

Repensez les « contrôles de projet ».

éliminer tous les obstacles
Le focus est sur l’élimination des obstacles qui empêchent l’équipe d’avancer.

Les manager de projet doivent diriger leurs efforts sur l’élimination des obstacles qui entravent l’équipe agile. La rétention de ressources et l’engagement du personnel de l’équipe et des clients sont primordiaux. Un leader agile doit s’assurer que les capacités de l’équipe sont pleinement utilisées, au lieu de gérer un ensemble de processus de contrôle comme tout chef de projet traditionnel.

Profitez des différences !

L’objectif d’Agile est de créer de manière collaborative le contenu le plus utile au client, même lorsque le client ne sait pas décrire ce dont il a besoin dans le détail !

L’avantage et le plaisir de l’agilité est que vous pouvez profiter du processus de découverte et fournir des capacités à court terme !

Bien plus qu’un outil de gestion de projet
Découvrir l’ERP de gestion de projet

PRINCE2 Agile et Kanban : Rendre les tâches du projet plus visibles !

Le par mopertodans agile, outils et méthodesLaisser un commentaire

L’utilisation de Kanban dans les projets est un moyen simple et direct d’aider les équipes à augmenter leur efficacité de travail en visualisant la charge de travail.

https://www.axelos.com/news/blogs/july-2020/prince2-agile-kanban-making-project-tasks-visible par Andrea Vecchi

Parmi les conseils disponibles dans PRINCE2 Agile®, Kanban un outil qui devrait être dans la boîte à outils de chaque chef de projet, en particulier dans les environnements moins complexes.

Kanban, conçu à l’origine pour améliorer l’efficacité dans la fabrication, est maintenant davantage utilisé pour visualiser les tâches d’un projet, affichées sur un tableau avec des notes autocollantes. De cette façon, il aide à rendre la planification plus facile et accessible à tous.

Cela est particulièrement vrai pour les personnes qui ne sont pas des managers de projet professionnels et qui ont du mal à utiliser un échéancier comme outil quotidien de gestion de projet. Kanban rend la planification si immédiate que les gens l’utilisent réellement !

Dans mon rôle de manager de PMO, je conseille aux chefs de projet professionnels d’utiliser Kanban comme un moyen de visualiser le plan de projet et, dans la mesure du possible, de basculer entre cela et leur vue de la planification. La vue Kanban se concentre sur ce que les gens font réellement, facilite la compréhension de la charge de travail de chacun et aide à hiérarchiser les tâches.

L’utilisation de la vue Kanban avec les nombreux petits projets moins complexes de notre entreprise nous aide à manager par exception selon le principe de PRINCE2. C’est parce que cette vue montre vraiment ce qui se passe avec une tâche et met en évidence quand il est nécessaire d’escalader au comité de projet. Cela aide également le comité à appréhender le planning, car ses membres ne participent pas au projet au jour le jour.

S’habituer au Kanban

Parfois, c’est le nom « Kanban » qui est un obstacle pour les gens. Cependant, une fois qu’ils comprennent le concept et commencent à l’utiliser, ils voient à quel point il est utile, puis Kanban devient une partie du langage et des méthodes de travail.

Par exemple, je travaillais récemment avec des membres de l’équipe dans le cadre d’opérations dans un autre pays.

Nous avions besoin d’un petit projet pilote, mais, pour quelque raison, cela n’a tout simplement pas eu lieu. Il n’y avait tout simplement pas de sentiment d’urgence dans l’équipe pour cela.

Nous avons donc créé une vue Kanban sur un tableau blanc au bureau avec des notes autocollantes et cela a fait une énorme différence. Le planning des tâches est devenu réel et le projet a pris de l’ampleur, les membres de l’équipe ont pu se suivre les uns les autres pour savoir si les tâches étaient terminées ou non et cela a augmenté l’appropriation. En effet, le tableau Kanban a rendu les tâches du projet visibles, physiques, présentes et compréhensibles et a rendu les gens plus responsables.

PRINCE2 Agile et Kanban

Livre sur Amazon

Pourquoi est-ce que je pense qu’il est important d’avoir une connaissance de Kanban et d’autres techniques Lean/agiles avec PRINCE2 Agile ?

Il est important pour les chefs de projet d’utiliser ces méthodes car les outils se rapportent aux contrôles classiques de gestion de projet. Ils aident les équipes à accroître la communication et rassemblent les gens. Les équipes extrêmement efficaces sont celles qui communiquent bien.

Livre sur Amazon

Les managers de projet ont parfois du mal à communiquer avec toute l’équipe et, au lieu de cela, ont recours au contrôle et cherchent à cocher toutes les cases du management de projet. Kanban les aide à être de meilleurs communicateurs.

En fin de compte, il s’agit pour les gens de s’organiser et d’organiser leurs activités plus efficacement afin de faire avancer les tâches en faisant les choses critiques plutôt que d’essayer de tout faire en même temps.

CertYou est partenaire de DantotsuPM

 

2021 Gartner Market Guide for Enterprise Agile Frameworks

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Obtenez votre exemplaire gratuit dès aujourd’hui !

Le Project Management Institute a été reconnu comme fournisseur représentatif dans le Gartner Market Guide de 2021.

Obtenez votre exemplaire du rapport Gartner Market Guide for Enterprise Agile Frameworks 2021 pour en savoir plus sur le marché agile.

© 2021 Gartner, Inc. and/or its affiliates.

Vous pouvez utiliser ce Guide pour mieux comprendre quel est le statut des approches Agiles et identifier qui peut le mieux vous aider à vous former.

Lesquelles de ces approches Agiles s’harmoniseront le mieux avec vos plans futurs et votre situation actuelle ?
CertYou est partenaire de DantotsuPM

Tableau Kanban pour tâches et projets avec Christian Hohmann

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Une mini vidéo de 3 minutes très éducative sur l’utilisation de Kanban dans les projets et pour manager une liste de tâches à réaliser.

Un tableau Kanban est un outil de management pour visualiser et gérer des tâches, leur avancement, la charge de travail, focaliser les efforts et plus généralement manager une équipe en mode projet.

Basiquement un tableau Kanban est fait de colonnes représentant le processus (le workflow) et dans lesquelles on déplace des cartes au fur et à mesure de l’avancement du travail dans le processus.

QRP est partenaire de DantotsuPM

Le Manifeste Agile en chanson

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Une parodie originale avec cette reprise du classique “Bohemian Rhapsody” de Freddy Mercury et Queen, entièrement réécrit à partir de zéro en studio avec les mots du guide Agile Product Management.

Rien de sérieux et quel beau travail d’équipe Agile !

CertYou est partenaire de DantotsuPM

le Centre of Excellence in PM² publie le PM²-Agile Guide (disponible gratuitement en Anglais)

Le par mopertodans agile, outils et méthodes, pointeurs utilesLaisser un commentaire

In the context of the PM2 solution, the Centre of Excellence in PM² has released the first-ever publicly available PM²-Agile Guide.

The new guide incorporates extensive feedback, making its approach highly relevant not only to the European Institutions but also to the external community.

Given the increasing adoption of Agile methods across organisations worldwide, this guide aims to support teams in becoming even more effective when delivering high-quality solutions, manage changing priorities and ultimately lead to an increase in productivity and project transparency.

Developed as an extension of the well-established PM² Project Management Methodology

Téléchargez ce guide

This guide has been created for:

  • Existing Agile practitioners in search of a framework to support them in the integration of Agile practices into their existing corporate structures.
  • Organisations already using PM² who are looking to apply Agile values and principles into their ways of working.
  • Anyone interested in adopting Agile practices into their work.

Even though PM²-Agile primarily addresses the needs of software development projects, most of the practices and tools and techniques included in this guide are applicable to non-IT projects, and this is reflected in the PM²-Agile Mindsets.

Key Elements 

  • A common vocabulary to facilitate communication between project teams and stakeholders.
  • The PM²-Agile model.
  • The PM²Agile lifecycle.
  • The basics of Agile practices.
  • The integration of Lean UX and Lean StartUp Model concepts and their impact on the PM²-Agile lifecycle.
  • An easy-to-use requirements model to support PM²-Agile.
  • A high-level overview of recommended Tools & Techniques is included and the detailed version of these will be published in Q4 2021.

PM²-Agile both extends and enhances the PM² Methodology with Agile principles and practices and provides harmonisation between these practices and corporate governance, programme management, operations, enterprise architecture and interoperability.

Download the guide today and do not hesitate to contact the CoEPM² team should you have any questions, comments or feedback.

Lab Hybrid au PMI France à la rentrée: En quête de l’avenir de la gestion de projets !

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Aujourd’hui la transformation des entreprises est le défi majeur qu’il faut relever, c’est aussi une nouvelle donne pour toutes les organisations.

Pour répondre à cette situation qui bouleverse notre monde des projets, nous sommes convaincus que l’hybridation, en tant que modèle de convergence des modes projet, est une solution majeure. Il faut dépasser les limites des approches existantes : Cycle en V, Agile, Agile à l’échelle…

À compter de septembre prochain, le PMI France propose à ses membres de rejoindre le Lab Hybrid du PMI France pour définir ensemble un cadre de travail référent sur cette thématique, en associant subtilement prédictif et itératif, en analysant les forces et faiblesses intrinsèques de chacune des méthodes et leur complémentarité.

Pour cela, PMI France va organiser des « Master Class » et des ateliers de travail sur l’hybridation, avec pour objectif final la création d’une micro-certification qui sera proposée au niveau du PMI Global.

L’hybridation est désormais ancrée dans le monde réel des projets, tant au niveau du portefeuille, des méthodes que des compétences. Enfin PMI® s’est engagé résolument dans cette voie, depuis l’acquisition de Disciplined Agile, le PMBOK Guide V6 et désormais avec la sortie du PMBOK Guide V7.

Il s’agit donc de fédérer les énergies et les compétences au sein du PMI France, afin de caractériser et définir ensemble cette nouvelle approche.

Faire avancer notre passion, c’est faire avancer le monde de projets !

Rejoignez une initiative innovante ! Rejoignez-nous ! Contactez Stéphane Derouin (sderouin@d2x-expertise.com).

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

Découvrez ce billet de QRP International: Waterfall vs Agile : Définition, concepts, différences

Dans un monde où les modes de travail évoluent constamment, les méthodologies de gestion de projet des organisations doivent également être révolutionnées.

La gestion de projet est devenue l’un des piliers les plus importants au sein de toute entreprise car elle a été reconnue comme l’un des facteurs fondamentaux de son bon fonctionnement.

Les entreprises recherchent des technologies, des systèmes et des processus qui les aident à personnaliser et à optimiser la gestion de projet.

Les clients connaissent une croissance exponentielle et, d’une manière ou d’une autre, les entreprises doivent être capables de s’adapter.

Les méthodes Agiles sont nées pour apporter cette flexibilité manquante, dans le monde de la gestion de projet, en se détachant complètement des méthodes traditionnelles, également appelées waterfall, en cascade ou cycle en V.

Quels sont les avantages et les inconvénients des méthodes agiles et traditionnelles ?

QRP est partenaire de DantotsuPM

 

La magie des Sprints de 1 jour !

Le par mopertodans agile, experience sharingLaisser un commentaire

Quelle devrait être la durée de vos sprints ? Généralement, 1 ou 2 semaines, avec une préférence vers le sprint plus court.

Mais ce n’est pas le sujet du jour. Je veux vous parler de la magie des sprints de 1 jour.

The Magic of 1-Day Sprints https://agileforall.com/the-magic-of-1-day-sprints/ par Richard Lawrence

J’ai remarqué que l’efficacité d’une équipe n’est pas fonction de combien de temps ses membres ont travaillé ensemble de façon agile. C’est plutôt fonction de combien de cycles ils ont réalisé ensemble. Combien de fois ils se sont regroupés, ont pris des engagements, ont réfléchi à comment les tenir et ensuite regardé rétrospectivement et adapté leur pratique. Autrement dit, pour une équipe Scrum, combien de sprints ils ont fait ensemble. En général, plus de sprints, plus d’enseignements.

Cela crée une opportunité unique que certains de mes clients veulent exploiter. Quand une équipe commence ou se regroupe, particulièrement après l’un de nos ateliers « Agile for Teams », il y a la nouvelle prise de conscience de soi-même, de l’enthousiasme et des idées à essayer. Pendant les deux semaines suivantes, vous pouvez les canaliser en un premier sprint fort… ou vous pouvez saisir l’occasion d’en faire dix.

Dix sprints de 1 jour vous permettent d’achever 10 cycles de travail et d’apprentissage ensemble, 10 fois plus rapidement qu’une équipe typique. Et cela vous force à identifier les compétences et pratiques critiques comme trouver de petites poches de valeur et collaborer ensemble sur quelque chose au lieu de juste de remettre son travail de l’un à l’autre en séquence, ignorant facilement les compétences et pratiques dans un sprint de 2 semaines.

Vous dépenserez plus de temps dans les cérémonies de sprint. Aussi, ne devriez-vous probablement pas les adopter pour toujours. Mais si vous ressemblez à mes clients, vous serez étonnés de constater combien vous aurez réalisé.

CertYou est partenaire de DantotsuPM

Alors, comment vous y prendre en pratique ?

Voici une journée 9h00-17h00 typique
  • 9:00-9:30 — Planifier la journée. Trouvez un, peut-être deux, incréments de valeur que vous pouvez achever ensemble aujourd’hui.
  • 9:30-12:00 — Réalisez des choses
  • 12:00-13:00 —Pause déjeuner
  • 13:00-13:15 — le Daily Scrum pour se coordonner sur les progrès du matin et prévoir l’après-midi
  • 13:15-16:30 — Réalisez plus de choses finies (en incluant le mûrissement d’items du backlog pour rendre la planification du lendemain plus facile)
  • 16:30-17:00 — Revoyez ce que vous avez fait et faites une rétrospective rapide de comment vous pourriez travailler différemment demain
  • 17:00 — Rentrez à la maison

Vous ne parvenez pas à avoir 8 heures en commun en raison d’autres engagements extra-professionnels d’autres membres d’équipe ?

Ne vous inquiétez pas, vous pouvez tout de même faire des sprints quotidiens. Le changement clé est de mettre la revue, retro et planification en séquence le matin ou l’après-midi quand vous êtes tous là. Puis, le temps à une extrémité ou l’autre de la journée de travail devient la partie sprint. 2vitez juste de travailler des heures supplémentaires car vous voulez parvenir à une réelle compréhension de ce que votre équipe peut accomplir en un jour de focus.

3 astuces pour ce travail

#1. Mettez-vous d’accord au départ que ce sera une expérience de deux semaines et non pas votre nouveau normal.

Travailler de cette façon est un changement intense pour la plupart des équipes. Savoir de ce sera limité dans le temps donne l’espace psychologique nécessaire pour vraiment essayer.

#2. Planifiez des choses plus petites que vous ne le pensez.

En réalité finir quelque chose de significatif en un seul jour est une partie clef de cette expérience. Il vaut mieux finir quelque chose de trop petit et terminer tôt que toujours quitter sur une chose partiellement faite. Et les compétences de découpage que vous développez seront de valeur à votre équipe sur le long terme.

#3. Bien que ce soit une expérience sur comment vous travaillez, faites attention que sur quoi vous travaillez est bien réel.

Vous en avez besoin que le quoi soit représentatif de votre travail normal pour en transférer facilement les enseignements. (Si, pour une certaine raison, vous ne pouvez pas le faire avec votre travail réel, le faire en style hackathon avec une innovation ou un projet caritatif peut aussi vous apprendre quelque chose. Ce mieux que rien, mais ce ne sera pas aussi instructif que 10 sprints d’1 jour de travail réel.)

Testez-le et donnez vos retours dans les commentaires !

Si vous préparez une certification #Scrum, attention à 5 différences introduites dans le guide en 2020 !

Le par mopertodans agile, formations et certifications2 commentaires

« Il m’a été donné de constater que certains organismes de certifications Framework Agile Scrum n’ont pas mis à jour certaines questions de certifications par rapport au guide Scrum 2020. Il appartient donc aux candidats de répondre en tenant compte du contexte de la question. » Zidane Zait

Zidane Zait

Zidane Zait, coach Agile et formateur Scrum, enseigne aux équipes l’agilité, l’Agile Framework Scrum et Agile MS Project. Son objectif est de faciliter le développement d’un esprit agile, la réalisation de solutions de valeur, la collaboration, l’auto-gestion des équipes, l’amélioration continue ainsi que l’engagement, la passion et l’enthousiasme envers ces approches.

5 changements entre le guide Scrum 2017 et le guide Scrum 2020 qui méritent d’être rappelés

  1. Guide téléchargeable gratuitement

    Dans le guide Scrum 2020, on trouve le rôle de « développeurs » alors que dans les guides précédents on utilise le rôle « d’équipe de développement »

  2. Introduction de l’Objectif de Produit dans le Guide Scrum 2020 pour permettre à la Scrum Team de se focaliser sur un objectif plus important.
  3. Les guides Scrum 2017 et précédents, utilisent le terme de autoorganisée, alors que le guide Scrum 2020 utilise le terme de Scrum Team autogérée.
  4. En plus des thèmes « Quoi » et « Comment » de la Sprint Planning, le Guide Scrum 2020 met l’accent sur un troisième thème « Pourquoi », faisant référence à l’Objectif de Sprint.
  5. Simplification globale du langage utilisé dans le guide Scrum 2020 pour atteindre un public plus large, gérant des projets hors du domaine informatique.
     

Pour rappel, relisez ce billet sur « Le guide Scrum 2020 : De nombreux articles et commentaires d’experts francophones »

CertYou est partenaire de DantotsuPM

Un peu de Scrum en musique pour terminer ce billet.

Zidane Zait ajoute ces autres changements à prendre en compte

Changement, évolution et améliorations apportées au guide SCRUM 2020:

En plus, des 5 changements et améliorations repris dans cet article, on peut les compléter par ce qui suit :

• Le guide 2020 définit le mot produit, comme un produit physique, un service, ou quelque chose de plus abstrait.

• Le terme « développeur », est un terme générique, et ne concerne pas uniquement le domaine informatique, on peut le remplacer par « réalisateur » en dehors du développement logiciel.

• Suppression des trois questions de la mêlée quotidienne et laisser la liberté aux développeurs d’inspecter la progression vers l’Objectif de Sprint. Les questions supprimées sont :
1. Qu’est-ce que j’ai fait hier ?
2. Qu’est-ce que je vais faire aujourd’hui ?
3. Y a-t-il des problèmes rencontrés ?

• La version 2020 ne parle plus de vision de produit, mais plutôt d’objectif de produit.

• Le Product Owner est redevable de définir et communiquer explicitement l’objectif du produit.

• Les développeurs sont redevables envers la qualité du produit en adhérant à la définition de terminé

• Le Scrum Master est redevable pour être le facilitateur de l’équipe et garantir son efficacité.

• Plusieurs incréments peuvent être créés pendant un sprint au lieu d’un seul dans les versions précédentes.

Le PMI Luxembourg a mis en ligne les wébinaires de l’ « Agile Week » !

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Avez-vous manqué l’événement remarquable : #agileweek ?

PMI Luxembourg a ajouté une playlist #agileweek à sa chaine youtube pour votre plus grand plaisir.

Vous pouvez rattraper votre retard ou revoir ces wébinaires et en découvrir d’autres du PMI Luxembourg.

Trop de règles rendent l’agilité impossible

Le par mopertodans agile, best practicesLaisser un commentaire

Combien de règles devez-vous suivre ?

Too many rules makes agility impossible

https://hennyportman.wordpress.com/2020/04/01/too-many-rules-makes-agility-impossible/ par Henny Portman

Un des principes du Manifeste Agile est “la Simplicité — l’art de maximiser le travail non fait — est essentielle”. Les études du Standish Group présentées dans l’un de leurs Chaos Report montrent que 60 % des fonctionnalités développées ne sont pas ou rarement utilisés. Si vous livrez seulement les bonnes, votre client obtiendra le produit beaucoup plus rapidement et à bien meilleur marché.

Considérer de manière critique les fonctionnalités du produit que vous développez est une façon de prendre en compte ce principe. Vous pourriez appliquer ce même principe au processus que vous utilisez pour développer votre produit. Combien de règles devez-vous suivre ?

Avez-vous jamais joué au jeu de Go ?

Le Go est un jeu de société de stratégie vieux de 2500 ans pour deux joueurs, dans lequel le but est d’entourer plus de territoire que l’adversaire. Malgré ses règles relativement simples, Go est déjà très complexe. Ou pensez au « jeu de la vie » de Conway sur l’automatisation cellulaire. Juste quelques règles très simples et des résultats stupéfiants. Ajouter davantage de règles aboutira au chaos.

CSP est partenaire de DantotsuPM

J’ai lu une histoire à propos des garderies d’enfants en Israël.

Ils faisaient face au problème e que certains parents venaient chercher leur enfant trop tard. Comme solution, ils ont mis en œuvre une nouvelle règle : Si vous venez chercher votre enfant en retard, vous devez payer une amende. Suite à cette règle même encore plus de parents sont venus récupérer leur enfant en retard. Ce qui était un compromis moral (je ne peux pas y aller trop tard) est maintenant devenu une transaction financière : je paie ma dette. Les règles ne sont pas nécessairement sacrées, les principes le sont.

Si vous regardez certaines structures agiles ou façons de travailler, vous pouvez vous demander si les concepteurs vous forcent à adopter une règle ou à la transgresser. Beaucoup sont pensées pour vous aider à construire des équipes d’équipes qui développent un produit ou un service, mais ici aussi, si vous pouvez réussir à ‘simplifier’ votre architecture vers des micro services vous n’aurez pas besoin de ces structures pour « monter en échelle/volume ».

Si vous comparez le nombre de règles de Scrum avec celles de SAFe, vous pourriez vous demander si vous réussissez sortir des agile release trains grâce aux règles SAFe ou malgré elles ?

Structure agile ou façon de travailler Règles
Manifeste agile 4 valeurs, 12 principes
Scrum 3 rôles, 5 cérémonies, 3 artefacts, 5 valeurs
Nexus 6 rôles, 5 cérémonies (équipe), 6 événements (Nexus), 7 artefacts, 5 valeurs
LeSS 5 rôles, 5 cérémonies (équipe), 3 événements (équipe d’équipes), 4 artefacts, 28 règles (LeSS), 12 règles (LeSS énorme)
AgilePM 13 rôles, 6 processus, 15 produits, 8 principes
PRINCE2 Agile 9 rôles, 7 processus, 7 thèmes, 7 principes, 5 comportements, 26 produits
Disciplined Agile Delivery 11 rôles, 3 phases, 6 cycles de livraison, 7 principes
SAFe 12 rôles, 6 cérémonies (équipe), 7 événements (programme), 2 cérémonies (grandes solutions), 7 artefacts, 4 valeurs, 10 principes

CertYou est partenaire de DantotsuPM

Si vous voulez fonder un laboratoire d’innovation ou de croissance, assurez-vous de rester à distance de la bureaucratie. Pour réduire des obstacles, exemptez le laboratoire des règles d’entreprise, des procédures, des manuels, des directives, des principes et des formats. Les approches innovantes peuvent faire sans !

Jim Johnson, rêveur et président du Standish Groupe a partagé dans un interview pour un magazine de Managers de Projet des Pays-Bas : “L’analyse des données de projet a apporté des standards, des approches et des structures, bien que j’hésite en réalité sur les standards, parce qu’ils limitent la croissance. Toutes choses bien considérées, le réflexe de construire des structures accroit les chances d’échec d’un projet technologique. Des structures sous forme d’outils de gestion compliqués, trop de règles de gouvernance, des exigences professionnelles trop étroitement définies… Des structures construites avec les meilleures intentions rendent les projets plus lents, plus chers et plus consommateurs de temps. Des structures dans lesquelles personne n’ose prendre la moindre décision.”

Si vous recherchez l’agilité, pensez à une citation de Pablo Picasso “Apprend les règles comme un professionnel afin de pouvoir les briser comme un artiste”.

Ou avec mes propres mots : Utilisez le bon sens en appliquant des approches agiles ou façons de travailler et démontrez une mentalité agile en comprenant juste la logique plutôt qu’en suivant des règles.

 

Comment travailler dans des environnements agiles pour les managers de projet ? 4 domaines d’attention.

Le par mopertodans agile2 commentaires

Que les managers de projet devraient-elles et ils garder en permanence à l’esprit dans les projets qui utilisent une approche agile ?

Four vital ways of working for project managers in agile environments

https://www.axelos.com/news/blogs/april-2020/four-ways-of-working-for-project-managers-in-agile par Allan Thomson – PPM Ambassadeur de Produit

Une checklist dans PRINCE2 Agile® best practice guidance décrit les points majeurs dont il faut avoir conscience.

Partenaire de DantotsuPM

#1 – Collaboration et auto-organisation

Un projet impliquant des méthodes agiles doit être basé sur une collaboration efficace avec une équipe auto-organisée qui résout les problèmes ensemble.

Un manager de projet devrait avoir confiance en l’équipe pour produire sans micro-management. PRINCE2 Agile souligne le besoin de permettre aux gens d’avancer pour produire les bonnes solutions exigées par le projet.

Et cela signifie que le comité de projet doit être clair sur ce que veut dire avoir d’une équipe « autonome » et être content que l’équipe projet fasse des changements si nécessaire. Si un élément de changement est majeur, PRINCE2 recommande de manager par exception (quand une situation dévie au-delà de ce que le comité de projet peut accepter).

#2 – Transparence, communication et exploration 

Un manager de projet doit communiquer la vision du produit clairement et l’équipe doit croire en la vision pour contribuer et créer un changement de valeur.

Cela peut impliquer le fait de donner la priorité aux exigences de produit majeures en se basant sur une méthode comme  MoSCoW (must have, should have, could have, won’t have for now). Puis, communiquer le résultat aux parties prenantes sur ce qu’elles obtiendront, devraient obtenir et n’auront pas.

Cette transparence avec les parties prenantes sur ce que sera le produit viable minimal les rassure sur le fait d’obtenir rapidement de la valeur pour leur investissement.

#3 – Environnement

Si Agile est un nouveau concept dans une organisation, PRINCE2 Agile introduit un « Agilomètre« . Le but de l’Agilometer est de fournir un guide vers agile qui créera un niveau de contrôle et de prévisibilité sans devenir excessivement normatif. Cela inclut l’évaluation de l’environnement et son niveau d’acceptation de méthodes et des comportements agiles.

Et, dans cet environnement, le manager de projet doit comprendre et adopter le rôle de servant leader. Il aide l’équipe à déplacer ou éliminer les points bloquants l’avancée du projet. Pour cela, l’engagement des parties prenantes est crucial.

Si l’équipe projet est novice avec les manières de travailler dites « agiles », introduisez-les à Scrum la méthode la plus utilisée. Puis, soyez clair avec les parties prenantes sur ce processus de développement et les éléments de langage utilisés. Soyez également transparent sur ce qu’ils auront et n’auront pas. Par exemple, montrez-leur la partie du produit qui est prête, mais ne les exposez pas à ce qui n’est pas encore prêt à voir ou démontrer.

CertYou est partenaire de DantotsuPM

Faire suivre cette démonstration client par une rétrospective d’équipe permet à chacun de reconnaître ce qui s’est bien déroulé avec les parties prenantes et ce qui n’a pas été. Cela crée une mentalité d’amélioration continue dans l’équipe.

#4 – Planification, suivi et contrôle 

Prenez contact avec chaque personne impliquée dans le projet chaque jour.

Il est essentiel de savoir si l’équipe est heureuse de la façon dont ses membres travaillent dans un environnement agile et un manager de projet doit y devenir un facilitateur. Vous créez dans l’équipe la confiance que vous savez ce que vous faites !

PRINCE2 Agile est construit sur le concept « d’infléchissement » ou « de priorisation », produire pour créer la valeur maximale en premier. Cela représente un changement significatif dans comment les gens pensent et agissent en travaillant sur un projet. Le comité de projet doit le comprendre pour fournir une direction efficace au projet.

Il y a une logique à suivre pour travailler de cette façon
  • Tenez les délais et respectez les jalons
  • Protégez le niveau de qualité car cela est primordial
  • Embrassez le changement puisqu’il va arriver
  • Gardez des équipes stables, n’essayez pas d’ajouter des gens pour aller plus vite
  • Acceptez que le client n’a pas besoin de tout : c’est le cas !

En fin de compte, PRINCE2 Agile complémente la bien établie méthode PRINCE2 mais dans un contexte agile. Ces conseils de bonne pratique prouvent maintenant pour être appropriés et applicables dans de nouveaux pays, avec de nouvelles traductions en allemand, polonais et hollandais.

Un tour de SAFe en 5 minutes !

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Cette vidéo explique les principes principaux de SAFe 5.0 en cinq minutes.

Elle comprend une explication des cadences, des cérémonies et des processus de Scrum et de SAFe applicables aux équipes, aux programmes, aux grandes solutions et aux portefeuilles de projets.

Pour en savoir plus sur SAFe, consultez le site scaledagileframework.com et la formation SAFe sur scaledagile.com.

CertYou est partenaire de DantotsuPM

Comment nous avons accidentellement inventé les histoires de travail, les Job Stories

Le par mopertodans agile, outils et méthodesLaisser un commentaire

La chose la plus formidable que vous puissiez comprendre en construisant un produit est quelles sont les motivations derrière les actions des gens.

How we accidentally invented Job Stories

https://www.intercom.com/blog/accidentally-invented-job-stories/ par Paul Adams

Chez Intercom, nous réévaluons constamment nos processus pour construire un excellent produit, un produit que les gens trouvent de valeur et utile, un produit qu’ils aiment.

nous écoutons les clients

Une chose sur laquelle nous portons une énorme attention est la recherche. Nous embauchons des personnes avec de l’expérience dans la recherche directe et chacun dans l’équipe produit parle directement aux clients. Nous avons aussi embauché un Directeur de Recherche bien plus tôt que la plupart des autres startups : Sian Townsend qui a précédemment mené les équipes de recherche pour Google Maps.

Bien sûr, il est évident que vous devriez parler aux clients fréquemment pour essayer de comprendre leurs besoins, mais quel est le meilleur outil pour y répondre n’est pas évident.

Chez Intercom, nous pensons constamment aux choses à partir des premiers principes et très tôt nous avons appliqué ce focus sur comment nous parlons à nos clients. Nous étions les grands supporters de l’approche Jobs-to-be-Done (JTBD), mais la plupart de ce qu’a été écrit sur JTBD a été appliqué aux milk-shakes et barres chocolatées. Il y avait peu de recherches publiées sur la façon d’appliquer JTBD au développement de logiciel. Alors, nous avons créé notre propre processus basé sur ce que nous savions.

Les Personas pour l’empathie, pas pour la pensée nouvelle

Livre sur Amazon

Pendant la majorité de ma carrière j’ai utilisé des personas et des scénarios comme des outils pour comprendre les clients.

Popularisé par Alan Cooper dans The Inmates are Running the Asylum, ils sont depuis devenus l’un des outils le plus largement utilisés dans le panel de recherche et conception de l’équipe.

 

Livre sur Amazon

Cooper a aussi écrit un livre fantastique appelé About Face que je recommande à tous les designers qui rejoignent mon équipe, mais je leur dis de sauter les chapitres sur des personas.

Quand je travaillais chez Google, j’ai créé des douzaines sinon des centaines de personas à travers beaucoup de projets. Nous suivions souvent la soigneusement méthode de Cooper et nous créions aussi souvent des itérations de notre propre fait. Universellement, j’ai constaté que leur valeur était limitée. Ils aidaient souvent à construire de l’empathie entre les employés qui étaient déconnectés de leurs utilisateurs, mais ils menaient rarement à des idées révolutionnaires ou fraîches de réfléchir à un problème.

Nous n’avons jamais utilisé de personas chez Intercom.

Les motivations des personnes peuvent être très similaires quelques soient les démographies

La première fois que j’ai vraiment commencé à mettre en doute la valeur des personas était quand j’ai quitté Google et rejoint Facebook. Une des choses saisissantes à propos des données comportementales de Facebook sur leurs utilisateurs était combien le comportement des gens était similaire. Les personas m’avaient amené à croire que les gens sont vraiment différents, avec des objectifs vraiment différents, mais les similarités sont beaucoup plus grandes que les différences et peu importe la démographie que vous pouvez imaginer : la race, l’âge, le genre, etc. Par exemple, les motivations d’une mère mariée avec trois enfants aux États-Unis postant les photos d’un barbecue familial est essentiellement la même que celle d’un adolescent coréen postant les photos de la fête à la maison le soir précédent. Les buts et attributs semblent totalement différents, mais leurs motivations sont les mêmes.

Les personas ne nous mèneraient jamais à un même produit conçu et construit pour ces deux audiences. Alors que les meilleurs personas se concentrent sur les buts (les buts dirigent le comportement des personnes) aussi bien que les attributs, la réalité est que la plupart des personas se concentrent seulement sur les attributs des personas et même des personas dirigés par leurs objectifs ségrèguent artificiellement ces audiences. Les personas limitent artificiellement la cible de votre produit parce qu’ils se concentrent sur des attributs plutôt que des motivations et des résultats. Cette observation a détruit ma foi en eux comme outil.

Ici les clients sont importants

Concevoir pour les motivations et les résultats est bien meilleur que concevoir pour des attributs. C’est la différence clef entre les personas et JTBD. Les personas regardent des rôles et des attributs, JTBD regarde des situations et des motivations. Les personas expliquent qui sont les gens et ce que font les gens. Mais ils jamais expliquent entièrement pourquoi les gens font quelque chose. Pourquoi les gens font certaines choses est beaucoup plus important.

Passer de ce que veulent les gens à pourquoi ils le veulent

les 5 pourquoi, les 5 whys
Utilisez la technique des 5 pourquoi (relisez ce billet)

Ainsi à la mi-2013 chez Intercom, nous nous sommes demandé quel pourrait être un meilleur outil que des personas. Nous parlions à des douzaines de clients chaque semaine et notre équipe de support client parlait à des centaines de plus, recueillant des demandes de fonctionnalités et comprenant les problèmes et les contraintes de notre produit.

Avoir cette relation directe avec nos clients a été inestimable, mais il y avait deux défis que nous avions besoin de surmonter :

  1. Les gens sont des experts dans leur problème pas la solution, mais il est plus naturel de suggérer une solution en forme d’une demande de fonctionnalité. La description d’une suggestion de solution est plus facile que la description d’un problème, mais vous devez retourner vers ces personnes avec des questions pour vraiment comprendre leur problème.
  2. Quand ils répondent, leur réponse initiale vous dira ce qu’ils veulent, sous forme d’attributs, mais pas pourquoi cela importe. Donc vous devez continuer à fouiller dans leurs motivations.

Il était donc critique que nous découvrions quel problème nos clients essayaient de résoudre et pourquoi ils avaient besoin de le résoudre.

Et une fois que nous aurions compris le problème, comment pourrions-nous faire de toute cette compréhension quelque chose d’actionnable pour l’équipe de conception ?

Les longs rapports de recherche et les packs de transparents de présentation avec des résultats de recherche sont difficiles à mémoriser et faciles à ignorer. Nous avions besoin de quelque chose de concis, de facile à communiquer et à se souvenir. Je ne peux compter chez Google le nombre de fois où nous faisions participer des gens à la recherche, à co-créer des Personas avec nous, seulement pour ensuite les ignorer parce qu’ils étaient trop difficiles à se souvenir, trop détaillés à analyser.

Se référer aux Personas n’est pas le chemin par défaut, en fait c’est le chemin de moindre résistance. Et souvent parce que les Personas ne sont pas assez concis pour des équipes développement rapide de produit.

En dehors des Personas, un autre outil très populaire est les User Stories, que le mouvement de développement de logiciel Agile avait popularisées. Nous n’avions jamais utilisé de User Stories non plus. Pour commencer, elles ne proviennent pas de recherche empirique et le format est technique plutôt que centré sur le client. Elles sont formatées pour décrire la fonctionnalité à construire, plutôt que les motivations des personnes.

Histoires de travail : Capturer des situations, motivations et résultats

Après avoir réfléchi à ce problème en repartant des premiers principes, nous avons inventé des Histoires de Travail, les Job Stories. Elles ne portaient pas ce nom en ce temps-là (Alan Klement l’a trouvé plus tard pour nous) mais le processus était là et fonctionnait bien pour nous.

CertYou est partenaire de DantotsuPM

Après avoir longuement considéré JTBD, nous avons créé notre propre approche centrée sur les situations, motivations et résultats :

 [ Quand _____]  [je veux faire _____]  [pour pouvoir _____]

‘ Quand ____ ’ se concentre sur la situation, ‘ je veux faire ____ ’ se concentre sur la motivation et ‘ pour pouvoir ____ ’ se concentre sur le résultat. Si nous avons compris la situation dans laquelle les gens rencontrent un problème à résoudre, comprendre la motivation pour le résoudre et comprendre à quoi ressemble un bon résultat, nous sommes confiants que nous construirons un produit de valeur pour nos clients.

Les Histoires de Travail sont maintenant un outil clef pour nous. Elles garantissent que l’équipe est en mode recherche, que les membres de l’équipe comprennent si bien le problème qu’ils peuvent le capturer en un format concis. Et que leur résumé du problème peut être mis en action par toute l’équipe de conception et technique.

Nous sommes impatients de vous revoir !

Avant que nous ne commencions un quelconque projet chez Intercom, nous créons un résumé d’une page pour le projet. C’est très simple et doit tenir sur une page d’A4 (qui est alors imprimée et collée sur les murs du bureau pour que les différentes équipes aient la visibilité du travail entrepris dans la société). Il a une section sur ses Histoires de Travail. Ces Histoires de Travail sont ce qui assure que nous comprenons le problème ou l’opportunité que nous abordons et elles nous tiennent focalisés sur celles-ci partout dans le projet.

Téléchargez le modèle au format  Word ou PDF

Les personas y ont leur place. Dans des environnements politiques où les gens disent seulement ce que l’on veut entendre sur les besoins réels des clients, je les ai trouvés utiles pour gagner en acceptation; ils peuvent conduire un rapport plus fort avec les réels utilisateurs d’un produit.

Mais les personas sont :
  • Laborieux à bien créer
  • Trop concentrés sur les différences entre les personnes
  • Et difficiles à se rappeler et à référencer.
En fait :
  • Beaucoup de personnes avec des attributs divers ont des motivations très similaires
  • Ces motivations sont faciles à rechercher
  • Et le focus sur ce que vous construisez peut être capturé en une série de phrases courtes et mémorisables.
Si cela ne vous convainc pas, souvenez-vous que les personas contraignent artificiellement le l’ensemble du marché pour votre produit. Nous misons tout sur les Histoires de Travail.