« Scrum ne fonctionnerait jamais pour nous ici… Ou le ferait-il ? » par Sam Adesoga

« Scrum ne fonctionnerait jamais ici ! »

Scrum Would Never Work for Us Here… Or Would It?

https://samadesoga.me/posts/scrum-would-not-work-for-us/

C’est une phrase que j’ai entendue d’innombrables fois, et elle reflète souvent une résistance plus profonde au changement ou une incompréhension de ce qu’est vraiment Scrum. S’il est vrai que Scrum n’est pas une solution unique, il s’agit d’un cadre incroyablement puissant pour les équipes axées sur la livraison de produits. Lorsqu’il est correctement mis en œuvre, Scrum peut transformer la façon dont les équipes travaillent, hiérarchisent les priorités et créent de la valeur.

Alors, pourquoi tant d’équipes ont-elles du mal avec Scrum ?

D’après mon expérience, la résistance se résume souvent à 3 problèmes clés :

  1. L’incapacité à établir des priorités, ce qui entraîne trop de « travail en cours » et un manque de concentration.
  2. Un manque de compréhension de l’établissement d’objectifs et de son impact sur le moral et la productivité de l’équipe.
  3. Un manque de confiance entre l’équipe et ses parties prenantes.

Ironiquement, ce sont précisément les raisons pour lesquelles Scrum peut être si efficace. Voyons comment Scrum relève ces défis, en particulier à travers le prisme de la définition d’objectifs.

Le pouvoir des objectifs : objectifs de produit et de sprint

En 2020, le Scrum Guide a explicitement introduit les concepts d’objectifs de produit et d’objectifs de sprint, et pour de bonnes raisons. Ces objectifs servent d’étoile polaire pour les équipes, apportant clarté, concentration et un sens commun de l’objectif.

Pourquoi les objectifs sont importants

Les objectifs ne sont pas seulement des choses agréables à avoir ; Ils sont essentiels pour une livraison efficace des produits.

Ils:

  • Fournissent une orientation claire à l’équipe et aux parties prenantes.
  • Aident à suivre les progrès et à mesurer le succès.
  • Alignent tout le monde autour d’un objectif commun.

Pourtant, de nombreuses équipes font à cet exercice à l’envers. Elles commencent par définir le « quoi » (les tâches ou les éléments du backlog), puis essaient d’adapter un « pourquoi » (l’objectif) autour d’eux. Cette approche conduit souvent à la confusion, au désalignement et à la déperdition d’efforts.

Le Scrum Framework renverse la situation. Il encourage les équipes à commencer par le « pourquoi », c’est-à-dire la raison impérieuse derrière le travail, puis à l’utiliser pour définir le « quoi ». En d’autres termes, créez d’abord l’objectif, puis laissez-le guider la création des éléments du backlog de produit.

Cette logique s’applique à la fois au Product Goal (objectif intermédiaire) et au Sprint Goal (objectif tactique). Ensemble, ils créent une feuille de route qui guide les efforts de l’équipe et assure l’alignement avec les attentes des parties prenantes.

Créez les objectifs grâce à la collaboration

L’une des idées fausses les plus courantes sur Scrum est que les objectifs sont dictés du haut vers le bas. En réalité, l’établissement d’objectifs efficaces est un processus collaboratif qui implique l’ensemble de l’équipe et ses parties prenantes.

Objectifs du produit

L’objectif du produit est l’objectif global vers lequel l’équipe travaille. Ce n’est pas quelque chose que le Product Owner imagine seul. Au lieu de cela, il s’agit d’une suggestion ou d’une idée, qui est ensuite affinée et finalisée en collaboration avec les parties prenantes, y compris les développeurs. Cela permet de s’assurer que l’objectif est à la fois ambitieux et réalisable.

Objectifs du sprint

De même, l’objectif de sprint est un tremplin vers l’objectif du produit. Ce n’est pas transmis à l’équipe ; il est co-créé pendant la planification du sprint. L’équipe discute de l’objectif, évalue sa faisabilité et s’engage à le livrer d’ici la fin du Sprint.

Cette approche collaborative favorise un sentiment d’appartenance et de responsabilité. Lorsque tout le monde participe à la création des objectifs, ils sont plus susceptibles de s’investir dans leur réalisation.

L’un des arguments contre l’adoption de Scrum est le désir de jongler avec plusieurs objectifs simultanément.

Bien que cela puisse être une préoccupation légitime, il existe des stratégies pour l’atténuer :

  1. Raccourcissez les délais : Réduisez la période de temps dédiée pour atteindre l’objectif du produit, par exemple, de trois mois à un mois. Cela rend l’objectif plus gérable et permet des boucles de rétroaction plus rapides.
  2. Élargissez l’objectif : Créez un objectif plus large qui offre une valeur significative dans la période temps choisie. Cela permet à l’équipe de rester concentrée sans se sentir débordée.

Ces stratégies aident les équipes à maintenir la clarté et le momentum, même lorsqu’elles sont confrontées à des priorités concurrentes.

Le rôle de la confiance et de la concentration

Scrum ne concerne pas seulement les processus et les objectifs ; Il s’agit de personnes. Pour que Scrum fonctionne, les équipes ont besoin de confiance, de soutien et de liberté pour se concentrer.

Confiance : Lorsque les parties prenantes font confiance à l’équipe pour respecter ses engagements, cela crée une boucle de rétroaction positive. L’équipe se sent responsabilisée et les parties prenantes voient des résultats cohérents.
Concentration : Les équipes sont plus performantes lorsqu’elles peuvent se concentrer sur leurs objectifs sans interruptions intempestives. Cela signifie qu’il faut réserver des capacités dédiées aux tâches non planifiées (comme le travail réglementaire ou de conformité) tout en veillant à ce que la majorité des efforts de l’équipe soient consacrés à la réalisation de ses objectifs de sprint et de produit.

Au fil du temps, les équipes qui adoptent des objectifs ambitieux mais réalisables développent un moral plus élevé et un sens plus fort de raison d’être. Elles deviennent plus autonomes, productives et alignées sur les besoins des utilisateurs.

CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Faites en sorte que Scrum travaille pour vous !

L’expression « Scrum ne fonctionnerait jamais pour nous ici » découle souvent d’un manque de compréhension ou d’une mauvaise application du cadre de travail Scrum. Mais lorsqu’il est mis en œuvre correctement, en mettant l’accent sur la collaboration, la définition d’objectifs et la confiance, Scrum peut changer la donne pour les équipes de livraison de produits.

Si votre équipe a du mal à établir des priorités, à s’aligner ou à garder le moral, envisagez d’essayer Scrum. Commencez par définir des objectifs clairs et convaincants. Impliquez votre équipe et vos parties prenantes dans le processus. Plus important encore, créez un environnement où la confiance et la concentration peuvent prospérer.

Scrum n’est pas une solution miracle, mais un outil puissant pour développer l’agilité et créer de la valeur. La question n’est pas de savoir si Scrum peut fonctionner pour vous, mais si vous êtes prêt à adopter les principes qui le font fonctionner.

Sam anime plusieurs cours sur le leadership agile et Scrum, si vous souhaitez en savoir plus sur le cadre Scrum, consultez la page de la ValueHut Consulting Academy.


Sam Adesoga

Sam Adesoga

Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux : Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.

 

 

Le premier rapport annuel sur l’état de SAFe, le « State of SAFe Report » a été publié !

« State of SAFe Report 2025 » – Simplifier les directives, les rendre plus pratiques, plus adaptables, et se focaliser sur les résultats business !

https://framework.scaledagile.com/blog/the-first-annual-state-of-safe-report-has-been-released par Steve Mayner

Scaled Agile a lancé un effort de recherche sur les retours des clients et utilisateurs SAFe et c’est le plus important de son histoire : State of SAFe Report 

Téléchargez ce rapport en langue anglaise.

Ce rapport 2025 donne un bon aperçu et analyse les informations partagées dans les réponses à l’enquête.

Sur de nombreux sujets, les commentaires reçus soutiennent la nécessité de simplifier les directives, de les rendre plus pratiques et adaptables, et de se concentrer davantage sur les résultats opérationnels plutôt que sur les processus.

La nécessité pour Scaled Agile de rendre SAFe encore plus facile à adapter en sort encore renforcée.

Et vous, quels sont vos retours pratiques sur SAFe ?

https://scaledagile.com/resources/state-of-safe-report/

© Scaled Agile, Inc.

AgilePM® : 3 documents en langue anglaise produits par APMG International sur la V3

AgilePM v3 est conçu pour vous aider à apporter plus de valeur, à manager le changement en toute confiance et à faire évoluer vos projets comme jamais auparavant.

APMG International vous offre un accès exclusif à trois ressources essentielles qui mettent en évidence pourquoi la version 3 se démarque comme la meilleure approche Agile. Ces documents vous aideront à approfondir votre compréhension et à appliquer efficacement les principes d’AgilePM.

3 documents gratuits

Voici ce que vous recevrez:

  1. The AgilePM Value Blueprint: un guide stratégique pour maximiser les avantages d’AgilePM. Les étapes décrivent un plan pour tirer le meilleur parti de vos projets grâce à l’application pragmatique et agile d’AgilePM (v3). Il s’agit d’un parcours en cinq étapes pour atteindre la maîtrise et libérer de la valeur pour vos clients, votre entreprise et vous-même.
  2. Les résultats de l’enquête « AgilePM Candidate Survey »: Les perspectives et attentes de plus de 380 candidats sur leurs expériences AgilePM. A la fois sur la formation pour préparer la certification et sur l’examen en lui-même.
  3. 10 Characteristics of a High-Performing Agile Team and How to Build One : 10 astuces pratiques pour améliorer les performances de votre équipe Agile.

Et relisez l’annonce : La version 3 d’AgilePM® est arrivée !

 

Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées. En particuliers celles sur Prince2 et AgilePM.

PIAF 2025 – Repensez l’agilité pour un avenir durable !

Le 14 mars 2025 aura lieu l’événement incontournable de l’agilité !

Inscrivez-vous rapidement en ligne.

Cette année, Piaf se transforme et se concentre sur une journée intense, riche en apprentissages et en échanges autour du thème : « Repenser l’agilité pour un avenir durable ». Une occasion unique pour les professionnels, leaders et passionnés de l’agilité de découvrir des stratégies novatrices et des solutions pratiques pour créer des organisations résilientes et durables.

Organisé par des experts de renom en agilité, avec le soutien précieux de PMI France, partenaire principal de cette édition, Piaf 2025 propose un programme soigneusement conçu, alternant conférences inspirantes et ateliers interactifs.

Explorez les nouvelles dimensions de l’agilité : écoconception, responsabilité sociétale, adaptation à long terme, et bien plus encore !

Pourquoi participer à Piaf 2025 ?

  • Un contenu avant-gardiste : Découvrez les dernières tendances et pratiques pour intégrer des valeurs durables dans vos projets agiles.
  • Des intervenants inspirants : Rencontrez des experts et des praticiens reconnus de l’agilité, qui partageront leur vision et leur expérience pour transformer vos défis en opportunités.
  • Une communauté engagée : Rejoignez une communauté dynamique de professionnels en quête de sens et d’impact durable, échangez des idées et développez de nouveaux partenariats.

Au programme :

  • Conférences thématiques autour des défis et innovations en agilité durable
  • Ateliers pratiques pour renforcer vos compétences et tester des approches concrètes
  • Rencontres et réseautage avec des experts et des praticiens de l’agilité

Cet événement est l’occasion idéale pour enrichir vos pratiques, repenser votre approche de l’agilité, et contribuer activement à la construction d’un avenir plus responsable.

Rendez-vous le 14 mars 2025 !

Inscrivez vous dès maintenant et soyez au cœur de cette transformation. Ensemble, réinventons l’agilité pour bâtir un avenir résilient.

Cette année, la billetterie sera solidaire :

  • Un accès gratuit pour les étudiants, personnes en recherche d’emploi ou reconversion s’ils le souhaitent.
  • Un accès payant (= solidaire à 20€) pour permettre l’organisation de l’événement et son accès à tous.

La version 3 d’AgilePM® est arrivée !

AgilePM est la principale certification non pas d’approches Agile mais de management de projet agile depuis son lancement en 2014.

La certification Agile Project Management, leader mondial, vient de s’améliorer.

Détails en ligne.

La certification AgilePM a été rapidement adoptée par les organisations mondiales et les gouvernements comme l’un des meilleurs cadres de travail pour le management de projet agile. Aujourd’hui, plus de 200 000 professionnels ont été certifiés en AgilePM pour fournir un management de projet de qualité, et de nombreux employeurs demandent spécifiquement la certification AgilePM pour leurs nouvelles embauches au vu des compétences et des connaissances acquises dans cette formation.

Dans l’esprit agile d’amélioration continue, AgilePM V3 vient d’être amélioré et regorge de nouvelles idées. La nouvelle certification s’aligne sur les progrès des méthodologies agiles, du management de projet, des pratiques business et de la technologie afin d’adopter une approche encore plus centrée sur l’humain.

Principaux changements entre AgilePM V2 et V3.

  • Passez de la livraison du produit à la création de valeur : Allez au-delà de la livraison de produits et créez une valeur business tangible à chaque étape de votre projet.
  • Passez de la gestion de projet au leadership de projet : Passez de chef de projet à leader Agile et amplifiez votre impact.
  • Adoptez SCRUM comme moteur de livraison de produits : Intégrez de manière transparente les pratiques Scrum dans les flux de travail de vos projets pour une agilité accrue de l’équipe.
  • Pour les projets multi-équipes : Appliquez des stratégies avancées pour manager efficacement plusieurs équipes de projet.
  • Pour le management des risques : Appropriez-vous les outils nécessaires pour améliorer la façon dont vous anticipez, évaluez et atténuez les risques de projet dans un environnement agile.
  • Expérience d’apprentissage et d’évaluation améliorée : Participez à une nouvelle simulation d’apprentissage interactive et pratique conçue pour approfondir votre compréhension et votre assimilation.

Téléchargez le guide PDF en anglais AgilePM v2 to v3 – what has changed? pour un résumé des changements.

CertYou est partenaire de DantotsuPM, allez voir les certifications et formations AgilePM !

A propos de valeur asymétrique dans vos projets.

Les projets transforment des contributions élaborées et construites par plusieurs personnes et groupe de personnes en un livrable de plus grande valeur.

Vos projets construisent une énorme valeur qui reste souvent indiscernable pour celle ou celui qui ne regarde que les briques qui la compose. C’est l’assemblage de ces briques qui produit une valeur supérieure.

La valeur dépend aussi de quel côté du mur on se trouve.

De plus, cette « valeur » est le plus souvent asymétrique pour vos parties prenantes et pour tous les bénéficiaires du livrable que construit votre projet.

« 1 tiens vaut mieux que 2 tu l’auras »

La valeur de disponibilité : Beaucoup de personnes préfèrent opter pour quelque chose qu’elles peuvent obtenir immédiatement plutôt que pour quelque chose de plus de valeur mais qu’elles ne sont pas certaines d’obtenir plus tard. La valeur actuelle est souvent plus attrayante qu’une valeur future plus importante. La valeur de votre livrable subit donc souvent une décote pour compenser le risque futur de ne pas l’avoir et le fait de ne pouvoir l’utiliser que plus tard et non pas tout de suite. Il y a un coût à attendre, surtout si le nouveau produit revient moins cher à l’usage que la solution actuelle.

 « Quand on n’a pas les moyens, on pic-nic. » Louis De Funès

La valeur relative : 1€ vaut beaucoup moins pour la personne qui a 100€ en poche que pour celle qui n’a que 5€. Même si vos commanditaires ou clients aiment votre proposition de livrable, peuvent-ils se l’offrir ?

L’asymétrie de la valeur peut donc souvent provenir du délai pour obtenir votre livrable mais aussi de la position actuelle des bénéficiaires (et de chaque bénéficiaire).

D’où l’intérêt des approches Agile qui permettent de délivrer rapidement le plus de valeur possible au moindre coût.

Sans oublier, les processus de management de portefeuilles de projets qui vous aident à sélectionner les projets les plus attractifs en fonction des objectifs de votre organisation et de vos clients pour y concentrer vos efforts et ressources.

Alors, si on vous demande « quelle est la valeur de votre projet », que répondez-vous ?

Comment favoriser une compréhension partagée de l’agilité pour vos équipes.

Lorsque les organisations n’obtiennent pas les résultats qu’elles attendent de l’agilité, je constate souvent que l’ingrédient manquant est une compréhension commune de ce que signifie être agile. Mike Cohn

How to Foster a Shared Understanding of Agile for Your Teams par Mike Cohn

https://www.mountaingoatsoftware.com/blog/how-to-get-teams-aligned-on-what-it-means-to-be-agile

Bien que les cadres de travail agiles comme Scrum offrent une structure, ils sont délibérément incomplets pour permettre la flexibilité. Cette même flexibilité, cependant, peut créer de l’ambiguïté et conduire à des interprétations incohérentes entre les équipes. Et cette incohérence peut devenir un obstacle important à l’obtention de tous les bénéfices de l’agilité, mais il y a certaines choses que vous pouvez faire.

Résistez à la tentation de(tout) standardiser.

Souvent, les organisations confrontées à de multiples interprétations de l’agilité essaient à tort de créer une cohérence par le biais de règles strictes et standardisées entre toutes les équipes.

À première vue, cela semble être une approche efficace. Si tout le monde suit les mêmes règles, tout le monde sera sûrement sur la même longueur d’onde ? Peut-être, mais c’est rarement une bonne longueur d’onde.

L’un des principes fondamentaux de l’agilité est l’inspection et l’adaptation. Cela ne s’applique pas seulement aux produits : Cela doit être appliqué à l’utilisation de l’agilité elle-même.

Au début d’une initiative agile, je pense que les équipes doivent rester très proches de ce qui est prescrit dans l’approche agile de leur choix, qu’il s’agisse de Scrum, Kanban, Extreme Programming, SAFe ou n’importe quelle autre.

Chacun de ces cadres de travail fait un bon effort pour placer des garde-fous (ou des contraintes) sur les équipes qui les empêcheront de s’éloigner des concepts agiles critiques. C’est important, car les équipes qui apprennent à être agiles n’ont pas nécessairement les connaissances ou l’expérience nécessaires pour décider quelles pratiques d’un cadre de travail peuvent être modifiées.

Mais dès que les équipes acquièrent de l’expérience, elles doivent avoir la liberté d’inspecter et d’adapter leur processus. Lorsqu’une organisation verrouille sa définition des pratiques agiles acceptables de manière trop rigide ou trop longue dans le parcours d’une équipe, ces dernières perdent leur sentiment d’autonomie.

La durée des itérations en est un bon exemple : Il est fort probable que, quelle que soit votre organisation, les équipes bénéficient d’itérations de différentes longueurs. J’ai vu une même durée d’itérations imposée trop de fois simplement parce que quelqu’un voulait recevoir des rapports d’avancement de toutes les équipes aux mêmes dates.

Évidemment, les équipes dont le travail est très imbriqué peuvent tout à fait bénéficier d’un accord sur une durée de sprint commune. Et, si c’est le cas, les équipes elles-mêmes le découvriront probablement sans que cela ne soit dicté.

Une organisation ne devrait pas dicter des règles qu’une équipe devrait choisir par elle-même. C’est un peu comme une règle dictant que je dois manger des tacos une fois par semaine ; Je le ferai quand même sans cette règle.

Une entreprise de développement de jeux avec lequel j’ai travaillé accordait plus d’attention au respect des règles de Scrum qu’à l’innovation. On avait dit aux équipes qu’elles devaient tout terminer à la fin de chaque sprint et qu’elles devaient atteindre l’objectif du sprint.

Dans la précipitation pour respecter une date limite de sprint, une équipe a développé des personnages trop grands pour tenir dans les véhicules conçus pour eux par une autre équipe. Cela avait été remarqué au milieu du sprint, mais aucune des deux équipes n’a estimé qu’elle pouvait apporter les changements nécessaires tout en atteignant son objectif de sprint.

Lorsque les équipes n’ont pas la liberté d’adapter les pratiques agiles à leurs besoins, elles se sentent contraintes et désengagées. Ces règles descendantes suggèrent fortement aux équipes que la direction ne leur fait pas confiance pour prendre leurs propres décisions, ce qui érode encore plus le moral.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Une meilleure approche : 3 stratégies pour aligner les équipes sur Agile

Le concept qui sous-tend ces trois conseils est essentiellement que tout le monde respecte les concepts qui sous-tendent l’agilité.

Mais soyons précis :

1. Concentrez-vous sur les principes qui sous-tendent les pratiques

L’agilité n’est pas une question d’adhésion rigide aux pratiques ; Il s’agit des principes qui les inspirent. Bien que les pratiques agiles puissent être utiles, elles ne constituent pas l’objectif final. Au lieu de cela, ce sont les principes qui ont inspiré ces pratiques qui comptent vraiment : Ils offrent la flexibilité nécessaire pour s’adapter et s’améliorer au fil du temps.

Par exemple, le Manifeste Agile met l’accent sur des principes tels que :

  • Les individus et les interactions plutôt que les processus et les outils
  • Réagir au changement plutôt que suivre un plan

Ces principes encouragent les équipes à privilégier la collaboration, la communication et l’adaptabilité. En se concentrant sur les intentions agiles, les équipes peuvent adapter leurs pratiques pour mieux s’adapter à leur contexte et à leurs défis uniques.

Une fois qu’une équipe a acquis suffisamment d’expérience et comprend parfaitement l’intention de chaque principe agile, elle doit expérimenter pour trouver ce qui fonctionne le mieux pour elle.

Un facteur de succès essentiel est qu’une équipe s’approprie son processus. Je ne suis pas opposé à ce qu’une organisation impose des règles aux équipes. Mais il doit s’agir de règles faciles à suivre et non en opposition avec les principes agiles. Il est logique de normaliser l’utilisation d’un outil à l’échelle de l’entreprise, tout comme d’établir une durée maximale d’itération.

N’oubliez pas que les équipes, au fur et à mesure qu’elles acquièrent de l’expérience, doivent être en mesure d’explorer les variations qui correspondent à leurs objectifs et à leurs valeurs. C’est ainsi qu’elles créent un processus agile plus efficace et durable qui répond vraiment à leurs besoins.

2. Utilisez un langage et des définitions partagés

L’un des plus grands obstacles à l’alignement est l’incohérence dans la terminologie utilisée. Lorsque différentes équipes utilisent des termes différents pour les mêmes pratiques, il y a de la confusion et des problèmes de communication.

Par exemple, sprint et itération signifient la même chose. Une équipe utilisant l’un de ces termes n’aura généralement aucun problème à communiquer avec une équipe utilisant l’autre. Mais une équipe avec laquelle j’ai travaillé a utilisé le sprint pour désigner une itération dans laquelle les membres de l’équipe devaient faire des heures supplémentaires pour atteindre leurs objectifs.

Personne dans les autres équipes ne le savait jusqu’à ce que quelqu’un demande avec désinvolture : « Pourquoi utilisez-vous les deux termes ? »

Il y a certaines choses que vous pouvez faire pour réduire les malentendus.

  1. Standardisez la terminologie : Créez un glossaire des termes couramment utilisés dans les pratiques Scrum et agiles. Ce glossaire devrait être accessible à tous et régulièrement mis à jour pour refléter les modifications ou les nouveaux termes introduits.
  2. Formation et ateliers : Organisez régulièrement des sessions de formation et des ateliers pour éduquer les membres de l’équipe sur les principes et les pratiques de Scrum. Organisez des sessions d’intégration pour les nouveaux membres de l’équipe et des cours de remise à niveau pour les membres existants.
  3. Utilisez des outils de communication : Tirez parti d’outils tels que les wikis, les intranets et les grands tableaux visibles pour diffuser des informations et fournir un emplacement centralisé pour le partage des connaissances. Utilisez plusieurs méthodes pour vous assurer que tout le monde a accès aux mêmes informations et définitions.
  4. Facilitez la communication ouverte : Encouragez une communication facile et transparente lors des standups, des revues et des rétrospectives quotidiennes. Les membres de l’équipe doivent se sentir à l’aise pour discuter de leurs progrès, de leurs difficultés et de toute divergence de compréhension, sans crainte.
  5. Ne combattez pas le vocabulaire de votre outil : Si vous utilisez un outil pour gérer le travail d’une équipe, ne vous battez pas avec sa terminologie. Même si je ne suis pas d’accord avec la façon dont Jira abuse du terme épopée, je suis d’accord avec ça lorsque je travaille avec Jira.
  6. Établissez des communautés de pratique : Il s’agit de groupes de personnes partageant les mêmes idées ou les mêmes compétences qui se réunissent volontairement en raison de leur passion et de leur engagement commun autour d’une technologie, d’une approche ou d’une vision. Elles aident à combler les écarts entre les différentes équipes, facilitant ainsi la diffusion des bonnes pratiques, de la cohérence et des connaissances au sein d’une organisation.

Dans une entreprise, le leader de l’initiative agile a insisté sur une définition de ce que signifiait être agile. Il l’a fait parce que, dans une organisation précédente, il avait vu des équipes appliquer l’étiquette agile à leurs approches très peu agiles. Lorsque ceux-ci échouaient inévitablement, l’agilité développait une mauvaise réputation.

Dans sa nouvelle organisation, il insistait sur le fait qu’une équipe ne pouvait se qualifier d’agile que si elle travaillait avec des règles comme les suivantes :

  • Mettre en production le code fonctionnel au moins toutes les deux semaines.
  • Avoir une seule personne pour guider la vision et le travail de l’équipe (c’est-à-dire un propriétaire de produit ou manager).
  • Effectuer des stand-ups quotidiens.
  • Organiser une rétrospective au moins une fois par mois.

3. Comprenez comment les leaders aident les équipes agiles à réussir

Le leadership joue un rôle essentiel dans l’alignement des équipes sur les principes agiles. Lorsque les leaders agiles modélisent les comportements qu’ils souhaitent voir, ils envoient un message clair que l’agilité n’est pas seulement un ensemble de règles, mais un état d’esprit et une culture à incarner.

Les leaders doivent adopter des valeurs agiles telles que l’adaptabilité, la collaboration et la transparence. En montrant qu’ils donnent la priorité à ces valeurs, les leaders créent un environnement où les équipes se sentent habilitées à vivre les principes agiles et à expérimenter des pratiques agiles.

Voici quelques mesures spécifiques que les leaders peuvent prendre :

  1. Responsabilisation et autonomie : Les leaders doivent permettre aux équipes de s’auto-organiser et de prendre des décisions. Prenez du recul et laissez les équipes travailler sans interférence. Les équipes développent un sentiment d’appartenance et de responsabilité pour les résultats qu’elles obtiennent de cette façon.
  2. Écoute active : Les leaders doivent pratiquer l’écoute active. Écoutez vraiment ce que disent les membres de l’équipe, comprenez leurs défis et fournissez un soutien sans dicter de solutions. Cette approche favorise une culture de confiance et d’ouverture.
  3. Encourager l’expérimentation : Les meilleures équipes sont celles qui sont prêtes à essayer de nouvelles choses. Les leaders doivent favoriser un état d’esprit d’expérimentation, où les équipes sont motivées à réfléchir à leurs processus et à mettre en œuvre des améliorations potentielles à chaque itération. Cette amélioration continue est au cœur de la réussite agile. Pour encourager l’expérimentation, les leaders ne peuvent pas se mettre en colère lorsqu’une expérience ne fonctionne pas.
  4. Équilibrer les priorités : Les leaders doivent reconnaître que chaque oui a un coût. En comprenant les compromis à faire lors de la sélection d’un objectif plutôt qu’un autre, les leaders peuvent aider les équipes à se concentrer sur ce qui compte vraiment, en évitant les pièges de l’engagement excessif et de l’épuisement professionnel.
  5. Lâcher prise des idées personnelles : Il est important que les leaders soient ouverts aux idées des autres et ne soient pas trop attachés aux leurs. La flexibilité crée un environnement où la diversité des points de vue est valorisée, ce qui permet d’obtenir des solutions plus innovantes.
  6. Modéliser les valeurs agiles : Les leaders doivent incarner les valeurs fondamentales de l’agilité, telles que la collaboration, la transparence et l’adaptabilité. « Joindre le geste à la parole » pour établir une norme à suivre par l’équipe, en renforçant l’état d’esprit agile dans toute l’organisation.
  7. Soutenir l’apprentissage continu : Il est crucial d’encourager les équipes à tirer des leçons à la fois des réussites et des échecs. Les leaders facilitent cela en offrant des opportunités de formation, d’ateliers et de rétrospectives, où les équipes peuvent réfléchir à leurs expériences et identifier les domaines de croissance.

Des parcours de formation qui facilitent l’alignement des équipes

La formation et les ateliers sont utiles pour acquérir une connaissance commune des principes et des pratiques. Mais il peut être difficile d’essayer de coordonner les calendriers de formation de plusieurs équipes.

C’est l’une des raisons pour lesquelles Mountain Goat Software a conçu ses Flex and Select Passes.

Agile Alliance a rejoint PMI® ! Cohérence et complémentarité.

Agile Alliance fut créée en 2001 par certains des auteurs originaux du Agile Manifesto et cette organisation accroit sa visibilité au niveau mondial en rejoignant le Project Management Institute®, référence inégalée dans le management de projet depuis 1969.

L’objectif de cette intégration est clair.

Agile Alliance et PMI proposent d’offrir ensemble des opportunités encore plus grandes de créer de la valeur par le biais de projets, de développement de produits et de transformations organisationnelles. Pierre Le Manh, Président et CEO, PMI.

En pratique, Agile Alliance change de nom et devient PMI Agile Alliance, tout en conservant sa structure et son conseil d’administration pour rester fidèle à sa mission et à ses valeurs : Propager l’agilité avec les valeurs et principes du Agile Manifesto.

Les membres de l’Alliance Agile et ceux du PMI auront dorénavant accès aux riches ressources combinées des deux organisations.

Je suis pour ma part très heureux de ce rapprochement qui me semblait inévitable car un management de projet efficace nécessite de comprendre et savoir utiliser des méthodologies et approches différentes pour répondre aux besoins spécifiques et au contexte de votre projet.

Le PMI l’a bien compris et propose depuis de nombreuses années une acculturation des managers de projets à l’agilité à travers de nouvelles formations et certifications comme PMI-ACP®.

Je suis certain qu’il ne s’agit pas d’un renoncement du PMI aux approches prédictives qui, après avoir fait sa renommée et sa réussite, restent très pertinentes dans de nombreux projets. Nous sommes plutôt dans une évolution naturelle et d’une preuve supplémentaire d’ouverture de cette belle organisation à toute approche qui permet de servir au mieux tous les types de projets, en particulier de développement de nouveaux produits et services.

J’essaie depuis de nombreuses années de vous faire découvrir les bénéfices de l’agilité et de l’hybridation dans votre management de projets à travers les témoignages de nombreux experts, praticiens, livre blancs…

J’espère pouvoir vous faire bénéficier d’encore plus de matériels (en particulier en français) grâce à cette combinaison attendue des savoirs et expériences.

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

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes dont PMI ACP !

Comment manager la dette technique sans tout bloquer ?

Manager la dette technique de votre projet et/ou produit est nécessaire et même vital, mais vous ne pouvez pas tout mettre en pause juste pour la rembourser.

How to manage technical debt par Sharad Vijalapuram

https://www.mindtheproduct.com/how-to-manage-technical-debt/

Sans ralentir le développement des produits

Manager la dette technique, c’est comme entretenir une maison dans laquelle vous vivez : C’est nécessaire, mais vous ne pouvez pas tout mettre en pause juste pour faire des réparations. Dans cet article, nous aborderons des approches pratiques pour traiter la dette technique tout en garantissant que le développement de produits continue à toute vitesse.

Chaque ligne de code est livrée avec un choix : Aller vite ou la construire correctement. La plupart des équipes choisissent la vitesse, et pour une bonne raison : Les opportunités business n’attendent personne. La dette technique s’accumule grâce à ces décisions précipitées, ces moments « on y reviendra plus tard » qui vous ont aidé à respecter une échéance critique ou à saisir une opportunité de marché. Mais à l’instar de son homologue financier, la dette technique s’accumule. Chaque correctif rapide et solution de contournement ajoute du poids à votre base de code jusqu’à ce qu’un jour, votre équipe se retrouve à pédaler dans la mélasse alors qu’elle avait l’habitude de sprinter.

Le véritable art n’est pas d’éviter la dette technique, mais de la gérer de manière stratégique.

Les meilleures équipes produit ont appris à trouver cet équilibre, à maintenir leur vitesse tout en empêchant la dette technique d’atteindre une masse critique. Voyons comment maîtriser cet exercice d’équilibre.

Identifiez et priorisez la dette technique

Toutes les dettes techniques ne sont pas égales. Comme pour la dette financière, il y a les bonnes dettes (pensez aux prêts immobiliers qui construisent votre patrimoine) et les mauvaises dettes (comme les cartes de crédit à taux d’intérêt élevé qui échappent à tout contrôle). L’essentiel est de savoir laquelle est laquelle.

Travaillez avec votre équipe d’ingénierie pour classer votre dette technique en trois catégories :

#1 – Blocages critiques

  • Ce système d’authentification tient ensemble par des bouts de ficelle.
  • La base de données atteint 90 % de sa capacité maximale toutes les deux semaines.
  • Une API (application programming interface ou « interface de programmation d’application ») tierce pourrait disparaître d’un jour à l’autre.

#2 – Des inquiétudes croissantes

  • Testez les lacunes de couverture dans les fonctionnalités de base.
  • Ce monolithe qui devient de plus en plus difficile à mettre à jour.
  • Les problèmes de performances qui n’affectent que les utilisateurs expérimentés.

#3 – Des correctifs intéressants

  • Une documentation obsolète.
  • De la duplication mineure de code.
  • Le framework d’interface utilisateur qui est juste un peu en retard sur la dernière version.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Concentrez votre énergie sur l’endroit où le retour sur investissement est le plus élevé.

Une base de code désordonnée qui fournit toujours de la valeur de manière fiable pourrait être moins urgente à revoir qu’un système d’apparence propre qui n’est qu’à un client majeur de s’effondrer.

Équilibrez la dette avec le développement de fonctionnalités.

L’éternelle lutte dans le développement de produits n’est pas de savoir s’il faut s’attaquer à la dette technique, mais quel effort lui consacrer. Dans notre exemple précédent d’entretien d’une maison dans laquelle vous vivez, vous ne pouvez pas arrêter de vivre dans la maison pour faire des réparations, mais vous ne pouvez pas non plus ignorer les signes avant-coureurs pour toujours. Le moment idéal ? De nombreuses équipes performantes le trouvent dans la « règle des 80/20 » :

Consacrez 20 % de chaque sprint à la maintenance du système tout en conservant votre moteur principal – le développement de fonctionnalités – à 80 % de sa puissance.

Il ne s’agit pas simplement de choisir un nombre arbitraire. Il s’agit de créer un rythme durable où la gestion de la dette technique devient aussi naturelle que votre stand-up quotidien. Lorsque vous intégrez la réduction de la dette dans votre flux de travail habituel plutôt que de la traiter comme un monstre distinct à combattre, vous maintenez l’élan tout en gardant votre base de code saine.

Communiquez sur la valeur commerciale de la gestion de la dette technique.

La gestion de la dette technique, c’est comme maintenir votre crédit auprès de vos parties prenantes : Vous devez parler leur langue pour obtenir leur adhésion. Alors que votre équipe d’ingénieurs s’embarrasse de code spaghetti et de dépendances vieillissantes, vos leaders se concentrent sur une chose : L’impact sur l’entreprise. La clé ? Transformez la dette technique d’un problème d’ingénierie en un récit d’entreprise.

Peignez le tableau en des termes qu’ils ne peuvent ignorer :

  • Ce retard de trois mois dans les fonctionnalités ? Il ne s’agissait pas seulement d’un code complexe, mais d’une perte de revenus potentiels de 200 000€.
  • La récente interruption de production n’a pas seulement frustré l’équipe d’ingénierie, elle vous a coûté 50 clients premium.
  • La capacité de mises à jour rapides de fonctionnalités de votre concurrent ne concerne pas seulement la taille de l’équipe, mais aussi une base de code plus propre et plus adaptable.

Lorsque vous formulez la dette technique en termes d’opportunités de marché manquées, de désabonnement de clients et d’avantage concurrentiel, ces sprints de re-factorisation ne ressemblent soudainement plus à de l’indulgence d’ingénierie. Ils deviennent des investissements stratégiques. Votre rôle est de faire le lien entre ces points, en montrant comment la dette technique d’aujourd’hui devient le handicap business de demain.

Créez une culture d’amélioration continue.

La santé du code, comme les bonnes habitudes, se construit quotidiennement. Il ne s’agit pas tant de sprints de nettoyage héroïques que de petits choix que votre équipe fait chaque jour : Le test unitaire supplémentaire écrit, la refonte rapide lors de la création d’une fonctionnalité, la révision de code réfléchie qui permet de détecter un futur casse-tête.

Créez un environnement où la qualité n’est pas seulement prêchée, mais célébrée.

Faites en sorte qu’il soit facile de faire ce qu’il faut.

  • Contrôles automatisés de la qualité du code qui détectent les problèmes à un stade précoce.
  • Modèles pour du code propre et cohérent.
  • Documentation claire et réellement tenue à jour.
  • Directives de révision de code qui mettent l’accent sur la maintenabilité.

Célébrez les victoires invisibles.

  • Citez l’ingénieur qui a nettoyé en ajoutant des fonctionnalités.
  • Partagez des indicateurs sur la réduction des taux de bogues et l’accélération des déploiements.
  • Soulignez comment un code propre a permis une réponse rapide au besoin du business.
  • Documentez le temps économisé grâce aux efforts de refactorisation précédents.

Pensez-y comme à une cuisine professionnelle : Les meilleurs chefs nettoient pendant qu’ils cuisinent. Ils n’attendent pas que toute la vaisselle s’empile, car ils savent qu’une cuisine propre signifie une sortie plus rapide, meilleure et plus fiable. Votre base de code mérite le même respect.

Établissez une stratégie de dette technique à long terme.

Considérez la gestion de la dette technique comme un jardin, pas comme le nettoyage du garage. Vous n’attendez pas que les mauvaises herbes prennent le dessus sur tout. Vous vous en occupez régulièrement, en l’intégrant à votre rythme quotidien plutôt qu’à une refonte saisonnière massive.

Le succès réside dans la systématisation et la mesure de la gestion de la dette.

  • Mettez en place des « moniteurs de santé » qui intéressent votre équipe :
    • Combien de temps faut-il pour intégrer un nouveau développeur ?
    • Quel est votre ratio entre les travaux prévus et les travaux d’urgence ?
    • En combien de temps pouvez-vous livrer un correctif critique ?
    • À quelle fréquence les mêmes zones de code se brisent-elles ?
  • Créez des rituels qui restent.
    • Examens mensuels des radars techniques avec vos responsables techniques.
    • « Fix it Fridays » où les équipes s’attaquent à l’endettement dans des domaines critiques.
    • Présentations trimestrielles sur la santé technologique aux parties prenantes
    • Métriques de qualité du code dans les revues de sprint.

L’objectif n’est pas la perfection, c’est le progrès durable. Lorsque la gestion des dettes devient aussi routinière que vos réunions quotidiennes, vous avez craqué le code. Votre futur moi (et votre équipe) vous remercieront lorsqu’une nouvelle opportunité de marché urgente ne sera pas entravée par des limitations techniques.

La voie à suivre.

Considérez la dette technique comme le score de crédit d’un produit : Tout le monde en a un, mais les équipes qui réussissent savent comment le maintenir au bon niveau. Il ne s’agit pas d’avoir zéro dette ; Il s’agit de faire des choix stratégiques qui maintiennent l’agilité de votre produit et la motivation de votre équipe.

La sauce secrète ? Une approche en trois volets.

  1. Rendez la dette visible.

    • Suivez-la comme vous suivez les fonctionnalités.
    • Mesurer son impact sur la rapidité de livraison.
    • Célébrez lorsque vous remboursez de la dette.
  2. Choisissez vos batailles.

    • Corrigez ce qui fait le plus mal.
    • Attaquez-vous à la dette qui bloque l’innovation.
    • Fusionnez les améliorations dans le travail sur les fonctionnalités.
  3. Adoptez des habitudes saines.

    • Nettoyez pendant que vous codez.
    • Examinez rétrospectivement l’impact de la dette.
    • Partagez les victoires et les leçons apprises.

N’oubliez pas : L’excellence technique n’est pas une question de perfection, mais de progrès. Les meilleurs produits ne sont pas ceux qui n’ont aucune dette technique ; Ce sont ceux où les équipes choisissent consciemment quelle dette contracter et laquelle rembourser.

Tout comme un investisseur intelligent équilibre croissance et stabilité, les équipes de produits intelligentes équilibrent vitesse et durabilité. Votre futur moi vous remerciera lorsque cette demande de fonctionnalité révolutionnaire vous arrivera, et que votre équipe pourra la livrer en quelques semaines au lieu de plusieurs mois.

Vendez Agile à vos prospects et clients.

Vendre le travail en approche Agile à vos interlocuteurs est SIMPLE.

Sell Agile to Customers par Zuzi Sochova

https://agile-scrum.com/2024/12/11/sell-agile-to-customers/

Les gens me demandent souvent comment vendre une approche de travail agile à leurs clients. En particulier aux clients qui sont habitués à une méthode de travail traditionnelle, aux clients qui sont habitués à définir leurs exigences et à la définition figée de la portée, du temps et du budget, et aux clients qui sont habitués à une phase d’analyse initiale importante.

Ne vous attendez pas à de la magie. Vendre est simple.

Tout ce que vous avez à faire est de montrer la valeur. Montrez-leur ce qui les attend. Parce que s’ils ne comprennent pas le type de valeur qu’ils obtiennent avec cette nouvelle façon de travailler, tout ce qu’ils ont, c’est peur. Peur de l’inconnu, peur de l’échec, peur du changement. Commencez toujours par le pourquoi. Aucun changement ne se produira à moins que vous ne créiez un sentiment d’urgence.

La valeur qu’ils obtiennent variera en fonction de la situation et de leur expérience, donc mon meilleur argumentaire de vente commence toujours par des questions.

  • Que diriez-vous de votre expérience actuelle ?
  • Quelles sont les douleurs typiques ?
  • Qu’est-ce qui marche bien ?
  • Qu’est-ce qui est important pour vous ?

J’essaie d’être ouverte à de nouvelles perspectives et curieuse de leur situation. Ensuite, sur la base de ce qu’ils disent, j’essaie de proposer une nouvelle façon de travailler.

« Nous faisons *quelque chose de différent* afin que *ceci* et *cela* ne se produisent pas. »

Plus vous vous rapprochez de leur langage, mieux c’est. En règle générale, vous devez adresser les problèmes suivants: Le manque de transparence, l’incompréhension des besoins du client, le non-respect du budget et/ou des problèmes de qualité.

Ils demandent aussi souvent une référence, alors soyez prêt à en donner une.

Le plus important est que vous ne pouvez vendre que des choses en lesquelles vous croyez vraiment. Il est bon d’avoir déjà une certaine expérience, non seulement pour avoir une référence, mais aussi pour votre confiance en vous. Il est toujours visible à partir de votre langage corporel de voir si vous y croyez ou pas.

De plus, il est difficile de répondre à leurs questions curieuses de détails sur votre travail si vous ne l’avez jamais expérimenté.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Collaboration agile : Qu’est-ce que c’est, comment cela se ressent et pourquoi est-ce si important ?

La collaboration agile est difficile, mais réalisable !

Agile Collaboration: What It Is, How It Feels, and Why It Matters par Mike Cohn

https://www.mountaingoatsoftware.com/blog/agile-collaboration-what-it-is-how-it-feels-and-why-it-matters

Le travail d’équipe et la collaboration sont des pratiques essentielles à cultiver dans les projets agiles.

Qu’est-ce que la collaboration agile ?

La collaboration agile est la pratique de travailler ensemble efficacement au sein d’un cadre agile, comme Scrum, pour atteindre des objectifs communs. La collaboration agile consiste à favoriser une culture d’équipe performante où les membres de l’équipe travaillent ensemble, se responsabilisent mutuellement et s’améliorent continuellement grâce à des objectifs communs et à un soutien mutuel.

Comment se ressent la collaboration dans les équipes agiles ?

Une métaphore courante de la collaboration d’équipe agile est celle d’un équipage d’aviron : 8 personnes tirant chacune une rame dans une coquille de noix.

À moins que vous n’ayez fait partie d’un équipage d’aviron, vous ne savez peut-être pas à quel point cela capture parfaitement le sens et l’esprit de la collaboration agile.

Les rameurs utilisent le terme swing pour désigner un équipage dont les membres sont tous parfaitement synchronisés. Et je veux dire parfaitement synchronisé. Cela signifie que chaque rameur :

  • Met une rame dans l’eau exactement au même moment,
  • tire sur le même temps et la même distance à la même vitesse,
  • soulève la rame hors de l’eau en même temps, et
  • glisse vers l’avant au même rythme.

Le swing n’arrive pas très souvent. Quelqu’un est généralement décalé d’une fraction de seconde à un moment donné à chaque coup de rame, et c’est suffisant pour que tout le monde dans l’embarcation le ressente. Quand je ramais, notre bateau aurait pu faire une course entière sans avoir une seule fois vraiment atteint son swing.

(Oui, c’était généralement de ma faute. Merci d’avoir posé la question.)

Avantages de la collaboration agile

Il y a beaucoup de bons résultats lorsqu’une équipe interfonctionnelle permet d’obtenir la sensation de swing qui découle de la collaboration en travail d’équipe agile.

Passages de relais petits et fréquents. Les transferts de travail entre les membres de l’équipe sont fréquents, petits et sans tambour ni trompette, car les tâches sont conçues pour se chevaucher. Les membres de l’équipe deviennent comme des couples qui sont ensemble depuis assez longtemps pour qu’ils terminent la … (Avez-vous terminé ma phrase pour moi ?). Mais, au lieu de finir les phrases de l’autre, ils finissent le travail de l’autre.

Des meetings courts et précieux. Quand les équipes réussissent le swing de collaboration interfonctionnelle, les réunions sont courtes et précieuses car les boucles de rétroaction sont courtes et se déroulent en temps réel. Les membres de l’équipe travaillent ensemble et communiquent souvent, de sorte que la plupart des gens sont déjà à niveau, ainsi les réunions peuvent se concentrer sur ce qui compte.

Planification collaborative. Les équipes travaillent vers un objectif, et elles atteignent généralement cet objectif. Lorsqu’elles n’atteignent pas un objectif, tout le monde (y compris les leaders) le comprend, les objectifs ne sont pas des garanties.

État d’esprit essayer-et-voir. Dans les cultures agiles et collaboratives, c’est l’état d’esprit d’essayer et voir qui prévaut. Au lieu de se disputer sur des pratiques (telles que les témoignages d’utilisateurs par rapport aux histoires utilisateurs ou points d’histoire par rapport au temps nécessaire) ou des cadres de travail (Scrum vs. SAFe vs. Kanban), les équipes expérimentent et décident elles-mêmes de ce qui fonctionne le mieux.

Environnement de travail amusant et engageant. Dans une équipe agile en plein essor, les membres de l’équipe s’amusent. Je décrie parfois le fait que le travail s’appelle travail. Je veux sincèrement que le travail soit amusant. Je ne suis pas naïf : Je sais que ce ne sera pas toujours le cas. Mais quand une équipe travaille bien ensemble, c’est amusant.

Un succès inévitable. Enfin, avec le swing, il y a un sentiment que le succès est inévitable. Au fur et à mesure qu’une équipe Scrum apporte de plus en plus de valeur, obtenant résultat après résultat, l’équipe commence presque à se considérer comme inarrêtable.

La collaboration agile est difficile, mais réalisable

Réaliser tout cela n’est pas facile, tout comme il n’est pas facile pour une équipe d’aviron de se synchroniser parfaitement. Mais lorsqu’une équipe collabore bien, c’est un signe que vous avez construit une équipe agile réussie.

En tant qu’entreprise, Mountain Goat Software a la chance de travailler avec de nombreuses équipes agiles différentes, en les formant pour améliorer la collaboration et trouver leur équilibre.

Mountain Goat Software a appris qu’il n’y a pas de voie unique pour y parvenir. Certaines équipes ont besoin d’affiner leur compréhension de l’agilité, d’autres doivent écrire ensemble de meilleures histoires d’utilisateurs ou collaborer sur des plans agiles.

5 facteurs clés pour une hiérarchisation efficace de l’arriéré de produit (Product Backlog)

Pensez d’abord à la valeur et aux coûts, puis tenez ensuite compte d’autres facteurs qui affectent la priorité d’un élément du product backlog : L’apprentissage, le risque et les dépendances.

5 Key Factors for Effective Product Backlog Prioritization par Mike Cohn

https://www.mountaingoatsoftware.com/blog/5-key-factors-for-effective-product-backlog-prioritization

Les arriérés de produits (product backlog) contiennent toutes les fonctionnalités connues qui finiront par se retrouver dans le produit. Qu’il s’agisse d’histoires utilisateur (user stories), d’histoires métier (job stories) ou d’une simple phrase ou deux, il est essentiel d’ordonner le backlog afin que les équipes construisent toujours les fonctionnalités les plus prioritaires. En plus de créer les bonnes fonctionnalités, il est important de les construire dans le bon ordre. Voici les 5 éléments clés à prendre en compte lorsque vous réfléchissez à la façon de hiérarchiser le backlog produit.

Facteur #1 : La Valeur

Commençons par le gros problème : la valeur. Et bien qu’il soit évident de considérer la valeur d’une fonctionnalité, « valeur » est un terme nébuleux.

La valeur est une mesure de l’utilité ou de l’impact sur un public particulier. La plupart des travaux qu’une équipe de développement agile entreprendra seront précieux pour les utilisateurs. Mais d’autres travaux peuvent être précieux seulement pour l’équipe elle-même. D’autres travaux seulement pour certains utilisateurs, parties prenantes et membres de l’équipe.

Par exemple, considérez la refactorisation ou réusinage de code ( le refactoring ) : Améliorer la structure mais pas le comportement du code. Parce qu’elle rend le code plus facile à maintenir ou à modifier, la refactorisation est d’une grande valeur pour les développeurs.

Le coût de la refactorisation est généralement justifié, cependant, car il profite également aux utilisateurs. Si le code est plus facile à maintenir, les utilisateurs devraient rencontrer moins de bogues. De même, un code amélioré signifie que les utilisateurs devraient recevoir un peu plus rapidement les nouvelles fonctionnalités dans ce domaine du produit. (Pour plus de façons de justifier la priorisation de la refactorisation, voir « 4 Ways to Persuade a Product Owner to Prioritize Refactoring. »)

Lorsque l’on réfléchit à la valeur d’une fonctionnalité, il peut être important de réfléchir à la façon dont la valeur d’une fonctionnalité se dégrade au fil du temps. Une fonctionnalité peut être très précieuse aujourd’hui, mais beaucoup moins précieuse plus tard.

L’un des exemples les plus forts que j’ai vus de cela est survenu lorsque je travaillais avec une équipe créant des logiciels pour soutenir les ligues de sports. Certaines fonctionnalités devaient être présentes le jour du repêchage, lorsque tous les joueurs sélectionnaient leur équipe. Si la fonctionnalité n’était pas disponible le jour du repêchage, les joueurs formeraient probablement leur ligue sur une autre plateforme. Le coût du retard dans ce cas était énorme.

Facteur #2 : Le Coût

La deuxième chose à considérer lors de l’établissement des priorités est le coût. Le coût le plus important est généralement l’effort de l’équipe produit pour développer une fonctionnalité. La plupart des équipes utilisent des story points pour estimer l’effort des éléments du backlog produit. D’autres estiment cet effort en jours-personnes, en temps idéal ou en d’autres unités similaires.

Dans certains cas, il peut y avoir des coûts supplémentaires qui doivent être pris en compte. Une considération commune actuelle ? Le coût permanent de la fourniture de fonctionnalités qui reposent sur divers produits d’IA. Ces produits incluent souvent de petits frais à l’utilisation, mais ceux-ci peuvent certainement s’additionner à grande échelle.

Quelle que soit l’unité dans laquelle une équipe estime les éléments de son backlog produit, le coût de développement et de support d’une fonctionnalité doit être pris en compte dans la priorité d’un élément. Par exemple, un élément qu’une équipe estime à 5 doit être prioritaire par rapport à une fonctionnalité estimée à 20 si toutes choses sont égales par ailleurs. Cela est vrai quelle que soit l’unité d’estimation utilisée par l’équipe.

Facteur #3 : L’Apprentissage

Un troisième facteur à prendre en compte lors de l’établissement des priorités est le suivant : Qu’est-ce qu’une équipe apprendra en effectuant un élément particulier du backlog de produit ? Si vous apprenez quelque chose en développant un élément du backlog, vous voudrez probablement développer cet élément tôt afin d’avoir le temps d’agir sur ce que vous avez appris.

Si vous apprenez quelque chose trop tard, vous n’aurez pas le temps de profiter des nouvelles connaissances.

L’apprentissage peut prendre deux formes. Il peut s’agir du produit ou du projet.

Apprendre à connaître le produit

L’apprentissage du produit se produit lorsque l’équipe développe une fonctionnalité et reçoit des commentaires à son sujet.

Si les utilisateurs aiment la fonctionnalité, privilégiez l’amélioration de la fonctionnalité ou la création d’autres choses similaires. Si les utilisateurs ne l’aiment pas, envisagez de supprimer la fonctionnalité ou de réduire la priorité des fonctionnalités associées.

En savoir plus sur le projet

L’apprentissage du projet fait référence aux connaissances que les membres de l’équipe acquièrent sur la façon de développer le produit ou la solution. Par exemple, supposons qu’une équipe ait l’intention de construire une partie d’un produit à l’aide d’une technologie que ses membres n’ont jamais utilisée auparavant.

Lorsque les membres de l’équipe développent le premier élément du backlog de produit à l’aide de cette nouvelle technologie, ils apprennent des choses à ce sujet, telles que :

  • La technologie fonctionne-t-elle comme promis ?
  • Les estimations relatives à l’utilisation de la nouvelle technologie devraient-elles être révisées ?
  • La technologie peut-elle être utilisée dans d’autres parties du produit ou du projet ?

N’oubliez pas le fait d’apprendre lorsque vous pensez à la hiérarchisation agile du backlog. Le potentiel d’une fonctionnalité à enseigner à l’équipe et à ses parties prenantes quelque chose sur les besoins des utilisateurs ou les réalités du projet peut être une raison suffisante pour en faire une priorité absolue.

Facteur #4 : Le Risque

Le quatrième facteur à prendre en compte lors de l’établissement des priorités est le risque inhérent à l’élaboration de l’élément du backlog produit. Si quelque chose est risqué et que vous devez le faire, faites-le tôt. Vous voulez savoir si ce risque va se matérialiser.

D’un autre côté, si une fonctionnalité est risquée et que vous n’avez peut-être pas besoin de la développer, retardez le travail dessus jusqu’à ce qu’il devienne clair que vous devez la faire.

Facteur #5 : Les Dépendances

Le dernier facteur que vous devez prendre en compte lors de la hiérarchisation des priorités est les dépendances entre les éléments du backlog produit. Certains items ne sont peut-être pas prioritaires en soi, mais ils sont nécessaires à la livraison d’autres articles. Lorsque c’est le cas, l’élément d’activation mais moins prioritaire doit être déplacé plus haut dans le backlog afin d’être terminé avant que l’élément n’en dépende.

À titre d’exemple, considérez un camp d’été où j’ai aidé à utiliser Scrum. Parmi les éléments de l’arriéré de produits, il y avait « peindre tous les canots ». C’était une priorité élevée, car ils voulaient montrer des photos de canoës brillants et nouvellement peints dans leur marketing.

Mais peindre les canots dépendait d’un autre élément de l’arriéré de produit : Poncer et réparer les canoës qui en avaient besoin.

Techniquement, la réparation des canoës n’avait pas besoin d’être effectuée avant un jour ou deux avant l’ouverture du camp d’été, mais cet élément était prioritaire dans le backlog des produits car les photos marketing des canoës devaient être prises bien avant cela.

Techniques formelles de hiérarchisation de l’arriéré

Il existe de nombreux cadres de travail pour la hiérarchisation afin de vous aider à comparer ces facteurs les uns par rapport aux autres de manière plus granulaire, notamment le modèle de Kano, le modèle de notation RICE et la pondération relative. Même avec ces méthodes formelles, lors de la création d’une feuille de route de produit, les facteurs que j’ai énumérés ici doivent être pris en compte, même s’ils ne font pas explicitement partie de ces modèles.

Cependant, vous pouvez obtenir un classement des éléments du backlog de produit en réfléchissant simplement à ces cinq facteurs. Lorsque vous faites cela, je ne vous recommande pas de les combiner avec une formule sophistiquée.

La valeur d’une fonctionnalité et son coût, c’est-à-dire nos premier et deuxième facteurs, sont les plus importants. Établissez donc d’abord les priorités en fonction du coût et de la valeur, en utilisant les trois autres facteurs (apprentissage, risque et dépendances) pour ajuster les priorités et résoudre les conflits.

Par exemple, supposons qu’un propriétaire ou un chef de produit ait hiérarchisé un élément de sorte qu’il ne soit pas terminé avant trois ou quatre autres itérations en fonction de sa valeur et de son risque. À ce stade, tenez compte de l’apprentissage, des risques et des dépendances. Avancez l’élément d’une itération ou deux si l’un de ces facteurs est significatif.

5 facteurs pour une hiérarchisation efficace des priorités

Dans les équipes agiles et Scrum,  les product owners sont chargés de tenir le backlog produit ordonné par priorité. Une façon simple d’aborder cela, sans utiliser de techniques formelles de hiérarchisation du backlog de produit, est de garder cinq facteurs à l’esprit. Pensez d’abord à la valeur et au coût. Tenez ensuite compte d’autres facteurs qui affectent la priorité d’un élément du backlog produit : L’apprentissage, le risque et les dépendances.

Lorsque vous le faites dans le cadre de vos efforts de planification agile , vos équipes ne se contenteront pas de construire les bonnes choses, elles les construiront dans le bon ordre.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

L’adoption de la méthode agile et les avantages de la transformation agile par Roy Schilling

Les transformations agiles peuvent être coûteuses, voire très coûteuses, et provoquer d’importantes perturbations au sein d’une organisation. Il faut donc se demander pourquoi les entreprises voudraient s’engager dans cette voie.

Bien qu’il y ait de nombreux avantages à passer à l’Agile, les organisations choisissent souvent les mauvais objectifs, ou ne vont pas assez loin pour réaliser ces avantages, échouent généralement (à un certain niveau) ou en tout cas se désillusionnent et se replient sur des méthodes familières. S’agit-il vraiment de « faire de l’agile » ou plutôt d’agilité et d’amélioration de la flexibilité ?

Lire le document complet: L’adoption de la méthode Agile et les avantage de la transformation.


Roy Schilling, CSP-SM, CSP-PO, ACP, ICP, ICP-ACC, PSM

Coach/formateur Agile

Depuis plus de 20 ans, Roy Schilling travaille avec des organisations pour mettre en place des équipes et des organisations performantes en utilisant les méthodologies Agile et Lean. Roy est un coach et un formateur agile expérimenté, doté de solides qualifications techniques et de leadership, avec plus de 30 ans d’expérience dans la planification stratégique, le développement d’équipes, la gestion de projets et de produits et les stratégies d’ingénierie des systèmes. Roy a prouvé sa capacité à analyser avec succès les problèmes critiques d’une organisation, à identifier les déficiences et les opportunités, et à développer des solutions innovantes et rentables pour améliorer la compétitivité et l’efficacité. Roy a travaillé dans de nombreux secteurs, notamment dans l’administration publique, les services financiers, l’assurance et l’industrie manufacturière.

 

Aussi agile que possible : Des techniques avancées pour la réussite de votre projet agile.

L’agilité va au-delà des principes de base de Scrum et Kanban. Pour exceller avec Agile, les équipes doivent adopter des comportements et des techniques qui améliorent la flexibilité, la collaboration et la réactivité.

As Agile as Possible: Advanced Techniques for Agile Project Success  par Bonnie Biafore

https://www.bonniebiafore.com/as-agile-as-possible-advanced-techniques-for-agile-project-success/

Voici des stratégies pour améliorer le succès des projets Agile.

Prévoyez plus de temps pour l’apprentissage.

Résistez à la tentation de vous précipiter vers le sprint suivant. Donnez à votre équipe agile le temps d’apprendre de chaque itération et de s’adapter. Soutenez la capacité des membres de l’équipe à examiner régulièrement leurs processus et leurs résultats, à identifier les domaines à améliorer et à mettre en œuvre des changements. Cela offre des avantages tels qu’une efficacité accrue, l’innovation et la créativité.

Étendez les processus de rétroaction des parties prenantes.

Engagez-vous activement dans les processus de collecte et d’intégration des commentaires des parties prenantes en dehors de l’équipe agile. Allez au-delà des revues de fin de sprint. Amorcez un dialogue continu avec les clients pour vous assurer que les livrables évoluent en fonction des attentes des parties prenantes. Non seulement cela permet de créer de meilleurs produits, mais cela minimise les risques liés à l’utilisateur final et garantit que les livrables s’alignent sur les objectifs business.

Mettez en place des outils de collaboration (même si vous pensez qu’ils ne sont pas nécessaires).

De nombreux bons outils de collaboration sur le marché facilitent la communication et la coordination entre les membres de l’équipe. Ceux-ci aident à la fois les équipes colocalisées et virtuelles. Les outils qui prennent en charge les mises à jour en temps réel, la gestion intégrée des tâches et les réunions virtuelles peuvent améliorer considérablement la capacité de l’équipe à travailler de manière cohérente et à réagir rapidement aux changements. Ils fournissent également des informations de statut faciles à comprendre pour toutes les parties prenantes.

Augmentez l’utilisation de membres d’équipe interfonctionnels.

Le cœur des méthodologies agiles est l’expansion des capacités et de la liberté de pensée des membres de l’équipe. Plus les compétences et l’expérience de ces membres de l’équipe sont larges, plus ils apportent de contributions au projet. Cherchez à développer vos équipes agiles avec une portée aussi large que possible. Cela réduit les dépendances vis-à-vis des équipes externes et accélère la résolution des problèmes. En outre, cela permet aux membres de l’équipe d’élargir leurs compétences et leurs connaissances business pour assumer plusieurs rôles dans de futurs projets.

Faites appel à un large éventail de parties prenantes de haut niveau pour hiérarchiser votre arriéré de produit, le backlog.

La prise en compte de nombreux points de vue dans la hiérarchisation des priorités permet de s’assurer que les fonctionnalités à plus forte valeur ajoutée sont livrées en premier. De plus, ne sautez pas les réévaluations programmées du backlog produit. De toute façon, l’équipe s’attaquera toujours à des fonctionnalités qui ont un impact significatif sur les objectifs tactiques et stratégiques.

Si vous travaillez sur des projets agiles, évaluez c omment votre environnement gère ces stratégies. Pouvez-vous trouver des moyens de vous améliorer ?

Pour en savoir plus sur les stratégies agiles, consultez le cours Agile Foundations de Doug Rose.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Nouvelle certification professionnelle PMI Agile Certified Practitioner (PMI-ACP®)

Les organisations qui adoptent l’agilité et l’adaptabilité surpassent les autres. La demande de professionnel(le)s agiles étant en plein essor, la certification PMI-ACP vous sera plus précieuse que jamais.

Pour tout savoir, consultez le site du Project Management Institute !

Le PMI-ACP est-il fait pour vous ?

Cette certification est développée par des pratiquant(e)s leaders de l’agilité et vous donnera le bon état d’esprit pour appliquer efficacement les principes, ainsi que les outils et les compétences Agiles nécessaires pour collaborer dans n’importe quel environnement et organisation.

Quel sera votre parcours vers la certification PMI-ACP ?

Avant de postuler, assurez-vous de répondre aux exigences de certification.

Le PMI® a toujours fait la promotion d’une approche du management de projet fondée sur des principes sans être lié à une méthodologie spécifique.

C’est au professionnel du management de projets que vous êtes ou deviendrez que revient de choisir la bonne approche en fonction du contexte spécifique de votre projet.

Tout l’environnement est alors à considérer, l’industrie, les objectifs de l’organisation de du projet au sein de celle-ci, vos parties prenantes, l’environnement concurrentiel, la composition et les compétences de votre équipe, la culture de votre entreprise…

La certification PMP basée sur le référentiel de bonnes pratiques PMBOK® nécessite une solide compréhension du panel d’approches, prédictives comme adaptatives, et de plus en plus souvent hybride.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes dont PMI ACP !

Le PMI-ACP va plus loin que le PMP® dans les nombreuses approches Agiles et vous dote d’une base solide en matière d’agilité en entreprise et d’entreprise Agile. PMI-ACP a été profondément remanié avec un parcours d’apprentissage complet, du cours d’apprentissage en ligne à l’examen accrédité ISO.

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

PS : Pour les PMP et autres managers de projet habitués à un environnement plus traditionnel qui souhaitent s’adapter à une approche plus agile : Le Guide Agile Practice Guide fournit des outils et une compréhension des différentes approches agiles disponibles

Valeurs Scrum pour les équipes produit par Sam Adesoga

Scrum constitue une base solide pour construire une culture de confiance et de collaboration.

https://samadesoga.me/posts/scrum-values-for-product-teams/

Les équipes produit sont soumises à une pression croissante pour offrir de la valeur qui satisfasse leurs clients et répondre de manière proactive aux conditions changeantes du marché. Cependant, cela ne sera réalisé que lorsque les équipes travailleront efficacement ensemble vers des objectifs communs dans le cadre d’une culture de confiance et de collaboration. Bien que je ne recommanderais pas le cadre Scrum à toutes les équipes ; Je crois que la valeur Scrum constitue une base solide pour construire la culture de confiance et de collaboration requise.

Pourquoi les valeurs sont importantes pour chaque équipe produit

Les valeurs jouent un rôle fondamental dans la dynamique de tout groupe et, avec l’adoption mondiale du travail à distance et une mobilité mondiale accrue, les équipes produit sont souvent diversifiées et cross-fonctionnelles par nature. Lorsque ces équipes ne disposent pas d’un ensemble explicite de valeurs partagées, chaque membre doit fonctionner en fonction de ses propres valeurs personnelles et de ses hypothèses sur « ce qui est juste ». Cela peut conduire à des malentendus, à des priorités mal alignées et à des conflits.

Par exemple, un membre de l’équipe peut donner la priorité à la production plutôt qu’au maintien de la qualité des produits, tandis qu’un autre peut se concentrer sur l’innovation au détriment de la rapidité. En l’absence d’un cadre convenu, ces valeurs divergentes peuvent causer des frictions et avoir un impact sur l’efficacité de l’équipe. Comme vous l’avez déjà deviné, cela conduit à une mauvaise communication, une confiance réduite et une équipe inefficace.

C’est là que les valeurs Scrum peuvent servir de guide, en veillant à ce que chaque membre de l’équipe, quelles que soient ses inclinations individuelles, s’aligne sur un ensemble commun de principes qui soutiennent une collaboration efficace et la livraison de produits de haute qualité pour leurs clients.

Les valeurs de Scrum

Les valeurs Scrum – engagement, concentration, ouverture, respect et courage – pourraient servir de cadre éthique pour les équipes de produit, favorisant un environnement de collaboration, de transparence et de respect.

Approfondissons ces valeurs et voyons comment elles peuvent améliorer les performances de n’importe quelle équipe produit :

Engagement : L’équipe produit s’engage à atteindre ses objectifs et est responsable de sa contribution aux résultats communs. Lorsque les équipes incarnent l’engagement, elles développent un sentiment de fiabilité et de confiance. Même lorsque les choses se compliquent, les membres de l’équipe s’auto-débrouillent pour surmonter les défis, en s’assurant que les objectifs soient atteints. L’équipe doit éduquer et prendre des engagements transparents envers ses parties prenantes, car cela peut être utilisé comme un levier à l’avenir. L’engagement est crucial pour l’adoption de tout processus itératif qui devrait fournir une valeur cohérente aux clients.

Concentration : La valeur de la concentration complète l’engagement et permet aux équipes de concentrer leurs efforts sur les priorités les plus importantes, c’est-à-dire les objectifs. Les équipes produit sont distraites par la multitude de demandes et de requêtes ad hoc émanant des parties prenantes. Pourtant, en incarnant une valeur de concentration partagée, les équipes peuvent minimiser les perturbations et s’assurer qu’elles canalisent leur énergie et leurs ressources vers l’obtention des résultats les plus percutants pour les clients. Les équipes qui n’ont pas une compréhension commune de l’objectif se dispersent entre plusieurs tâches/projets, ce qui conduit à l’épuisement professionnel et à un travail de moindre qualité.

Ouverture : L’ouverture favorise une culture de transparence et d’honnêteté, où les membres de l’équipe se sentent en sécurité pour exprimer leurs pensées, partager leurs préoccupations et exprimer des idées novatrices. Les équipes qui incarnent l’ouverture sont plus susceptibles de communiquer les défis, les obstacles et de collaborer pour les résoudre de manière proactive avant que cela n’affecte leur capacité à respecter leur engagement. Les équipes qui incarnent l’ouverture participent activement au partage des connaissances et à l’apprentissage continu, qui sont essentiels au succès à long terme des équipes produit. D’autre part, les équipes qui manquent d’ouverture deviendront cloisonnées, les individus gardant pour eux des informations, ce qui entravera la collaboration et réduira l’efficacité de l’équipe à créer de la valeur.

Respect : Le respect garantit que la voix de chaque membre de l’équipe est entendue et valorisée ; Cela crée une culture où les différences d’opinion sont considérées comme une force et où les équipes sont en mesure de s’engager dans des débats sains, de remettre en question les hypothèses et de collaborer pour prendre de meilleures décisions. L’équipe produit doit se respecter mutuellement en tant que professionnels, respecter ses parties prenantes et respecter ses clients. Le respect des parties prenantes garantira que l’équipe est ouverte sur ses résultats, son apprentissage et s’engage à atteindre les objectifs qui ont été convenus avec les parties prenantes. Le respect des clients garantit que l’équipe produit s’engage à fournir un produit utilisable, utile et précieux à ses clients.

Courage : Le courage permet aux équipes de prendre des risques, d’accepter le changement et de se tenir mutuellement responsables. Le courage permet aux équipes de renforcer leurs engagements et de s’attaquer à des problèmes difficiles. Qu’il s’agisse de remettre en question les méthodes de travail qui ont depuis longtemps cessé de servir l’équipe, d’exprimer une opinion dissidente ou d’expérimenter une nouvelle approche, le courage est nécessaire pour stimuler l’innovation et l’amélioration continue. Sans courage, les équipes peuvent éviter les conversations difficiles, se contenter de la médiocrité ou résister aux changements nécessaires, ce qui peut entraver les progrès.

Intégrer les valeurs Scrum dans n’importe quelle équipe produit

Voici quelques moyens pratiques pour toute équipe produit d’adopter les valeurs Scrum :

  1. Créer une Charte des Valeurs : Organisez un atelier pour définir et convenir d’un ensemble de valeurs partagées. Utilisez les valeurs Scrum comme point de départ et discutez de la signification de chaque valeur dans le contexte de la configuration de votre équipe, de la nature du travail, de l’objectif commun et de la dynamique au sein de l’équipe.
  2. Les leaders modélisent les valeurs dans le comportement : Les chefs d’équipe et les managers doivent incarner les valeurs dans leurs propres actions. Lorsque les leaders font preuve d’engagement, d’ouverture, de respect, de courage et de concentration, cela donne un excellent exemple au reste de l’équipe.
  3. Encouragez la réflexion régulière : Prenez l’habitude de réfléchir à la façon dont l’équipe incarne ces valeurs. Utilisez des rétrospectives ou des cérémonies similaires pour discuter des domaines dans lesquels l’équipe excelle et de ceux où elle peut s’améliorer en accord avec ces valeurs. Partagez des histoires qui renforcent la présence ou l’absence des valeurs Scrum.
  4. Célébrez les comportements qui reflètent les valeurs Scrum : Reconnaissez et célébrez lorsque les membres de l’équipe démontrent ces valeurs. Ce renforcement permet d’ancrer les valeurs dans la culture de l’équipe.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Les valeurs Scrum sont plus qu’une simple liste de mots ; Il s’agit d’une philosophie qui favorise une culture d’équipe collaborative, performante et efficace. Qu’une équipe produit ait adopté ou non le cadre Scrum, l’incarnation de ces valeurs peut être transformatrice. Elles fournissent une base partagée qui réduit les conflits, renforce la confiance et favorise l’efficacité. En adoptant l’engagement, la concentration, l’ouverture, le respect et le courage, une équipe produit libérera son plein potentiel et offrira une plus grande valeur à ses parties prenantes et à ses clients.

Pour en savoir plus sur le cadre Scrum et ses principes associés, rejoignez l’un de nos ateliers Scrum dans les semaines à venir.


Sam Adesoga

Sam Adesoga

Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux : Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.

 

Et si vous veniez parler hybridation avec les passionné(e)s du PMI France ?

Après la publication de leur 1er guide de bonnes pratiques en management de projet, l’initiative Lab Hybrid du PMI France se retrouve pour une nouvelle saison.

Cette année  s’annonce encore riche en retours d’expérience et propice au développement de nouvelles réflexions autour de l’hybridation.

Disponible sur Amazon

Que vous soyez débutant ou expérimenté en management de projets hybrides, vous avez votre place au sein de l’équipe !

Venez échanger autour de cas pratiques découverts dans le guide ou partager votre propre expérience terrain et apprendre de nouvelles pratiques.

Pour plus d’informations ou envie de contribuer, connectez-vous sur la page  PMI France ou contactez l’équipe à l’adresse : labhybrid@pmi-france.org

Pour acheter le guide

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Daily Scrum – Un format simple pour arriver à « Done » par Sam Adesoga

Le Daily Scrum ne doit pas être ni devenir une mise à jour de statut pour le Scrum Master, le Delivery Lead ou le Product Owner !

Daily Scrum – A simple format for getting to “Done” by Sam Adesoga

https://samadesoga.me/posts/daily-scrum-getting-to-done/

Les participants à notre formation Scrum me demandent souvent quel est le format que je préfère pour un Daily Scrum. Je ne sais pas si j’ai un format préféré, mais ce n’est certainement pas : « Ce que j’ai fait hier, ce que je prévois de faire aujourd’hui et discussion sur les bloqueurs ».

Cependant, si je peux vous amener à réfléchir à l’objectif du Guide Scrum,

… pour inspecter la progression vers l’objectif de sprint et adapter le backlog de sprint si nécessaire, en ajustant le travail prévu à venir. Guide Scrum, 2020

Un bon format pourrait être :

  1. Les développeurs se remémorent l’objectif du sprint ; ce simple point de départ permet de ramener les objectifs de sprint au centre de l’attention des développeurs.
  2. Passez en revue les éléments du backlog (l’arriéré de produit) dans le Sprint ; Discutez de l’état d’avancement de ces items et soulignez tout problème concernant chacun. Il est important de toujours penser à la « définition de Done » lorsque vous discutez de l’avancement des éléments du backlog qui contribuent à l’objectif du sprint.
  3. Assurez-vous qu’il existe un plan pour progresser vers les objectifs de sprint, par exemple, en s’assurant que chaque membre de l’équipe est clair sur la voie à suivre pour atteindre l’objectif de sprint.
  4. Dans le cadre de l’élaboration du plan pour les prochaines 24 heures, les développeurs doivent prêter attention aux membres de l’équipe qui pourraient avoir besoin d’aide ; des pratiques telles que le mobbing (une approche collaborative où un groupe de membres de l’équipe, souvent l’ensemble de l’équipe, se concentre simultanément sur une seule tâche ou un seul problème) ou le pairing (la programmation en binôme est une technique de développement logiciel Agile dans laquelle deux développeurs font équipe sur un seul ordinateur. Les deux personnes travaillent ensemble pour concevoir, coder et tester des user stories) peuvent aider à faire passer des éléments spécifiques du backlog de sprint à « Done ».
  5. Passez en revue tous les autres éléments du backlog du Sprint Backlog qui ne contribuent pas nécessairement à l’objectif du produit.

Quel que soit le format que vos équipes choisissent d’adopter, il est important que les développeurs comprennent l’objectif du Daily Scrum et continuent à y trouver de la valeur. En tant que coach agile chez J P Morgan, j’ai encouragé les développeurs à réfléchir régulièrement sur le Daily Scrum, à identifier les pratiques qui ne servaient pas l’équipe et les développeurs ont expérimenté différents formats de Daily Scrum jusqu’à ce qu’ils trouvent un format adapté à leur contexte.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Nous savons tous que le Daily Scrum ne doit pas être une mise à jour de statut pour le Scrum Master, le Delivery Lead ou le Product Owner, mais une réunion de planification pour les développeurs. Cependant, j’ai observé que lorsque les équipes n’utilisent pas d’objectif de sprint, le Daily Scrum dégénère très rapidement en une mise à jour de statut.

Pour en savoir plus sur le Framework Scrum et ses principes, rejoignez l’un de nos Scrum Workshops dans les semaines à venir.

Sam Adesoga

Sam Adesoga

Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux : Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.

Choisir l’approche de management de projet hybride par Alan Zucker

La première grande décision d’un manager de projet est le choix de l’approche et du cycle de vie.  Historiquement, ce n’était pas un problème.  L’option par défaut était prédéterminée en fonction du type de projet, des préférences organisationnelles et de l’inertie. Mais ce n’est plus le cas !

Picking the Hybrid Project Management Approach by Alan Zucker

http://www.planningplanet.com/blog/hybrid-project-management-part-3-picking-approach

La première grande décision d’un manager de projet est le choix de l’approche et du cycle de vie.  Historiquement, ce n’était pas un problème.  L’option par défaut était prédéterminée en fonction du type de projet, des préférences organisationnelles et de l’inertie.

Les projets de construction et d’ingénierie ont toujours été prédictifs. Pour les projets logiciels, des facteurs organisationnels indépendants de la volonté du manager de projet ont souvent conduit à la décision prédictive ou agile.  Les approches de projet ad hoc et maison sautaient les pratiques standard et manquaient de répétabilité ou de cohérence.

Le choix de l’approche du projet doit être réfléchi et intentionnel. Il y a plusieurs rubriques de prise de décision et aucune « bonne » réponse. Chaque projet et chaque équipe sont uniques. Il est essentiel de comprendre le contexte et d’envisager les options.

Deux facteurs prédominants influencent la décision de sélection de l’approche :

  1. Problèmes et solution.  Quelle est la nature du problème ?  Quelle approche est susceptible de mener à une solution réussie ?
  2. L’organisation et les gens. Quels sont les facteurs organisationnels à prendre en compte ?  Quelles sont les compétences et le niveau de maturité de l’équipe projet ?

Espace Problèmes et Solution

Les projets résolvent des problèmes.  La compréhension du problème fournit un contexte pour structurer l’approche de la solution.

Le cadre Cynefin de David Snowden  est un modèle de création de sens (ndlt Version française).

Il classe les problèmes en quatre types principaux :

  • Évident.  Des problèmes qui sont bien compris et qui ont des relations de cause à effet claires. Les solutions sont simples et peuvent être résolues à l’aide de procédures établies.  La standardisation améliore l’efficacité.
  • Compliqué.  Problèmes avec plusieurs solutions potentielles.  Une expertise est nécessaire pour analyser le problème et développer l’approche.  L’ingénierie et le développement de nouveaux produits en sont des exemples.
  • Complexe. Problèmes caractérisés par l’incertitude et l’ambiguïté. La solution peut émerger par itération et expérimentation.  L’exploration, l’adaptation et la collaboration sont nécessaires pour résoudre ces problèmes.
  • Chaotique.  Des problèmes intrinsèquement imprévisibles.  La situation doit être stabilisée avant que le problème puisse être résolu.
Ralph Stacey a développé un modèle similaire qui a été adapté pour décrire la complexité du projet.

Il cartographie ce que l’on sait du problème (exigences) par rapport à la solution (technologie), ce qui peut ensuite éclairer l’approche :

  • Les problèmes simples ont des exigences et des solutions claires.  Les approches prédictives ou Kanban sont efficaces.
  • Les problèmes complexes ont des exigences et des solutions moins claires. Des approches prédictives ou hybrides-prédictives utilisant la livraison incrémentale ou itérative peuvent être utilisées. Par exemple, les ingénieurs résolvent des problèmes complexes en les décomposant, puis en agrégeant la solution.

Les problèmes complexes ont des exigences et des solutions peu claires et nécessitent l’approche incrémentale et itérative d’Agile.  Les scientifiques utilisent cette approche pour expérimenter et s’adapter en fonction de ce qui a été appris.

Modèle Nieto-Rodriguez

Le professeur Antoni Nieto-Rodriguez a proposé un modèle de sélection de l’approche de projet basé sur l’évaluation des critères suivants dans chaque phase du projet.  L’approche a été présentée lors d’un webinaire organisé par le PMI en janvier 2024 et accompagnée d’un article dans la Harvard Business Review, « It’s Time to End the Battle Between Waterfall and Agile ».

Pour chaque phase ou composante importante du projet, évaluez les facteurs sur une échelle de 1 (faible) à 5 (élevée) :

  • Incertitude de la portée.  Dans quelle mesure les exigences sont-elles incertaines et instables ?
  • Adaptabilité du changement. Quelle est la probabilité que des changements critiques devront être abordés ?
  • Engagement et rétroaction des parties prenantes. Quelle est l’importance des retours et de l’engagement fréquents des clients ?
  • Délai de livraison. Quelle est l’urgence pour que les livrables soient terminés dans un court délai ?
  • Management des risques et complexité. Quel niveau de risque et quelle complexité devraient être pris en compte dans la planification et l’évaluation ?

Le score total identifie l’approche préférée :

  • Waterfall (1-9),
  • Hybride (10-21) ou
  • Agile (22-25).

Les phases ou les composants de notation prennent en charge une approche mixte, telle que l’utilisation de Waterfall pour l’infrastructure et d’Agile pour les interfaces utilisateur.

Modèle Boehm-Turner

Lors du choix de l’approche de projet, la dynamique d’équipe, les facteurs humains et les exigences du projet doivent être pris en compte. Le modèle Boehm-Turner et l’arbre de décision Disciplined Agile intègrent ces deux facteurs dans leurs rubriques de sélection d’approche.

Les professeurs Barry Boehm et Richard Turner ont mis au point un modèle adaptable et fondé sur le risque pour sélectionner l’approche de projet.  Le modèle évalue l’équipe à travers 5 catégories quantifiables :

  • Personnel.  Quelle est la maturité agile de l’équipe ?
  • Dynamisme.  Les exigences sont-elles susceptibles de changer ?
  • La culture.  L’équipe prospère-t-elle dans le chaos ou l’ordre ?
  • Taille.  Quelle est la taille de l’équipe projet ?
  • Criticité.  Le projet apporte-t-il une solution vitale ?

Le guide de pratique agile du PMI  comprenait une version modifiée du modèle qui évalue le projet à travers neuf domaines organisés en trois catégories : équipe, culture et projet.

Arbre de décision Disciplined Agile

Disciplined Agile (DA) est une boîte à outils qui prend en charge plusieurs cycles de vie agiles.  Les principales options sont basées sur l’itération (DA Agile) et sur le flux (DA Lean).  Les deux approches peuvent être renforcées par des options de livraison continue pour les équipes matures.  Bien que DA se concentre sur l’agilité, il reconnaît également que le séquentiel (prédictif) peut être le bon choix pour certains projets et équipes.

La boîte à outils de Disciplined Agile comprend un arbre de décision pour aider les équipes à choisir la meilleure approche en fonction d’une évaluation de plusieurs facteurs :

  • Compétences d’équipe.  Les compétences et la maturité sont des considérations importantes.  Le prédictif peut être le meilleur choix pour les équipes moins qualifiées ou moins matures.  La livraison continue nécessite plus de compétences.
  • Organisation et culture d’équipe. Le prédictif peut être le meilleur choix pour les projets confrontés à des contraintes rigides, car l’agilité nécessite une plus grande flexibilité et adaptabilité.
  • Nature du problème. Le prédictif est conçu pour les grandes solutions.   Agile pour les plus petites et les plus rapides.
  • Contraintes business.  Un engagement régulier des parties prenantes est essentiel pour l’agilité, mais moins important pour le mode prédictif.

Options agiles

L’agilité est un état d’esprit décrit par un ensemble de valeurs et de principes. De multiples cadres, méthodologies et boîtes à outils permettent l’agilité. Les cadres formels ont d’importants points communs et se chevauchent. En pratique, les équipes matures mélangent librement les meilleures pratiques en fonction des besoins spécifiques de leurs équipes.

Les principaux choix de cadre agile sont basés sur l’itération, le flux et la mise à l’échelle.

Basé sur l’itération.  Scrum est l’approche agile basée sur l’itération la plus couramment utilisée. De petites équipes auto-organisées apportent une valeur ajoutée à leurs clients, généralement toutes les deux semaines.  Cette approche est optimisée pour résoudre des problèmes adaptatifs complexes.

Basé sur le flux.  Kanban est l’approche basée sur les flux la plus couramment utilisée.  Son objectif principal est de fournir de petites augmentations de valeur avec le délai de livraison répétable le plus court possible.  De nombreuses équipes Scrum adoptent des principes basés sur le flux, créant une pratique hybride agile parfois appelée « Scrum-Ban ».

Échelle. Scrum et Kanban sont des pratiques d’équipe.  Les grandes organisations ont souvent besoin de programmes ou d’équipe d’équipes agiles pour mettre en œuvre des solutions à grande échelle.  Plusieurs cadres soutiennent ces efforts, notamment Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) et Scrum of Scrum.

© 2024, Alan Zucker ; Principes fondamentaux de la gestion de projet, LLC


Découvrez ou relisez les 2 précédents billets de Alan Zucker sur Hybride

  1. Management de projet hybride : Qu’est-ce que l’hybride ?
  2. Management de projet hybride : Quels changements ?

 

Ne sortez plus de nouvelles fonctionnalités dont personne ne se soucie !

L’opposé d’une usine à fonctionnalités est une équipe responsabilisée qui se concentre sur les résultats et qui est impatiente de montrer ses livrables et de s’adapter en permanence en fonction des retours des utilisateurs.

Releasing new features nobody cares about par David Pereira

https://www.mindtheproduct.com/releasing-new-features-nobody-cares-about/

Lisez un court extrait du livre de David Pereira sur la sortie de fonctionnalités dont personne ne se soucie.

Livre sur Amazon

Quelle est votre expérience lors de la sortie de nouvelles fonctionnalités ? Peut-être est-ce un peu aléatoire. Malheureusement, de nombreuses équipes tombent dans le piège de devenir des usines à fonctionnalités. Dans son livre, David Pereira, coach produit et auteur, aide les équipes à surmonter ces pièges dangereux et à créer des produits que les clients aiment vraiment.

Vous trouverez ci-dessous un court extrait de son livre sur la sortie de fonctionnalités dont personne ne se soucie. Si vous aimez ce que vous lisez, vous pouvez obtenir le livre complet ici.

Comment fonctionnent les entreprises « Feature Factory » (usines à fonctionnalités) ?

Après des mois de travail acharné et une coordination exhaustive, l’équipe produit publie enfin une nouvelle fonctionnalité. Tout le monde dans l’équipe et dans l’entreprise l’adore. La nouvelle fonctionnalité brillante est prête pour les clients, mais quelque chose d’inattendu se produit. Les clients qui interagissent avec la nouvelle fonctionnalité ne comprennent pas son objectif et n’en tirent pas de bénéfices. Confus, les clients rejettent la nouvelle fonctionnalité brillante tant appréciée des parties prenantes de l’entreprise, et inévitablement, tout le monde est frustré.

Construisez-vous des fonctionnalités dont les clients n’ont pas besoin ?

Ce n’est pas la raison d’être des équipes produit que de créer des solutions que leur entreprise adore mais dont les clients se moquent. Pourtant, cela se produit plus souvent qu’il ne le devrait. J’appelle cela un bug, pas une fonctionnalité. Comme pour tous les bogues critiques, il nécessite un correctif.

Le remède : Des équipes responsabilisées grâce à des flux collaboratifs.

Si l’usine à fonctionnalités est un bogue, qu’est-ce qui résoudrait cela ? Vous ne pouvez pas vous attendre à une solution simple, mais la promotion d’équipes autonomes avec des flux collaboratifs transformera la situation.

Marty Cagan, partenaire SVPG, définit les équipes responsabilisées comme suit :

« Les grandes équipes sont composées de gens ordinaires qui sont responsabilisés et inspirés. Ils sont habilités à résoudre des problèmes difficiles d’une manière que leurs clients aiment, tout en travaillant pour leur entreprise. Ils sont inspirés par des idées et des techniques pour évaluer rapidement ces idées afin de découvrir des solutions qui fonctionnent : elles sont précieuses, utilisables, réalisables et viables. »

Comment les méthodes de travail courantes piègent-elles ou libèrent-elles les équipes ?

Les équipes responsabilisées ont beaucoup plus de chances de créer de la valeur que les équipes d’usine à fonctionnalités. Pourtant, il n’est pas facile de responsabiliser les équipes. Pour l’instant, concentrons-nous sur les défis de la collaboration.

Flux de développement de produits coordonnés ou collaboratifs

Au fil des ans, j’ai remarqué 2 flux standard de développement de produits dans les entreprises, quel que soit leur cadre :

  1. Flux de coordination : Les membres de l’équipe passent beaucoup de temps à coordonner les activités entre eux, les parties prenantes et les autres équipes. La majeure partie de leur énergie est consacrée à l’organisation de la façon de faire le travail. Cette approche vise à éviter les erreurs et les échecs, obligeant les équipes à être rigides dans leur flux de développement. Cela devient un contrat « strict » parce que quelqu’un est blâmé lorsque quelque chose ne va pas.
  2. Flux collaboratif : Les membres de l’équipe se concentrent sur la collaboration pour utiliser leurs connaissances actuelles afin de découvrir des opportunités prometteuses. L’objectif ultime est de créer de la valeur pour les clients et l’entreprise. L’équipe est flexible dans la façon dont elle fait le travail tout en se concentrant sur la création de valeur. La confiance est à la base de l’approche collaborative. Lorsque quelque chose déraille, l’équipe prend ses responsabilités et trouve ensemble une solution.

Le flux coordonné : Une façon logique de travailler avec des résultats inattendus

Comment transformer une idée en quelque chose de précieux ? C’est l’une des questions les plus importantes pour les entreprises. Une mauvaise réponse conduit au gaspillage et à la démotivation.

Les étapes d’un flux coordonné

  1. Priorisation : Le flux de coordination commence par la hiérarchisation, visant à trouver l’idée la plus prometteuse. Cependant, c’est plus facile à dire qu’à faire car plusieurs tours de discussion auront lieu. Lorsque vous dites oui à une idée, vous dites non à de nombreuses autres, et presque aucune partie prenante de l’entreprise n’accepte facilement cette réponse
  2. Conception : La phase de conception commence une fois que vous avez défini ce sur quoi l’équipe va travailler. Le résultat est souvent un prototype haute-fidélité que les parties prenantes de l’entreprise approuvent. Cette approche est dangereuse car les ingénieurs logiciels et les clients ont tendance à être laissés à l’écart. Malheureusement, la solution devient l’objectif, et non le résultat.
  3. Test utilisateur : Après beaucoup de coordination, les parties prenantes de l’entreprise approuvent finalement la conception et il est temps de la tester avec des clients potentiels. Les résultats sont probablement biaisés car tout le monde aime déjà la solution. Malheureusement, être la proie du biais de confirmation n’est pas l’exception, mais plutôt le résultat typique. Compte tenu de leur passion pour la solution, les concepteurs de produits recherchent des signes positifs et, sans surprise, ils les trouvent. Ils peuvent accepter des ajustements mineurs de la solution, mais aucun pivot ou abandon de solution ne se produira dans cette phase.
  4. Développement : Une fois que les concepteurs de produits ont confirmé que le prototype haute-fidélité a du sens pour les utilisateurs finaux, il est temps de développer la solution. Les concepteurs de produits jettent les spécifications par-dessus le mur et espèrent que les ingénieurs logiciels font le bon travail. Bien sûr, il est peu probable que les ingénieurs logiciels accueillent la solution à bras ouverts, car ils n’ont pas participé aux étapes précédentes. Malgré cela, c’est à eux de transformer le prototype haute-fidélité en une solution fonctionnelle.
  5. Lancement : Compte tenu de la quantité de coordination nécessaire, il faut des mois pour transformer une idée en solution. Vous ne devriez pas être surpris quand quelque chose prend six mois. Chaque phase est strictement définie et comporte de nombreuses étapes pour assurer une solution parfaite à la fin de celle-ci. Pourtant, quelque chose d’inattendu se produit lorsque vous lancez la solution. Malgré tout l’enthousiasme interne et l’amour pour la nouvelle solution sophistiquée, les clients ne s’y intéressent pas, et vous ne savez pas pourquoi.

Ce qui me choque, ce n’est pas de me retrouver dans cette situation tragique. J’y suis allé plus de fois que je ne peux compter, mais j’ai appris la leçon. La question est de savoir ce que vous faites après avoir été confronté à un résultat indésirable. La réponse la plus courante n’a guère de sens pour moi. Revenez à la hiérarchisation, choisissez une autre idée et recommencez. Lorsque vous suivez la même approche, il y a de fortes chances que vous soyez à nouveau confronté aux mêmes résultats. Le flux de coordination oblige les équipes à se concentrer sur les résultats plutôt que sur les résultats, ce qui les réduit au rang d’usines.

9 idées sur 10 échoueront

Notre taux de réussite est pire que ce que nous pouvons imaginer. Regardez les start-up : 90% d’entre elles ne tiennent pas plus de cinq ans. Les idées subissent à peu près le même sort. Curieusement, cela passe inaperçu car les équipes investissent beaucoup de temps à trouver comment réduire le temps de développement. Je vois de la valeur dans cette affaire, bien que je perçoive une autre question comme plus urgente : « A quelle vitesse pouvez-vous laisser tomber les mauvaises idées ? »

Nous supposons que nos idées sont bonnes, mais la réalité nous montre le contraire. Pourtant, nous insistons pour suivre la même approche à plusieurs reprises. Pas étonnant que nous soyons confrontés à des résultats indésirables.

Un bon management de produit nécessite de s’adapter en apprenant. C’est OK de se tromper. Il n’est pas bon d’ignorer la réalité. La collaboration plutôt que la coordination est le principe qui peut vous sortir de ce piège. Au lieu de rendre votre flux de développement rigide et complexe, vous bénéficierez d’une simplicité et d’une flexibilité accrues. Explorons une autre méthode de travail qui augmente les chances de générer de la valeur plus rapidement.

Flux collaboratif : Une méthode de travail simple qui apporte des résultats exceptionnels.

Personne ne mérite de perdre du temps. Après de nombreuses années d’expérience, j’ai appris que les échecs sont inévitables. Au lieu d’ajouter des étapes pour prévenir les échecs, il est plus logique d’identifier et d’abandonner rapidement les mauvaises idées. Contrairement au flux coordonné, le flux collaboratif se concentre sur des itérations plutôt que sur des phases.

Les étapes d’un flux collaboratif

  1. Évaluez : Le début d’un flux collaboratif est le même que pour un flux coordonné. Vous avez plein d’idées, et tout le monde veut que tout soit terminé d’hier. L’astuce n’est pas d’identifier les idées les plus prometteuses dès le départ, mais plutôt de les évaluer toutes et de laisser tomber celles qui ne conviennent pas. Laisser tomber des idées vous donne de la liberté parce que vous avez moins d’attentes à gérer.
  2. Apprenez : L’itération d’apprentissage commence par des idées adaptées à votre stratégie, mais cela ne signifie pas qu’il faille passer directement à la mise en œuvre. Vous devriez laisser tomber les idées que vos clients ne désirent pas, que l’entreprise ne peut pas soutenir, que vous n’avez pas la technologie pour développer ou qu’il est contraire à l’éthique de poursuivre. Restez simple et posez les questions suivantes sur chaque idée restante :
  • À quel point les clients veulent-ils ceci ? (Désirabilité)
  • Quels sont les bénéfices pour l’entreprise ? (Fiabilité)
  • Dans quelle mesure pouvons-nous le faire ? (Faisabilité)
  • À quel point est-il bien de le faire ? (Éthique)
  1. Expérimentez : Après avoir compris les aspects clés de vos idées, il est temps de mener des expériences plus robustes. Vous voulez tester les solutions qui peuvent donner les résultats potentiels. Il est essentiel d’explorer quelques alternatives et de s’en tenir aux plus prometteuses. Il est trop courant de choisir une solution et de se lancer à fond. Je vous décourage de suivre cette voie, car elle augmente rapidement l’engagement. En tant qu’êtres humains, plus nous sommes investis dans quelque chose, plus nous y investissons volontiers.
  2. Déployez : Les idées qui survivent à l’itération de l’expérience sont les plus importantes. Dans l’itération précédente, vous avez construit pour apprendre. Maintenant, vous créez pour évoluer. Il est fondamental de rembourser la dette technologique avant de mettre la solution à la disposition de l’ensemble de votre public ou de passer à votre prochaine opportunité

Principaux points à retenir

  • La première étape pour libérer votre équipe consiste à examiner votre situation actuelle. Comprendre la dynamique peut révéler des opportunités pour simplifier votre flux de développement.
  • Les symptômes d’une usine à fonctionnalités comprennent l’absence d’objectifs, l’obsession de la production, la fourniture de solutions qui ne résolvent aucun problème, une direction peu claire, une réticence à laisser tomber des idées et un manque d’attention aux résultats. L’opposé d’une usine à fonctionnalités est une équipe responsabilisée qui se concentre sur les résultats et qui est impatiente d’examiner ses livrables et de s’adapter en permanence.
  • Plus vous vous rapprochez d’un flux de développement coordonné, plus il faut de temps pour générer de la valeur et plus vous créez de déchets. Les flux coordonnateurs transforment involontairement les plans en objectifs.
  • Plus vous vous rapprochez d’un flux de développement collaboratif, plus tôt vous créez de la valeur et moins vous produisez de déchets. La collaboration vous aide à adapter vos plans pour atteindre vos objectifs lorsque la réalité rend votre plan obsolète.
  • Lorsque vous comprenez parfaitement le flux de développement d’un produit, vous pouvez favoriser les changements étape par étape. La première étape consiste à collaborer avec les parties prenantes de l’entreprise et les membres de l’équipe pour reconnaître ce qui est inutilement complexe. Équipé de cette compréhension, vous pouvez obtenir du soutien et collaborer pour simplifier votre travail.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM