Étiquette : scrum

Comment faciliter les conversations difficiles de l’équipe Scrum ?

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

Être un Scrum Master ou un membre de l’équipe efficace implique inévitablement d’avoir des conversations difficiles.

How to Facilitate Difficult Scrum Team Conversations par Stephanie Ockerman

https://www.scrum.org/resources/blog/how-facilitate-difficult-scrum-team-conversations

Être un Scrum Master ou un membre de l’équipe efficace implique inévitablement d’avoir des conversations difficiles. La façon dont nous abordons les discussions difficiles peut faire la différence entre un moment de transformation et un déraillement. Heureusement, nous pouvons faire beaucoup pour nous préparer à ces moments où nous devons nous débattre d’une question épineuse. Examinons quelques stratégies pour faciliter les conversations difficiles de l’équipe Scrum.

Sujets sensibles et fort niveau émotionnel

Les conversations difficiles impliquent des niveaux élevés d’anxiété, d’inquiétude ou de doute. Peut-être devons-nous prendre une décision difficile ou trouver comment faire quelque chose que nous n’avons jamais réalisé auparavant. Peut-être qu’il y a un conflit entre les membres de l’équipe, ou qu’il y a eu un échec important ou bien un Sprint exceptionnellement difficile. Peut-être que les parties prenantes ne sont pas satisfaites des progrès ou ont des opinions divergentes sur l’orientation du produit ou sur la façon d’interpréter les changements sur le marché. Il existe une myriade d’exemples de circonstances à enjeux élevés auxquelles les équipes Scrum sont régulièrement confrontées et qui nécessiteront des conversations difficiles. Alors, comment pouvons-nous traverser ces périodes avec succès ?

CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Respirez et préparez-vous

L’un des faux pas les plus courants que nous faisons face à une conversation difficile est d’être réactif et de sauter directement sur une tentative pour « résoudre » le problème.

Mais une facilitation réussie implique de prendre le temps de vous familiariser avec la situation et de décider comment vous allez l’aborder.

Idéalement, vous serez en mesure de prendre suffisamment de temps pour vous préparer en toute confiance. Mais même dans les situations où une situation difficile a émergé, vous pouvez souvent faire une brève pause pour vous recentrer. Laisser le temps à la conversation de se dérouler avant de vous lancer vous aidera à comprendre les problèmes. Vous pourriez avoir besoin de proposer une ou plusieurs sessions de travail pour permettre aux gens d’analyser des idées et des options avant de vous réunir.

Définissez l’intention

Le fait d’être clair sur l’objectif de la conversation apporte de la clarté au processus de facilitation. Tout le monde autour de la table devrait savoir pourquoi ils sont là et quelles sont les attentes.

Êtes-vous réunis pour chercher à comprendre le point de vue de chacun ? Allez-vous réfléchir ensemble à des solutions ou parvenir à un consensus sur les idées déjà sur la table ? Devez-vous en équipe réparer les relations interpersonnelles ou créer une identité d’équipe plus claire ? Avoir une idée claire de l’objectif de se réunir réduit l’anxiété et maintient la conversation centrée et productive.

Soyez inclusif

Familiarisez-vous avec la gamme de techniques et activités de facilitation adaptées à différentes personnalités et attitudes. Certaines personnes préfèrent faire un remue-méninge par elles-mêmes avant de partager des idées en groupe. D’autres préfèrent interagir en petits groupes ou partager leurs pensées par écrit plutôt que verbalement. Les techniques impliquant la visualisation, les métaphores et autres outils créatifs peuvent également mieux convenir à certaines équipes. Vous aurez probablement besoin de combiner ces techniques et outils.

facilitationComprendre la dynamique de notre équipe et présenter les options aidera à faire en sorte que tout le monde se sente aussi à l’aise que possible pour s’engager.

Soyez présent

Soyez présent et appréciez pleinement cette opportunité.

Les facilitateurs efficaces sont à l’écoute de ce qui se passe pendant la conversation en :

  • Écoutant activement (vous vérifiez avec l’orateur pour vous assurer que vous avez compris ou pour clarifier).
  • Lisant les messages non exprimés, telles que « se déconnecter » en regardant son smartphone ou d’autres indices.
  • Remarquant des interactions entre les membres de l’équipe qui pourraient révéler une dynamique tacite en action.

Être conscient et présent vous permet de détecter la direction de la conversation et de faire des choix éclairés dans l’instant.

Soyez flexible

flexibilitéBien que vous deviez être intentionnel et prêt à faciliter, vous devez également vous adapter à ce qui se passe devant vous. Comme tous les agilistes le savent, les choses ne se déroulent pas toujours comme prévu, il est donc préférable de ne pas trop vous attacher à votre agenda ou à des structures de facilitation spécifiques.

Ralentissez

Il est très facile dans les situations de forte émotion de passer en mode réactif, ce qui réduit votre capacité à rester ouvert, flexible et créatif. Vous voulez éviter une réaction instinctive à ce que vous entendez ou expérimentez pour diriger la situation de manière réfléchie.  Vous pouvez en apprendre plus sur cette dynamique dans ce précédent article Staying Creative in a Reactive World.

Prendre conscience de la façon dont vous réagissez pendant les périodes stressantes peut vous aider à rester calme et à changer de cap si nécessaire. Une première étape utile consiste simplement à ralentir les choses lorsque le stress du moment vous incite à les accélérer. Ce n’est pas aussi facile qu’il n’y paraît. Les anglophones nord-américains deviennent typiquement mal à l’aise avec des pauses de plus de quelques secondes dans les conversations. Il faut de la pratique.

Faire des pauses régulières pour traiter l’information améliore la compréhension et vous permet de répondre avec curiosité et ouverture. Alors, respirez et encouragez les autres membres de votre équipe à faire de même. Prendre des pauses fréquentes permet également aux membres de votre équipe qui pourraient avoir besoin de plus de temps pour traiter les informations de s’engager plus facilement. Il permet à chacun de prendre de meilleures décisions, plus éclairées.

Reconnaissez également que certaines situations et décisions nécessitent plus de temps que d’autres. Nous avons tendance à avoir un faux sentiment d’urgence dans nos organisations, mais souvent nous pouvons retarder un peu les décisions quand nous devons prolonger la conversation ou recueillir plus d’informations. L’expression « Prenez des décisions au dernier moment raisonnable » me vient à l’esprit.

Notez que je ne préconise pas d’étendre les durées des événements Scrum. Si les problèmes que vous devez traiter nécessitent plus de temps, il est préférable de déplacer ces discussions en dehors de l’événement.

Cultivez un « espace courageux »

Faciliter une conversation difficile avec succès nécessite une sécurité psychologique pour les participants. Les membres de l’équipe doivent savoir qu’ils ne seront pas punis ni humiliés pour avoir dit ce qu’ils pensaient et suggéré des idées. Mais gardez à l’esprit qu’un espace « sûr » ne signifie pas nécessairement être parfaitement à l’aise. Les membres de l’équipe vont éprouver des sentiments inconfortables en discutant de questions épineuses.

Je promeut plutôt l’idée d’un « espace courageux ».  Dans un espace courageux, nous sommes prêts à être vulnérables. Nous sommes ouverts aux commentaires difficiles de nos collègues. Nous nous engageons à apprendre.

Les compétences en animation sont pour tout le monde

L’amélioration des compétences en animation n’est pas réservée aux Scrum Masters. Tout membre de l’équipe Scrum peut animer des événements et des sessions de travail. Les compétences en facilitation sont précieuses pour de nombreux problèmes qui surviennent dans votre vie professionnelle quotidienne, et lorsque chaque membre de l’équipe Scrum se sent à l’aise avec la facilitation, toute l’équipe en bénéficie.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Conclusion

Il existe de nombreuses techniques de facilitation créatives et intéressantes disponibles en ligne. Mais il est essentiel que vous soyez intentionnel quant aux techniques que vous sélectionnez, comment vous les combinez et comment vous choisissez de répondre dans l’instant en ce qui concerne la direction de ce qui émerge au cours de nos conversations.

C’est pourquoi j’apprécie la formation  Professional Scrum Facilitation Skills (PSFS). Tout comme « there are no best practices in Scrum”, il n’a pas de meilleures techniques de facilitation. Ce cours vise à vous aider à développer l’état d’esprit d’un facilitateur, en apprenant à sélectionner des techniques efficaces pour différentes situations dans votre contexte.

Petit rappel: Développez la productivité et l’innovation avec des groupes de toutes tailles grâce aux Liberating Structures !

Visitez le site en Français

Voici un pointeur fort utile vers des méthodes (et une app pour votre mobile) pour vous aider à impliquer tout le monde lors de vos sessions de travail de groupe.

Téléchargez l’app LISA sur votre smartphone IOS ou Android. C’est gratuit, très intéressant et fort utile !

Améliorez la culture organisationnelle grâce à la reconnaissance pendant les rétrospectives.

Le par mopertodans agile, experience sharingLaisser un commentaire

Les rétrospectives présentent de belles opportunités pour les membres de l’équipe de reconnaitre d’une manière authentique et sincère les efforts des autres personnes au cours du sprint passé.

Improving organizational culture through retrospective recognition par Kiron Bondale

https://kbondale.wordpress.com/2018/11/25/improving-organizational-culture-through-retrospective-recognition/

Après avoir observé les acheteurs frénétiques en compétition les uns avec les autres lors des ventes du Black Friday à l’automne dernier, on pourrait être tenté d’oublier que Thanksgiving était à l’origine une expression de gratitude.

Guide téléchargeable gratuitement

Le Guide Scrum n’identifie pas spécifiquement l’expression d’appréciations comme un ingrédient clé des rétrospectives de sprint, mais il énumère les activités qui peuvent intégrer l’appréciation telles que l’inspection des interactions des membres de l’équipe et le rôle du Scrum Master pour encourager l’équipe non seulement à être plus efficace, mais aussi à passer un moment plus agréable ensemble au prochain sprint.

Les animateurs de rétrospectives encouragent souvent les participants à identifier ce qui s’est bien passé ou ce qu’ils ont aimé. C’est une bonne opportunité pour les membres de l’équipe de reconnaitre d’une manière authentique et sincère les efforts des autres personnes au cours du sprint passé.

Remercier pour l’aide reçue pour franchir un obstacle signifie aussi que vous seriez prêt à aider à votre tour.

Tout comme l’identification des possibilités d’amélioration, les membres de l’équipe doivent non seulement reconnaître les grandes réalisations, mais aussi les petites qui peuvent s’additionner au fil du temps. Nous sommes prompts à reconnaître un membre de l’équipe qui a laissé tomber ce qu’il faisait pour nous aider pendant quelques heures sur une question vraiment délicate, mais qu’en est-il de ce membre de l’équipe qui nous a emmenés prendre un café parce qu’il a remarqué que nous semblions être particulièrement stressés ce jour-là ?

Tout comme pour fournir des commentaires constructifs, nous ne devrions pas attendre une prochaine rétrospective pour nous remercier, mais la cérémonie de rétrospective offre une bonne occasion de remercier tardivement ceux dont les efforts ont fait la différence au cours du sprint passé. Un Scrum Master peut introduire cette pratique dans une rétrospective en utilisant des chocolats ou tout autre petit cadeau à offrir par les membres de l’équipe à ceux qu’ils souhaitent reconnaître. Dans les rétrospectives ultérieures, l’équipe peut identifier de nouvelles façons de faire pour garder la pratique vivante.

Un récent article du Washington Post décrit comment la gentillesse peut être contagieuse.

Toute personne qui a participé ou initié une chaîne de « paiement en avance » serait probablement d’accord avec l’auteur de l’article. Lorsque quelqu’un apprécie de vive voix ce que nous faisons, nous ressentons le besoin de faire de même. Exprimer régulièrement vos sentiments positifs pourrait améliorer progressivement la culture au sein de vos équipes, de vos départements et, éventuellement, de votre organisation globale.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Votre projet est-il adapté aux pratiques agiles ?

Le par mopertodans agile, outils et méthodes1 commentaire

Tous les projets ne sont pas adaptés aux approches agiles. Des critères bien pensés peuvent vous aider à déterminer si vos projets sont de bons candidats agiles.

Is your project suitable for agile practices? par Bonnie Biafore

http://www.bonniebiafore.com/is-your-project-suitable-for-agile-practices/

Voici des questions que vous pouvez utiliser pour développer vos propres critères de qualification pour Agile :

Pouvez-vous obtenir le bon personnel ?

Les membres appropriés de l’équipe technique et métier doivent être dédiés au projet. Cela signifie que vous devez gérer les compromis difficiles entre le travail de projet et les considérations opérationnelles. Les projets agiles produisent des résultats rapidement, ils prennent donc beaucoup de temps aux participants. De plus, les approches agiles nécessitent des membres essentiels des équipes business et technique qui sont critiques à vos activités opérationnelles. Il est important de prioriser leur temps sur le projet afin qu’ils puissent contribuer efficacement.

Les ressources ont-elles une profondeur de connaissances appropriée ? 

Une connaissance approfondie des domaines business et techniques liés au projet est cruciale. L’approche agile repose sur des experts métier travaillant en étroite collaboration avec les experts de l’équipe technique. Ce qui rend les méthodologies agiles Agile, c’est la réactivité à l’évolution des besoins. Les techniciens et les personnes du business compétents doivent constamment réévaluer les livrables du projet, les besoins de l’entreprise aux niveaux macro et micro et la priorité des fonctionnalités requises par le client final.

Le Sponsor a-t-il un état d’esprit Agile ?

Le sponsor doit être disposé à participer à des revues fréquentes du produit en construction, qui sont fondamentales dans l’approche agile. La réactivité agile aux conditions changeantes de l’entreprise et son environnement évolutif sont très différentes des méthodes de projet traditionnelles. Si un sponsor veut un ensemble linéaire et méthodique d’objectifs livrés selon un calendrier prédéfini, il aura du mal avec les livrables du projet en approche agile. Les sponsors qui sont mal à l’aise avec la nature évolutive de l’agilité créent des difficultés qui peuvent couler le projet.

L’équipe peut-elle être co-localisée (physiquement ou virtuellement) ?

Agile implique un dialogue profond, interactif et parfois difficile. Pour tirer le meilleur parti de ce dialogue, vous devez créer l’environnement le plus riche possible. Co-localisez les membres de votre équipe de projet si possible. Si vous ne pouvez pas, simulez la colocalisation avec les meilleurs outils vidéo et audio que vous pouvez obtenir. Essayez de faciliter un dialogue agile avec des outils de communication médiocres, c’est comme essayer de remorquer une caravane avec une tondeuse à gazon.

Existe-t-il une synergie entre les membres de l’équipe business et technique ?

Une équipe agile doit bien s’entendre pour réussir. Les méthodologies agiles nécessitent le dévouement d’experts business et techniques qui sont ouverts à soutenir de nouvelles idées et à se soutenir les uns les autres en tant qu’individus. Vous avez besoin d’un coach agile qui comprend et peut gérer la dynamique humaine, et qui peut favoriser un environnement où les membres de l’équipe partagent facilement leurs idées et leurs préoccupations.

Le produit peut-il être construit (et livré) de manière itérative ?

Les meilleures qualités des approches Agile proviennent de la fourniture de solutions partielles tout en apprenant de chaque itération. En plus des livrables logiciels, d’autres produits peuvent également être construits de cette façon. Avec un peu de créativité, des déménagements, la mise en œuvre de nouveaux processus et même certains projets de construction dans le bâtiment peuvent utiliser des approches agiles.

Utilisez-vous d’autres critères pour déterminer si un projet est candidat à une approche agile ?

Si oui, partagez-les avec nous !

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Connaissez-vous la roue de croissance du coaching agile ?

Le par mopertodans agile, best practicesLaisser un commentaire

The Agile Coaching Growth Wheel

La roue de croissance du coaching agile est un outil pour les coachs agiles, les scrum masters, les leaders et tous ceux qui souhaitent accroître leur capacité à aider et à développer les équipes et les organisations en utilisant les principes et les pratiques agiles.

La roue vous permet de réfléchir et de grandir dans votre cheminement agile.

Faites-vous aider d’un autre coach Agile pour progresser.

Tous les détails sur cette roue: https://resources.scrumalliance.org/Article/agile-coaching-growth-wheel

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

 

Comment votre équipe manage-t-elle ses standups ?

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

Quelle que soit la façon dont votre équipe coordonne son travail, il est important que de tels événements ne soient pas perçus comme une perte de temps par l’équipe ou par les principales parties prenantes.

How does your team run their standups? par Kiron Bondale

https://kbondale.wordpress.com/2022/07/10/how-does-your-team-run-their-standups/

Que vous les appeliez Scrums, stand-ups ou daily, une façon de planifier au fur et à mesure avec une approche adaptative est d’organiser régulièrement des événements de coordination pour s’assurer que tout le monde travaille de manière alignée et sur le travail le plus important.

L’un des sujets les plus courants pour de tels événements est de discuter de l’arriéré de travail de l’équipe à court terme.

Mais de telles discussions peuvent avoir lieu de différentes manières.

Pour s’assurer que tout le monde a la possibilité de s’exprimer, une approche pourrait être de discuter du travail incomplet personne après personne.

Bien que cela ait l’avantage de s’assurer que la voix de chacun soit entendue et donne à chaque membre de l’équipe l’occasion de remonter ses préoccupations ou de confirmer les hypothèses qu’il pourrait faire, cela peut également amener les membres de l’équipe qui ont déjà parlé à se désengager de ce qui est discuté par les membres de l’équipe qui viennent après eux. Bien que cela ne soit pas très préoccupant si le travail de chaque membre de l’équipe est indépendant des autres, dans la plupart des cas, il est probable qu’il y ait des dépendances entre les membres de l’équipe au niveau d’un élément de travail ou d’une activité.

Dans de tels cas, si un membre de l’équipe « s’est déconnecté » de la conversation, il pourrait manquer quelque chose d’important pour son travail ou manquer l’opportunité de corriger une hypothèse invalide faite par les autres.

Une alternative qui résout cet inconvénient est de travailler élément de travail par élément de travail. Cela est susceptible de garder la plupart des membres de l’équipe engagés plus longtemps que l’approche personne par personne, en particulier lorsque plusieurs membres de l’équipe doivent collaborer ensemble pour terminer un élément de travail. Cependant, lorsque certains membres de l’équipe ont terminé les éléments de travail qu’ils ont choisis et soutiennent maintenant activement les autres dans l’achèvement d’éléments de travail « étrangers », tous les membres de l’équipe peuvent ne pas avoir la chance de s’exprimer.

Lorsque les éléments de travail passent par un flux de travail bien défini, une autre option consiste à discuter des éléments de travail en fonction de la phase de développement dans laquelle ils se trouvent. En supposant que les membres de l’équipe travaillent sur des éléments à travers différentes phases, cela réduira la probabilité qu’un membre de l’équipe se désengage de la conversation générale, même s’il a déjà terminé la discussion des éléments de travail dans la phase en cours.

La plupart des outils de management du travail fournissent une méthode pour organiser les éléments dans les colonnes d’un tableau de travail afin que l’équipe puisse discuter des éléments incomplets dans l’ordre dans lequel ils sont présentés. Cependant, une approche plus efficace pourrait consister à donner la priorité aux quelques éléments vitaux qui méritent vraiment d’être discutés.

Il y a 3 façons courantes de le faire

Par coût du retard

Cela comprend des considérations telles que la valeur commerciale, la réduction des risques, la dépendance d’éléments de travail à venir ou la capacité d’exploiter une opportunité.

Par durée des éléments de travail

Visualisation sous forme de tableau Kanban

En supposant que l’équipe a atteint une maturité suffisante pour n’avoir que quelques tailles d’éléments de travail différentes, l’équipe pourrait se concentrer sur la discussion des éléments de travail actifs qui sont en dehors des attentes normales en matière de durée pour leur taille.

Par statut de l’élément de travail

Cela peut être fait en commençant par les éléments de travail bloqués, puis ceux avec des obstacles identifiés, puis (si nécessaire) les autres.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Beaucoup d’équipes avec lesquelles j’ai travaillé utilisent une méthode personne par personne pour leurs événements de coordination, mais je voulais comprendre quelle était la répartition entre les différentes approches.

J’ai mené un sondage d’une semaine dans le groupe de discussion LinkedIn Project, Program and Portfolio Management de PMI et dans la communauté ProjectManagement.com.

Sur les 369 réponses reçues :

  • 66 % ont utilisé une approche élément de travail par élément de travail,
  • 20 % ont été traitées personne par personne,
  • 11 % ont discuté des éléments de travail par étape de développement et
  • 3 % ont eu une autre méthode.

Dans ce dernier cas, j’avais demandé aux répondants de fournir des détails, mais dans la plupart des cas, les commentaires reflétaient une approche par élément de travail et par ordre de priorité.

Quelle que soit la façon dont votre équipe coordonne son travail, il est important que de tels événements ne soient pas perçus comme une perte de temps par l’équipe ou par les principales parties prenantes. Discuter de l’efficacité et de l’efficience de tous les événements standard dans les sessions d’amélioration des processus, tels que les rétrospectives, est un moyen de s’assurer que cela ne se produise pas.

le livre de Kiron Bonale : « Easy in Theory, Difficult in Practice » contient 100 autres leçons sur le leadership de projet

(Si vous avez aimé cet article, pourquoi ne pas lire le livre de Kiron Easy in Theory, Difficult in Practice qui contient 100 autres leçons sur le leadership de projet ?)

Petit retour sur 7 précédents billets au sujet des Daily Scrum meetings

TOP 3 d’Octobre 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de la fin d’année pour vous remercier d’avoir particulièrement apprécié ces billets.

Le modèle Thomas Kilmann propose 5 approches de résolution de conflit.

Les cinq approches sont légitimes.

Face à un conflit, cela vaut la peine de considérer les parties impliquées et votre résultat préféré avant la négociation.  Considérez quelles fins de partie vous êtes prêt à accepter et déterminez la meilleure approche à adopter pour atteindre votre fin de partie préférée.

CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Connaissez-vous ces formations gratuites proposées par le PMI® ? 

Le Project Management Institute® (PMI®) propose de nombreuses formations en particulier pour préparer les certifications. Certaines, plus généralistes ou introductives sont ouvertes à toutes et tous gratuitement.

Voici le lien que j’utilise et qui liste toutes les formation en anglais et français de la gratuite à la plus onéreuse.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes

La signification de MVP – Corrigez les idées fausses les plus courantes !

Chacun a sa propre interprétation de ce que signifie un produit minimum viable (MVP) pour son organisation et, bien que les spécificités d’une définition de MVP puissent varier, ce billet explore ce qu’est un MVP et ce qu’il n’est certainement pas.

Bien que votre définition personnelle du MVP de votre produit puisse varier, assurez-vous que vous ne vous basez pas sur l’une de ces fausses idées.

TOP 3 d’Août 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de la trêve de fin d’année pour vous remercier d’avoir particulièrement apprécié ces billets.

L’intelligence émotionnelle : un atout pour les managers de projets comme pour tout autre leader

Qui n’a jamais entendu les phrases :

Les émotions n’ont pas leur place dans le monde professionnel !

ou encore

Quand on vient au bureau, on laisse ses émotions à la maison.

Avez-vous lu ce rapport sur l’état du coaching agile : « 2022 State of Agile Coaching Report » ?

Téléchargez le document

Riche des données de plus de 2 000 coachs agiles professionnels qui ont partagé leurs expériences sur l’impact du coaching agile, le deuxième rapport annuel sur l’état du coaching agile est publié. Le rapport couvre un éventail de sujets liés au coaching agile dans le monde réel, y compris le retour sur investissement, la valeur et les métriques permettant de définir le succès.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

15 avantages que vous apporte le management de projet  

Et vous, en tant que manager de projet, dirigez et menez et vous assurez que l’organisation tire le plein avantage de tout ce que vous faites. Cela vous rend extrêmement précieux pour toute organisation avec laquelle vous travaillez. Du niveau de l’équipe jusqu’au comité exécutif où ils examinent les résultats et les impacts business. Soyez fier de vous. Vous êtes manager de projet.

Il y a des différences très significatives entre « Mechanical Scrum » et « Professional Scrum », les connaissez-vous ?

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

« Mechanical Scrum » consiste à appliquer les principes et cérémonies de Scrum. « Professional Scrum » va plus loin, changeant la manière dont vous travaillez, pensez et agissez.

Cette brève vidéo de Scrum.org revient sur les idées qui supportent « Professional Scrum » et expose comment cela dépasse le Scrum Guide.

Et cette vidéo, plus longue et en français, entre dans les détails de ce qu’est Scrum Professionnel

French edition Scrum Pulse – Ne faites pas semblant, pratiquez Scrum professionnel ! avec Fabio Panzavolta

Scrum a été développé à l’origine pour des projets complexes de développement de logiciels. Il est maintenant utilisé pour presque tout type de produits crées en équipe. Le cadre, tel qu’il est défini dans le Guide Scrum, est un moyen simple mais puissant de mettre de l’ordre dans la complexité par l’apprentissage en fournissant des occasions fréquentes de feedback à la fois sur la façon de travailler et sur ce sur quoi nous avons et aurons à travailler.

Bien que de nombreuses personnes pratiquent Scrum, le pratiquer efficacement exige quelque chose de plus que de simplement suivre les mécanismes et les principes fondamentaux du cadre. Scrum professionnel aide les équipes à se défaire de cette habitude mécanique et routinière lorsqu’il s’agit de Scrum.

Dans ce webinaire Scrum Pulse, Fabio Panzavolta, PST @Scrum.org, partage avec les participants en quoi le Scrum professionnel est différent et comment il requiert les valeurs de Scrum, une mentalité et des méthodes de travail et de pensée différentes, en se concentrant sur les résultats et un environnement qui soutient le Scrum professionnel, y compris la confiance.

Lien original au webcast, avec présentation à télécharger :  https://www.scrum.org/resources/french-edition-scrum-pulse-ne-faites-pas-semblant-pratiquez-scrum-professionnel

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Comment ré-estimez-vous les histoires utilisateurs inachevées lors d’un sprint avec l’approche Scrum ?

Le par mopertodans agileLaisser un commentaire

Lorsque le travail n’est pas terminé dans le sprint, que faites-vous ?

When Work Isn’t Finished In the Sprint, What Do You Do? par Joel Bancroft-Connors

https://resources.scrumalliance.org/Article/re-estimate-unfinished-stories?utm_campaign=practical-agility&utm_medium=dantotsuPM

Est-ce que vous ou votre équipe avez déjà dit :

« Nous n’avons pas terminé tout le travail de ce sprint. Nous allons découper l’histoire afin d’obtenir du crédit pour le travail que nous avons déjà réalisé. »

« C’est fait à 90%, il faut juste le tester. Passons de 13 points à 1 point pour le prochain sprint. »

« Wow, c’est bien plus que 5 points. Nous aurions dû en faire un item à 13 points. »

« Nous n’avons pas terminé ces quatre histoires, nous allons simplement les reporter au prochain sprint. »

« C’est fait, il faut juste le tester. Créons une nouvelle histoire juste pour ça et marquons celle-ci comme terminée. »

J’entends ces phrases et d’autres similaires tout le temps. L’estimation, dans des circonstances normales, est difficile. Ensuite, tenez compte de ce qu’il faut faire lorsque vos estimations étaient « fausses » et que cela devient carrément désordonné. Ces exemples sont les raisons et les scénarios les plus courants que j’entends lorsque les gens posent des questions sur la réestimation du travail.

Alors, comment ré-estimez-vous le travail inachevé ?

Réponse courte : Je ne le fais pas.

Je ne ré-estime jamais le travail qui n’est pas terminé. Il n’a pas répondu à la définition de Done et retourne dans le l’arriéré de produit (le « backlog produit ») où il pourra être pris en compte pour le prochain sprint.

L’estimation ne change pas parce que nous avons commencé ou que c’est plus difficile que nous le pensions, et nous n’obtenons aucun crédit pour un travail qui n’est pas « terminé ».

En tant que « sauveteur » chef de projet, j’aime beaucoup la simplicité de la définition de Fait (Done) (les mesures de qualité requises pour le produit). Comme le binaire n’est qu’une série de 1 et de 0, la définition de Done n’a que 2 états, « Done » et « Not Done ».

À la fin du sprint , nous examinons chaque élément du backlog produit et nous nous demandons : « Est-ce que cela répond à la définition de Done ? » Si la réponse est oui, elle va à la revue du sprint. Si la réponse est non, cela retourne dans l’arriéré de produits.

« Not Done » est également très précis : l’élément de l’arriéré de produit n’est pas utilisable et ne génère donc aucune valeur. Cela retourne dans l’arriéré de produits et je le traite comme si aucun travail n’avait été fait. C’est dans l’arriéré de produit et vous le traitez comme n’importe quel autre élément du backlog. Il a juste l’avantage de plus de « préparation ».

Pourquoi ne ré-estimez-vous pas ?

C’est une bonne question. Il y a un certain nombre de raisons de traiter un item « Not Done » comme n’importe quel autre élément de l’arriéré de produit.

Doit être utilisable

La première raison vient directement du Guide Scrum. « Afin de fournir de la valeur, l’incrément doit être utilisable. » Je ne divise pas une histoire juste pour obtenir un crédit partiel. Si j’avais pu le diviser en un travail plus petit et qu’il était encore utilisable, j’aurais déjà dû le faire en guise de préparation. Nous nous concentrons sur les résultats (la valeur) et non sur les livrables (le travail accompli).

Le code pourrit

J’ai appris cela d’un développeur expérimenté il y a des années. Même dans les environnements où la « production » ne change que tous les six mois, la base de code peut changer beaucoup en une semaine. Lorsque le travail a commencé sur la nouvelle interface de connexion, les environnements étaient à l’état X. À la fin du sprint, les environnements étaient à l’état Y et lorsque nous avons finalement terminé l’interface de connexion, deux sprints plus tard, les environnements étaient à l’état Z. J’ai vu du travail qui répondait à la définition de Done dans le sprint précédent planter le système construit parce qu’il n’a été déployé que quatre semaines plus tard. « Il faut juste le tester », est probablement tout en haut avec « qu’est-ce qui pourrait mal tourner? » dans les déclarations qui précèdent la catastrophe.

Ne prenez pas de raccourci

Ceci est étroitement lié à la pourriture du code. Si le travail n’est pas terminé dans le sprint, je ne le reprends pas dans le sprint suivant comme si rien n’avait changé. Je prends toutes les tâches (qui ne sont pas Done) et les ramène à « à faire » (To Do). Lorsque je reprends le travail, je valide à nouveau tout le travail. Non seulement le « code pourrit », mais vous avez peut-être appris quelque chose de nouveau, avez une nouvelle approche, quelqu’un d’autre a fait le travail. En revenant au tout début, vous vous assurez que rien n’a été manqué et que la qualité reste élevée.

Le tout s’équilibre

Cela entre en jeu à la fois avec un travail qui est « presque terminé » et un travail qui est « ouh la la ! C’est beaucoup plus gros que ce que nous pensions ». Vous allez reprendre un travail qui a été entrepris dans un sprint précédent et qui était à 1 point d’effort de finir, et vous allez également prendre un travail qui finira par nécessiter trois fois plus de travail que prévu, et à long terme, le tout s’équilibre. La loi des grands nombres nous dit essentiellement que, au fil du temps, le nombre d’éléments surestimés s’équilibrera avec le nombre de sous-estimés.

Ne le faites pas

Si cela n’a pas été fini dans le sprint, profitez-en pour examiner le travail à nouveau. Commencez par les critères d’acceptation. Sont-ils trop vagues ? Peut-on y répondre par oui ou non ? Regardez au-delà de cet élément de l’arriéré pour avoir une vue d’ensemble. L’équipe prend-elle trop de travail, cet élément dépendait-il d’un autre élément, y a-t-il une difficulté avec la définition de Done ?

Enfin, profitez-en pour poser la question suivante

Devrions-nous encore faire ce travail ?

Chaque sprint est une opportunité d’inspection et d’adaptation. Une partie consiste à examiner tout ce qui se trouve dans l’arriéré de produit et à vous demander si cela soutient toujours l’objectif du produit.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

La controverse sur les Story Points : Quelle est leur réelle valeur ?

Le par mopertodans agileLaisser un commentaire

Voici un billet que j’ai trouvé très intéressant sur la réelle valeur des story points et les raisons pour lesquelles ils créent des conflits dans vos projets Agiles.

The Story Point Controversy par Natalie Barnes

https://resources.scrumalliance.org/Article/story-point-controversy

L’estimation du travail agile fait l’objet de débats dans les organisations depuis des années. Il existe plusieurs techniques d’estimation, mais les story points, en particulier, peuvent être un mystère pour beaucoup. Bien qu’il s’agisse d’une méthode couramment utilisée, certains peuvent questionner son efficacité. Cet article décrit le but des story points et pourquoi ils peuvent être sujets à controverse.

Qu’est-ce qu’un Story Point ?

Un story point est une unité de mesure d’une user story basée sur des facteurs tels que la complexité, l’effort, l’incertitude et le risque. Les story points peuvent être utilisés dans des approches agiles comme Scrum lors de la planification du sprint en attribuant une valeur en points à une user story.

Le story-pointing est un moyen rapide d’estimer le travail à l’aide d’outils tels que Planning Poker ou le modèle de Fibonacci. Par exemple, l’équipe peut attribuer un 1 ou un 2 à une histoire qu’elle considère comme nécessitant peu d’effort. L’objectif est d’aider les équipes Scrum à avoir un dialogue ouvert pour acquérir une compréhension commune du travail relatif à toutes les histoires utilisateurs dans l’arriéré de produit, le product backlog.

Relisez ce billet sur « pourquoi Fibonacci ? »

Toute l’équipe (ceux qui font le travail) discute des éléments et des composants impliqués dans le développement de l’histoire utilisateur et parvient à un consensus sur l’estimation en story points. Certaines équipes établissent une base de référence convenue pour l’histoire d’effort le plus faible avec le nombre de story points le plus bas. Si une user story a un nombre très élevé de points, l’équipe décompose l’histoire en histoires plus petites puis les estime.

Comment les story points sont-ils utilisés dans les sprints ?

Une fois que la planification du sprint est terminée et que l’équipe a décidé de ce à quoi elle peut s’engager dans le sprint, elle a alors son nombre total de points d’histoire, de story points, engagés. À la fin du sprint, l’équipe aura consommé tous les story points qui répondent à leur définition de terminé, done. Toutes les histoires qui ne sont pas complètes sont alors soit déplacées dans le backlog, peut-être affinées et ré-estimées, soit reportées au sprint suivant : c’est une décision d’équipe.

L’équipe répète ce processus pour chaque sprint. Au fil du temps, les membres développent leur vélocité, qui est une moyenne du nombre total de story points complétés à la fin de chaque sprint. Les story points terminés peuvent varier à chaque sprint en fonction de la capacité de l’équipe (temps disponible pour chaque sprint). Les facteurs qui pourraient avoir une incidence sur la capacité comprennent le nombre de membres de l’équipe travaillant dans le sprint en raison d’un congé personnel ou d’une maladie, d’une formation ou de conférences, d’événements imprévus, de distractions externes ou peut-être d’un sprint lourd en réunions (pensez aux réunions de département ou d’organisation).

Pourquoi les story points peuvent-ils être sujets à controverse ?

Étant donné que les story points sont une valeur nébuleuse et arbitraire, certaines organisations peuvent ne pas comprendre l’unité réelle de cette mesure des histoires utilisateur. Elles peuvent mal interpréter leur objectif, et il est difficile d’associer systématiquement les points d’histoire au délai de livraison. Prenons la vélocité, par exemple. Elle est considérée comme une mesure clé dans Agile, mais elle peut être utilisée à mauvais escient lors de la mesure de la productivité d’une équipe. Les dirigeants peuvent poser des questions sur la vélocité de l’équipe et vouloir savoir combien de points d’histoire ils achèvent à chaque sprint. Cet état d’esprit de la vélocité en tant que mesure de productivité utilisant des story points ne donne pas une bonne idée de la productivité ni du temps qu’il faudra à l’équipe pour livrer une fonctionnalité.

Disons que l’équipe prend en charge et complète 20 story points dans le sprint 1. Dans le sprint 2, ils prévoient 40 story points mais ne complètent que 30 story points. Dans le sprint 3, ils embarquent et complètent 30 points d’histoire. Cela ne signifie pas que l’équipe est plus ou moins productive de sprint en sprint. Cela fait partie du processus de planification de l’équipe pour déterminer ce qu’elle peut engager dans chaque sprint compte tenu de son expérience du dernier sprint. Étant donné que les user stories présentent différents degrés de complexité et d’incertitude, l’équipe a peut-être appris que ses estimations lors de la planification du sprint étaient trop élevées ou trop basses et s’ajuste en conséquence à chaque sprint.

La capacité de l’équipe est une autre raison pour laquelle les story points peuvent fluctuer. Peut-être qu’ils n’ont pas pu en terminer autant qu’ils l’avaient prévu en raison d’une personne malade dans l’équipe ou d’un autre événement inattendu.

Les story points sont également utilisés à mauvais escient comme métrique pour comparer une équipe à une autre. L’équipe A peut avoir une moyenne de 40 story points tandis que l’équipe B peut avoir une moyenne de 80 story points. Le management peut mal interpréter cela comme signifiant que l’équipe A est deux fois plus productive que l’équipe B. Il n’y a pas deux équipes égales. Leurs membres peuvent avoir des compétences différentes, la taille des équipes peut être différente et les définitions d’un story point peuvent varier. La comparaison des équipes nuit à leur processus d’estimation, crée des estimations gonflées et démoralise l’équipe.

Trouvez un équilibre

Il est compréhensible que les organisations aient besoin de savoir à quel point les équipes sont productives et elles ont besoin de quelque chose de tangible pour mesurer leur performance. Cependant, il est erroné de supposer que les story points et la vélocité sont des mesures d’évaluation de la productivité. Les story points sont utilisés par l’équipe Scrum à des fins de planification et ne doivent pas être considérés comme une unité de productivité par la direction. La vélocité en tant que métrique doit être utilisée par l’équipe Scrum comme point de référence pour les aider dans leur prise de décision pour les engagements de sprint.

Les apprentissages continus et l’expérience de l’équipe donnent la possibilité à l’équipe Agile d’améliorer ses estimations au fil du temps.

Grâce à l’inspection et à l’adaptation, les membres de l’équipe deviennent plus prédictifs et capables de prévoir les délais pour les fonctionnalités. Ce qui compte dans l’agilité, c’est un dialogue ouvert et productif sur le travail, la progression vers l’objectif du produit et la création fréquente de valeur pour les clients.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Qu’est-ce qui challenge le plus vos équipes avec Scrum ?

Le par mopertodans agile, experience sharingLaisser un commentaire

L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

What challenges teams most with Scrum? de Kiron Bondale

https://kbondale.wordpress.com/2022/03/20/what-challenges-teams-most-with-scrum/

L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

Guide téléchargeable gratuitement

La première partie de ce cliché est évidente car le Guide Scrum ne comporte que 11 pages (si vous ne comptez pas la page de titre, l’objectif et la table des matières). Il y a 3 rôles, 3 livrables et 4 événements/cérémonies (cinq si vous incluez les sprints en tant qu’événement, mais je préfère ne pas le faire car l’idée générale d’événements dans des événements me donne la nausée).

La deuxième partie de ce cliché devient apparente une fois que vous essayez d’implémenter Scrum dans un système existant. Ce n’est que dans de très rares cas qu’il est possible d’introduire Scrum sans affecter radicalement la façon de travailler de l’équipe. Ceci, en soi, n’est pas une mauvaise chose car l’amélioration des résultats de livraison implique un certain nombre de changements.

Cependant, la nature immuable de Scrum est l’endroit où les défis se matérialisent. En surface, introduire un nouvel ensemble d’événements ou de livrables ne semble pas trop drastique, mais lorsqu’il s’agit de remplacer les rôles, les livrables et les événements existants par les rôles Scrum, et de les mettre en œuvre tels qu’ils sont destinés à être utilisés, c’est là que les défis émergent.

Compte tenu de mes observations personnelles sur les problèmes d’adoption de Scrum, j’ai pensé qu’il serait utile de sonder un public plus large sur l’aspect de Scrum qui a généré le plus de défis.

Au total, 35 membres de la communauté LinkedIn PMI Project, Program and Portfolio Management ont répondu au sondage avec la répartition suivante des votes :

  1. Les événements/cérémonies : 31 %
  2. Les rôles : 31 %
  3. Les livrables/artefacts : 17 %
  4. Le timeboxing de 1 à 4 semaines : 20%

Cela concorde avec ce que j’ai observé.

Bien qu’il puisse y avoir des problèmes de qualité avec les sprints et les arriérés de produits, et que les équipes immatures ne produisent pas toujours un incrément, il ne faut généralement pas trop de temps à la plupart des équipes pour se familiariser avec ces artefacts. De même, bien qu’il puisse être nécessaire d’augmenter la durée du sprint lorsque vous prenez en compte des contraintes du « monde réel » des projets non logiciels, au fil du temps, les équipes s’améliorent pour découper les éléments de travail de sorte que « quelque chose » de valeur puisse être produit en peu de temps.

Les plus grands défis que j’ai vus concernent l’adoption correcte des événements et des rôles Scrum.

Qu’il s’agisse des Daily Scrums qui se transforment en réunions de statut, de rétrospectives de sprint dangereuses psychologiquement, de revues de sprint auxquelles n’assiste aucune partie prenante externe ou de planification de sprint qui prend des jours à compléter, le but et les conditions préalables à la réussite des événements se perdent dans leur mise en œuvre.

La propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.

Alors que nous voulons tous des Product Owners fantastiques et des équipes « entières » interfonctionnelles, nous nous retrouvons avec des Product Owners qui n’ont aucun pouvoir décisionnel ou pas de temps, et une répartition imprévisible des membres de l’équipe d’un sprint à l’autre.

Aussi, lorsque nous considérons le grand nombre de conditions requises pour permettre à Scrum d’être mis en œuvre tel que conçu, la probabilité qu’elles soient toutes remplies au sein d’une organisation typique est assez faible.

Et c’est pourquoi « Scrumbut » (Scrum mais…) est la valeur par défaut, pas l’exception.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

+++++++++++++++++++++++++++

Qu’est-ce que le « Scrumbut » ?

https://www.scrum.org/resources/what-scrumbut

Les ScrumButs sont des raisons pour lesquelles les équipes ne peuvent pas tirer pleinement parti de Scrum pour résoudre leurs problèmes ni tirer pleinement parti du développement de produits à l’aide de Scrum.

Chaque rôle, règle et timebox Scrum est conçu pour fournir les bénéfices souhaités et résoudre les problèmes récurrents prévisibles.

Scrumbut – L’équipe contourne le problème plutôt que le résoudre.

ScrumBut signifie que Scrum a mis en évidence un dysfonctionnement qui contribue au problème, mais qui est trop difficile à résoudre.

Un ScrumBut conserve le problème tout en modifiant Scrum pour le rendre invisible afin que le dysfonctionnement ne soit plus une épine dans le pied de l’équipe.

Un ScrumBut a une syntaxe particulière : (ScrumBut)(Raison)(Contournement)

Exemples de ScrumBut

  • « (Nous utilisons Scrum, mais) (avoir un Daily Scrum tous les jours génère trop de frais) (donc nous n’en avons qu’un par semaine.) »
  • « (Nous utilisons Scrum, mais) (Les rétrospectives sont une perte de temps) (donc nous ne les faisons pas.) »
  • « (Nous utilisons Scrum, mais) (nous ne pouvons pas créer une fonctionnalité en un mois) (donc nos Sprints durent 6 semaines.) »
  • « (Nous utilisons Scrum, mais) (parfois nos managers nous confient des tâches spéciales) (donc nous n’avons pas toujours le temps de répondre à notre définition de Done.) »

Connaissez-vous ces formations gratuites proposées par le PMI® ?

Le par mopertodans formations et certificationsLaisser un commentaire

Le Project Management Institute® (PMI®) propose de nombreuses formations en particulier pour préparer les certifications. Certaines, plus généralistes ou introductives sont ouvertes à toutes et tous gratuitement.

Voici le lien que j’utilise et qui liste toutes les formation en anglais et français de la gratuite à la plus onéreuse.

A ce jour 8 formations en ligne totalement gratuites

  1. Project Management for Beginners
  2. Free Introduction: PMI® Authorized On-demand PMP® Exam Prep
  3. Free Introduction: Basics of Disciplined Agile™ Online Course
  4. The Basics of Scrum
  5. Taming Bias: Using Wicked Problem Solving to Make Better Decisions and Align Teams
  6. Highlights from the 2021 Virtual Experience Series
  7. PMI Citizen Developer™ Business Architect: CDBA Introduction
  8. Business Continuity

“PMI,” the PMI logo, “PMP” and “Project Management Institute” are registered marks of Project Management Institute, Inc.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes

Un produit minimum viable n’est pas toujours la chose la plus précieuse pour une startup

Le par mopertodans agile, best practices, experience sharingLaisser un commentaire

Certaines startup décident de ne pas construire de MVP et d’attendre que le produit soit complet et mature avant de demander à des clients potentiels de l’essayer et fournir des retours. Vous voudrez peut-être aussi envisager cette approche…

A minimum viable product is not always a startup’s most valuable player de Srikrishnan Ganesan

https://www.mindtheproduct.com/a-minimum-viable-product-is-not-always-a-startups-most-valuable-player/

Une pratique courante de lancement de startup consiste à créer d’abord un produit minimum viable (MVP). Largement considéré comme la meilleure première étape pour prouver un produit, un MVP permet à une startup de commercialiser rapidement une version initiale du produit et de solliciter au plus tôt les commentaires des clients pour l’améliorer avant de lancer le produit. Avec un MVP, une startup peut se concentrer sur la unique selling proposition du produit, la proposition de valeur qui rend le produit unique, et construire autour de celle-ci.

Rocketlane a pris un chemin différent. Nous n’avons pas construit de MVP, mais nous avons attendu que le produit soit complet et mature avant de nous engager avec des clients potentiels et de leur demander de l’essayer et de fournir des retours. Vous voudrez peut-être aussi envisager cette approche lorsque vous évaluerez diverses façons de mettre votre produit sur le marché. Dans cet article, nous allons vous expliquer pourquoi.

Pourquoi casser les codes ?

Brisez les codes !

Un MVP fonctionne bien lors de la création d’un produit entièrement nouveau pour un nouvel espace et pour des solutions ponctuelles simples pour les petits clients. Cependant, si un produit doit remplacer des produits horizontaux matures par des solutions spécialement conçues, le produit ne réussira pas en commençant en tant que MVP, d’autant plus si le produit cherche à unifier, en remplaçant un ensemble d’outils horizontaux cloisonnés.

La signification du MVP – Corriger les idées fausses les plus courantes

Les principaux piliers de notre histoire de produit sont ses capacités de « tout-en-un » et « d’unification », rassemblant les tâches, les rapports de projet, les notes de réunion, la collaboration de documents en direct et les flux de travail dans une expérience étroitement couplée.

Nous devions intégrer tous ces composants dans notre toute première version de produit et livrer un produit avec une gamme significative de fonctionnalités dès le premier jour. Pour gagner l’adhésion, un produit qui promet une expérience tout-en-un doit faire au moins 80% de ce que fait chacune des solutions horizontales. Le produit doit d’abord avoir toutes ses fonctionnalités de base en place, puis ajouter une couche d’innovation au-dessus.

Distractions et détours

Si vous créez un produit tout-en-un remplaçant plusieurs outils établis et cloisonnés, ce n’est pas non plus une bonne idée de développer et de lancer chaque module séquentiellement en tant que MVP. Si vous donnez un module ou une partie de votre solution à vos clients potentiels pour qu’ils la testent, ils vous fourniront des retours pour améliorer cette partie, ce qui pourrait vous faire perdre de vue votre solution complète.

Supposons que vous alliez plus loin et que vous lanciez une partie de votre produit en tant que MVP, alors l’ensemble du marché pourrait fournir des commentaires similaires et vous faire perdre encore plus de concentration sur votre vision plus aboutie. Vous lanceriez également un MVP qui n’est probablement pas encore au niveau en le comparant fonctionnalité par fonctionnalité avec l’une des solutions établies et cloisonnées que vous souhaitez remplacer, ce qui pourrait entraîner des critiques plus mitigées que vous ne le recevriez autrement si vous aviez attendu pour livrer votre vision complète.

Ne laissez pas un client vous entraîner dans la spirale d’une vision qui lui est propre.

Un autre risque à lancer ou engager des clients potentiels avec un module MVP de votre produit est de suivre LEUR vision de ce module.

Il pourrait finir par ressembler à d’autres produits déjà sur le marché, car ils vont comparer chaque module MVP à d’autres solutions cloisonnées qu’ils utilisent ou connaissent déjà.

Il est préférable d’allouer du temps et des ressources à l’analyse des retours des clients sur des modules et des fonctionnalités spécifiques après avoir livré la vision complète et votre différenciation.

Construire dans les délais lors de la création d’un produit

Une autre raison d’impliquer les clients potentiels tard dans la phase de développement est que les clients jugent en fonction de l’agilité et de la vitesse de production. Lors de la construction des fondations d’un produit, les clients ne percevraient peut-être pas de progrès mensuels significatifs. Plutôt que d’impliquer les clients potentiels dans les premières étapes et risquer la désillusion, il est préférable d’attendre les derniers mois avant le lancement.

Une fois que vous avez un bon produit qui est à 80% de ses fonctionnalités, il ne devrait pas être difficile d’engager des clients potentiels à l’essayer pour quelques équipes et cas d’usage, puis à itérer rapidement avec eux pour atteindre l’adéquation produit / marché cible.

La présentation d’un nouveau produit presque fini aux clients potentiels garantit également qu’ils n’ont pas besoin d’imaginer ce qu’il sera à l’avenir. Ils le voient déjà fonctionner avec succès en fonction de votre vision et peuvent mieux comprendre cette valeur.

Idéalement, les clients potentiels verraient également qu’il n’y a pas d’autre produit équivalent sur le marché ni ailleurs. Lorsqu’ils utilisent le produit en fonction de votre vision complète, ils doivent également imaginer comment cela pourrait les aider.

Gestion des risques

reconstructionImpliquer des clients potentiels tard dans la phase de développement inclut le risque de construire trop sans le valider. Le risque augmente avec l’ampleur et la complexité du produit. Même si vous avez de l’expérience dans la création de produits et que vous connaissez la direction, les demandes des clients et ce dont ils peuvent et ne peuvent pas se passer, il est préférable d’engager un panel d’examinateurs, pas nécessairement des clients potentiels, qui sont intéressés par votre vision. Dès la phase de conception, vous pouvez leur montrer des maquettes de ce que sera votre produit complet. De cette façon, vous aurez un flux de retours sur les démonstrations de maquettes même pendant la construction du produit, ce qui vous aidera à réduire les risques.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Vendre la vision

Vous devrez peut-être éduquer les investisseurs et les employés sur votre approche de produit mature. Les deux groupes peuvent être plus familiers de l’approche MVP et peuvent se demander pourquoi attendre la fin de la phase de développement pour engager des clients potentiels. Vous pouvez manager cela avec des réunions régulières où vous présentez les progrès et répondez aux questions. Vous pouvez également distribuer une note de service écrite aux investisseurs et employés, ce qui serait un bon exercice pour cristalliser votre pensée et pour les deux groupes d’avoir un document de référence.

Un produit mature est le produit le plus viable

Il y a plus d’une façon de construire un produit, en particulier pour les catégories horizontales et compétitives. Au lieu de créer un MVP, vous voudrez peut-être créer un produit avec plus de maturité et d’étendue avec quelques expériences innovantes clés qui servent de promesse différenciante (unique selling proposition) et illustrent pourquoi votre produit est le meilleur pour des cas d’utilisation spécifiques.

Si vous engagez les clients potentiels lorsque le produit semble mature, ils comprendront pourquoi ils devraient s’aligner sur votre vision et vous ne sacrifierez pas la différenciation que vous apportez sur le marché.

 

La signification de MVP – Corrigez les idées fausses les plus courantes !

Le par mopertodans agile, best practicesLaisser un commentaire

Chacun a sa propre interprétation de ce que signifie un produit minimum viable (MVP) pour son organisation et, bien que les spécificités d’une définition de MVP puissent varier, ce billet explore ce qu’est un MVP et ce qu’il n’est certainement pas.

The Meaning of MVP – Correcting Common Misconceptions de Phil Tarnowski

https://www.mindtheproduct.com/the-meaning-of-mvp-correcting-common-misconceptions/

Chacun a sa propre interprétation de ce que signifie un produit minimum viable (MVP) pour son organisation et, bien que les spécificités d’une définition de MVP puissent varier, ce billet explore ce qu’est un MVP et ce qu’il n’est certainement pas.

Un MVP réussi est essentiel à la création d’un produit numérique réussi : C’est l’ensemble de fonctionnalités ciblées qui lance votre produit sur le marché, donne le ton pour l’avenir de votre produit et vous aide à vous guider vers des améliorations prioritaires sur la feuille de route du produit. C’est la version initiale qui met votre produit sur le marché et vous permet d’itérer, d’obtenir des retours et de vous concentrer sur l’adéquation produit / marché. Votre MVP n’est pas le strict minimum, ni le nombre maximum de fonctionnalités : Il se situe quelque part entre les deux.

Voici quelques choses qu’un MVP n’est certainement pas.

Squelette

Il y a 20 ans, votre nouveau produit numérique était souvent le premier à être commercialisé. Il y avait moins de solutions numériques qu’aujourd’hui et les attentes en matière d’expérience utilisateur étaient plus faibles. Aujourd’hui, les goûts et les attentes des consommateurs ont changé. Tout comme le marché (nous avons écrit un guide en anglais sur la façon de définir la première version de votre produit numérique).

Lorsqu’il existe des dizaines d’autres concurrents avec des offres de produits similaires, vous devez rendre votre MVP plus beau et plus intuitif que la concurrence. Il ne devrait pas seulement fonctionner. Il devrait résoudre de vrais problèmes et être élégant en le faisant.

Aujourd’hui, si les gens ne savent pas facilement comment utiliser un produit, ils passeront à autre chose. S’ils ne voient pas la valeur rapidement, ils passeront à autre chose. Pour cette raison, vous devez créer un MVP qui fait le travail rapidement et facilement.

Un seul et c’est fini (one and done)

Les produits numériques ne sont pas une construction où une seule version suffit. Peu importe l’expérience que vous avez des produits numériques, il y aura des fonctionnalités que vous manquerez ou sur lesquelles vous vous tromperez dans votre première version.

Vous obtiendrez des retours sur votre MVP, ce qui signifie que vous devrez revenir sur la conception pour améliorer le produit. Si vous pensez que votre premier jet sera parfait et n’aura pas besoin de changements, vous serez déçu. Tout comme une maison, les produits numériques nécessitent des améliorations et un entretien continus. Et, si votre MVP est apprécié par vos utilisateurs, vous devrez éventuellement « maintenir l’existant » et « ajouter une chambre d’amis » pour continuer à répondre à leurs attentes et vous assurer qu’ils reviennent.

Le produit parfait

Bien que votre MVP ne devrait pas être le simple squelette de toutes vos idées, il ne devrait pas non plus être toutes vos idées. Si vous passez trois ans à développer entièrement toutes les caractéristiques du produit de vos rêves, puis mettez ce produit sur le marché, vous serez probablement surpris du résultat. Vous constaterez peut-être que certaines fonctionnalités que vous pensiez être des aspects essentiels de votre produit sont déroutantes et inutiles pour vos utilisateurs.

Cela signifie que vous avez passé trois ans à construire quelque chose que vos utilisateurs ne veulent même pas. C’est une grosse perte de temps et d’argent.

Créez un MVP qui adresse les problèmes clés que vos utilisateurs doivent résoudre, mettez-le sur le marché et obtenez des retours. Répétez cette stratégie et itérez au fil du temps. La rétroaction et l’itération atténueront les risques. Cela vous aidera à créer un produit axé sur l’utilisateur. En abordant les problèmes par de petites améliorations incrémentales, vous vous assurerez de créer un produit précieux pour les personnes qui utilisent réellement le produit.

Bien que votre définition personnelle du MVP de votre produit puisse varier, assurez-vous que vous ne vous basez pas sur l’une de ces fausses idées.

  • Définissez votre MVP en commençant par les objectifs business à long terme et travailler à rebours.
  • Priorisez impitoyablement et évitez le piège d’avoir un MVP qui est un squelette ou exagérément musclé.
  • Et n’oubliez pas de recueillir de manière obsessionnelle des retours afin de pouvoir continuer à maintenir et à améliorer votre produit au fil du temps.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

La mort de la dérive de contenu (le « scope creep ») et le management de projet Agile

Le par mopertodans agile, best practicesLaisser un commentaire

Un seul mot, adaptabilité, résume les avantages du management de projet agile de la manière la plus brève et la plus directe possible.

The Death of Scope Creep  – Agile Project Management

https://www.projectsmart.co.uk/scope-management/the-death-of-scope-creep-agile-project-management.php  par Duncan Haughey

Un seul mot, adaptabilité, résume les avantages du management de projet agile de la manière la plus brève et la plus directe possible. Les organisations qui adoptent l’agilité, qui s’équipent pour s’adapter, sont mieux préparées à s’adapter rapidement aux évolutions fréquentes du marché et aux besoins des clients.

Cependant, d’après mon expérience, la flexibilité de l’agilité peut être une arme à double tranchant. Lorsque vous avez beaucoup trop de latitude sans définitions explicites, la dérive de contenu se produit. Et si vous ne contrôlez pas ce glissement du périmètre, vous vous retrouverez avec des membres de l’équipe fatigués, des clients mécontents et une initiative qui a déraillé !

Qu’est-ce qui motive la dérive de contenu dans les projets agiles ?

Et plus important encore, comment pouvez-vous l’empêcher de mettre en danger vos projets ?

Continuez à lire ce billet pour le savoir.

À quoi ressemble le Scope Creep et comment pouvez-vous le repérer ?

La dérive de contenu se produit lorsque les besoins, les objectifs ou les buts d’un projet changent bien au-delà de ce qui a été promis à l’origine. Chaque fois que ce changement se produit, le projet n’est plus strictement décrit. Et pire encore, les limites des attendus et finalement de la fin du projet deviennent floues.

Savoir à quoi ressemble le scope creep n’aide que si vous savez comment le repérer, et il existe plusieurs façons de le faire. Peut-être introduisez-vous progressivement des choses mineures. Peut-être que les délais sont ignorés. Les délais manqués peuvent amener les membres de l’équipe à mal comprendre leurs devoirs et obligations. Peut-être que votre analyste d’affaires est moins directement engagé.

Si vous apercevez de tels signes, la dérive de contenu met probablement en danger votre projet.

Qu’est-ce que la dérive de contenu et le management de projet agile ?

Dans le management de projet agile, la dérive de contenu fait généralement référence à des changements réguliers, mais non approuvés et non planifiés, qui ont un impact négatif sur les limites du projet. Généralement, en pratique, de tels scénarios signifient que vous mettez constamment en œuvre des changements sans tenir compte de la façon dont le projet en est impacté.

Comment reconnaître cette dynamique ?

Eh bien, ce glissement se manifeste le plus souvent avec l’ajout de nouvelles fonctionnalités et services aux produits. Et cela se produit surtout lorsque de tels ajouts sont effectués sans tenir compte de l’effet sur d’autres limites du projet (par exemple : les délais, le budget, le personnel, la qualité, la sécurité, etc.).

Donc, beaucoup d’entre nous, y compris moi-même, sont conscients du concept de triple contrainte dans le management de projet : Si le contenu d’un projet change, cela peut en affecter la durée et / ou les coûts. Si les effets sur les délais et le budget ne sont pas pris en compte, la qualité va en souffrir. Et c’est ainsi que vous obtenez une dérive de contenu dans le management de projet agile.

Comment éviter que la flexibilité agile ne provoque de dérive de contenu

Pour éviter le glissement de portée associé à la flexibilité requise avec l’agilité, créez votre processus de contrôle des modifications à l’aide d’un tableau Kanban. Une flexibilité incontrôlée peut éventuellement entraîner une dérive de contenu et détourner le projet de son plan initial. Même si votre portée est flexible, restez constamment aligné avec votre plan.

Comment ? Utilisez le nettoyage du backlog (backlog grooming), également connu sous le nom de SCRUM refinement. Cette activité importante est trop souvent négligée.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Le nettoyage du backlog doit être effectué une fois par sprint et implique les éléments suivants
  • Ajout de critères, de contexte, d’urgence, d’estimations ou d’éléments narratifs aux éléments du backlog avant de les pousser vers la production dans un cycle.
  • Suppression des éléments inutiles qui n’offrent plus de sens pour le projet.
  • Harmoniser les objectifs avec la vision pour maintenir un bon périmètre.

Il est essentiel de prendre ces mesures pour minimiser ou prévenir la dérive de contenu. En fin de compte, le nettoyage du backlog permet aux équipes d’accélérer la planification des sprints et d’améliorer l’allocation et la décomposition du travail. Le processus permet essentiellement à un système efficace de management du changement de prendre effet tout en maintenant la flexibilité souhaitée.

Impliquez tous les membres de l’équipe de projet et atténuez les causes du scope creep

Pour éviter la dérive de contenu, impliquez tous les membres de l’équipe. Cela signifie que, même lorsque vos parties prenantes sont satisfaites, n’oubliez pas de vérifier que vos développeurs sont également satisfaits. Informez-les du processus de management des changements et de la façon dont cela les affectera. Ils doivent être des gardiens, des garants de la portée du projet, plutôt que des acteurs du changement.

Gardez également à l’esprit que les membres de l’équipe projet, du moins d’après mon expérience, aiment aider et peuvent accepter d’apporter de gros changements sans passer par la procédure de management des changements.

Pour éviter cela, précisez que tout le monde ne devrait pas accepter d’apporter des modifications à moins d’y être autorisé pour éviter de perturber le calendrier du projet et potentiellement créer une dérive de contenu. Tout membre de l’équipe qui souhaite aider les intervenants doit décrire la procédure de contrôle des changements et se porter volontaire pour aider à enregistrer la demande de changement.

Pourquoi est-il si important d’être si vigilant ?

C’est une question à laquelle il est facile de répondre : la dérive de contenu est un sérieux problème dans les projets agiles, en particulier lorsque le manager de projet, les équipes et les partenaires n’apprécient pas l’effet que les changements peuvent avoir sur l’équipe, le budget et les délais. Heureusement, si vous êtes explicite sur la portée initiale du projet et que vous gérez correctement les modifications apportées à votre plan de projet tout au long de la durée de vie du projet, il est peu probable que la dérive de contenu soit un problème majeur.

Mais pour en être certain, vous aurez toujours besoin d’un système de management de projet efficace qui soit à la hauteur du défi, alors utilisez des outils de management des changements qui vous permettent de documenter de nouvelles modifications et d’évaluer instantanément l’impact de ces modifications.

En tant que manager de projet, vous pouvez hiérarchiser ces modifications et allouer les tâches aux membres de l’équipe à l’aide de solutions telles que ProjectManager. Ensuite, une fois qu’un changement est autorisé, quelqu’un peut s’y atteler immédiatement.

Mettez en œuvre des procédures de management des changements

Que se passe-t-il lorsque quelqu’un essaie d’apporter des changements ? Selon mon expérience, il est naïf de croire que rien ne changera. Mais tous les changements ne sont pas mauvais. Un changement structuré, bien géré et approuvé dans vos projets est tout ce dont vous avez besoin pour éviter la dérive de contenu.

Pour cultiver de tels changements, vous voudrez utiliser une stratégie de management des changements pour décrire les processus de contrôle du changement qui doivent être mis en œuvre et quand le plan de projet doit être mis à jour.

Il est également essentiel de mettre en place une procédure de management des risques qui spécifie la fréquence à laquelle le statut global de votre projet sera évalué. Cette étape vous permet de tenir à jour le registre des risques dont la dérive de contenu.

Et le processus n’a pas besoin d’être intimidant : une procédure de gestion des changements est simple. Fondamentalement, quelqu’un propose un changement via une demande qui est ensuite examinée, acceptée ou refusée. Si elle est acceptée, le changement est inclus dans le plan du projet. L’utilisation des fonctionnalités de management des changements fournies par votre outil de gestion de projet facilitera ce processus.

En fait, l’établissement des mesures correctives implique de déterminer qui évaluera et approuvera les changements car, sans méthode, le changement se produit sans prévenir.

Évitez les changements de DERNIÈRE MINUTE

Enfin, pour éviter toute dérive de contenu, évitez tout changement de dernière minute. Commencez par déterminer la portée de votre projet en fonction des besoins de vos parties prenantes. Ensuite, à l’aide d’une structure de répartition du travail (WBS), générez un plan de travail complet. Le plan de travail est la conséquence de savoir ce que votre projet apportera. Dans le plan, incluez tous les besoins et la façon dont vous y répondrez sous forme d’activités, d’événements et d’objectifs.

Pour vous assurer que vous n’avez rien négligé, faites le lien entre l’échéancier de votre projet et votre processus de management des besoins.

Conclusion & à retenir

Quel que soit le projet, l’évolution des besoins est considérée comme un échec de planification dans le management de projet conventionnel. Aussi, votre étape de planification initiale doit-elle être solide comme le roc, surtout si vous voulez éviter la dérive de contenu.

Si vous ignorez la dérive et n’essayez pas de l’empêcher de se produire en premier lieu, vous risquez de mener votre projet à l’échec et personne ne souhaite cela !

Comment contrôlez-vous la portée de vos projets ?

TOP 3 de juin 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de l’été pour partager sur les billets les plus lus depuis le début de l’année, mois après mois.

Juin: 2 règles pour vos réunions, 12 mythes sur l’agilité et périodes de complexité.

#1 – Voici 2 règles qu’il pourrait être amusant d’essayer pendant une semaine pour vos réunions

Abstentions et annulation pure et simple !

#2 – « 12 mythes sur l’Agilité » par Jean-Yves Klein

Jean-Yves Klein

L’Agilité est souvent fantasmée, parfois usurpée et trop fréquemment mal comprise.

Voici 12 mythes à garder à l’esprit pour éviter de se tromper quand on envisage d’adopter une approche Agile.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

#3 – 7 choses simples qui renforcent la clarté pendant une période de complexité

Lorsque des complexités emplissent votre esprit, l’inquiétude affaiblit vos appuis. La complexité chasse la clarté. Les ombres deviennent réalité.

L’effroi dilue vos capacités.

L’anxiété déplace votre confiance.

Se sentir dépassé est inévitable lorsque la complexité bannit la simplicité.

N’importe quel idiot peut rendre les choses faciles difficiles !

Guide Scrum pour les leaders

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Si vous dirigez des équipes Scrum ou si vous êtes un leader dans une organisation qui tire parti de Scrum, le Guide « Scrum Companion for Leaders » est fait pour vous.

Il examine les différents éléments de Scrum et réfléchit à un moyen efficace pour les dirigeants de s’engager dans l’agilité.

Le guide a été écrit pour la version Scrum Guide 2020.

Il existe de nombreuses définitions du leadership qui s’appliquent à l’utilisation de Scrum. Les leaders sont à la fois à l’intérieur et à l’extérieur de l’équipe Scrum. Tout le monde fonctionne avec un certain niveau de leadership. Cependant, ce guide est axé sur les personnes qui sont en dehors de l’équipe Scrum. Par exemple, les managers des ressources humaines, les managers de projets et de programmes et les responsables de département. Si vous êtes un exécutif, nous vous suggérons de lire la première section car elle vous fournira un contexte sur le fonctionnement de Scrum dans votre organisation.

Télécharger la version française

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Disponible dès maintenant, le rapport 2022 sur l’état du coaching agile : « 2022 State of Agile Coaching Report »

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Le Business Agility Institute, Scrum Alliance et ICAgile ont collaboré pour affiner davantage la mesure de l’impact du coaching agile.

Avec les données de plus de 2 000 coachs agiles professionnels qui ont partagé leurs expériences sur l’impact du coaching agile, le deuxième rapport annuel sur l’état du coaching agile est publié et disponible dès maintenant. Le rapport couvre un éventail de sujets liés au coaching agile dans le monde réel, y compris le retour sur investissement, la valeur et les métriques permettant de définir le succès.

 

Téléchargez le document

Ce rapport montre que le coaching agile reste un domaine en pleine croissance, que la demande de coachs qualifiés continue d’augmenter et que les coachs apportent des améliorations mesurables au sein des organisations.

Les coachs pensent que le plus grand impact qu’ils et elles ont est de faire évoluer une organisation vers un état d’esprit et une culture agiles.

Fait intéressant, ils et elles trouvent également que c’est le changement le plus difficile à faire, et l’un des plus grands obstacles à l’agilité s’il n’est pas atteint.

L’agilité dans le business est un ensemble de capacités organisationnelles, de comportements et de méthodes de travail qui offre à votre entreprise (ou organisation) la liberté, la flexibilité et la résilience nécessaires pour atteindre son objectif. Peu importe ce que l’avenir nous réserve. Business Agility Institute

Téléchargez gratuitement le rapport bien documenté et illustré en anglais.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

TOP 3 d’avril 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de l’été pour partager sur les billets les plus lus depuis le début de l’année, mois après mois.

#1 – Quelle est la différence entre un plan de test et une stratégie de test ? Quand utiliser l’un ou l’autre ? par Fidaa Berrjeb

En ce qui concerne les tests de logiciels, deux termes importants entrent en jeu. Ce sont « Plan de test » et « Stratégie de test ». Bien que les deux soient des éléments essentiels du processus de Quality Assurance, ces termes risquent souvent être mal interprétés et utilisés de manière interchangeable.

Alors, quelle est la différence entre un plan de test et une stratégie de test ?

#2 – Avec Scrum, quand un sprint est-il terminé ?

Le Sprint est l’un des concepts de base de Scrum. En fait, c’est l’un des cinq événements de Scrum (avec Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective).

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé. Pour le comprendre, vous devez comprendre le but d’un sprint et pourquoi il est timeboxé (réalisé sur une période de temps limitée).

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

#3 – Que vous en soyez conscients ou pas, votre leadership est contagieux !

Voici quelques-unes des façons dont les leaders peuvent s’assurer que la contagiosité de leur leadership ne propage que de bonnes qualités.

Comment ceci s’applique-t-il à votre management de PMO et Portefeuille de Projets (PPM) ?

TOP 3 de mars 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de l’été pour partager sur les billets les plus lus depuis le début de l’année, mois après mois.

#1 – La métaphore du chef d’orchestre est séduisante pour le manager de projet, mais qu’en est-il dans la réalité ?

Les chefs d’orchestre célèbres sont souvent jugés sur une heure ou deux sur scène. Ils portent des vêtements coûteux, font des gestes dramatiques et reçoivent les ovations. Ils sont aussi très cher payés pour porter une très petite baguette et ils sont les seuls sur scène à ne pas produire de son.

Mais il s’avère que toutes ces choses ne sont pas ce qui fait un grand chef d’orchestre.

#2 – Top 5 des conseils de cohésion d’équipe, de « team building », pour les managers de projets

Les managers de projet donnent le ton à leurs équipes de projet. Le meilleur team building se produit lorsque vous profitez des opportunités quotidiennes pour booster le moral de votre équipe.

#3 – 7 péchés des revues de projet que vous pouvez éviter !

Votre équipe suit un framework Agile spécifique ou a adopté une approche mixte dans ses pratiques, un principe d’Agile est l’utilisation de courtes boucles de rétroaction pour soutenir l’inspection et l’adaptation.

Que votre équipe fixe une cadence régulière pour les évaluations externes des livrables ou qu’elles soient effectuées dans la foulée, il est important d’obtenir des retours exploitables. Mais mener une revue n’est pas seulement une question de rassembler les gens.

Bien qu’il y ait probablement plus que ces 7 manières de gaspiller de précieuses revues de projet, apprenez pour commencer à reconnaitre et éviter celles-ci.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile