Étiquette : scrum

Que fait un manager de projet agile (que ne ferait pas tout.e. manager de projet) ?

Le par mopertodans agile, formations et certifications1 commentaire

Le billet “What does an agile project manager do?” m’a interpelé et j’ai voulu comprendre si il existe réellement des différences majeures entre un(e) manager de projet Agile par rapport à tout(e) autre manager de projet.

Personnellement, je n’en vois aucune et je rejette la vue caricaturale du manager de projet « traditionnel » qui s’enfermerait dans un mode de management de type « commande et contrôle ».

Les responsabilités et compétences listées me semblent s’appliquer à toute et tout manager de projet, que le projet soit mené avec une approche prédictive, adaptative ou hybride. Connaître les principes et approches Agile est un prérequis pour tout(e) manager de projet dans le monde où nous œuvrons.

Qu’en pensez-vous ?

Que fait un(e) manager de projet Agile ?

https://apmg-international.com/article/what-does-agile-project-manager-do

En matière de gestion de projet, l’émergence des méthodologies agiles a transformé la façon dont les entreprises conceptualisent, planifient et exécutent les projets.

Le manager de projet Agile est crucial pour le succès de toute entreprise Agile, un rôle central chargé de rassembler des éléments distincts pour atteindre les objectifs du projet. Le manager de projet a de nombreuses responsabilités, privilégiant l’adaptabilité, la collaboration et s’assurant que les projets répondent aux attentes. Un manager de projet agile est un poste complexe et polyvalent qui nécessite diverses compétences et attributs.

Ce rôle complexe n’est pas toujours facile à comprendre. Pourtant, le succès de l’entreprise repose souvent sur le fait que le manager de projet agile favorise la collaboration entre les services et donne aux équipes les moyens de comprendre, de communiquer et de renforcer le leadership. Ainsi, lorsque tout le monde comprend le rôle du manager, les projets ont plus de chances de réussir et les méthodologies agiles peuvent être déployées efficacement.

Qu’est-ce que le management de projet agile ?

Le management de projet agile est une approche dynamique et itérative du management de projet qui favorise la flexibilité, la collaboration et l’orientation client. Contrairement aux méthodologies traditionnelles, qui suivent souvent un chemin plus rigide et linéaire, l’approche Agile embrasse le changement et donne la priorité à la création de valeur incrémentielle aux parties prenantes pour une livraison précoce et continue.

En favorisant la planification adaptative et le travail d’équipe interfonctionnelle, les méthodes agiles permettent aux équipes de répondre rapidement à l’évolution des exigences et à la dynamique du marché.

Ces dernières années, la popularité des valeurs agiles a explosé, signalant un changement de paradigme dans le management de projet. Les organisations de tous les secteurs adoptent désormais les méthodes Agiles pour améliorer leur réactivité et augmenter la satisfaction de leurs clients.

Les rôles dans les équipes de projet agiles

Une équipe de projet Agile englobe une gamme de rôles essentiels qui conduisent collectivement les projets à leur terme. Différentes équipes peuvent avoir besoin d’une adaptation des rôles principaux.

Ces rôles, tels qu’ils sont décrits  dans le cadre de projet DSDM de l’Agile Business Consortium, peuvent inclure:

  • Sponsor business, qui est responsable de l’ensemble du projet, du budget et des livrables dans le cadre commercial plus large ; Visionnaire, qui est responsable de la vision et de l’orientation globales.
  • Coordinateur technique, qui s’assure que la solution est techniquement correcte et répond aux exigences.
  • Manager d’équipe, responsable des petites zones et de parties détaillées du projet.
  • Analyste d’affaire, travaillant à identifier les opportunités et les changements dans l’entreprise dans son ensemble qui peuvent avoir une incidence sur le projet.
  • Développeur de solutions, prend les exigences de l’entreprise et les utilise pour informer la solution.
  • Solution Tester, responsable des tests de performance à chaque étape.

Les équipes agiles ont souvent des rôles divers et variés adaptés aux objectifs du projet, ce qui favorise l’idée d’adaptabilité. Pourtant, au milieu de ces variations, le rôle central du manager de projet agile reste le même, favorisant la coordination et promouvant les principes agiles.

Qu’est-ce qu’un manager de projet Agile ?

Un manager de projet Agile est un rôle à multiples facettes qui allie leadership de haut niveau et facilitation dans un environnement de projet Agile. Leur objectif principal est de façonner l’environnement de travail en évolution de la solution et de favoriser la collaboration au sein de l’équipe de développement de la solution. Le manager de projet guide les membres de l’équipe sans imposer de plans de projet détaillés au processus de développement. Au lieu de cela, ils utilisent une approche facilitatrice, pilotant le projet sans exercer un style strict de « commandement et de contrôle ».

Le rôle du manager de projet est essentiel pour assurer la réussite du projet, englobant des responsabilités allant de la communication efficace avec les parties prenantes à la supervision de la planification et de l’ordonnancement de haut niveau du projet. De plus, le manager de projet surveille les progrès, gère les risques et les problèmes, et encourage l’autonomisation et la motivation de l’équipe.

Tout au long du cycle de vie du projet, de la fondation au déploiement, le manager de projet reste essentiel au maintien d’une coordination et d’une communication efficaces.

Principales responsabilités d’un manager de projet agile

assumer ses responsabilitésLes managers de projet agiles assument diverses responsabilités critiques, qui sont différentes des postes de manager de projet traditionnels. Ce rôle doit être flexible et central dans le flux de travail agile. Les responsabilités sont les suivantes :

  • Orchestrer l’évolution du projet jusqu’à son achèvement.
  • Promouvoir une communication et une collaboration transparentes au sein de l’équipe agile.
  • Favoriser un environnement où les membres de l’équipe peuvent s’auto-organiser et prendre des décisions.
  • Fournir du coaching et de la formation pour faciliter l’adoption d’Agile et l’amélioration continue.
  • Aligner les objectifs du projet sur les objectifs plus larges de l’organisation.
  • Faciliter une collaboration et une intégration interfonctionnelles efficaces.
  • Guider l’équipe de développement dans la création et le suivi d’un plan de livraison.
  • Suivi de l’avancement du projet et de l’échéancier du projet.
  • Identifier les obstacles et résoudre les problèmes rapidement.
  • Assurer le management des risques et la résolution des obstacles en temps opportun.
  • Cultiver une culture de l’adaptabilité, de l’innovation et de l’apprentissage.
  • Concilier les retours et les besoins des clients avec les contraintes techniques.
  • Encourager les boucles de rétroaction continues pour affiner les processus et les livrables.
  • Collaborer avec les parties prenantes pour recueillir et hiérarchiser les exigences.
  • Donner à l’équipe les moyens d’accepter le changement et de s’adapter à l’évolution des circonstances.
  • Promouvoir les pratiques agiles au sein de l’organisation.

Les responsabilités spécifiques du rôle de manager de projet agile varient en fonction des particularités de l’environnement Agile, de la nature du projet et des exigences de l’entreprise.

Quelle est la différence entre un manager de projet traditionnel et un manager de projet agile ?

La différence entre un manager de projet traditionnel et un manager de projet agile réside dans son approche du management de projet :

Manager de projets traditionnels

Met l’accent sur un style « commander et contrôler », en prescrivant des tâches et des processus. Se concentre sur la planification initiale détaillée, en visant un plan de projet complet dès le début. Principalement responsable de la répartition des tâches et de la supervision des contributions individuelles.

Manager de projets Agiles

Privilégie la collaboration et l’adaptabilité, en favorisant le travail d’équipe et la communication ouverte. Adopte une planification itérative et agile, permettant des ajustements flexibles tout au long du projet. Encourage le leadership partagé au sein d’équipes auto-organisées, en donnant aux membres les moyens de prendre collectivement des décisions et d’obtenir des résultats.

Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Les compétences essentielles nécessaires pour réussir en tant que manager de projet Agile

Devenir un manager de projet Agile compétent implique de perfectionner un mélange de compétences techniques, interpersonnelles et de leadership pour guider les projets avec succès dans le paysage dynamique Agile. Les managers de projet Agile ont la responsabilité globale de gérer les projets agiles du début à la fin, ce qui nécessite un éventail de compétences uniques et adaptables, notamment :

  • Solides compétences organisationnelles : Capacité à gérer des projets complexes, à allouer efficacement les ressources et à s’assurer que les tâches sont accomplies à temps.
  • Excellentes compétences en communication : Aptitude à articuler les idées, les besoins et les progrès à différents niveaux de l’organisation, en favorisant la transparence.
  • Gestion des risques :  Aptitude à identifier les risques potentiels du projet, à évaluer leur impact et à élaborer des stratégies d’atténuation.
  • Résolution de conflits : Capacité à gérer les désaccords et les différences au sein de l’équipe, à favoriser un environnement productif et agile et à améliorer l’efficacité de l’équipe.
  • Leadership adaptatif : Capacité à ajuster le style de leadership en fonction des besoins de l’équipe, en encourageant l’autonomie et l’auto-organisation.
  • Expertise Agile : Une compréhension du manifeste Agile et des quatre valeurs clés pourrait être avantageuse. Une connaissance approfondie d’un cadre Agile, tel que l’approche de  projet DSDM, ainsi que des outils Agile, est essentielle pour une mise en œuvre réussie.
  • Flexibilité : Capacité à naviguer dans les incertitudes et les changements inhérents au travail Agile tout en se concentrant sur les objectifs.
  • Collaboration : Volonté de travailler en étroite collaboration avec les équipes interfonctionnelles, les parties prenantes et les clients afin de créer de la valeur en collaboration.
  • Approche centrée sur le client : Concentrez-vous sur la compréhension et la satisfaction des  besoins des clients, en favorisant la satisfaction des clients et la collaboration.
  • Prise de décision : Capacités supérieures de pensée critique et de prise de décisions éclairées et opportunes.

Certifications et formations en management de projet agile

faire monter en puissance, développerAlors que les approches de management de projet Agile continuent de dominer le management de projet, APMG propose une gamme variée de certifications de premier plan parmi lesquelles les apprenants peuvent choisir. Nos qualifications et formations en gestion  de projet agile permettent aux managers de projet de développer des compétences et d’apprendre des approches agiles.

Cours et certifications agiles APMG :

  • Gestion de projet Agile (AgilePM) : Apprenez à appliquer le cadre de référence pour la réalisation de projets Agile
  • Gestion de programme Agile (AgilePgM) : Découvrez comment créer des programmes agiles flexibles, capables de répondre à l’évolution des besoins de l’entreprise.
  • Analyse d’affaires agile (AgileBA) : Maîtriser le rôle d’un Business Analyst dans un environnement Agile.
  • Agent de changement agile : Développez vos capacités pratiques en matière d’agilité et de changement.
  • Scrum : Apprenez à tirer le meilleur parti de Scrum avec Formation Scrum Master et Product Owner.
  • DASA DevOps : Transformez l’informatique de votre organisation en mettant en œuvre le DASA DevOps Principes.

Avec une qualification APMG, les managers de projet deviennent adeptes des processus agiles et des méthodologies agiles populaires, ce qui leur confère un avantage concurrentiel distinct.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Conclusion

Alors que les organisations reconnaissent de plus en plus le besoin de flexibilité, de collaboration et de progrès itératif, les managers de projet sont apparus comme des facilitateurs de ce changement de paradigme. En adoptant l’état d’esprit Agile, les managers de projet ne se contentent pas de superviser les projets, mais guident activement les équipes vers l’adaptabilité et l’orientation client.

En fin de compte, en incarnant l’éthique Agile et en cultivant un environnement qui nourrit les valeurs Agile, les managers de projet ouvrent la voie à des projets réussis, innovants et axés sur le client dans le paysage moderne dynamique.

Liens utiles

Et si, en cette nouvelle année, vous vous engagiez à respecter le “Agile Sustainability Manifesto” ?

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Inspirés par le Manifeste Agile , découvrez de meilleures façons de travailler en le mettant en pratique de manière durable et en aidant les autres à le faire.

Engagez-vous à respecter le “Agile Sustainability Manifesto”.

https://www.agilealliance.org/sustainability-manifesto/ par Agile Alliance

L’  Agile Sustainability Initiative est un effort visant à sensibiliser la communauté Agile à la durabilité et à explorer comment Agile peut contribuer à un avenir plus durable.

Nous reconnaissons le rôle essentiel que l’agilité peut jouer dans la construction d’un monde durable et résilient. Nous croyons qu’en adoptant les valeurs et les principes agiles et en faisant évoluer nos pratiques, nous pouvons relever les défis complexes auxquels notre société, notre économie et notre environnement sont confrontés.

Inspirés par le Manifeste Agile et les contributions des membres de l’Alliance Agile, nous découvrons de meilleures façons de travailler en l’appliquant et en aidant les autres à le faire.

En reconnaissant que le Manifeste de développement durable agile changera au fur et à mesure que nous apprendrons au fil du temps, nous en sommes venus à apprécier :

  1. Les gens et la planète plutôt que le profit

Nous accordons la priorité au bien-être des lieux (services écosystémiques et biodiversité) et des personnes (individus, communautés et générations futures) plutôt qu’aux gains financiers à court terme, favorisant ainsi un monde régénérateur et équitable.

  1. L’adaptabilité plutôt que la rigidité

Nous considérons le changement comme une opportunité de croissance, de résilience et de durabilité, en valorisant l’adaptabilité plutôt que les plans et les structures rigides. Être capable de s’adapter à des conditions changeantes est une compétence clé face au changement climatique.

  1. L’abondance plutôt que la rareté

Nous reconnaissons que les défis mondiaux exigent de cultiver des relations de coopération et des efforts de collaboration, et nous nous engageons à travailler ensemble au-delà des frontières pour trouver des solutions durables et, surtout, les mettre en pratique. #BetterTogether. Nous prônons une communication ouverte et transparente afin d’instaurer la confiance, de partager les connaissances et d’aborder honnêtement les questions de durabilité.

  1. La valeur plutôt que la consommation

Nous nous efforçons de réduire la consommation d’énergie, de matériaux et de transport dans tout ce que nous faisons, avec le courage de donner impitoyablement la priorité à la valeur et de plaider pour une utilisation responsable des ressources et une consommation consciente sur notre planète finie avec la poursuite de la régénération chez toutes nos parties prenantes.

Les principes agiles de durabilité

#1 – Pratiques durables

Nous nous engageons à intégrer des pratiques durables dans tous les aspects de notre travail, en cherchant à minimiser l’impact environnemental et à promouvoir l’équilibre écologique.

#2 – Relever les défis mondiaux et y répondre

Nous accueillons les défis en constante évolution posés par le changement climatique, les inégalités sociales et la dégradation de l’environnement comme autant d’opportunités d’innover et de conduire un changement durable.

#3 – Fournir fréquemment de la valeur durable

Nous nous engageons à fournir des solutions durables de manière incrémentale, en privilégiant des délais plus courts, afin de résoudre les problèmes de durabilité urgents et à long terme. Nous insufflons et raccourcissons les boucles de rétroaction pour évaluer rapidement s’il faut changer ou persévérer.

#4 – Collaborer avec diverses parties prenantes

Nous collaborons activement avec diverses parties prenantes, y compris les communautés, les gouvernements et les organisations, afin de co-créer des solutions durables qui profitent à tous.

#5 – Responsabiliser les leaders agiles en matière de développement durable

Nous formons une nouvelle génération de leaders agiles en matière de développement durable qui défendent des pratiques éthiques, équitables et respectueuses de l’environnement.

#6 – Soutenir l’adoption académique de la durabilité agile

Nous encourageons l’intégration des principes de durabilité agile dans les programmes académiques afin d’éduquer les générations futures sur l’importance du développement durable.

#7 – Innover pour le bien-être de la société et de l’environnement

Nous explorons comment l’agilité peut être une force d’impact social et environnemental positif, en nous efforçant de trouver des solutions innovantes qui améliorent les vies (au-delà de l’anthropocentrisme – Système ou attitude qui place l’homme au centre de l’univers et qui considère que toute chose se rapporte à lui) et les écosystèmes.

#8 – Faire évoluer l’agilité pour répondre aux besoins modernes en matière de durabilité

Nous adaptons les pratiques agiles pour répondre aux besoins en constante évolution d’un monde durable, en améliorant continuellement nos pratiques pour créer un avenir meilleur. Laissant derrière nous un endroit meilleur qu’en l’état où nous l’avons trouvé.

En adoptant le Manifeste pour le développement durable Agile, nous nous engageons à utiliser les principes Agile pour relever les défis urgents de notre époque, en nous efforçant de créer un monde plus durable, équitable et prospère pour les générations actuelles et futures. Ensemble, nous pouvons bâtir un avenir résilient et harmonieux qui privilégie le bien-être humain, l’adaptabilité, la collaboration et la transparence dans la poursuite du développement durable.

Ines Garcia, Jutta Eckstein et Maryse Meinen – Auteurs de 2023 The Agile Sustainability Manifesto©

En cette nouvelle année, je vous encourage donc à signer le Manifeste Agile pour le Développement Durable.

Chaque geste compte, et chacun a quelque chose à apporter à la création d’une société respectueuse de la nature et régénératrice. Alors, retroussez vos manches ! Signez le Manifeste !

Ajoutez votre nom

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Confiance, REX Spotify et Management du changement furent les billets les plus lus de Novembre 2023 sur DantotsuPM, le blog du management de projet.

Le par mopertodans pointeurs utiles2 commentaires

3 articles très différents vous ont attiré en Novembre. Alors, prenez confiance en vous, ne copiez pas « bêtement » quelqu’un d’autre et facilitez l’enracinement des changements qu’apporte votre projet.

La confiance arrive souvent avant le succès. Vous pourriez même dire que le succès est dû à la confiance.

Comment avoir davantage de confiance en vous ?

Vous ne pouvez pas copier-coller l’approche de quelqu’un d’autre en matière d’agilité. Leur approche s’est développée à partir de leur peuple et de leur culture. Zoom sur Spotify.

Le modèle de mise à l’échelle de Spotify : Spotify ne l’utilise pas, vous ne devriez pas non plus !

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Voici quelques-unes des tactiques qu’un responsable de la transformation peut essayer et adopter.

4 étapes qui aident votre transformation à « s’ancrer » dans la durée par Tony Lockwood.

Réparez des réunions quotidiennes « Daily Scrum » devenues cauchemardesques !

Le par mopertodans agileLaisser un commentaire

Vos réunions quotidiennes débordent-elles la durée agréée ? Est-ce qu’une ou deux personnes s’accaparent la conversation ?

Découvrez plusieurs conseils pour aider les membres de l’équipe à reconnaître quand leur contribution a duré un peu trop longtemps (ou trop peu).

Troubleshooting Nightmarish Daily Scrums par Mike Cohn

https://www.mountaingoatsoftware.com/blog/troubleshooting-daily-scrums

La daily scrum est censée être une réunion de synchronisation d’équipe rapide et factuelle. Elle peut rapidement se transformer en cauchemars récurrents si les gens parlent trop ou trop peu. En tant que Scrum Masters, notre travail consiste à faciliter ces réunions quotidiennes afin qu’elles atteignent leur objectif et restent dans leur zone de temps.

Deux vidéos suivent. Et vous devrez peut-être regarder les deux, en fonction de votre équipe !

La première vidéo présente quatre choses que vous pouvez essayer pour faire bouger la réunion lorsque quelqu’un domine la conversation. La deuxième vidéo traite des choses à essayer lorsque certaines personnes donnent des réponses vagues (ou ne parlent pas du tout !). Si vous préférez lire, une transcription suit chaque vidéo.

Les deux vous aideront à éviter deux monstres des daily scrum : Les vampires qui sucent le temps et les zombies qui tuent l’énergie.

4 choses à essayer lorsque les gens parlent trop dans les mêlées quotidiennes

Certaines personnes ne veulent tout simplement pas se taire. Peut-être qu’elles sont nerveuses à propos de quelque chose, alors elles parlent. Peut-être pensent-elles que tout le monde veut entendre chacune de leurs pensées. Peut-être elles ne sont même pas conscientes qu’elles parlent autant. Mais trop parler peut être un énorme problème, surtout dans une réunion avec une limite de temps courte comme le daily scrum. Voyons ce que vous pouvez faire à ce sujet.

1. Mettez une minuterie

2 petites minutesUne solution courante pour un membre de l’équipe trop bavard consiste à lancer un chronomètre d’une minute lorsque chaque personne commence à donner sa mise à jour pendant le daily scrum. Ce n’est pas grave, mais je trouve que cela oblige souvent une équipe à finir trop vite. La mise à jour de quelqu’un gagnerait souvent à prendre 2 à 3 minutes. Ceci est déconseillé, cependant, avec une minuterie d’une minute par personne.

2. Faites en sorte que l’horloge soit bien visible

Un Scrum Master, Kayleigh, m’a enseigné notre deuxième technique. Au fur et à mesure que chaque personne donne une mise à jour, elle tient un ballon de 3 kg droit devant elle.

La balle n’est pas très lourde, mais la tenir bras tendus devant vous deviendra plus difficile au fur et à mesure que vous parlerez. Ce que j’aime dans cette technique, c’est que la position devient de plus en plus difficile à tenir au fil du temps. Cela le rend très efficace.

3. Interrompez poliment

Voici un troisième conseil pour faire face à un membre de l’équipe trop bavard. Interrompez-le, surtout si vous êtes le Scrum Master ou le coach. Nous hésitons à l’interrompre parce que nous pensons que ce serait impoli. En réalité, ce qui est impoli, c’est que cette personne monopolise la réunion avec son soliloque.

Si quelqu’un est vraiment en train de blablater, le Scrum Master (ou, vraiment, n’importe qui sur le Équipe Scrum) doit les interrompre. Sinon, c’est impoli envers tout le monde dans la réunion.

Voici une bonne façon de l’interrompre poliment. Dites à la personne qui parle qu’il semble qu’elle ait encore beaucoup à dire sur ce sujet. Ajoutez ensuite que tout le monde doit avoir la possibilité de faire le point dans le délai prescrit de 15 minutes. Enfin, proposez de revenir vers l’orateur loquace une fois que tout le monde aura eu l’occasion de partager.

Certaines équipes utilisent l’idée bien connue d’un parking (parking lot) pour de tels sujets. Annoncez simplement que vous ajoutez cet élément au parking et que vous y reviendrez une fois que chacun aura fourni sa mise à jour.

D’autres équipes s’intéressent un peu plus à l’esprit agile des choses et se référeront au parking comme à la « seizième minute ».

4. Créez un signal

demander la permissionSi vous avez du mal à interrompre quelqu’un, voici une technique qui vous aidera. Au lieu d’interrompre la personne, donnez aux membres de l’équipe un moyen de signaler poliment à la personne qu’elle est trop longue. Pensez aux discours de remise des Oscars. Parlez trop longtemps et l’orchestre commence à jouer. Continuez à parler et ils jouent plus fort.

Une façon amusante d’obtenir le même effet est d’utiliser Elmo, le personnage de Sesame Street. Ensuite, utilisez son nom comme acronyme : Assez, passons à autre chose. Si vous êtes tous en présentiel, achetez un Elmo en peluche et gardez-le dans votre salle de réunion. N’importe qui peut brandir l’Elmo en peluche s’il pense que quelqu’un se perd. Cela fonctionne encore mieux pour les visioconférences. Encouragez tout le monde à trouver leur arrière-plan Elmo préféré et à le remonter lorsque quelqu’un parle trop longtemps.

Les daily Scrum sont censées être des réunions rapides et précises. Je ne veux pas qu’une équipe en termine en 5 minutes. C’est certainement trop court pour que quoi que ce soit de significatif ait été discuté ou partagé.

Mais je ne veux pas non plus que la réunion dure trop longtemps, et je ne veux certainement pas qu’une personne monopolise la conversation.

4 choses à essayer lorsque les gens ne parlent pas dans les mêlées quotidiennes

Parlons maintenant de ne pas parler. Comment faire en sorte que quelqu’un s’exprime lors d’une réunion quotidienne ?

Cela ne me dérange pas si quelqu’un reste silencieux lors d’une réunion alors qu’il n’a rien à apporter. C’est très bien, et il faut le féliciter davantage pour ce comportement de quelqu’un qui se sent obligé d’intervenir sur tout.

Mais, rester silencieux dans un stand-up quotidien est un problème parce que chaque personne est censée contribuer.

Pendant des années, les réunions quotidiennes scrum (ou réunions debout quotidiennes) ont suivi le même format. Chaque participant devait dire ce qu’il avait fait depuis la réunion précédente, ce qu’il ferait avant la prochaine réunion et décrire tout ce qui entravait ses progrès. Ces trois éléments représentaient les progrès, les plans et les problèmes d’une personne.

Ces trois éléments ne sont plus exigés d’une équipe Scrum dans ses daily scrum. Ils restent une bonne option par défaut pour la plupart des équipes sur ce qui devrait être couvert lors de la réunion. Mais la façon dont vous arrivez aux progrès, aux plans et aux problèmes n’est pas gravée dans le marbre. Vous devriez changer un peu, surtout si vos mêlées quotidiennes ne fonctionnent pas. Je recommande d’y aller  histoire par histoire, plutôt que personne par personne.

Mais que devez-vous faire si vous êtes un Scrum Master ou un coach avec des membres de l’équipe qui fournissent une mise à jour mais ne disent rien de significatif ? Quelque chose comme : « Hier, j’ai travaillé sur quelques tâches. Aujourd’hui, je vais travailler sur quelques tâches. Pas de bloqueurs. »

J’ai entendu cela trop de fois pour les compter. Et ça ne vaut rien.

1. Recherchez les détails

Quand quelqu’un donne une mise à jour comme celle-ci, vous devez le pousser sur les détails. S’ils disent simplement qu’ils ont « travaillé sur certaines tâches », demandez-leur de nommer les tâches spécifiques. Ou si vous êtes physiquement avec un tableau des tâches sur Kanban, demandez-leur de pointer vers les lignes ou les cartes spécifiques.

2. Revenez à la structure

Posez une question à la fois aux personnes qui donnent des mises à jour vagues. Si votre équipe suit la convention de parler des progrès, des plans et des problèmes, posez d’abord des questions sur les progrès.

Ne laissez pas cette personne vous parler des trois aspects de son travail. S’ils commencent à se transformer en plans ou en problèmes, ramenez-les d’abord au progrès. Dites quelque chose comme : « C’est génial, et nous voudrons tous en savoir plus dans une minute sur votre plan pour aujourd’hui, mais sur quelles tâches spécifiques avez-vous travaillé hier ? » Ramenez-les à un seul sujet.

Donnez une structure et rappelez-la souvent.

Souvent, quelqu’un qui donne une mise à jour vague, comme dire qu’il a travaillé sur certaines tâches, est introverti. Et je peux comprendre : moi aussi. Mais ce qu’il faut savoir sur les introvertis, c’est que même si nous redoutons les bavardages, la plupart d’entre nous se débrouillent bien avec les conversations structurées. Alors, renforcez la structure de ces réunions.

Si vous voulez que les gens parlent des progrès, des plans et des problèmes, mettez l’accent sur cette structure en posant des questions sur chacun d’entre eux à tour de rôle.

En fait, je ne suis pas un grand fan d’un Scrum Master ou d’un coach qui appelle les gens et pose des questions de cette manière. Je préfère laisser une équipe s’organiser elle-même dans la façon dont elle aborde la réunion. Mais avec des individus calmes, ramenez un peu de structure. Cela aidera les introvertis de l’équipe.

3. Encouragez un ordre

chacun à son tour

Une autre façon d’ajouter de la structure à la réunion est de demander aux gens de donner leurs mises à jour dans un ordre connu. Et envisagez de demander aux membres de l’équipe, calmes et vagues, de passer en premier. Ou vous pouvez même y aller en premier vous-même. (Oui : je pense que les Scrum Masters et les coachs devraient aussi donner des mises à jour.)

Une bonne façon de le faire est de commencer par quelque chose comme : « OK, écoutons d’abord Ajay, puis Astrid, mais je vais commencer. » Ensuite, donnez votre propre mise à jour, ce qui donne aux deux personnes que vous avez nommées une chance de préparer les leurs.

Pourquoi est-ce que j’aime commencer par les gens qui donnent des mises à jour vagues? Parce que sinon, ils sont nerveux tout au long de la réunion à l’idée qu’ils seront appelés ensuite. Il est préférable de leur faire savoir quand ils parleront. Et quand vous y allez en premier, vous leur offrez un moment pour rassembler leurs pensées.

4. Renforcez l’objectif

Une autre mesure que vous pouvez prendre est de renforcer l’objectif des réunions debout quotidiennes. Il ne s’agit pas de microgérer une équipe. Les daily scrum ne sont pas des réunions d’étape  conçues pour vérifier l’état des choses. Ce sont des réunions de synchronisation. Les membres de l’équipe synchronisent leurs efforts pour s’assurer que rien d’important n’est négligé et que deux personnes ne font pas la même chose sans être conscientes l’une de l’autre.

Lorsque les gens connaissent le but d’une réunion, ils sont plus susceptibles de comprendre la bonne façon de participer, en ne parlant ni trop ni trop peu, mais juste assez !

Ce ne sont là que quelques-unes des nombreuses façons de créer des réunions quotidiennes plus efficaces pour vos équipes.

De quelles autres façons avez-vous fait passer vos sessions Daily Scrum de hantées et horribles à productives et déterminées ?

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Voici de nombreux billets sur le sujet des Daily Scrum car il sont au cœur de l’approche et restent difficiles à organiser et bien utiliser.

  1. Les 3 questions du Daily Scrum ne mourront pas : Faites-les fonctionner pour votre projet !
  2. Le Manager dans les Daily Scrum : Quelles sont les choses à ne pas faire en dehors d’éviter totalement sa présence.
  3. Comment surmonter 4 objections communes au « Daily Scrum » ?
  4. Comment réussir vos « Daily Scrum » avec des équipes géographiquement distribuées ?
  5. 5 manières pour le #ScrumMaster d’améliorer ses réunions quotidiennes « Daily Standups »
  6. 5 pièges à éviter dans les réunions debout, les désormais célèbres Daily Stand-Up meetings de Scrum
  7. 3 questions pour grandement améliorer l’efficacité de vos réunions quotidiennes ou « daily stand-up meeting »
  8. Comment votre équipe manage-t-elle ses standups ?

« Quelle est la meilleure méthodologie pour gérer un projet au sein des DSI ? » par Ophélie Gomes

Le par mopertodans experience sharing, outils et méthodesLaisser un commentaire

Cycle en V, Méthodes itératives, Méthodes agiles et maintenant méthodes hybrides, on ne sait plus où donner de la tête : à chaque décennie sa méthodologie, à chaque méthode ses supporters et ses détracteurs.

Avec 15 ans d’expérience en gestion de projet et en tant qu’intervenante auprès d’étudiants, la question sur la meilleure méthodologie projet revient très souvent.

En tant que chef de projet, vous devrez faire ce premier choix, choix qui peut être impactant pour la suite du projet. Je vous partage ici les quatre points clés vous permettant de choisir la bonne méthodologie.

#1 – Prendre le temps de connaitre le contexte du projet

Migration d’une application existante, volonté de mettre sur le marché une nouvelle offre digitale, mise en place d’un nouveau process : chaque projet est différent. Voici quelques repères « simples » permettant d’associer une typologie de projet à une méthodologie :

Parmi les atouts d’une méthode agile, nous pouvons citer les itérations courtes permettant d’avoir un retour sur le produit rapidement. Le travail conjoint au quotidien entre les métiers et les équipes techniques permet une adaptabilité rapide face aux changements. Cette méthode est adaptée pour le lancement de nouveaux produits.

A l’opposé, la méthode cycle en V a aussi un certain nombre d’avantages : les phases sont prévisibles (et donc la planification des ressources versus d’autres projets), le périmètre est connu à l’avance. Cette méthode est adaptée par exemple lors de migrations techniques : peu d’incertitude sur la finalité du produit, impératifs business réduits.

Et il y a la vraie vie : votre projet. Il n’est pas complètement agile parce que la direction des achats demande une estimation budgétaire (donc besoin d’un périmètre soi-disant figé). Néanmoins, le périmètre n’est pas suffisamment stable pour appliquer une pure méthode cycle en V parce que certaines fonctions sont encore « à creuser ». Dans ces cas-là, une approche itérative ou encore hybride peut être utilisée.

#2 – Se former… mais garder les fondamentaux toujours en tête

Mener un projet en mode agile quand on ne s’est jamais formé, c’est comme demandé à un développeur de développer une application en technologie Java alors qu’il ne connait que Python et ce dans les mêmes délais qu’un expert Java !

Mener un projet en cycle en V si on n’a fait que de l’agilité, c’est partir à l’échec !

En tant que chef de projet, vous devez donc vous former aux différentes méthodes : cela vous permettra de prendre du recul par rapport à l’existant, d’être confiant sur la méthodologie que vous souhaitez mettre en place et surtout de vérifier son adéquation à votre contexte projet.

Et même en étant formé, n’oubliez pas les fondamentaux d’un projet : fixation des objectifs du projet, gestion des risques, gestion de la communication, suivi budgétaire et du périmètre. Quel que soit la méthodologie ou les outils utilisés, tous ces aspects doivent être adressés pour garantir la maitrise du projet.

#3 – Connaitre les parties prenantes du projet

Une fois que vous avez pris connaissance du contexte et que vous avez acquis une bonne connaissance des différentes méthodologies projet, vous êtes convaincus : c’est la méthode agile qu’il faut utiliser sur ce beau projet à venir !

Sauf que la durée estimée du projet est de 6 mois, que votre équipe n’a jamais travaillé avec cette méthodologie et que les métiers ouvrent de grands yeux quand vous leur parlez de « User Stories » ; surtout ils ne sont pas du tout disponibles sur toute la durée du projet. Arrêtez tout !

Une méthodologie doit s’adapter non seulement au contexte du projet mais également aux parties prenantes du projet.

Si vous avez de la marge de manœuvre sur le planning, vous pourrez décider de prendre plus de temps pour planifier des formations, négocier les disponibilités. Dans le cas contraire, abandonnez la méthode agile de vos rêves pour revenir sur une méthode plus classique de type cycle en V ou hybride.

#4 – Savoir innover

Pour finir, ne soyez pas rigide sur une méthode. Ne perdez pas de vue l’objectif initial du projet, les fondamentaux du management de projet, le niveau de maturité des parties prenantes, vos propres connaissances et enfin vos marges de manœuvre.

Combiner à une approche Lean, vous serez en mesure de changer certains aspects de la méthodologie choisie initialement, d’innover et de rendre votre méthode de plus en plus efficace et efficiente au fil du temps projet.

Ophélie GOMES

43 ans, mariée 2 enfants de 16 et 13 ans

Ophélie Gomes

Je suis issue d’une filière technologique : diplômée MIAGe à Lyon en 2002. J’ai commencé ma carrière dans une Entreprise de Services du Numérique (ESN) en tant que développeuse Java en mars 2003 tout en continuant en parallèle une thèse en Business Intelligence que j’ai soutenue en 2010.

J’ai occupé différentes fonctions dans l’IT pendant 10 ans chez Capgemini à Grenoble: Business Analyst, Chef de projet run, chef de projet build dans différentes technologies (java, SAP, Documentum, .Net) et différents secteurs (Services privés, Énergies, secteur public, industrie). J’ai ensuite rejoint un éditeur de logiciel où j’ai occupé mon premier poste de manager. En 2017, je retourne chez Capgemini pour participer à la mise en place des processus de delivery pour toute l’entité au niveau France. En plus de mon rôle de manager, je suis coach agile certifiée SPC – Implementing SAFE.

Depuis 6 mois j’occupe le poste de Head of Delivery & digital chez Europ Assistance France

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Précédent billet d’Ophélie: Êtes-vous fait pour le rôle de manager / chef de projet ? Comment présenter votre rôle différemment ?

Le modèle de mise à l’échelle de Spotify : Spotify ne l’utilise pas, vous ne devriez pas non plus !

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

Vous ne pouvez pas copier-coller l’approche de quelqu’un d’autre en matière d’agilité. Leur approche s’est développée à partir de leur peuple et de leur culture.

The Spotify Model of Scaling – Spotify Doesn’t Use It, Neither Should You par Mark Levison

https ://agilepainrelief.com/blog/the-spotify-model-of-scaling-spotify-doesn’t-use-it-neither-should-you.html (en anglais seulement)

Le « modèle Spotify » n’est probablement pas un modèle et n’est absolument pas ce qui est actuellement pratiqué chez Spotify aujourd’hui. (Certains suggèrent que cela n’a jamais été le cas.)

L’image ci-dessous a été rendue célèbre dans des vidéos d’Henrik Kniberg, où il explique comment le travail était organisé en escouades, tribus et guildes (Squads, Tribes, and Guilds).

Spotify Engineering Culture – Part 1&2 (aka the « Spotify Model »)

Beaucoup de gens voient la structure et essaient de l’imiter dans leur organisation. Pire encore, beaucoup tentent d’obtenir le bénéfice supposé en renommant les structures organisationnelles existantes avec ces nouvelles étiquettes.

En conséquence, la plupart des tentatives  du modèle Spotify sont en fait du Cargo Cult.

Figure 1 – La célèbre image de Henrik Kniberg & Anders Ivarsson dans https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

La structure n’est pas le plus important. La culture dévorera n’importe quelle structure. (Indice : c’est pourquoi le fait de renommer vos équipes en « Escouades » et d’appeler les responsables de service « Chefs de chapitre » n’a jamais aidé.)

Cela dit, si je ne résume pas ici ces étiquettes, vous irez les chercher ailleurs de toute façon, alors c’est parti…

  • Squad : En fait une équipe Scrum avec un nouveau nom. Lorsque l’article original a été publié, chaque escouade possédait une petite partie de l’interface utilisateur ou du comportement du système. Ils possèdent cette partie du produit et peuvent mener des expériences sans dépendre d’autres équipes. Les personnes qui sont familières avec LeSS remarqueront que les escouades sont des équipes fonctionnelles.
  • Tribu : Un ensemble d’escouades qui travaillent dans un domaine connexe. Elle est conçue pour avoir une collaboration optimale entre les escouades avec peu de dépendances avec d’autres tribus. Les tribus sont limitées à 100 personnes afin de minimiser « les règles restrictives, la bureaucratie, la politique, les couches supplémentaires de management et autres gaspillages ».
  • Chapitre : Personnes d’un même domaine de compétence au sein d’une tribu, par exemple les testeurs ou les développeurs qui travaillent avec une certaine technologie. Les chapitres se réunissent régulièrement pour discuter des problèmes et partager les apprentissages dans leur domaine.
  • Guilde : une communauté d’intérêts plus large. Les guildes incluent généralement les chapitres, mais toute personne intéressée par un sujet peut rejoindre une guilde. Lorsque l’article original a été écrit, ils avaient des guildes pour la technologie Web et la guilde des coachs agiles.

Structurellement, il s’agit d’une façon parfaitement saine d’organiser les équipes. L’obstacle est si vous changez les étiquettes sans les changements culturel et de mentalité qui vont avec. Et la formation seule ne réalisera pas ce changement.

S’agit-il simplement d’un autre modèle matriciel, le genre de chose que les coachs agiles déconstruisent depuis des années ?

Oui, c’est le cas, mais c’est un autre type de matrice. Dans d’autres modèles matriciels, la relation horizontale est la relation principale. Par exemple, un développeur relève d’un responsable de développement ; un testeur à un manager des tests, etc. L’affiliation avec l’équipe ou les équipes avec lesquelles ils travaillent est plus lâche.

Spotify a inversé cette tendance. La relation principale est celle de membre d’une équipe stable et interfonctionnelle.

Le responsable du chapitre (ce n’est pas un bon choix de nom) est un coach, qui se concentre sur les compétences et l’excellence technique. En théorie, c’est génial. Dans la pratique, c’est le premier endroit où de nombreuses organisations commettent une erreur. Les responsables de votre chapitre ne devraient pas être d’anciens managers qui ont obtenu un nouveau titre de poste.

Il y a une myriade d’autres erreurs que les gens commettent en lisant un livre blanc et en regardant une vidéo. La liste serait plus longue que l’article original. Ce problème est si populaire qu’il a même son propre mème :

Vous ne pouvez pas copier-coller l’approche de quelqu’un d’autre en matière d’agilité. Leur approche s’est développée à partir de leur peuple et de leur culture. De plus, toutes les tentatives de documentation d’une culture sont des simplifications qui manquent des détails importants.

Au lieu de copier  le modèle Spotify ou le modèle d’une autre entreprise au hasard (par exemple, FitBit, John Deere), développez votre propre modèle Agile. C’est la seule voie à long terme vers le succès.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Concentrez-vous sur les choses que Spotify avait dans son moteur

  • Apporter de la valeur. Toutes les améliorations apportées au système doivent être testées en se posant les questions suivantes : Cette amélioration ou cette expérience nous aide-t-elle à créer de la valeur ?
  • Amener de la valeur au produit. Ceci nécessite de mener des expériences et de voir ce qui fonctionne pour les utilisateurs finaux réels.
  • Autonomie plutôt qu’ordres et contrôle. Sans autonomie, il n’y a pas d’apprentissage, d’amélioration, d’innovation ni de capacité à s’adapter à des circonstances changeantes.
  • Alignement. Au lieu de dire aux gens ce qu’ils doivent faire pour les fonctionnalités et l’architecture du produit, concentrez-vous sur le fait d’amener les équipes à s’aligner sur un objectif produit commun. Envisagez d’avoir plusieurs équipes travaillant à partir d’un objectif produit commun.
  • Équipes interfonctionnelles orientées produit (alias Feature Teams). Plutôt que de constituer des équipes en fonction de leur souche fonctionnelle (par exemple, base de données, logique métier, interface utilisateur).
  • Une culture d’ingénierie qui met l’accent sur la qualité et la simplicité. Créez un  pipeline de livraison continue qui permet aux équipes de créer de la valeur indépendamment les unes des autres. Au lieu d’un pipeline qui nécessite d’attendre que l’ équipe DevOps le déploie pour eux. Astuce : Dans de nombreuses organisations, DevOps est une équipe en aval de l’équipe de développement de fonctionnalité, qui déploie l’application. Il s’agit d’un anti-modèle bien connu.
  • Sécurité psychologique. L’article original l’appelait « expérimentation conviviale ». (experiment friendly). L’élément clé de l’expérimentation conviviale est la création d’un environnement où nous pouvons reconnaître la valeur de la prise de risques et l’apprentissage du processus. Le nom à la mode pour cela est « sécurité psychologique ».
  • L’amélioration continue en tant que caractéristique du système. Les équipes n’ont jamais fini de s’améliorer. Nous devons créer des cultures qui favorisent cet état d’esprit.
  • Le moral. Appelé à l’origine bonheur, il s’agit de la volonté et de la persévérance des membres de l’équipe à travailler pour le bien commun.
  • Améliorer le flux du travail dans le système. Les outils comprennent la limitation  du travail en cours (ou WIP),  le développement des compétences croisées et l’élimination des goulots d’étranglement. Vous pouvez mesurer le succès de cette opération à l’aide  du temps de cycle et du délai d’exécution.

Avez-vous trouvé l’Agile que vous cherchez ?

Le par mopertodans agileLaisser un commentaire

« I Still Haven’t Found The Agile I’m Looking For » de Chad Beier

Et vous, l’avez-vous trouvé ?

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Code de déontologie pour le coaching agile par Agile Alliance

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

On s’attend à ce que les personnes pratiquant le coaching agile agissent de manière éthique, mais qu’est-ce que cela signifie en pratique ?

Code of Ethical Conduct for Agile Coaching by Agile Alliance

https://www.agilealliance.org/agilecoachingethics/

L’intention de ce Code de conduite éthique (Code) est de fournir des conseils aux personnes qui entreprennent des activités de coaching agile, afin de guider les types de comportements, de conseils et d’approches attendus d’elles.

Le coaching agile est une pratique évolutive englobant de nombreuses disciplines, y compris le coaching individuel, d’équipe et systémique, la facilitation, l’enseignement et le mentorat, toutes appliquées avec un parti pris ouvert et délibéré vers l’utilisation d’approches agiles pour aider à répondre aux besoins du client.

La complexité du coaching agile signifie que vous rencontrerez inévitablement des situations difficiles. Ce Code vous aidera à prendre ces décisions difficiles et vous pourrez le fournir en support de vos décisions avec vos clients.

Toute personne qui adhère au Code s’efforce d’agir de manière éthique, même si cela implique de prendre des décisions difficiles. Ils agissent courageusement, même s’il y a un impact négatif sur le plan personnel.

Les signataires de ce Code sont multiculturels, multigénérationnels et affiliés à de nombreux groupes différents. Nous croyons que la puissance de ce mouvement est amplifiée lorsque nous mettons de côté les différences et que nous nous aidons les uns les autres à nous élever dans la poursuite d’une meilleure voie. Nous nous engageons à nous soutenir mutuellement dans les décisions difficiles et les conversations courageuses.

Le Code

En tant que personne qui pratique le coaching agile de manière éthique, je m’engage à ce qui suit.

#1 – Protéger la confidentialité, la propriété intellectuelle et la sécurité de l’information

  • Je protégerai les renseignements qui m’ont été communiqués et je ne les divulguerai que pour des raisons juridiques ou lorsque j’aurai un accord clair avec mon client et les parties prenantes.
  • J’attribuerai les idées des autres de manière appropriée et j’éviterai de donner l’impression qu’elles sont les miennes.

#2 – Agir selon mes capacités

  • Je ferai preuve d’ouverture et de transparence quant à mes compétences, mon expérience et mes qualifications.
  • Je serai clair avec mon client et les parties prenantes s’ils font une demande au-delà de mes capacités.
  • Je serai ouvert avec le client si je pense qu’il a besoin d’une autre forme d’aide professionnelle.

#3 – Pratiquer l’introspection et le développement professionnel continu

  • Je m’engagerai avec un groupe de pairs ou un mentor pour explorer les défis éthiques et autres dans mon travail de coaching agile.
  • Je chercherai à améliorer ma conscience de soi et mon efficacité par l’introspection et le développement professionnel.

#4 – Gérer les conflits d’intérêts

  • Je ferai preuve de transparence quant à tout conflit d’intérêts potentiel avec toutes les personnes qui pourraient être touchées.
  • J’éviterai consciemment les situations où je m’enrichis au détriment du client et des parties prenantes afin de conserver un jugement professionnel et une pensée objective.
  • Je résoudrai les conflits d’intérêts en travaillant avec le client et les parties prenantes, je demanderai de l’aide au besoin et je suspendrai ou mettrai fin à la relation si nécessaire.

#5 – Garantir la valeur de la relation

  • Je vérifierai auprès de mon client et des parties prenantes pour m’assurer que la relation est de valeur et qu’elle ne se prolonge que d’un commun accord.
  • Je ferai preuve de transparence si mon client est dépendant de mes services et je m’efforcerai de lui permettre d’atteindre sa propre agilité.
  • Je serai ouvert avec le client si je crois que la valeur de la relation diminue.

#6 – Défendre la responsabilité sociale, la diversité et l’inclusion

  • Je chercherai des occasions d’apporter des voix différentes à la conversation.
  • Je prendrai des mesures pour décourager et éliminer la discrimination sous toutes ses formes.
  • Je m’efforcerai de laisser l’entreprise meilleure que je ne l’ai trouvée, par mon action ou mon inaction.

#7 – Se mettre d’accord sur les limites

  • Je veillerai à ce que nous ayons une portée convenue, même si elle évolue.
  • Je travaillerai avec le client pour comprendre ses besoins et éviter d’imposer des solutions basées sur mes préférences et mes désirs personnels.
  • Je contesterai ouvertement lorsque mon client poursuit des objectifs en contradiction avec les valeurs et les principes du Manifeste Agile.

#8 – Gérer les différences de statut et de pouvoir

  • Je n’utiliserai pas mon autorité, mon pouvoir ou mon influence pour obtenir un gain personnel ou saper les objectifs de mon client.
  • Je créerai une prise de conscience lorsque le pouvoir, les privilèges et le rang entravent les objectifs de mon client ou ma capacité à le servir efficacement.

#9 – Faire preuve de responsabilité envers la profession

  • J’inviterai les autres personnes qui pratiquent le coaching agile à adopter les normes professionnelles et ce code de déontologie.
  • J’améliorerai et élèverai la réputation de la profession de coach agile.
  • J’encouragerai un dialogue et une réflexion sains lorsque je rencontrerai un comportement contraire à l’éthique chez les autres.

Remerciements

Des codes de déontologie existent déjà pour le coaching, la facilitation et d’autres disciplines incluses dans la pratique du coaching agile.  En préparant ce code, nous nous sommes inspirés de ces codes existants et du travail de nombreuses personnes qui ont contribué aux conversations sur l’éthique dans le coaching agile au fil des ans. Ce code de déontologie est étayé par des explications supplémentaires dans les scénarios d’éthique connexes.

Vous trouverez plus d’informations sur le site Web de l’Alliance Agile : https://www.agilealliance.org/resources/initiatives/agile-coaching-ethics/

Version 2.0 Mars 2022 – Ce matériel est publié sous la licence Creative Commons, Attribution, Share Alike 4.0

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

« La culture de l’entreprise est un facteur sous-estimé dans le monde du projet » par Yanis Ioualitene

Le par mopertodans agile, experience sharingLaisser un commentaire

Dans le domaine des projets, la méthodologie de gestion de projet, la gestion des parties prenantes et la planification occupent une place cruciale, et elles ont un impact très significatif sur le résultat final du projet, qu’il soit couronné de succès ou qu’il échoue.

Toutefois, deux aspects essentiels sont souvent sous-estimés : la culture et la structure organisationnelle de l’entreprise où le projet sera mené.

Cet article examine comment la culture d’entreprise influe de manière significative sur le cours d’un projet.

Des structures bureaucratiques héritées des années 60s

Revenons en arrière, dans les années 60, lorsque les entreprises étaient ancrées dans l’ère du Fordisme, caractérisée par une forte emphase sur les structures bureaucratiques, la hiérarchie et la division du travail.

À cette époque, la gestion de projet n’était pas aussi avancée qu’aujourd’hui, ce qui est d’ailleurs corroboré par la fondation du Project Management Institute (PMI) à la fin de cette décennie, en 1969. Dans les entreprises largement bureaucratiques de cette période, l’accent était principalement mis soit sur la compétence technique des employés, soit sur la planification, en raison de la proximité temporelle de la Seconde Guerre mondiale.

Henry Gantt

Par exemple, à cette époque, le chef de projet était embauché principalement pour ses compétences dans la création de diagrammes de GANTT, de PERT, et pour sa capacité à donner des ordres. Son style de Management était principalement basé sur l’autorité directe, et il était souvent perçu comme un administrateur de ressources. Cette approche prévalait jusqu’aux années 1990, mais elle a progressivement diminué avec l’émergence de nouvelles cultures d’entreprise telles que l’Agile, le Lean, et les concepts d’Entreprise Libérée.

Comme vous avez pu le constater, lorsque l’on déploie un projet au sein d’une entreprise caractérisée par une culture directive, hiérarchique, et un fonctionnement en silos, le projet suivra également ce schéma, et le chef de projet sera recruté principalement pour ses compétences techniques, plutôt que ses compétences relationnelles qui ne sont pas prioritaires dans ce type d’entreprise. Il est donc fréquent que de nombreuses personnes pensent qu’un projet sera couronné de succès au sein de cette organisation.

Cependant, il est essentiel de se demander comment un projet peut réussir lorsque les différents services ne communiquent pas entre eux, qu’il n’y a pas de démarche d’amélioration continue en place, et que le leadership est moins valorisé que la maîtrise d’outils tels que MS Project ou JIRA.

Prenons un exemple concret : Avez-vous déjà eu l’occasion de travailler avec le cadre de travail Scrum au sein d’une entreprise traditionnelle ?

Vous seriez peut-être surpris de constater que le Scrum Master doit parfois surveiller de près les activités des Développeurs lors des Daily Scrum, ou encore que le sponsor considère le Scrum Master comme un chef de projet. En effet, étant donné que Scrum fournit un cadre Agile, son application au sein d’une entreprise caractérisée par une bureaucratie bien établie peut s’avérer complexe. Les philosophies et dogmes des entreprises traditionnelles et Agile sont fondamentalement différentes, et cela peut avoir un impact significatif sur la gestion des projets, comme c’est le cas avec Scrum.

Quels éléments de la culture d’entreprise ont une incidence sur le projet ?

La figure ci-dessous évoque les facteurs qui influencent un programme composé de projets.

Environnement du projet

Vous voyez, cela ne repose pas uniquement sur la méthodologie de gestion de projet, mais sur plusieurs facteurs qui relèvent de la culture de l’entreprise. Permettez-moi d’en lister quelques-uns.

1. L’organigramme du projet

Dans une entreprise traditionnelle, la structure est généralement pyramidale. Cependant, selon Mintzberg et d’autres experts en théorie des organisations, un projet doit adopter une structure en réseau dédié ou circulaire, plutôt que pyramidale.

Organigramme du projet

Supposons que vous travailliez au sein d’une grande entreprise bureaucratique ou traditionnelle et qu’on vous charge, en tant que chef de projet, d’implémenter un projet en utilisant une approche Agile. Selon une étude menée par la Scrum Alliance, il en ressort que 80 % à 90 % des équipes agiles, qui évoluent au sein d’une structure circulaire, éprouvent des tensions en raison de l’incohérence et de la difficulté à concilier les structures pyramidales et circulaires au sein d’une organisation bureaucratique.

D’ailleurs la figure ci-dessous, illustre la complexité d’allier deux organigrammes différents :

Réseau Agile – Source Frank Taillandier : Expliquer l’Agile

2. Le mode de management du chef de projet

Alors qu’autrefois, on valorisait le fait que le chef de projet soit un expert des outils et des méthodes, aujourd’hui, avec l’émergence d’entreprises axées sur le Lean, l’Agilité et l’innovation, on attend du chef de projet qu’il soit un véritable leader. Cette évolution a même conduit à inverser l’équation. Autrefois, le savoir-faire était essentiel, tandis qu’aujourd’hui au sein de ce type d’entreprises, c’est le savoir-être qui prend le dessus. Il est intéressant de noter que des organisations professionnelles telles que PMI® ou Prince2® accordent désormais une grande importance à cet aspect.

Voici l’évolution du chef de projet en fonction de la culture d’entreprise

Évolution du chef de projet en fonction de la culture d’entreprise

Ce diagramme que j’ai élaboré illustre que si vous travaillez dans une entreprise bureaucratique, on accorde de l’importance à vos compétences techniques. D’ailleurs, vous pouvez le constater lors de vos entretiens d’embauche.

livre sur Amazon

Néanmoins, si vous êtes chef de projet dans une entreprise qui se revendique « Lean« , alors on recherche un chef de projet pour piloter des projets où il y aura de la résistance aux changements, et où vous devrez maîtriser à la fois les outils et les méthodes Lean et de gestion de projet. Ayant commencé ma carrière en tant que Chef de projet Lean, je peux vous dire que ces entreprises sont très exigeantes et attendent que le chef de projet soit à la fois rigoureux et un leader.

Enfin, dans les entreprises Agiles, ce qui est demandé, c’est l’écoute active, l’empathie, et simplement aider les parties prenantes. Toutefois, le savoir-faire reste important, mais ce type d’entreprise cherche à recruter des chefs de projet Agile qui adhèrent d’abord à la vision et à la culture de l’entreprise avant même de considérer les compétences.

3. La maturité de l’entreprise

Travailler dans son coin sur un découpage des tâches et livrables.

Supposons qu’un chef de projet souhaite mettre en œuvre une méthodologie PMI ou PRINCE2 au sein d’une entreprise caractérisée par une bureaucratie bien établie. Cette démarche est particulièrement difficile, et il se voit souvent contraint de travailler

en isolation pour élaborer un diagramme de Gantt dans MS Project et générer des documents imprimés pour assurer le suivi du projet. Il peut également rencontrer des obstacles lors des comités de pilotage (COPIL), car certaines parties prenantes clés pourraient être absentes en raison du manque de maturité de l’entreprise dans ce domaine.

En fin de compte, cette approche peut convenir pour des projets simples, mais elle s’avère inadaptée pour des projets complexes. Cela vient du fait que l’entreprise accorde de l’importance aux opérations et moins ou pas aux projets.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

4. Le chef de Projet et ses Parties prenantes

Votre entreprise fonctionne-t-elle en « silos » ? (lisez ce billet)

Si vous évoluez au sein d’une entreprise où tous les services sont compartimentés, il ne devrait pas être surprenant que le chef de projet rencontre des défis similaires au sein de son équipe.

De nombreuses entreprises traditionnelles ont tenté de remédier à cela en recrutant de nouveaux chefs de projet ayant une expérience significative dans des projets Agile ou Lean.

Malheureusement, ce qui se produit souvent, c’est que le nouveau chef de projet tente initialement de créer un climat de confiance, de communiquer avec diverses parties prenantes et de négocier avec les responsables fonctionnels de ces parties prenantes. Hélas, après un certain temps, ce nouveau chef de projet finit par se conformer à la culture de l’entreprise et cesse d’innover, car cela n’est pas encouragé.

En revanche, dans une entreprise innovante où une culture d’amélioration continue est déjà en place, le chef de projet aura des relations plus harmonieuses avec ses parties prenantes. Dans un tel environnement, l’efficacité sera accrue, car chacun sera déjà conscient et engagé dans cette démarche.

Comment mettre en œuvre un projet de manière efficiente au sein d’une entreprise traditionnelle ?

Imaginons que vous venez d’être embauché dans ce type d’entreprise, et on vous a confié un projet d’envergure. Par où et par quoi commencer ?

Tout d’abord, ne soyez pas focalisé seulement sur le projet, mais analysez la culture de votre entreprise (rituels, leaders, etc.).

Par exemple, observez si les parties prenantes du projet ont l’habitude de communiquer entre elles ou non. Vérifiez si le comité de direction encourage les employés à prendre des initiatives.

De même, renseignez-vous sur l’utilisation d’une méthodologie de gestion de projet au sein de l’entreprise, qu’il s’agisse du PMI, de Prince 2 ou même de Scrum (bien que ce dernier ne soit pas strictement une méthodologie de gestion de projet).

Ensuite, prenez le temps de discuter de vos préoccupations avec votre sponsor et soumettez des propositions.

Salle Obeya

Par exemple, si les employés de l’entreprise ne communiquent pas entre eux, envisagez de créer une salle Obeya avec la participation des parties prenantes et établissez un rituel où chacun s’engage à se réunir à une heure précise dans un lieu déterminé.

Ensuite, en plus de votre rôle de chef de projet, adoptez également celui de formateur. Vous devrez vous impliquer dans la conduite du changement, dispenser des formations en gestion de projet, et envisager la mise en place de séminaires ou de team building afin de renforcer la confiance et de favoriser les liens informels.

Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Pour terminer, assurez-vous de toujours communiquer de manière transparente. Lorsque vous remontez des informations lors des comités avec le sponsor et la direction, assurez-vous de faire un retour transparent à vos parties prenantes. Appliquez le bon sens en toutes circonstances, et vous gagnerez la confiance de vos parties prenantes.

Cas extrême : Envisageons un scénario où toutes les parties prenantes s’opposent aux changements.

Dans de telles circonstances, vous pourriez envisager de faire appel à au moins deux ou trois consultants spécialisés en gestion de projet, afin de ne pas vous retrouver seul(e) et élever le niveau de compétence en gestion de projet. Cela peut contribuer à instaurer un climat de confiance. Bien que cette approche ne fonctionne pas toujours, elle a fait ses preuves en tant que stratégie efficace.

En fin de compte, la méthodologie de gestion de projet, la gestion des parties prenantes et la planification… sont toutes influencées par la culture de l’entreprise.

Si, par le passé, il était courant d’attendre d’un chef de projet qu’il soit un expert sans nécessairement être un leader, c’était dans un contexte qui prévalait à cette époque.

Cependant, aujourd’hui, nous sommes en pleine transition, avec un monde en constante évolution, et il est de plus en plus important que, en plus de votre rôle de chef de projet, vous incarniez également le rôle de leader et d’accompagnateur du changement.

Vous devrez acquérir certaines compétences pour aider les organisations à passer d’une culture d’entreprise traditionnelle à une culture innovante.

N’oublions pas que l’objectif ultime du projet est d’apporter de la valeur ajoutée à l’entreprise, et toute transformation passe par la mise en œuvre de programmes et de projets.

Yanis IOUALITENE est chef de projet Lean.

Yanis Ioualitene

Il est diplômé de Skema Business School en management de Projets & Programmes.

Il est certifié PMP ®, Prince2, ITIL 4, PSM I, Agile PM DSDM et Green Belt Lean.

Yanis a contribué au groupe de travail sur le PMBoK 7 organisé par le PMI Francophone.

Découvrez ou relisez son précédent billet sur ce blog.

« A la différence, de l’adhocratie, où votre pouvoir est limité. Vous serez tel le Scrum Master qui est présent pour guider son équipe (mais sans la diriger), tout en sachant canaliser et centraliser les relations informelles. »

Vous êtes Scrum Master ou Coach Agile ? Participez à cette enquête de salaires pour mieux négocier le vôtre !

Le par mopertodans agileLaisser un commentaire

Scrum Master Salary Report 2024 : Un sondage anonyme de la communauté pour la communauté

https://age-of-product.com/scrum-master-salary-report-2024/

Le but de ce rapport anonyme sur les salaires des Scrum Master  est de créer un benchmark clair, basé sur des données réelles, qui permet à tous les membres de la communauté Agile de comprendre si leur rémunération est bien positionnée. Le rapport couvre les Scrum Masters et les Coachs Agile, employés comme indépendants.

L’objectif est d’avoir au moins 1 000 réponses d’ici la fin novembre 2023 pour créer le rapport à temps pour janvier 2024. Bien entendu, le rapport sera disponible gratuitement.

Vous pouvez télécharger gratuitement le rapport de salaire Scrum Master 2023

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Vos clients détestent les MVPs (Minimum Viable Product), produisez plutôt un SLC (Simple, Lovable and Complete product).

Le par mopertodans agileLaisser un commentaire

J’ai trouvé ce billet très vrai par rapport à mon vécu personnel sur des projets Agiles qui se sont tellement concentrés sur produire un « Minimum » MVP que leurs premiers livrables n’étaient que très rarement utilisables / « Viables » en situation réelle.

Extraits du billet de  Jason Cohen: Your customers hate MVPs. Make a SLC instead.

Vos clients détestent les MVPs. Faites plutôt un SLC.

[…]

Les équipes produit ont répété le mantra du MVP (Minimum Viable Product) depuis toute une décennie sans réévaluer si c’est réellement la bonne façon de maximiser l’apprentissage tout en satisfaisant le client.

Eh bien, ce n’est pas le meilleur système !

Cette approche MVP est égoïste et fait mal aux clients.

[…]

La motivation qui dirige le MVP est toujours valable :

  1. Construisez quelque chose de petit, parce que les petites choses sont rapides et peu coûteuses à tester.
  2. Mettez-la rapidement sur le marché, car le véritable apprentissage ne se produit que lorsque de vrais clients utilisent un vrai produit.
  3. Jetez-la ou changez complètement de direction s’il s’agit d’un échec, ou investissez davantage s’il s’agit d’un semis avec du potentiel.

Les MVPs sont parfaits pour les startups et les équipes produit car ils maximisent le plus rapidement possible ce que l’on appelle « l’apprentissage validé ». Et, bien que  les entretiens avec les clients soient utiles, vous apprenez de nouvelles choses lorsqu’un client utilise réellement le produit. Mais les MVPs sont un acte égoïste.

Le problème est que les clients détestent les MVPs.

Les startups sont encouragées par le célèbre Reid Hoffman à « lancer le produit assez tôt pour que vous soyez embarrassé par votre version V1.0. ». Mais aucun client ne veut utiliser un produit inachevé qui embarrasse ses créateurs. Les clients veulent des produits géniaux qu’ils peuvent utiliser immédiatement.

Les MVPs sont trop M et rarement V.

Les clients le voient et détestent cela. C’est peut-être génial pour l’équipe produit, mais c’est mauvais pour les clients. Et en fin de compte, ce qui est mauvais pour les clients est mauvais pour l’entreprise.

[…]

Soyez « Slick » (habile et astucieux) !

À partir de ce raisonnement, il y a des années, j’ai nommé ce que je pense être la bonne alternative au MVP : Simple, Lovable/Aimable et Complet (SLC). Nous le prononçons « Slick ». Comme dans : « Quelle est la version (habile et astucieuse) ‘Slick’ de votre idée ? ».

Un autre avantage de SLC devient évident lorsque vous considérez la prochaine version du produit.

Un produit SLC ne nécessite pas de développement continu pour ajouter de la valeur. Il est possible que la V1 évolue pendant des années en une V4, mais vous avez également la possibilité de ne pas investir davantage dans le produit, tout en ajoutant de la valeur. Un MVP qui ne recevra jamais d’investissement supplémentaire n’est qu’un mauvais produit. Un SLC qui n’obtient jamais d’investissement supplémentaire est un bon produit, même s’il est modeste.

Henrik Kniberg, un coach agile et produit de longue date pour Spotify, a créé l’illustration populaire ci-dessus pour donner un exemple à suivre aux équipes produit lorsqu’elles envisagent de livrer un produit minimum viable, ou MVP, à leurs clients.

Une planche à roulettes est un produit SLC. C’est plus rapide que la marche, c’est simple, beaucoup de gens l’adorent, et c’est un produit complet qui n’a pas besoin d’ajouts pour être amusant ou pratique. En même temps, vous pouvez faire évoluer le skateboard en ajoutant une potence et un guidon, pour créer une trottinette (seulement un peu moins simple, et certainement appréciable et complet). Ensuite, vous pouvez faire grandir les roues, ajouter un siège et des pédales, et vous avez un vélo. Encore une fois, moins simple, mais vous avez maintenant un produit avec des avantages massifs de vitesse, de distance et d’efficacité énergétique…

[…]

Avec SLC, les résultats sont meilleurs et vos options pour les prochaines étapes sont meilleures.

Si le SLC échoue, ce n’est pas grave : C’est une expérience ratée. Les SLCs et les MVPs atteindront parfois ce résultat parce que le but est d’ expérimenter. Mais si un SLC réussit, vous avez déjà apporté une valeur réelle aux clients et vous avez plusieurs futurs possibles à votre disposition, dont aucun n’est urgent. Vous pourriez construire une V2, et parce que vous générez déjà de la valeur, vous avez plus de temps pour décider à quoi elle devrait ressembler. Vous pouvez même interroger les clients existants pour déterminer exactement ce que la V2 devrait impliquer, au lieu d’un groupe d’alpha-testeurs qui veulent juste savoir « Quand allez-vous réparer cette chose qui ne fonctionne pas ? »

Ou, vous pouvez décider de ne plus travailler dessus. Tous les produits ne doivent pas nécessairement devenir complexes. Tous les produits n’ont pas besoin de nouvelles versions majeures tous les deux trimestres.

Certaines choses peuvent juste rester Simples, aimables/Lovable et Complètes.

Demandez à vos clients. Ils seront d’accord.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

La folie coûteuse d’un arriéré de produit surdimensionné

Le par mopertodans agile, best practicesLaisser un commentaire

Certains propriétaires de produits (Product Owners) pensent qu’un arriéré de produit (Product Backlog) complet est le meilleur moyen d’atteindre l’objectif du produit et d’être en même temps totalement transparent .

The Expensive Folly of the Oversized Product Backlog par Stefan Wolpers

https://age-of-product.com/oversized-product-backlog/

Les coûts d’un arriéré de produit surdimensionné

Apprenez-en davantage sur l’impact négatif d’un Product Backlog surdimensionné sur l’innovation, la capacité de votre équipe Scrum à créer de la valeur et vos relations avec les parties prenantes.

Les effets secondaires coûteux d’un arriéré de produit surdimensionné

Certains Product Owners estiment en effet que tenir un Product Backlog surdimensionné est une stratégie optimale pour atteindre l’objectif du produit et maintenir une transparence totale, garantissant qu’aucune idée de valeur potentielle ne soit perdue. Cependant, construire à l’avance une liste complète de tous les éléments de travail imaginables n’est pas seulement une perte de temps pour une équipe Scrum, un Product Backlog surdimensionné est une erreur coûteuse à long terme.

Voici 8 effets secondaires critiques de cet anti-pattern (contre-modèle ou fausse bonne idée) du Product Backlog.

#1 – Encourage le gaspillage

Un Product Backlog surdimensionné favorise le gaspillage en investissant du temps dans des éléments qui ne seront peut-être jamais développés en raison de la découverte continue de tâches plus précieuses. C’est une violation claire des principes du Manifeste Agile. En particulier, la simplicité – l’art de maximiser le travail non fait – qui est essentielle.

#2 – Augmente les risques du piège des coûts irrécupérables

Les « sunk costs » sont des dépenses non récupérables quoi que l’on fasse ou décide maintenant. Relisez ce billet.

Un important Product Backlog peut favoriser le syndrome des coûts irrécupérables. Les équipes peuvent continuer à affiner et à prioriser des éléments parce qu’elles y ont déjà investi du temps plutôt que parce qu’ils ajoutent une valeur significative. Ce comportement contredit le principe d’amélioration continue et d’adaptation du Manifeste Agile.

#3 – Conduit à la paralysie d’analyse

Un énorme Product Backlog peut provoquer ce que l’on appelle la paralysie d’analyse, où le volume d’items devient écrasant, conduisant à l’indécision et aux retards. L’équipe peut passer trop de temps à évaluer, hiérarchiser et redéfinir les priorités, ce qui nuit à sa capacité à se concentrer sur le développement réel du produit. Cet excès de choix ralentit souvent les processus de prise de décision, ce qui rend difficile pour l’équipe de déterminer par où commencer ou sur quoi se concentrer ensuite. En fin de compte, cela ralentit l’ensemble du projet, détournant l’énergie de la création de valeur pour le client vers la gestion du Product Backlog lui-même.

#4 – Nuit à l’engagement des parties prenantes

Un Product Backlog gonflé présente un défi important en matière de communication efficace. Le grand nombre d’items peut rendre difficile pour les intervenants de comprendre le plan, les progrès et les priorités, ce qui peut entraîner un décalage dans les attentes. Les intervenants peuvent avoir du mal à trouver leurs intérêts spécifiques dans la longue liste, ce qui les rend confus et peut causer un sentiment de détachement.

#5 – Produit un effet d’éviction

Un Product Backlog complet et surdimensionné peut décourager sans le vouloir les parties prenantes et les membres de l’équipe de faire part de leurs réflexions et de leurs idées. L’exhaustivité perçue du Product Backlog pourrait donner l’impression qu’il n’y a pas de place ni de besoins supplémentaires à ajouter, ce qui pourrait faire perdre des idées précieuses.

#6 – Inhibe l’innovation

Un énorme Product Backlog peut involontairement étouffer l’énergie créative au sein de l’équipe Scrum. La longue liste de tâches peut créer une culture de « cocher les cases » où l’équipe se concentre davantage sur compléter des tâches plutôt que sur explorer et innover. L’équipe peut se sentir contrainte, percevant qu’il n’y a pas de place pour de nouvelles idées, ce qui peut limiter leurs compétences créatives en résolution de problèmes et les dissuader de trouver des solutions innovantes. Cet état d’esprit contredit la valeur Scrum de « l’ouverture » et le principe Agile d’exploiter le changement pour le bénéfice business du client.

#7 – Donne un faux sentiment de sécurité

Guide téléchargeable gratuitement

Un Product Backlog exhaustif peut donner un faux sentiment de sécurité, une illusion de contrôle. Il peut sembler que l’équipe Scrum a identifié tout le travail nécessaire, réduisant ainsi le besoin perçu de découverte et d’apprentissage. Ce décalage avec le Guide Scrum, qui préconise l’apprentissage itératif et la découverte, peut être nuisible.

#8 – Encourage l’optimisation précoce

Un Product Backlog enflé peut conduire à une optimisation prématurée. L’équipe peut se sentir forcée de concevoir des systèmes ou des flux de travail qui anticipent l’achèvement des futurs éléments du backlog, ce qui entraîne une complexité inutile, contribuant au gaspillage si ces tâches changent ou sont dépriorisées par la suite. Cette approche entre en conflit avec le principe agile de simplicité (l’art de maximiser la quantité de travail non effectué) et la valeur Scrum de focus, car elle encourage l’effort dirigé vers des besoins futurs incertains plutôt que vers les besoins présents les plus précieux.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Comment contrer au mieux les effets d’un Product Backlog surdimensionné

Heureusement, il existe de nombreuses façons d’éviter de créer un Product Backlog surdimensionné dès le départ. Mieux encore, c’est à l’équipe Scrum de les utiliser à bon escient. Voici 8 tactiques pour commencer :

#1 – Adoptez la simplicité

Tenez-vous-en au principe de simplicité du Manifeste Agile, qui implique de maximiser le travail non effectué. Concentrez-vous sur les articles les plus précieux pour offrir la plus grande valeur client et business.

#2 – Limitez les travaux en cours (Work in Progress : WiP)

Limitez le nombre d’éléments dans le Product Backlog à tout moment. La limite WiP peut éviter la surcharge et encourager l’équipe à terminer les objets avant d’en prendre de nouveaux.

#3 – Affinez régulièrement le Product Backlog

Gardez le Product Backlog gérable en organisant régulièrement des sessions d’affinement pour vous assurer que les éléments sont toujours pertinents, précieux et correctement hiérarchisés.

#4 – Affinez juste-à-temps

Évitez de trop affiner les éléments qui ne sont pas imminents pour le développement. Plus un élément est éloigné de la sélection pour un Sprint, moins il devrait être détaillé. L’équipe Scrum ajoute des détails lors des séances de raffinement juste à temps.

#5 – Hiérarchisez et dépriorisez

Acceptez le fait que tous les éléments du Product Backlog ne seront pas implémentés. Établissez régulièrement des priorités et, si nécessaire, supprimez les priorités ou supprimez les éléments du Product Backlog qui ne correspondent plus à l’objectif du produit.

#6 – Responsabilisez les équipes

Encouragez l’auto-organisation au sein de l’équipe Scrum. Donnez-leur les moyens de proposer et de négocier des éléments dans le Product Backlog, renforçant ainsi leur sentiment d’appartenance et d’engagement. Les meilleurs développeurs challengent toujours leurs Product Owners !

#7 – Faites la promotion un dialogue ouvert

Favorisez une culture de dialogue ouvert et de collaboration entre l’équipe Scrum, les parties prenantes et le Product Owner. Encouragez tout le monde à apporter des idées et à remettre en question celles qui existent déjà, en évitant l’effet d’éviction.

#8 – Favorisez l’apprentissage continu et l’adaptation

Adhérez au processus empirique de « transparence, inspection et adaptation » de Scrum. Apprenez de chaque Sprint, adaptez le Product Backlog en fonction des informations, par exemple, de la revue de Sprint (Sprint Review), et soyez ouvert aux changements.

Pour terminer

Le Product Backlog est un outil essentiel dans le développement de produits avec Scrum. Son efficacité est liée à la simplicité, à la limitation du travail en cours, au raffinement régulier, aux détails juste-à-temps, à la priorisation, à l’autonomisation des équipes, au dialogue ouvert et à l’apprentissage continu.

Tous ces principes fonctionnent ensemble pour garder le Product Backlog concentré, exploitable et aligné sur l’objectif du produit, améliorant ainsi la transparence et favorisant une culture de collaboration et d’amélioration continue.

Comment empêchez-vous un nouveau Product Backlog de devenir surdimensionné ?

Comment présenter les user stories à votre équipe ?

Le par mopertodans agile, best practicesLaisser un commentaire

Dans sa série de nouvelles en prévision de la rentrée, Mike Cohn de Mountain Goat Software a abordé un problème fréquent : « Comment présenter des user stories à votre équipe ? »

Astuce #1: Commencez par quelques définitions.

Une user story (ou histoire utilisateur) décrit quelque chose qu’un utilisateur veut. L’histoire suit généralement ce modèle: « En tant que [type d’utilisateur], je [veux, j’ai besoin ou je suis obligé de faire cette chose] afin que [je puisse atteindre cet objectif]. »

Une epic (ou épopée) est une grande user story. Voilà. Rien de plus, rien de moins.

Un thème est une collection d’histoires utilisateurs connectées entre elles. Certaines personnes ont introduit le terme de feature (fonctionnalité) pour désigner une histoire utilisateur suffisamment grande pour être livrée ou peut-être assez grande pour que les utilisateurs la remarquent et soient plus heureux.

Toutes ces définitions ne sont utiles que si elles simplifient la discussion sur le produit que vous développez. Pour en savoir plus sur comment et pourquoi utiliser ces termes (et pourquoi les outils ont ajouté à la confusion), consultez Epics, Features et User Stories.

Astuce #2: Ajoutez le bon niveau de détails au bon moment.

Comme Boucle d’or et les trois ours, nous ne voulons pas d’articles dans l’arriéré de produits avec trop peu ou trop de détails. Nous voulons juste le bon niveau de détails.

Si un Product Owner écrit une user story qui inclut trop peu de détails, les développeurs n’en sauront pas assez lors de la planification du sprint pour comprendre ce qu’il faut construire. Lorsque des détails excessifs sont inclus, le temps et l’argent dépensés à ajouter ces détails inutiles sont gaspillés.

Il est peu probable que le product backlog (l’arriéré de produit) d’une équipe soit parfaitement détaillé dès le départ. Cela signifie que l’équipe devra probablement itérer pour aller vers la bonne quantité de détails.

Je trouve qu’il est beaucoup plus facile pour les membres de l’équipe de trouver le bon équilibre lorsqu’ils commencent avec trop peu de détails. Commencez donc par remplir le modèle d’histoire utilisateur avec le strict minimum de fonctionnalités et de détails du produit, et partez de là.

Astuce #3: Apprenez la méthode SPIDR pour découper les histoires

SPIDR : Spike, Path, Interfaces, Data, and Rules. (Spike*, chemin, interfaces, données et règles). Vous pouvez lire sur chaque technique et obtenir une affiche SPIDR gratuite ici.

L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper les histoires utilisateurs. Je parie que vous avez eu du mal avec cela, parce que je l’ai certainement connu au début. C’est pourquoi j’ai trouvé un acronyme facile à retenir pour détailler les cinq facteurs différents qui pourraient vous aider à diviser une histoire.

J’espère que ces conseils vous aideront, vous et votre équipe, à réussir avec agile,

P.S. Il ne vous reste que deux chances d’assister à un cours Better User Stories en direct avec Mike avant la fin de l’année. https://www.mountaingoatsoftware.com/training/courses/better-user-stories

* Spike : 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é.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Billets les plus lus sur le blog du management de projets DantotsuPM au mois d’ Avril 2023 : Habitudes des PMs efficaces, SAFe 6.0 et retour au bureau.

Le par mopertodans pointeurs utilesLaisser un commentaire

10 habitudes des managers de projet très efficaces : Comment pouvez-vous produire les résultats escomptés ou souhaités dans vos projets ?

Focus sur le management des risques !

Même si je ne suis pas personnellement un grand fan de SAFe, une nouvelle version recèle toujours son lot de nouveautés dont nous pouvons toutes et tous apprendre : Voici donc SAFe 6.0 !

Cette version représente une avancée significative dans la façon dont les entreprises intègrent les pratiques SAFe dans le travail quotidien, font perdurer le changement et obtiennent les avantages d’une véritable agilité business.

20 raisons impérieuses pour les employés de retourner au bureau

Suite à la pandémie et au télétravail généralisé dans certaines professions et secteurs, de nombreuses personnes n’en sont encore qu’à envisager de retourner au bureau, ou pas…

Billets les plus lus sur le blog du management de projets DantotsuPM au mois de Février 2023 : Adaptation aux pratiques Agiles, Postures du manager de projets et motivation personnelle.

Le par mopertodans pointeurs utilesLaisser un 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.

Un facteur souvent sous-estimé est la posture à tenir par le chef de projet au sein d’une bureaucratie et/ou d’une adhocratie. Yanis Ioualitene

Yanis Ioualitene : « A la différence, de l’adhocratie, où votre pouvoir est limité. Vous serez tel le Scrum Master qui est présent pour guider son équipe (mais sans la diriger), tout en sachant canaliser et centraliser les relations informelles. »

Pour beaucoup de personnes, la reconnaissance est le carburant de leur moteur de productivité.

A propos de développement itératif et approches adaptatives #Agile

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Retour sur les nombreux billets publiés sur cette thématique sur le blog DantotsuPM depuis 2009.

Et si vous appliquiez l’heuristique de « How Big Things Get Done » à l’approche de développement adaptative !

Les mégaprojets fournissent souvent des leçons applicables aux projets de toutes tailles. Le livre du professeur Bent Flyvbjerg et Dan Gardner « How Big Things Get Done » propose 15 heuristiques ou principes qui s’appliquent à tous les projets.

« Effet Frankenstein : Le côté obscur de la gestion de projet hybride » par Pierre-Étienne Pernet

À lire les nombreux articles qui fleurissent un peu partout, la gestion de projet hybride semble parée de toutes les vertus. Si cela n’est pas dénué de certains fondements, cette approche possède également quelques inconvénients que l’on oublie trop souvent de présenter.

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

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

Votre projet est-il adapté aux pratiques agiles ?

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.

Qu’est-ce qu’un incrément de produit ?

Dans Scrum, un incrément de produit est ce que vous avez précédemment construit, plus tout ce que vous venez de terminer dans le dernier sprint, le tout intégré, testé et prêt à être livré ou déployé.

Votre projet est-il un bon candidat pour Agile ?

Pour réussir avec agile, assurez-vous que vos projets sont de bons candidats agiles.

Soyez réaliste dans votre choix d’utiliser une approche Agile (ou pas) !

Pour réussir avec Agile, assurez-vous d’utiliser des critères bien réfléchis pour qualifier vos projets comme de bons candidats pour une approche Agile.

Est-il plus pertinent pour vous d’adopter une approche itérative Agile, une prédictive comme Prince2 ou de mixer les 2s ?

Comment avoir une approche de management de projet en laquelle on a déjà confiance et y ajouter le nouveau ‘ test de pertinence ’ pour s’assurer que l’approche adoptée est la bonne pour le projet en question ?

Itérations et incréments

Agile, c’est le développement itératif et progressif et la livraison fréquente avec un changement culturel vers la transparence.

Que pensez-vous de ces 10 bonnes raisons de faire du développement Agile ?

Voici 10 bonnes raisons d’appliquer les principes et pratiques de développement Agile…

4 avantages de la nature itérative de Scrum

Il y a un certain nombre de défis dans les projets de développement qui suivent le chemin de méthodologies de développement plus rigides comme la méthode dite « en cascade ».

Vos clients sont-ils prêts pour Agile ?

Aujourd’hui, comme la communauté IT a bien adopté et s’est adaptée aux pratiques Agile, en faites-vous assez pour instruire et informer votre écosystème et surtout vos clients ?

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Voici que répondre à certaines préoccupations sur SAFe…

Le par mopertodans forum de discussionLaisser un commentaire

SAFe reconnaît et respecte que de nombreuses organisations en transition vers des pratiques agiles ont encore un état d’esprit traditionnel. Par conséquent, beaucoup de matériel dans SAFe peut paraître inacceptable pour les agilistes confirmés.

Addressing some SAFe concerns par Michael Küsters

https://failfastmoveon.blogspot.com/2023/05/addressing-some-safe-concerns.html

Très souvent, je rencontre des préoccupations avec SAFe (Scaled Agile Framework). Lorsque l’on regarde la situation dans son ensemble, et ce que de nombreuses entreprises font de SAFe, ces préoccupations sont recevables et devraient être prises au sérieux. Pourtant, aucune de ces préoccupations ne pourrait être résolue par un consultant SAFe compétent (SAFe® Practice Consultant-T – SPCT) et une direction soucieuse de réaliser une différence significative dans ses méthodes de travail. Dans cet article, je considère certaines de ces préoccupations. Michael Küsters.

Préoccupations typiques avec SAFe

Avant de creuser, je crois que les compétences et l’expérience de vos consultants SAFe sont essentielles au succès de SAFe. Si vous comptez sur des gens qui ne comprennent pas les conséquences des conseils qu’ils donnent, vous êtes dans une situation difficile. Un de mes amis SPCT (SAFe® Practice Consultant-T – SPCT) a récemment déclaré :

Avoir les mauvais SPC (SAFe® Practice Consultant) – ou ignorer complètement les conseils d’un SPC – vous coûtera facilement dix fois plus cher que ce qu’un bon SPC vous coûterait.

Je suis d’accord. Les bons SPC valent leur pesant d’or. Malheureusement, ils ne poussent pas sur les arbres… Mais c’est une autre histoire. Maintenant, jetons un coup d’œil à certaines des préoccupations que je rencontre habituellement, et ce que vous devez considérer.

SAFe répond à l’état d’esprit traditionnel

SAFe reconnaît et respecte que de nombreuses organisations en transition vers des pratiques agiles ont encore un état d’esprit traditionnel. Par conséquent, beaucoup de matériel dans SAFe est écrit d’une manière qui pourrait être plus acceptable pour les personnes qui ont une faible compréhension de l’agilité. C’est l’idée de « rencontrer les gens là où ils sont ». Oui, c’est controversé, mais c’est de loin mieux que d’affronter les personnes mêmes dont vous avez besoin pour réussir un changement. Ce qui se passe après les avoir rencontrés dépend beaucoup de leur motivation à changer et de la capacité du SPC à mener le changement.

Complexité excessive

Tout d’abord, si vous n’avez pas les problèmes que SAFe adresse, ne l’utilisez pas. Ceci étant dit, SAFe ne peut pas et ne devrait généralement pas être appliqué dans son intégralité. Au contraire, lorsque vous repérez un problème pour lequel SAFe propose une solution, vous pouvez regarder ce que dit SAFe, avoir une discussion pour savoir si cela vaut la peine d’essayer. Et, si c’est le cas, alors allez-y.

Visitez le site SAFe

Cela ne signifie pas non plus que vous devez faire des choses qui adressent des problèmes que vous n’avez pas, ni que vous devez faire les choses comme SAFe dit de le faire si cela ne fonctionne pas pour vous. Pour ma part, quand quelqu’un vient me voir et me dit : « Nous utilisons SAFe et avons tel ou tel problème », je me réfère généralement à un article SAFe, et les pointeurs originaux auxquels SAFe fait référence, et je prends la discussion à partir de là. Pour moi, SAFe est un déclencheur de discussion, pas la panacée à tous les maux.

Des dépendances partout !

SAFe reconnaît que les dépendances peuvent être un défi dans les organisations complexes. Il fournit des conseils et des pratiques clairs qui rendent les dépendances visibles, puis offre un moyen de traiter ces dépendances de manière systématique. Dans de nombreuses organisations, les dépendances sont inévitables mais au moins vous savez quels problèmes vous avez à cause d’elles, et vous pouvez commencer la discussion sur ce qu’il faut faire à leur sujet. J’ai vu plus d’une fois que les équipes trouvaient leurs dépendances irréalisables et décidaient de se réorganiser. Une excellente discussion à avoir.

Durée des intervalles de planification

SAFe utilise une approche de planification basée sur un cadencement avec des intervalles de planification (Planning Intervals – PIs) de longueur fixe s’étendant généralement sur 8 à 12 semaines. Des intervalles de planification plus longs offrent stabilité et prévisibilité aux équipes au détriment de la flexibilité. Cependant, vous pouvez ajuster la durée des PIs en fonction de votre propre contexte. J’ai vu des trains de livraison agiles exécuter 3 sprints de 1 semaine plus un sprint PI de 1 semaine. Cela correspond même au vieux slogan de Scrum, « Working Software in 30 days or less » – à grande échelle ! Essayez ce qui fonctionne pour vous et discutez.

Processus de planification descendants

Peut-être avons-nous une mauvaise image dans notre tête, mais qui peut nous en blâmer quand nous avons été conditionnés à penser en hiérarchies ? Dans un contexte SAFe, vous aimeriez décentraliser ce qui a du sens mais tout n’a pas de sens à être décentralisé. Par exemple, la fonction de Product Management dans SAFe pourrait être composée de Product Owners par équipe, s’ils ont les compétences et la capacité de réussir dans ce rôle, de sorte que cela n’a pas besoin d’être hiérarchique.

Ce dont vous avez besoin, c’est de vous concentrer clairement sur les plus gros morceaux de valeur et d’aligner toutes les équipes autour d’eux.

La façon dont cela se produit peut varier d’une organisation à l’autre, mais le fait que chaque équipe décide par elle-même n’augure rien de bon. Veuillez noter que SAFe encourage la participation active et l’autonomisation des équipes et des individus dans la prise de décisions.

Pas de vrai Scrum

Guide téléchargeable gratuitement

SAFe n’est pas une implémentation stricte de Scrum, mais plutôt un cadre qui intègre des principes et des pratiques agiles provenant de diverses sources, y compris Scrum. Étant donné que de nombreuses équipes utilisent déjà Scrum et sont familières avec les concepts de base de Scrum, SAFe en a tiré parti et conserve les principes fondamentaux de transparence, d’inspection et d’adaptation.

Lorsque je coache des équipes SAFe, je me réfère souvent au Guide Scrum et suggère que comprendre et pratiquer Scrum aide beaucoup à bien mettre à l’échelle. Malheureusement, ce que je vois assez souvent, c’est que les organisations ont déjà utilisé un Scrum hautement dysfonctionnel depuis des années, et veulent maintenant changer cela. En fait, la transformation SAFe pourrait être l’occasion de réparer les trucs Scrum qui ont toujours été cassés et n’ont jamais été résolus.

Les équipes deviennent des usines à fonctionnalités (Feature Factories)

C’est déjà un dysfonctionnement parce que les fonctionnalités produites avec SAFe devraient se concentrer sur la valeur, pas sur la maximisation de la quantité de travail livré. Vous ne devriez avoir qu’un seul ART Kanban hiérarchisé par valeur et les équipes devraient collaborer sur des objectifs partagés, en utilisant des backlogs communs et des événements inter-équipes pour assurer une solution système cohérente qui maximise la valeur.

Lisez cet article en anglais.

Alors que parfois, je constate que les équipes individuelles peuvent se concentrer sur la fourniture de leurs propres fonctionnalités indépendamment de la valeur.

SAFe fournit des mécanismes tels que les démonstrations système et les événements d’inspection et d’adaptation pour s’assurer que les équipes ne partent pas sur une tangente et effectuent une grande quantité de travail de faible valeur.

Processus d’estimation fallacieux

Il y a beaucoup à dire sur le processus d’estimation de SAFe, et j’ai ma propre opinion sur les conseils donnés. Pour faire simple: Ces conseils sont réservés aux personnes qui ne savent pas par où commencer. Le coaching et l’empirisme devraient conduire à une approche qui répond aux besoins de ceux qui ont besoin des estimations.

Vous devez réaliser que dans les grandes organisations, très souvent, plusieurs parties prenantes, d’autres équipes et potentiellement de grosses sommes d’argent dépendent de l’établissement de prévisions assez précises de l’achèvement. L’estimation peut avoir des implications qui n’existent pas dans des contextes plus petits.

Mon propre exemple est que nous devons absolument savoir si la fonctionnalité sera prête pour un salon précis ou si nous devons mitiger. Mais « Eh bien, nous pourrions ou être prêts à temps ou pas pour le salon » pourrait conduire à un désastre majeur en matière de relations publiques, et est probablement inacceptable.

Un événement d’amélioration continue tous les 3 mois, c’est trop peu, trop tard

Alors que l’événement Inspect and Adapt (I+A) se produit à la fin de chaque intervalle de planification (PI), SAFe encourage l’amélioration continue tout au long du PI, les Scrum-of-Scrums (SoS) et les rétrospectives étant des opportunités pour faire apparaître et résoudre les problèmes transversaux.

J’ai moi-même donné des conseils sur le fait que les équipes sont censées apporter leurs propres changements et améliorations indépendamment de l’événement I+A, et même partager leurs apprentissages avec d’autres équipes pendant cet événement. Je m’attends à ce que les équipes apportent des problèmes à court terme au SoS, et n’apportent à l’I+A que des problèmes qui nécessitent des périodes de préparation et d’observation plus longues, et ont un impact bien au-delà des limites de l’équipe. Surtout, vous devez considérer que le I+A est un point de réflexion, où vous vous détachez de la routine quotidienne et vous réunissez en tant qu’équipe d’équipes pour discuter des choses dont vous devez discuter et dont vous n’avez jamais eu l’occasion de discuter auparavant. Il y a toujours quelque chose. Oui, vous pourriez avoir de tels événements plus souvent si vous pensez que cela pourrait aider, il n’y a rien dans SAFe qui vous arrête. Essayez.

Conclusion

Je conviens que le Scaled Agile Framework (SAFe) a des domaines d’interprétation et suscite des préoccupations. S’attendre à ce que ce soit une solution miracle est complètement irréaliste. SAFe fournit une approche structurée pour les grandes organisations qui essaient de donner un sens à toute cette chose « Agile », mais cela ne fonctionne que si elles ont quelqu’un qui comprend plus que ce que dit le matériel. Lorsque vous pouvez faire face aux complexités du développement à grande échelle, de la collaboration entre les équipes et de l’alignement global tout en vous améliorant continuellement, vous avez réussi avec SAFe.

Pour y arriver, vous devez absolument personnaliser SAFe et l’utiliser à bon escient sinon cela deviendra un gâchis, et c’est pourquoi vous avez besoin de personnes qui savent de quoi elles parlent.

Et j’ai vu ce gâchis : La pagaille prend des années à nettoyer. Les personnes qui soutiennent votre initiative de changement doivent être en mesure de répondre aux préoccupations critiques en fonction de leur propre expérience et de leurs apprentissages. Et les personnes de votre organisation qui ont des préoccupations ont besoin d’un temps et d’un endroit où exprimer ces préoccupations car ce n’est qu’alors que vous pourrez vraiment vous améliorer.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Et si vous appliquiez l’heuristique de « How Big Things Get Done » à l’approche de développement adaptative !

Le par mopertodans agile, best practices, experience sharing, leadership2 commentaires

Les mégaprojets fournissent souvent des leçons applicables aux projets de toutes tailles. Le livre du professeur Bent Flyvbjerg et Dan Gardner « How Big Things Get Done » propose 15 heuristiques ou principes qui s’appliquent à tous les projets.

 

Applying the heuristics of “How Big Things Get Done” to adaptive delivery par Kiron Bondale

https://kbondale.wordpress.com/2023/05/08/applying-the-heuristics-of-how-big-things-get-done-to-adaptive-delivery/

livre sur Amazon

Chaque année, je lis un certain nombre de livres sur le leadership de projet mais en général, je n’en trouve qu’un ou deux qui ont vraiment un impact.

 Le livre du professeur Bent Flyvbjerg et Dan Gardner « How Big Things Get Done » est l’un de ceux-ci.

Je n’ai jamais eu l’occasion de diriger un mégaprojet (le terme est généralement utilisé pour les projets qui ont un budget supérieur à 1 milliard de dollars), mais au cours des quinze dernières années, j’ai lu un certain nombre d’articles publiés par le professeur Flyvbjerg sur le sujet et j’ai toujours appris des leçons applicables aux projets auxquels j’ai participé.

Dans le livre, les auteurs fournissent de nombreuses études de cas soutenant onze heuristiques dérivées des décennies de recherche du professeur Flyvbjerg sur de grands projets complexes. Bien que le terme « heuristique » soit approprié car chacun est un raccourci mental utile, ils pourraient également être utilisés comme principes.

Relisez ce billet de Grace Najjar sur les mégaprojets au Moyen-Orient.

Étant donné que 22 des 23 catégories de projets évalués sont des projets physiques (p. ex. construction, exploitation minière, aérospatial), il est tentant de supposer que ces heuristiques ne sont pertinentes que pour les projets réalisés avec une approche prédictive.

Ce serait une hypothèse erronée car sur les onze heuristiques, j’ai constaté que la plupart de ces principes sont également applicables à l’approche adaptative. En voici quelques-uns.

Embauchez un ou une maître d’œuvre

Vous voulez avoir quelqu’un avec une expérience significative du domaine et une expérience prouvée de succès à mener ce travail.

De même, que vous cherchiez à remplir le rôle de chef de projet, de responsable agile (par exemple, Scrum Master) ou de propriétaire de produit, une expérience et des connaissances pertinentes sont essentielles.

Donnez raison à votre équipe

La première déclaration de valeur du Manifeste pour le développement logiciel Agile est « Les individus et les interactions plutôt que les processus et les outils ».

Et comme le dit le professeur Flyvbjerg, le travail principal du maître d’œuvre est de choisir les bons membres dans l’équipe pour faire le travail.

Demandez « Pourquoi ? »

Bien que l’on s’attende à ce que la portée d’un projet émerge au cours de sa vie lors de l’utilisation d’une approche adaptative, ce peut être une erreur fatale que de ne pas passer suffisamment de temps à identifier une vision finale attendue.

Relisez ce billet sur l’art de savoir communiquer une vision claire.

Cette étoile polaire permet à l’équipe de questionner les éléments de travail qui ne permettront pas d’atteindre les résultats souhaités et ce questionnement réduira la probabilité qu’une approche de livraison adaptative ne devienne une marche aléatoire vers nulle part.

Construisez avec des Legos

L’idée de créer de grands systèmes à partir de composants plus petits s’inscrit naturellement dans la nature incrémentale de l’approche adaptative.

Lorsqu’une équipe prend un gros élément de travail et trouve un moyen de le découper en morceaux plus petits qui fournissent toujours individuellement de la valeur, elle applique cette heuristique.

Pensez lentement, agissez vite

En surface, cette heuristique sonne comme une invitation à une grande planification, lourde et initiale basée sur le papier que les agilistes évitent. Ce n’est pas ce que préconise le professeur Flyvbjerg.

Ce qu’il recommande, c’est de réduire le coût des essais et des erreurs en prenant le temps d’identifier les principaux domaines d’incertitude qui pourraient avoir une incidence sur la réussite et d’apprendre et trouver des moyens de les résoudre efficacement le plus tôt possible dans le cycle de vie du projet.

Les exemples fournis sur la façon dont Pixar planifie ses films ou comment Frank Gehry a conçu le musée Guggenheim de Bilbao démontrent tous deux que la réduction précoce des risques est un attribut essentiel de l’approche adaptative.

Dites non et partez

Le professeur Flyvbjerg souligne l’importance de la concentration lors de la réalisation de projets complexes. Si une action ne contribue pas à l’atteinte des résultats du projet, ignorez-la.

Cela correspond bien au dixième principe du Manifeste : « La simplicité – l’art de maximiser la quantité de travail non effectuée – est essentielle. »

Bien que je n’aie pas couvert toutes les heuristiques et leur applicabilité adaptative dans cet article, j’espère vous avoir tous encouragés à lire ce livre, quel que soit le domaine ou l’approche utilisée pour livrer vos projets.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Les parties prenantes insistent sur le fait qu’elles ont besoin d’une fonctionnalité ou histoire utilisateur MAINTENANT !

Le par mopertodans agileLaisser un commentaire

Vos clients ou parties prenantes viennent-ils parfois vous voir et font pression pour un changement immédiat ? Je suis sûr qu’au moins quelques-uns d’entre eux le font. Les miens l’ont toujours fait.

Publié par Mike Cohn dans la lettre hebdomadaire de Mountain Goat Software

J’ai remarqué quelque chose à ce sujet, cependant.

La plupart du temps, lorsque les gens insistent : « Nous avons besoin de cela maintenant », ils le font parce qu’ils ont appris que c’est la meilleure façon d’attirer notre attention. S’ils peuvent augmenter la gravité afin que nous agissions immédiatement à la demande, ils savent qu’ils obtiendront le changement.

Ces clients et parties prenantes ont appris au fil des ans que s’ils ne parviennent pas à obtenir notre attention immédiate, la demande disparaîtra dans le puits sans fond des demandes et ne sera jamais faite.

Un réel avantage de travailler de manière agile est que nous pouvons changer la conversation avec ces personnes. Au lieu de tout laisser tomber pour répondre à leur besoin immédiat, nous pouvons plutôt leur expliquer que notre équipe évite d’introduire des changements dans une itération, mais sera heureuse de planifier ce nouveau travail dans la prochaine itération.

J’ai eu beaucoup de succès en répondant quelque chose comme ceci

Cela semble important et j’aimerais que nous nous y mettions. Mais nous travaillons par blocs de temps de deux semaines que nous appelons itérations [ou sprints] et nous en sommes au milieu d’une itération en ce moment. Nous essayons vraiment d’éviter d’ajouter un nouveau travail à l’un de ces blocs de temps, car cela affecte notre capacité à tenir les promesses que nous avons pu faire aux autres parties prenantes. Nous avons une nouvelle itération qui commence la semaine prochaine. Que se passe-t-il si je m’engage à planifier cette demande dans cette itération et à vous la donner quelques jours après [ou à la fin de l’itération] ?

Faire comprendre aux utilisateurs et aux parties prenantes qu’ils n’ont plus besoin d’attirer notre attention en insistant sur le fait que tout est nécessaire « maintenant » peut représenter une énorme victoire.

Cela permet aux équipes de mieux planifier leurs itérations et d’avoir moins d’interruptions. Ceci vous aidera à réussir avec agile.

PS: Le management des parties prenantes est quelque chose que Mountain Goat Software couvre dans les cours CSM et CSPO. En tant que Scrum Master, vous apprendrez à minimiser les conflits et à éviter les perturbations lors de réunions clés telles que le daily scrum. Et en tant que Product Owner, vous apprendrez à communiquer efficacement entre les parties prenantes et l’équipe pour apporter constamment de la valeur. Vous pouvez trouver les détails des deux cours ici.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Plusieurs vidéos intéressantes sur Scrum en langue anglaise

Le par mopertodans agileLaisser un commentaire

Je vous propose de commencer par Scrum.Org avant de zoomer sur les valeurs de Scrum, le Sprint Planning et les Sprint Reviews.

Ces vidéos peuvent s’avérer très utile pour sensibiliser votre comité de projet, votre sponsor et autres parties prenantes à ce qu’est Scrum avec ses valeurs ainsi que certaines de ses « cérémonies » les plus utiles.

Dans cette vidéo de 2 minutes, apprenez-en davantage sur ce que Scrum.org est et fait.

Voici quelques exemples de comment appliquer les valeurs Scrum de courage, engagement, focus, ouverture et respect.

Comment faciliter le Sprint Planning ?

Dans cette vidéo introductive, comprenez comment et quand utiliser certaines techniques de facilitation comme le vote romain, la visualisation et le questionnement afin que votre équipe puisse quitter la session de planification du sprint avec un objectif de sprint en direction de l’objectif du produit et un plan initial pour le sprint.

Comment faciliter les primordiales sessions de Sprint Review ?

Voici au moins une technique de facilitation qui va vous aider à transformer la revue de sprint en une session plus engageante et collaborative. Vous pourrez alors y recueillir des commentaires précieux des parties prenantes pour déterminer les futures adaptations de votre approche et de votre produit.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile